LINUX.ORG.RU
решено ФорумAdmin

wireguard tls handshake problem

 , , ,


0

1

Доброго времени суток.

Имеем следующее ноутбук -> wifi -> router -> wireguard-gw -> wireguard server -> internet

При попытке открыть некоторые хосты с ноутбука получаю следующее:

curl -v https://rutracker.org
*   Trying 195.82.146.214:443...
* Connected to rutracker.org (195.82.146.214) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /data/data/com.termux/files/usr/etc/tls/cert.pem
  CApath: /data/data/com.termux/files/usr/etc/tls/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: Connection reset by peer in connection to rutracker.org:443
* Closing connection 0
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to rutracker.org:443

Что пробовал:

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380

Без изменений. С самой машины с wg все отстреливает как надо.

Конфиги:

Server

[Interface]
Address = 10.100.100.10/24
SaveConfig = false
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; iptables -A FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; iptables -D FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
ListenPort = 51820
PrivateKey = 


[Peer]
PublicKey = 
AllowedIPs = 10.100.100.19/32, 10.66.1.254/24

Client

[Interface]
Address = 10.100.100.19/24
PrivateKey = 
DNS = 1.1.1.1, 1.0.0.1

PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o ens18 -j MASQUERADE; iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o ens18 -j MASQUERADE; iptables -D FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

[Peer]
PublicKey = 
Endpoint = :51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25
Ответ на: комментарий от zerofun

Добавлю tcpdump неудачного хендшейка.

14:05:04.348862 IP (tos 0x0, ttl 62, id 7286, offset 0, flags [DF], proto TCP (6), length 60)
    10.66.1.182.44412 > rutracker.org.https: Flags [S], cksum 0x26bb (correct), seq 2248750446, win 65535, options [mss 1380,sackOK,TS val 1455554049 ecr 0,nop,wscale 9], length 0
14:05:04.434914 IP (tos 0x0, ttl 54, id 0, offset 0, flags [DF], proto TCP (6), length 48)
    rutracker.org.https > 10.66.1.182.44412: Flags [S.], cksum 0x8d83 (correct), seq 1876197590, ack 2248750447, win 14600, options [mss 1460,nop,wscale 8], length 0
14:05:05.938951 IP (tos 0x0, ttl 54, id 0, offset 0, flags [DF], proto TCP (6), length 48)
    rutracker.org.https > 10.66.1.182.44412: Flags [S.], cksum 0x8d83 (correct), seq 1876197590, ack 2248750447, win 14600, options [mss 1460,nop,wscale 8], length 0
14:05:07.939014 IP (tos 0x0, ttl 54, id 0, offset 0, flags [DF], proto TCP (6), length 48)
    rutracker.org.https > 10.66.1.182.44412: Flags [S.], cksum 0x8d83 (correct), seq 1876197590, ack 2248750447, win 14600, options [mss 1460,nop,wscale 8], length 0
14:05:13.788279 IP (tos 0x0, ttl 62, id 7295, offset 0, flags [DF], proto TCP (6), length 552)
    10.66.1.182.44412 > rutracker.org.https: Flags [.], cksum 0x5ae5 (correct), seq 1:513, ack 1, win 172, length 512
14:05:13.874037 IP (tos 0x0, ttl 54, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    rutracker.org.https > 10.66.1.182.44412: Flags [R], cksum 0xaddc (correct), seq 1876197591, win 0, length 0
zerofun
() автор топика
Ответ на: комментарий от Sorcus

Да, я прочитал всю твою тему и именно после нее стал копать в сторону mss. Жаль, что tcpdump’ы протухли, очень хочется на них взглянуть.

zerofun
() автор топика
Ответ на: комментарий от zerofun

Тех логов у меня уже нет.
Глянул сейчас на роутере в фаервол и там в цепочках forward только iif br-lan oif wg0 tcp flags syn tcp option maxseg size set rt mtu стоит для правки mtu.
Так что я не знаю, почему аналогичное правило для iptables не работает…
И вот ещё относительно mtu.
На роутере у меня mtu выставлен 1408 для интерфейса wg0.
На сервере mtu выставлен в 1420 для интерфейса wg0.

Sorcus
()
Последнее исправление: Sorcus (всего исправлений: 1)
Ответ на: комментарий от Sorcus

Самое интересное: у меня дома крутится 2 dell poweredge r720 с vSphere и Proxmox VE. Из любого контейнера хендшейк отстреливает за секунду. Хендшейк так же мгновенно отстреливает и с компьютера на windows который кабелем воткнут в свитч. Однако, есть второй компьютер который точно также воткнут кабелем в тот же самый свитч и на нем хендшейк не проходит совсем как и на всех клиентах беспроводной сети. На данный момент уже даже не знаю в какую сторону можно продолжать копать. На vlan это все не разбито и находится в одной подсети. С помощью сниффера посмотрел, что pmtu выставляется корректный в зависимости от изменения оного в iptables на виртуальной машине с wireguard.

zerofun
() автор топика

Зачем в клиенстком конфиге эти правила iptables?

anonymous
()

Минимум

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380

Выставляется в таблице mangle а не в filter
iptables -t mangle -A FORWARD...
И попробуйте ещё вручную занизить --set-mss 1380 т.е. меньше 1380.

anc ★★★★★
()
Ответ на: комментарий от bhfq

Скриптец использовался, должного результат не дал.

Спасибо за рекомендации по iptables, сейчас попробую.

Что еще было сделано:

  1. Смена ОС клиента на debian 10 + nftables
  2. Добавление следующего на стороне сервера
iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; iptables -A INPUT -s 10.100.100.0/24 -p udp -m udp --dport 53 -m conntrack --ctstate NEW -j ACCEPT;
zerofun
() автор топика
Ответ на: комментарий от zerofun

Дополню: сменил сервер и провайдера. МТУ выставил 1280 и теперь каждый раз проходит хендшейк но с задержкой около 10 - 15 секунд.

zerofun
() автор топика
Ответ на: комментарий от zerofun

Проблема решена создание схожего правила на микротике.

/ip firewall mangle add chain=postrouting action=change-mss new-mss=clamp-to-pmtu passthrough=yes tcp-flags=syn,rst protocol=tcp out-interface=pppoe-out log=no

/ip firewall mangle add chain=postrouting action=change-mss new-mss=clamp-to-pmtu passthrough=yes tcp-flags=syn,rst protocol=tcp out-interface=bridge_lan log=no

Всем спасибо за участие 8)

zerofun
() автор топика
18 ноября 2020 г.
Ответ на: комментарий от zerofun

можно примерчик правила для iptables ?

тоже самое: начали ловить хедшейки когда один из ДЦ включил ddos protection который дропает UDP а как известно наш wireguard использует UDP, до включения ddos защиты работало все нормально на MTU 1400 и с авто mss

dabster
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.