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

Зависание сессий RDP и SSH в IPsec / WireGuard туннелях: исправление MTU/MSS

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

Сессия SSH успешно подключается, но зависает намертво при выполнении команд с большим объемом вывода (cat large.log, ls -la /usr/bin).
Подключение RDP зависает на этапе «Оценка качества» или показывает статичный черный экран после ввода учетных данных.
Пакеты малого размера (команда ping) проходят без потерь, но передача HTTP/SMB файлов останавливается.
Блокировка ICMP сообщений типа 3 кода 4 (Destination Unreachable: Fragmentation Needed and DF set) на фаерволах.

1. Причина сбоя: Path MTU Discovery Black Hole

Шифрование IPsec, WireGuard и OpenVPN добавляет собственные заголовки (от 40 до 80 байт) к каждому сетевому пакету. Если хост отправляет стандартный Ethernet-пакет размером 1500 байт с установленным флагом DF (Don't Fragment), зашифрованный пакет превышает MTU внешнего провайдера (1500 байт) и отбрасывается. Если при этом промежуточные фаерволы блокируют сообщения ICMP Type 3 Code 4, механизм PMTUD ломается, образуя «черную дыру».

2. Точное измерение MTU через Ping

# Linux (поиск максимального MTU без фрагментации)
ping -M do -s 1472 10.100.0.1

# Windows
ping 10.100.0.1 -f -l 1472

# Если пинг не проходит, уменьшайте размер (1460, 1420, 1380, 1360),
# пока не исчезнет сообщение "Packet needs to be fragmented but DF set".

3. Решение 1: Зажим TCP MSS в Linux (iptables / nftables)

Добавьте правило MSS Clamping на VPN-маршрутизаторе, автоматически уменьшающее анонсируемый размер TCP сегмента в SYN-пакетах:

# Для iptables
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

# Или жесткая фиксация безопасного MSS (1360 байт)
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360

# Для nftables
nft add rule inet filter forward tcp flags syn tcp option maxseg size set 1360

4. Решение 2: Зажим TCP MSS на MikroTik RouterOS

/ip firewall mangle
add action=change-mss chain=forward comment="Clamp MSS for VPN" new-mss=clamp-to-pmtu \
    passthrough=yes protocol=tcp tcp-flags=syn

# Или принудительный безопасный размер:
add action=change-mss chain=forward new-mss=1360 out-interface=all-ppp protocol=tcp tcp-flags=syn

5. Решение 3: Настройка Cisco IOS / ASA

! На туннельном интерфейсе Cisco
interface Tunnel1
 ip mtu 1400
 ip tcp adjust-mss 1360

! На Cisco ASA
sysopt connection tcpmss 1360

💡 Практика специалистов: Всегда проверяйте, чтобы в вашем Firewall не было слепого правила iptables -A INPUT -p icmp -j DROP. Разрешайте служебный ICMP (icmp-type 3/code 4 для IPv4 и Packet Too Big для IPv6), иначе Path MTU Discovery не сможет работать корректно.

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

Почему Ping размером 64 байта работает идеально, а RDP и SSH зависают?

Маленькие пакеты (ping, подтверждения TCP ACK, набор символов в консоли) укладываются в размер MTU. Графические кадры RDP и длинные списки вывода SSH формируют полноразмерные IP-пакеты (1500 байт), которые отбрасываются из-за превышения лимита MTU туннеля.

Как рассчитать правильный TCP MSS для WireGuard?

Формула: MTU туннеля (1420) минус заголовок IPv4 (20 байт) минус заголовок TCP (20 байт) = MSS 1380 байт. Для IPv6 отнимите еще 20 байт (MSS 1360).

Помогает ли включение опции MTU в клиенте WireGuard?

Да, если задать параметр 'MTU = 1360' в секции [Interface] конфигурационного файла WireGuard, клиент сам будет фрагментировать исходящие пакеты перед шифрованием.

Почему нельзя просто разрешить фрагментацию в IPsec?

Фрагментация увеличивает нагрузку на CPU роутера, а потеря хотя бы одного фрагмента зашифрованного пакета приводит к отбрасыванию всего блока данных и повторной передаче.