PMTUD_MSS_BLACKHOLE Сетевое оборудование и VPN

Траблшутинг MTU и MSS: решение проблем с фрагментацией, зависанием SSL и SSH

Обновлено: 25.08.2026 · Официальная документация ↗

Утилита ping работает стабильно, но сессии SSH зависают сразу после авторизации при выполнении ls -la или cat.
HTTPS-соединения зависают на этапе передачи сертификата (TLS Server Hello / Certificate Exchange).
Сетевые тоннели (IPsec, GRE, WireGuard, VXLAN) теряют большие пакеты данных.
В дампе трафика отсутствуют сообщения ICMP Type 3 Code 4 (Destination Unreachable, Fragmentation Needed and DF Set).

1. Ручное определение фактического MTU на пути (Path MTU)

Выполните пинг с установленным флагом запрета фрагментации (Don't Fragment — DF):

# Linux (1472 байта ICMP payload + 20 IP + 8 ICMP = 1500 MTU):
ping -c 4 -M do -s 1472 192.168.1.1

# Если выдает 'Frag needed and DF set', уменьшайте размер payload:
ping -c 2 -M do -s 1420 192.168.1.1

# Windows:
ping 192.168.1.1 -f -l 1444

2. Настройка TCP MSS Clamping на сетевом шлюзе

Если на промежуточных узлах блокируется ICMP (PMTUD Blackhole), маршрутизатор должен принудительно переписывать значение MSS в SYN-пакетах TCP:

# На оборудовании Cisco IOS:
interface GigabitEthernet0/0/1
 ip tcp adjust-mss 1360
exit

# На оборудовании MikroTik RouterOS:
/ip firewall mangle
add chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=1400-65535

# На Linux / iptables (для VPN интерфейсов):
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

3. Корректировка MTU на туннельных интерфейсах

Для инкапсулирующих протоколов установите MTU с учетом размера оверхеда заголовков:

# WireGuard (40-80 байт оверхед):
mtu = 1420

# GRE / IPsec over IPv4:
interface Tunnel0
 ip mtu 1400
 ip tcp adjust-mss 1360
exit

4. Включение PLPMTUD в ядре Linux

sysctl -w net.ipv4.tcp_mtu_probing=1
echo "net.ipv4.tcp_mtu_probing = 1" >> /etc/sysctl.d/99-pmtud.conf

💡 Практика специалистов: Никогда не блокируйте ICMP Type 3 Code 4 (Fragmentation Needed) на пограничных фаерволах. Полная блокировка протокола ICMP не повышает безопасность, а ломает фундаментальный механизм согласования размера пакетов в интернете.

Частые вопросы (FAQ)

Почему SSH и HTTPS зависают именно при проблемах с MTU?

Служебный обмен (TCP Handshake) использует маленькие пакеты (< 100 байт), которые свободно проходят. Но когда сервер отправляет большой объем данных (баннер SSH, список файлов или цепочку SSL-сертификатов размером > 1500 байт) с выставленным DF-битом, пакет отбрасывается на линке с меньшим MTU.

Как рассчитывается оптимальный размер TCP MSS?

Формула: MSS = MTU - 20 байт (IP-заголовок) - 20 байт (TCP-заголовок). Для стандартного MTU 1500 байт MSS равен 1460 байт. Для VPN с MTU 1400 байт MSS должен быть не более 1360 байт.

Что такое PMTUD Black Hole?

Это ситуация, когда промежуточный маршрутизатор с малым MTU отбрасывает пакет с флагом DF=1 и пытается отправить отправителю ICMP Type 3 Code 4, но этот служебный ICMP-пакет блокируется глухими фаерволами (Drop ICMP) на пути. В итоге отправитель бесконечно шлет большой пакет и ждет ACK.

Помогает ли параметр net.ipv4.tcp_mtu_probing=1?

Да, эта опция включает механизм Packetization-Layer Path MTU Discovery (RFC 4821), который определяет 'черные дыры' MTU по факту отсутствия ACK-подтверждений на большие сегменты и автоматически снижает размер MSS без использования ICMP.