Сообщить об ошибкеКороткий ответ
MTU задаёт максимальный размер IP-пакета без фрагментации. В туннелях служебные заголовки уменьшают доступный MTU: крупные пакеты могут теряться при блокировке ICMP, поэтому проверяют Path MTU Discovery и настраивают меньший MTU или MSS clamping.
Как это работает подробнее
Когда пакет превышает MTU промежуточного канала и установлен флаг Don't Fragment (DF), маршрутизатор обязан отбросить пакет и отправить обратно ICMP Fragmentation Needed; механизм Path MTU Discovery (PMTUD) должен использовать этот ICMP-ответ, чтобы отправитель уменьшил размер последующих пакетов — но если этот ICMP-пакет заблокирован файрволом где-то на пути, отправитель никогда не узнаёт о проблеме и соединение просто зависает на передаче больших данных (классический симптом: SSH-сессия устанавливается и держит маленькие команды, но зависает на cat большого файла или scp).
Пример кода
ping -M do -s 1472 example.com # 1472 + 28 байт заголовков = 1500
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtuЧто использовать на практике
- Практика. при туннелях MTU на интерфейсе туннеля нужно явно занижать (например, 1400 вместо 1500) с учётом накладных расходов инкапсуляции, либо корректировать MSS через iptables (TCPMSS clamping) на границе туннеля, чтобы TCP-соединения сразу согласовывали меньший размер сегмента и не полагались на потенциально заблокированный ICMP.
Подводные камни
- Риск. Частая ошибка — диагностировать такую проблему только обычным ping (с маленькими пакетами по умолчанию), который проходит нормально, не используя ping с увеличенным размером пакета и флагом запрета фрагментации для поиска реального рабочего MTU.