MTU и MSS в туннеле

MTU канала

Или своё значение

Внешняя сеть

По какому протоколу идёт сам туннель.

Что накручено поверх

WireGuard +60 байт · 20/40 IP + 8 UDP + 16 заголовок + 16 тег Poly1305IPsec ESP, AES-GCM (туннель) +54 байт · 20/40 IP + 8 SPI/Seq + 8 IV + 16 ICV + 2 хвостIPsec ESP, AES-CBC+SHA1 (туннель) +73 байт · 20/40 IP + 8 SPI/Seq + 16 IV + 12 ICV + до 17 выравниваниеIPsec ESP за NAT (UDP 4500) +62 байт · то же, что AES-GCM, плюс 8 байт UDPGRE +24 байт · 20/40 IP + 4 GREGRE поверх IPsec +78 байт · 24 GRE + 54 ESP AES-GCMVXLAN +50 байт · 20/40 IP + 8 UDP + 8 VXLAN + 14 внутренний EthernetGeneve +50 байт · как VXLAN, без опцийPPPoE +8 байт · 6 PPPoE + 2 PPP — отсюда классические 1492L2TP/IPsec +90 байт · 54 ESP + 8 UDP + 12 L2TP + 4 PPP + 14 EthernetOpenVPN UDP (AES-GCM) +53 байт · 20/40 IP + 8 UDP + 5 opcode/ID + 4 IV + 16 тег6in4 / SIT +20 байт · IPv6 внутри IPv4, только заголовок IPv4Метка VLAN 802.1Q +4 байт · кадр растёт до 1518 — MTU обычно не меняется, но канал должен это позволятьQinQ (два тега) +8 байт · две метки 802.1QМетка MPLS +4 байт · по 4 байта на метку в стеке

Слой	Байт	Из чего складывается
WireGuard	+60	20/40 IP + 8 UDP + 16 заголовок + 16 тег Poly1305
Итого	60	1500 − 60 = 1440

Куда вписать полученные числа

WireGuard: MTU = 1440

nginx / haproxy за туннелем: clamp MSS до 1400

iptables: -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400

Почему это вообще болит

Пакет, который не влезает в MTU канала, должен быть либо фрагментирован, либо отброшен с сообщением ICMP «нужна фрагментация». Многие сети режут ICMP целиком, и тогда получается фирменная картина: пинг идёт, страницы открываются, а большие ответы — картинки, загрузки, SSH с длинным выводом — виснут насмерть. Лечится не увеличением MTU, а его уменьшением: ставят MTU туннеля и заодно clamp MSS, чтобы TCP сам не просил больше, чем пролезает.