Path MTU Discovery и Black Hole: устранение зависаний VPN и TCP MSS Clamping

Одной из наиболее труднодиагностируемых сетевых аномалий является «тихое зависание» (silent freeze) соединения. Первичное трехстороннее рукопожатие TCP Three-Way Handshake успешно завершается, служебные пакеты малого размера (40–60 байт) курсируют без задержек, но в момент начала передачи объемной прикладной нагрузки — будь то загрузка веб-страницы с насыщенным медиаконтентом, передача сертификатов TLS 1.3 ServerHello или аутентификация ключей OpenSSH — сессия внезапно замирает. Никаких ошибок TCP RST или отчетов о недостижимости не поступает; соединение остается заблокированным до срабатывания тайм-аута TCP Retransmission Timeout в стеке операционной системы.

В архитектуре защищенных виртуальных сетей и протоколов туннелирования L3 (WireGuard, IPsec) подобное поведение практически всегда обусловлено сбоем механизма динамического согласования размера пакетов Path MTU Discovery (PMTUD) по стандарту RFC 1191 и возникновением так называемой «черной дыры ICMP» (ICMP Black Hole).

Физические интерфейсы Ethernet (IEEE 802.3) оперируют стандартным предельным размером фрейма Maximum Transmission Unit (MTU), равным 1500 байт. Однако при инкапсуляции клиентского трафика в криптографические контейнеры с аутентификацией ChaCha20-Poly1305 служебные заголовки забирают от 60 до 80 байт полезного пространства. Если промежуточные маршрутизаторы не могут корректно согласовать сегментацию, пакеты размером 1500 байт молча отбрасываются, парализуя сетевой обмен.

[Стандартный кадр локальной сети Ethernet]
Полезная нагрузка + Заголовок TCP (20B) + Заголовок IP (20B) = 1500 Байт (Полный кадр)

────────────────────────────────────────────────────────────────────────────────────────

[Структура кадра после инкапсуляции в туннель VPN]
[Внешний IP (20B)] [Внешний UDP (8B)] [Заголовок WireGuard (16B)] [Тег Poly1305 (16B)] [ПАКЕТ]
                                  Суммарный оверхед = от 60 до 80 Байт!
Предельный внутренний MTU = 1500 - 60 = 1440 Байт (или 1420 Байт для сетей PPPoE/LTE)

Механика протокола Path MTU Discovery (RFC 1191)

Параметр Maximum Transmission Unit (MTU) определяет наибольший объем полезной нагрузки в октетах, который сетевой интерфейс способен отправить без фрагментации.

Поскольку маршрут между узлами в глобальной сети пролегает через разнородные транзитные каналы — от магистральных оптических линий Tier-1 (MTU 1500–9000 байт Jumbo Frames) до абонентских линий PPPoE (MTU 1492 байт) и мобильных сетей 4G LTE/5G (MTU 1400–1420 байт) — наименьшее значение MTU среди всех промежуточных участков называется Path MTU (PMTU).

В ранних спецификациях IPv4 (RFC 791) маршрутизаторам разрешалось фрагментировать негабаритные пакеты. Однако фрагментация на лету создает серьезную нагрузку на процессоры сетевых устройств, резко увеличивает риск потери данных (утрата единственного фрагмента разрушает весь 1500-байтный пакет) и открывает векторы для атак переполнения памяти при реассемблинге.

Для отказа от фрагментации IETF утвердил стандарт RFC 1191 (Path MTU Discovery):

1. Установка флага Don't Fragment: Узел-отправитель выставляет бит DF = 1 в заголовке IPv4 каждого исходящего датаграмма.
2. Анализ размера на транзитном узле: Если маршрутизатор получает пакет размером 1500 байт, а MTU исходящего интерфейса составляет 1420 байт, бит DF = 1 блокирует фрагментацию.
3. Отправка уведомления ICMP: Маршрутизатор уничтожает пакет и генерирует сообщение об ошибке ICMP Destination Unreachable: Type 3, Code 4 (Fragmentation Needed and DF set). Согласно RFC 1191, в сообщение обязательно помещается значение Next-Hop MTU (например, 1420).
4. Адаптация отправителя: Получив ICMP Type 3 Code 4, сетевой стек отправителя снижает значение PMTU для данного целевого IP-адреса и повторяет отправку данных в безопасных границах 1420 байт.

