Справочник системных ошибок и решений

Windows Server, Active Directory, 1С:Предприятие, СУБД, Linux, Cisco, MikroTik, Asterisk.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты на сайте предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, программного обеспечения, баз данных, сетевого оборудования и других компонентов инфраструктуры. Перед выполнением действий создайте резервную копию и по возможности протестируйте изменения в безопасной среде. Пользователь самостоятельно оценивает риски и несет ответственность за результат. При отсутствии необходимых знаний обратитесь к квалифицированному ИТ-специалисту.

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

Траблшутинг Path MTU Discovery: устранение ICMP Black Hole и Packet Fragmentation

Обновлено: 25.08.2026 · Официальная документация ↗
  • Сессия TCP успешно устанавливается (SYN/ACK проходят), но зависает при передаче больших данных (зависание SSL/TLS рукопожатия, SSH сессий, скачивания файлов).
  • Команда ping с маленьким размером пакета проходит, но с параметром -f -l 1472 (Don't Fragment) теряет 100% пакетов без ответа.
  • Проблема проявляется исключительно внутри туннелей IPsec, GRE, VXLAN, PPPoE или WireGuard.
  • В дампе сетевого трафика отсутствуют входящие сообщения ICMP Destination Unreachable (Fragmentation Needed and DF set).

1. Принцип возникновения проблемы PMTUD Black Hole

Когда хост отправляет пакет размером 1500 байт с установленным флагом DF=1 (Don't Fragment), а промежуточный маршрутизатор с меньшим MTU (например, 1420 байт из-за оверхеда IPsec туннеля) не может его пропустить, он обязан сбросить пакет и вернуть источнику сообщение ICMP Type 3, Code 4 с указанием допустимого Next-Hop MTU. Если межсетевой экран блокирует этот ICMP-пакет, возникает «черная дыра» (ICMP Black Hole) — клиент бесконечно отправляет повторные попытки (TCP Retransmissions).

2. Практическая проверка Path MTU утилитой Ping

# Windows (проверка границы фрагментации, где 1472 + 28 байт ICMP/IP заголовка = 1500)
ping -f -l 1472 error.itstm.ru
ping -f -l 1400 error.itstm.ru

# Linux
ping -M do -s 1472 error.itstm.ru
ping -M do -s 1392 error.itstm.ru

# Определение точного MTU через tracepath
tracepath error.itstm.ru

3. Решение 1: Разрешение ICMP Fragmentation Needed на межсетевых экранах

Убедитесь, что фаерволы не фильтруют служебный ICMP-трафик:

# Linux iptables / nftables
iptables -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type fragmentation-needed -j ACCEPT

# Cisco ASA / Firepower
access-list OUTSIDE_IN extended permit icmp any any unreachable

4. Решение 2: Настройка TCP MSS Clamping (Production Workaround)

Наиболее надежный промышленный метод — принудительное переписывание поля Maximum Segment Size (MSS) в проходящих TCP SYN пакетах на сетевом шлюзе:

# Cisco IOS / IOS-XE на туннельном интерфейсе
interface Tunnel1
 ip address 10.100.0.1 255.255.255.252
 ip mtu 1400
 ip tcp adjust-mss 1360

# Linux Router (iptables)
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

# Mikrotik RouterOS
/ip firewall mangle
add chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=yes tcp-flags=syn protocol=tcp
💡 Практика специалистов: Всегда активируйте команду 'ip tcp adjust-mss' на всех GRE, IPsec и PPPoE интерфейсах маршрутизаторов. Это полностью предотвращает появление тикетов о зависании клиентских браузеров на этапе TLS Client Hello.

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

Как рассчитывается оптимальный TCP MSS для туннеля с MTU 1400 байт?

Формула: MSS = MTU - 20 байт (IP-заголовок) - 20 байт (TCP-заголовок). Для MTU 1400 байт оптимальный размер TCP MSS составляет 1360 байт (для IPv6 вычитается 40 байт базового заголовка IPv6: MSS = 1340).

Почему ping 1500 байт работает, а веб-страницы по HTTPS не открываются?

Стандартный ping без флага DF фрагментируется на шлюзе и успешно доходит до цели частями. Пакеты HTTPS TLS Application Data идут с установленным флагом DF=1 (Don't Fragment) от веб-сервера и отбрасываются в туннеле без генерации ICMP ответа.

Помогает ли TCP MSS Clamping для трафика UDP (DNS, VoIP, WireGuard)?

Нет. TCP MSS Clamping модифицирует только флаги TCP SYN пакетов. Для UDP приложений необходимо либо разрешать сквозной ICMP Type 3, либо настраивать размер буфера на уровне самого приложения (например, dns-max-udp-size).

Что такое PLPMTUD (Packetization Layer Path MTU Discovery)?

Это современный механизм (RFC 4821), реализованный в ОС Linux и Windows, позволяющий стеку TCP изолированно определять максимальный размер пакета путем зондирования данными разного размера без опоры на сообщения ICMP.

Полезные материалы
Рекомендуем