MTU, MSS и fragmentation: как они ломают сеть и как это диагностировать

Проблемы с сетью не всегда выглядят как «сервер недоступен». Иногда сайт просто открывается медленно, а API-запросы подвисают без видимой причины. Очень часто корень проблемы — неправильно настроенный MTU, сломанный MSS или фрагментация пакетов.

Разберёмся, что это такое и как диагностировать такие ситуации.

Что такое MTU

MTU (Maximum Transmission Unit) — это максимальный размер пакета, который можно передать через сетевой интерфейс без фрагментации.

Стандартное значение для Ethernet:

1500 байт

Если пакет больше MTU, он:

либо фрагментируется,
либо отбрасывается (если установлен флаг DF — Don't Fragment).

Что такое MSS

MSS (Maximum Segment Size) — максимальный размер полезной TCP-нагрузки.

Формула простая:

MSS = MTU - IP header - TCP header

Обычно:

1500 - 20 - 20 = 1460 байт

MSS согласовывается при TCP handshake через опцию в SYN-пакете.

Если MSS больше реального допустимого размера в пути — начинаются проблемы.

Что такое фрагментация

Фрагментация возникает, когда пакет больше MTU промежуточного узла.

Есть два сценария:

1. IPv4-фрагментация

Маршрутизатор может разбить пакет на части.

Минусы:

рост latency;
увеличение нагрузки на CPU;
если потеряется один фрагмент — теряется весь пакет.

2. Path MTU Discovery (PMTUD)

Если установлен флаг DF, пакет не фрагментируется. Вместо этого отправителю возвращается ICMP-сообщение "Fragmentation needed".

Но если ICMP блокируется firewall'ом — возникает так называемая:

Black Hole MTU problem

Пакеты просто «исчезают», а соединение зависает.

Типичные симптомы проблем с MTU

HTTPS работает, но большие POST-запросы зависают
VPN подключается, но сайты не открываются
API отвечает медленно только из определённых сетей
TCP-сессия устанавливается, но данные не передаются

Особенно часто это встречается при:

использовании VPN
PPPoE
GRE / IPsec туннелях
Docker / Kubernetes overlay-сетях

Потому что каждый уровень инкапсуляции уменьшает реальный MTU.

Как проверить MTU

Проверить MTU интерфейса:

ip link show

Проверить путь до хоста с DF-флагом:

ping -M do -s 1472 example.com

1472 = 1500 - 28 байт заголовков ICMP+IP

Если пакет не проходит — уменьшаем размер, пока не найдём рабочий.

Это и есть реальный Path MTU.

Диагностика через tcpdump

Смотрим ICMP-сообщения:

tcpdump -i eth0 icmp

Если видим:

fragmentation needed and DF set

значит проблема именно в MTU.

Также можно проверить MSS в SYN-пакете:

tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0'

MSS clamping — практическое решение

Если PMTUD ломается (например, ICMP режется), используют MSS clamping.

В iptables:

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

Это автоматически уменьшает MSS до безопасного значения.

Особенно полезно для:

VPN-шлюзов
Kubernetes ingress
серверов за NAT

MTU и контейнеры

В Docker overlay-сетях реальный MTU часто:

1450 или меньше

Проверить можно:

docker network inspect bridge

Неправильный MTU внутри контейнера — частая причина странных сетевых лагов.

Практический чеклист

Проверить MTU интерфейса
Проверить Path MTU через ping с DF
Посмотреть ICMP через tcpdump
Проверить MSS в SYN-пакете
При необходимости включить MSS clamping

Итог

MTU и MSS — это низкоуровневые параметры, которые редко трогают, но которые могут полностью сломать сеть.

Если у вас «необъяснимые» зависания TCP или странные лаги под нагрузкой — почти всегда стоит проверить MTU.

В высоконагруженной инфраструктуре, с VPN, контейнерами и туннелями, контроль MTU — обязательная часть диагностики.

Понимание этих механизмов позволяет находить проблемы, которые иначе выглядят как «магия сети».