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

Настройка MTU для Wireguard.

 , ,


2

1

На клиенте и сервере установлен Wireguard.
И там и там был выставлен MTU в 1412, т.к. все значения выше не пропускают нормально трафик.
Выглядит это так, что сайты вообще не открываются. Никакие.
1. Почему работает только со значением 1412 (по дефолту WG ставит 1420, но оно не работает).
2. Если eth0 с MTU 1500, то wg0 должен быть со значением меньшим, чем eth0?
И на сколько меньшим? 1500 минус дополнительный размер заголовка от Wireguard? 

[root@localhost ~]# ip a
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
3: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1412 qdisc noqueue state UNKNOWN group default qlen 1000

3. В схеме ISP провайдер <-> Router with PPPoE <-> OpenWRT with Wireguard <-> Client почему-то некоторые сайты не открываются.
Трафик зависает на этапе инициализации TLS.
Вот пример трафика, пойманного TCPdump-ом в момент открытия сайта. 
11:17:38.080131 IP (tos 0x0, ttl 64, id 43434, offset 0, flags [DF], proto TCP (6), length 60)
    10.0.1.177.40572 > 52.71.38.59.443: Flags [S], cksum 0x5899 (correct), seq 2150728512, win 64240, options [mss 1460,sackOK,TS val 999534342 ecr 0,nop,wscale 7], length 0
11:17:38.214844 IP (tos 0x0, ttl 238, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    52.71.38.59.443 > 10.0.1.177.40572: Flags [S.], cksum 0xb1a6 (correct), seq 2270306161, ack 2150728513, win 28960, options [mss 1460,sackOK,TS val 768039974 ecr 999534342,nop,wscale 8], length 0
11:17:38.214884 IP (tos 0x0, ttl 64, id 43435, offset 0, flags [DF], proto TCP (6), length 52)
    10.0.1.177.40572 > 52.71.38.59.443: Flags [.], cksum 0x4f17 (correct), seq 1, ack 1, win 502, options [nop,nop,TS val 999534477 ecr 768039974], length 0
11:17:38.224076 IP (tos 0x0, ttl 64, id 43436, offset 0, flags [DF], proto TCP (6), length 569)
    10.0.1.177.40572 > 52.71.38.59.443: Flags [P.], cksum 0xed75 (correct), seq 1:518, ack 1, win 502, options [nop,nop,TS val 999534486 ecr 768039974], length 517
11:17:38.358734 IP (tos 0x0, ttl 238, id 17205, offset 0, flags [DF], proto TCP (6), length 52)
    52.71.38.59.443 > 10.0.1.177.40572: Flags [.], cksum 0x4e65 (correct), seq 1, ack 518, win 118, options [nop,nop,TS val 768040010 ecr 999534486], length 0
11:17:38.638119 IP (tos 0x0, ttl 238, id 17210, offset 0, flags [DF], proto TCP (6), length 1310)
    52.71.38.59.443 > 10.0.1.177.40572: Flags [P.], cksum 0x5b4a (correct), seq 4345:5603, ack 518, win 118, options [nop,nop,TS val 768040080 ecr 999534486], length 1258
11:17:38.638189 IP (tos 0x0, ttl 64, id 43437, offset 0, flags [DF], proto TCP (6), length 64)
    10.0.1.177.40572 > 52.71.38.59.443: Flags [.], cksum 0xa0cc (correct), seq 518, ack 1, win 502, options [nop,nop,TS val 999534900 ecr 768040010,nop,nop,sack 1 {4345:5603}], length 0
А вот пример того, как это выглядит в Curl 
archlinux% curl --verbose --head https://appcrawler.com --raw
*   Trying 2606:4700:30::6812:3e42...
* TCP_NODELAY set
* Connected to appcrawler.com (2606:4700:30::6812:3e42) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to appcrawler.com:443 
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to appcrawler.com:443
Доступ к некоторым сайтам удаётся «пофиксить» правкой MTU, но некоторые не открываются даже после правки MTU.
Может кто-нибудь сталкивался с подобным? И как это починить?
Если это MTU, то каким должно быть значение на каждом узле? Спасибо.

★

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

Говорят, что 1380 может помочь.

athost ★★★★★
()

1. Нащупать реальный mtu можно пингом с DF флагом

2. В твоем случае это Eth MTU - (ip header, tcp header, pppoe header). 1500 - (20 + 20 + 8) = 1452. Но могут быть нюансы у каждого вендора. Поэтому смотри п.1

najar ★
()

Так-с. Ну с MTU вроде более-менее понятно. Спасибо.
Но вот по 3-му вопросу пока не могу разобратся.
Вот более подробный выхлоп TCPdump (зависание при инициализации TLS).
Места, где зависает, выделил звёздочками.
https://gist.github.com/MrSorcus/f8fe69227a323817af5471e2990e38b7
На лор не влезает сообщение, поэтому залил на Gisthub.
Зависание происходит на строках 134 и 148.
А вот лог TCPdump к этому же сайту спустя несколько попыток (успешный коннект).
https://gist.github.com/MrSorcus/9b6334a950fbee9f7ec0d23a7adeb1f0
Т.е. ошибка TLS подключения не постоянна.
Иногда сайт открывается, а иногда нет.
Быть может кто-нибудь подскажет, в какую сторону копать с подобными ошибками?

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

Осознанно. Уже несколько лет таким образом сижу по IPv6 через Wireguard на ноутбуке.
Но проблема началась именно после установки Wireguard на OpenWRT.
Проверил, по IPv4 открывает без проблем.
Как только 4 заменяю на 6, начинаются проблемы.
Сейчас подключился к роутеру от дом.ру и запустил Wireguard на ноуте.
Проверка v4 и v6 к этому адресу происходит без проблем.
Но как только отключаю Wireguard на ноуте и подключаюсь к роутеру OpenWRT с Wireguard, который подключён к роутеру дом.ру, начинаются проблемы.

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

MSS только через фаервол можно править?
И данное правило прописывать на роутере или сервере? Или и там и там?
Спасибо.

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

лучше на маршрутизаторах

смысл имеет править в местах, где присутствуют туннельные интерфейсы, т.к. это наиболее простой и логичный вариант.

iptables -t mangle --append POSTROUTING -o wg+ -j TCPMSS --clam-mss-to-pmtu

Z0termaNN ★
()

Большое спасибо всем за подробное объяснение по поводу MTU / MSS.
Для nftables правило можно найти здесь - https://wiki.nftables.org/wiki-nftables/index.php/Mangle_TCP_options
nft list ruleset 

table ip filter {
        chain forward {
                type filter hook forward priority 0; policy accept;
                oif "wg0" tcp flags syn tcp option maxseg size set 1372
        }
}
table ip6 filter {
        chain forward {
                type filter hook forward priority 0; policy accept;
                oif "wg0" tcp flags syn tcp option maxseg size set 1372
        }
}
Может не совсем корректно сделал, но так хотя бы работает сейчас.

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

С правилом oif "wg0" tcp flags syn tcp option maxseg size set 1372 всё-равно могут быть проблемы.
Нужно правило oif "wg0" tcp flags syn tcp option maxseg size set rt mtu.
Но оно не применится, т.к. в OpenWrt опция NETFILTER_ADVANCED выключена.
После включения этой опции при компиляции ядра данное правило будет работать.
См. Проблема с nftables на OpenWrt.

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