Path MTU Discovery та виявлення Black Hole: усунення зависань VPN і TCP MSS

Однією з найскладніших для діагностики мережевих аномалій є «тихе зависання» (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 байтів, а вихідний інтерфейс наступного кроку підтримує лише 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 або мережевого сканування.

[Клієнт-відправник]                             [Транзитний маршрутизатор]                   [Цільовий сервер]
        │                                                    │                                       │
        ├─ 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/4!)     ├─ Генерація ICMP Fragmentation ──X     │
        │                                                    │                                       │
        │   Відправник НЕ отримує жодного сповіщення!        │                                       │
        ▼                                                    │                                       │
[Зависання сесії: Нескінченні повтори до тайм-ауту]          │                                       │

Коли маршрутизатор відкидає пакет 1500 байтів і надсилає повідомлення ICMP Type 3 Code 4, але захисний екран на зворотному шляху знищує це сповіщення:

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

Накладні витрати тунелів: Розрахунок лімітів MTU для WireGuard

Під час налаштування безпечних каналів 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 байти), а стільникові мережі 4G 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{ байтів}$.
• Для тунелю WireGuard з MTU 1420 байтів: $\text{MSS} = 1420 - 20 - 20 = 1380\text{ байтів}$ (або 1360 байтів для IPv6).

Якщо пристрій усередині тунелю спробує узгодити з'єднання зі стандартним значенням MSS 1460 байтів, віддалений сервер генеруватиме кадри розміром 1500 байтів, які не зможуть пройти через віртуальний адаптер.

Щоб запобігти збою, шлюз перехоплює пакети TCP SYN у ланцюжку пересилання й автоматично коригує поле 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; у разі втрати пакета мережевий стек плавно знижує оцінку PMTU без жодних повідомлень ICMP.

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

Захист мережі від атак і сигнатурного аналізу

Точне налаштування меж MTU відіграє помітну роль у захисті інфраструктури:

1. Захист від атак фрагментації (Tiny Fragment та Overlapping Fragment): Зловмисники історично розділяли шкідливі пакети (RFC 1858, RFC 3128) так, щоб перший фрагмент містив лише заголовок IP та частину портів, витісняючи керуючі прапорці TCP у другий фрагмент. Спрощені фільтри пропускали перший фрагмент, створюючи загрозу для захищеного вузла. Встановлення жорсткого ліміту 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 налаштовані на стабільний розмір 1420 байтів (із гнучким зниженням до 1280 байтів на нестабільних мобільних мережах), що забезпечує вільне проходження пакетів без фрагментації.
• Політика повної відмови від фрагментів: Шлюзи VPNRice фільтрують фрагментовані пакети і проводять криптографічну перевірку цілісності за допомогою ChaCha20-Poly1305, гарантуючи надійний захист і стабільну пропускну здатність.