В протоколе IPv6 (RFC 8201) фрагментация промежуточными узлами запрещена архитектурно; механизм PMTUD обязателен, а превышение лимита вызывает отправку сообщений ICMPv6 Packet Too Big (Type 2, Code 0).

Природа возникновения черной дыры ICMP (ICMP Black Hole)

Безупречное функционирование алгоритма RFC 1191 всецело зависит от гарантированной доставки служебных пакетов ICMP. К сожалению, на практике эта обратная связь часто нарушается.

Многие корпоративные межсетевые экраны, домашние роутеры и пограничные шлюзы интернет-провайдеров настраиваются по принципу неизбирательной блокировки: они уничтожают весь входящий ICMP-трафик, ошибочно классифицируя любые служебные пакеты как потенциальные векторы сетевых атак DoS/DDoS.

[Клиент-отправитель]                            [Транзитный маршрутизатор]                   [Целевой сервер]
        │                                                    │                                       │
        ├─ 1. TCP SYN (MSS=1460, DF=1) ─────────────────────>│──────────────────────────────────────>│ (Handshake OK)
        │<─ 2. TCP SYN-ACK (MSS=1460) <──────────────────────│<──────────────────────────────────────┤
        │                                                    │                                       │
        ├─ 3. Передача пакета TLS ClientHello (1500 Байт) ──>│ [MTU интерфейса: 1420 Байт]           │
        │                                                    │ (Пакет УНИЧТОЖЕН: превышен лимит MTU) │
        │                                                    │                                       │
        │   (Фаервол блокирует пакет ICMP Type 3 Code 4!)    ├─ Генерация ICMP Fragmentation ──X     │
        │                                                    │                                       │
        │   Отправитель НЕ получает уведомления!             │                                       │
        ▼                                                    │                                       │
[Зависание сессии: Бесконечные ретрансмиты до тайм-аута]     │                                       │

Когда маршрутизатор отбрасывает пакет 1500 байт и отсылает ICMP Type 3 Code 4, но фильтр на обратном пути уничтожает это уведомление:

• Отправитель не знает, что передача сорвалась из-за несовпадения MTU.
• Стек предполагает временную потерю пакета и повторно высылает тот же самый 1500-байтный кадр с битом DF = 1.
• Промежуточный узел снова его уничтожает.
• Сессия входит в состояние перманентного ступора: служебные подтверждения TCP ACK (40–60 байт) циркулируют свободно, а прикладные данные бесследно исчезают в черной дыре ICMP.

Накладные расходы туннелей: Расчет MTU для WireGuard и RiceGuard

При развертывании защищенных каналов L3 точный расчет границ MTU имеет решающее значение. Каждый пакет инкапсулируется во внешний UDP-контейнер и шифруется с аутентификацией ChaCha20-Poly1305.

Структура оверхеда туннеля WireGuard:

Для стандартного физического интерфейса с MTU 1500 байт:

• Туннельный адаптер WireGuard поверх IPv4 (wg0) поддерживает максимальный MTU: 1500 - 60 = 1440 байт.
• Адаптер WireGuard поверх IPv6 поддерживает максимальный MTU: 1500 - 80 = 1420 байт.

В реальных сценариях провайдерские каналы накладывают дополнительные ограничения: подключение по протоколу PPPoE отнимает 8 байт (MTU 1492 байт), а сотовые сети LTE/5G используют протокол GTP (GPRS Tunneling Protocol), уменьшая базовый MTU до 1400–1420 байт.

Для обеспечения стабильности шлюзы VPNRice по умолчанию устанавливают MTU виртуальных интерфейсов на консервативную отметку 1420 байт (или 1280 байт — гарантированный минимум, предписанный стандартом IPv6 RFC 8200).

Механизм TCP MSS Clamping: Проактивная ликвидация черных дыр

Если PMTUD реагирует на проблему постфактум, протокол TCP предлагает упреждающий инструмент предотвращения генерации негабаритных пакетов: фиксацию максимального размера сегмента (TCP MSS Clamping).

В ходе первичного обмена пакетами SYN и SYN-ACK стороны согласовывают параметр Maximum Segment Size (MSS) через опции TCP. Значение MSS определяет предельный размер чистых пользовательских данных в одном сегменте без учета заголовков IP и TCP:

