MTU и фрагментация

Разработчик развёртывает сервис за VPN. Маленькие запросы работают нормально. Большие — загрузка файла, большой JSON-payload — тихо зависают. Никакого сообщения об ошибке. Сервер не получает ничего. Проблема — несоответствие размера пакета максимуму который может нести линк, плюс firewall блокирует сообщение об ошибке которое исправило бы это.

Что такое MTU

Maximum Transmission Unit (MTU) — наибольший IP-пакет (заголовок + payload) который линк может нести без фрагментации. Стандартный MTU Ethernet — 1500 байт. Разные технологии линков имеют разные MTU:

Path MTU — наименьший MTU на всём пути от источника до назначения. Пакет должен вписываться в Path MTU, иначе он будет дропнут где-то на пути.

Фрагментация IPv4

Когда IPv4-пакет приходит на роутер у которого исходящий линк имеет меньший MTU, роутер разбивает пакет на фрагменты:

1. Роутер копирует поле identification во все фрагменты.
2. Устанавливает флаг «more fragments» на всех кроме последнего.
3. Каждый фрагмент несёт смещение внутри исходного пакета.
4. Назначение переcобирает все фрагменты с одним ID + source IP.

Фрагментация дорогостоящая: потеря любого фрагмента вынуждает повторно передавать всю исходную датаграмму. Каждый фрагмент маршрутизируется независимо. Фрагментация на роутерах добавляет задержку и CPU-работу.

Бит DF (Don’t Fragment). Когда установлен в поле Flags IPv4-заголовка, роутер не может фрагментировать пакет. Если пакет не вписывается в MTU исходящего линка, роутер дропает его и шлёт ICMP «fragmentation needed» обратно к источнику. Это обеспечивает PMTUD.

IPv6 — без фрагментации роутерами

IPv6-роутеры никогда не фрагментируют. Если пакет слишком большой, роутер дропает его и шлёт ICMPv6 «Packet Too Big» обратно к отправителю. Отправитель должен уменьшить размер пакета и повторно передать. Это переносит сложность на отправителя и упрощает обработку роутером.

Отправители IPv6 обязаны поддерживать минимальный MTU 1280 байт (они всегда могут отправлять 1280-байтные пакеты к любому назначению). Path MTU Discovery обязателен для IPv6.

Path MTU Discovery (PMTUD)

PMTUD обнаруживает наименьший MTU на пути. Отправитель устанавливает DF=1 (IPv4) и шлёт полноразмерные пакеты. Когда роутер дропает один потому что он слишком большой, он шлёт ICMP «packet too big» (или «fragmentation needed») обратно. Отправитель уменьшает размер пакета и повторяет попытку.

PMTUD black holes возникают когда firewall или middlebox тихо дропает ICMP. Отправитель никогда не получает сигнал «packet too big». Он продолжает передавать полноразмерные пакеты, которые продолжают дропаться. Соединение зависает — маленькие запросы работают (они вписываются), большие зависают навсегда.

Симптомы PMTUD black hole:

• Маленькие HTTP-запросы успешны; большие payload’ы или файлы зависают.
• ping -M do -s 1450 destination завершается без ответа.
• traceroute показывает путь нормально, но TCP-сессии зависают при больших размерах.

Решения для PMTUD black holes

TCP MSS clamping: MSS (Maximum Segment Size) согласовывается в TCP handshake. Роутер на пути (VPN-шлюз, PPPoE-терминатор) перезаписывает опцию MSS в SYN-пакетах до безопасного значения (например 1452 = 1500 - 20 IP - 20 TCP - 8 PPPoE). Эндпойнты никогда не согласовывают размер сегмента который создал бы oversized пакет. Это прагматичное исправление для большинства VPN и PPPoE развёртываний.

PLPMTUD (RFC 4821): Packetisation-Layer PMTUD. Отправитель зондирует всё большими TCP-сегментами; если зонд не получает ACK — отступает. Вообще не полагается на ICMP — устойчив к ICMP-фильтрации. Современные стеки по умолчанию используют PLPMTUD.

Открытые ICMP-политики: разрешить ICMP type 3 (destination unreachable) и ICMPv6 type 2 (packet too big) через firewall’ы. Фильтрация всего ICMP — распространённая но неверная «политика безопасности» которая ломает PMTUD и traceroute.