Народный

Сеть

MTU / Path MTU Discovery

MTU — максимальный размер кадра, который интерфейс отправляет без фрагментации. PMTUD — механизм автоматического определения наименьшего MTU по всему пути. Кривая настройка MTU — классическая причина «работает, но медленно» в VPN.

Что это

MTU (Maximum Transmission Unit) — максимальный размер L2-кадра в байтах, который сетевой интерфейс способен передать одной порцией. Для Ethernet стандарт — 1500 байт. Если IP-пакет больше MTU, он либо фрагментируется (если флаг DF=0), либо отбрасывается с ICMP-сообщением «Fragmentation Needed» (если DF=1).

Path MTU Discovery (PMTUD, RFC 1191 для IPv4, RFC 8201 для IPv6) — механизм определения наименьшего MTU по всему пути от source до destination. Хост отправляет первые пакеты с DF=1 и максимальным MTU; промежуточные роутеры с меньшим MTU возвращают ICMP «Fragmentation Needed» с указанием своего MTU; хост уменьшает размер и пробует снова.

Почему VPN-туннели обязательно уменьшают MTU

Туннелирование добавляет overhead: каждый исходный пакет оборачивается во внешний IP + UDP + протокольный заголовок. Если внутри туннеля передавать пакеты с MTU=1500, после оборачивания они превысят 1500 на физическом канале и будут фрагментированы (медленно, теряется производительность) либо просто дропнуты.

Стандартные значения:

ПротоколТуннельный MTUOverhead
WireGuard (IPv4)142080 байт
WireGuard (IPv6)1400100 байт
OpenVPN (UDP)1450~50 байт
IPSec ESP (tunnel mode, NAT-T)1400~80–100 байт
VLESS Reality поверх TCP1400 (рекомендация)TCP MSS clamping до ~1360
Hysteria 2 / QUIC1350–1400UDP+QUIC header

WireGuard ставит 1420 по умолчанию именно потому, что 1500 − 20 (внешний IP) − 8 (UDP) − 32 (WG header + nonce + auth tag + padding) ≈ 1420.

Black hole — самая частая патология

PMTUD полагается на ICMP-сообщения, но многие провайдеры (особенно мобильные) фильтруют ICMP. В результате хост шлёт большие пакеты с DF=1, они дропаются где-то посередине пути, никаких ICMP не возвращается, и хост думает, что соединение жить, просто всё «зависло». Это и есть «PMTUD black hole» — соединение устанавливается (handshake маленькими пакетами проходит), но как только начинается передача больших порций — всё встаёт.

Симптом: TCP-соединение успешно, curl качает страницу до определённого размера ответа и виснет; SSH открывается, но ls -la в большом каталоге не доходит.

Лечение — MSS clamping

Простейший fix: уменьшить TCP MSS (Maximum Segment Size) на интерфейсе VPN. MSS — это L4-аналог MTU: «не присылай мне сегменты больше N байт». Уменьшение MSS заставляет другую сторону сразу слать маленькие пакеты, минуя проблему PMTUD.

На Linux:

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

Или жёстко:

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --set-mss 1360

На MikroTik (ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn action=change-mss new-mss=clamp-to-pmtu).

В WireGuard на роутерах OpenWrt — option mtu '1380' + автоматический MSS clamp в стоковом fw4.

Почему это важно для пользователя VPN

В 2026 в РФ MTU-проблемы — массовая жалоба у пользователей мобильного VPN:

  • VLESS Reality + ТСПУ + 4G МТС. Сочетание трёх факторов: TLS-handshake большой, ТСПУ добавляет искусственную потерю, мобильный NAT режет ICMP. Симптом — «сайт открывается, но картинки не грузятся». Решение — снизить MTU клиента до 1280 (IPv6 минимум, всегда работает).
  • WireGuard через PPPoE. PPPoE-overhead 8 байт → MTU физики 1492, не 1500. WireGuard ставит 1420, что слишком много. Снизить до 1412.
  • GRE/IPSec через CGNAT. Двойное оборачивание + NAT-T → MTU должен быть 1300–1350.

Универсальный подход: если соединение «висит» — попробуйте ping -M do -s 1372 youtube.com (Linux) и снижайте размер на 16 байт, пока пинг не пойдёт. Это и есть ваш безопасный MTU + 28 (заголовки ICMP).

Связанные термины

WireGuard, OpenVPN, IPSec ESP, VLESS Reality — у каждого свой overhead. NAT traversal — relay-серверы (TURN, DERP) часто имеют ещё меньший MTU из-за двойного туннелирования.

Источники

← все термины смотреть рейтинг VPN →