$$\text{MSS} = \text{MTU интерфейса} - \text{Заголовок IP (20/40B)} - \text{Заголовок TCP (20B)}$$

• Для Ethernet с MTU 1500 байт: $\text{MSS} = 1500 - 20 - 20 = 1460\text{ байт}$.
• Для туннеля с MTU 1420 байт: $\text{MSS} = 1420 - 20 - 20 = 1380\text{ байт}$ (или 1360 байт для IPv6).

Если клиент внутри туннеля попытается согласовать сессию со стандартным значением MSS 1460 байт, внешний сервер сформирует 1500-байтные кадры, которые физически не поместятся в туннель.

Для предотвращения коллизии шлюз перехватывает пакеты TCP SYN в цепочке FORWARD и перезаписывает поле MSS:

# Автоматическая корректировка MSS под текущий Path MTU через 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

Модификация MSS на границе туннеля информирует обоих участников соединения о пропускной способности канала еще до отправки первого байта полезной нагрузки, предотвращая появление негабаритных кадров и защищая от черных дыр ICMP.

Протокол PLPMTUD (RFC 4821) для трафика без TCP

Для сетевых протоколов без поддержки сессионного квитирования — таких как UDP в стеке HTTP/3 (QUIC), DNS-запросах или медиапотоках WebRTC — механизм TCP MSS Clamping неприменим из-за отсутствия опций согласования сегментов.

Для нейтрализации потерь UDP-трафика IETF утвердил спецификацию RFC 4821: Packetization Layer Path MTU Discovery (PLPMTUD).

Вместо ожидания сообщений ICMP Type 3 от промежуточных роутеров, PLPMTUD переносит логику оценки на конечные точки приложения. Клиент посылает изолированные тестовые зонды (search probes) ступенчато возрастающего размера. Если тестовый пакет подтверждается противоположной стороной, путь признается валидным для этого MTU; при потере зонда стек плавно понижает расчетный размер кадра без привлечения ICMP-уведомлений.

Современные транспортные протоколы, включая QUIC (RFC 9000, раздел 14), изначально содержат встроенные алгоритмы зондирования RFC 4821.

Вопросы информационной безопасности и сигнатурного анализа

Грамотная настройка лимитов MTU защищает инфраструктуру от ряда специфических угроз:

1. Атаки фрагментации (Tiny Fragment и Overlapping Fragment): Злоумышленники исторически разделяли вредоносные TCP-пакеты (RFC 1858, RFC 3128) так, чтобы первый фрагмент содержал лишь заголовок IP и часть портов, вынося флаги управления во второй фрагмент. Неотслеживающие состояние фильтры пропускали первый фрагмент, открывая брешь в периметре. Установление жестких лимитов MTU и сброс аномальных фрагментов нейтрализуют данную опасность.
2. Пассивный фингерпринтинг ОС по значению MSS: Анализаторы трафика исследуют начальное значение MSS в пакетах TCP SYN для идентификации типа системы (например, 1460 для базовых ядер Linux/Windows, 1440 для виртуальных инстансов облачных провайдеров).
3. Борьба с буферблоатом (Bufferbloat): Дробление негабаритных пакетов удваивает число очередей на промежуточных коммутаторах, вызывая скачки задержки (jitter) в интерактивных сервисах.

Архитектурные решения VPNRice и протокола RiceGuard

Инфраструктура VPNRice исключает вероятность возникновения сетевых зависаний благодаря специализированным механизмам протокола RiceGuard:

• Динамический MSS Clamping на Anycast-шлюзах: Все узлы VPNRice автоматически корректируют поле TCP MSS в прямом и обратном направлениях, исключая генерацию клиентскими приложениями пакетов, превышающих лимиты туннеля.
• Отказоустойчивый базовый MTU 1420 Байт: Адаптеры RiceGuard инициализируются с рабочим значением MTU 1420 байт (с автопонижением до 1280 байт при переходе на нестабильные мобильные каналы), что гарантирует прохождение пакетов без сегментации.
• Политика Zero-Fragment: Шлюзы VPNRice отбрасывают неавторизованные фрагментированные пакеты и подтверждают подлинность данных по алгоритму ChaCha20-Poly1305, гарантируя целостность трафика и стабильную скорость.