Сучасні віртуальні приватні мережі (VPN) передають різнорідні потоки прикладного трафіку через непередбачувані фізичні маршрути. У високошвидкісній мережевій інфраструктурі реальна продуктивність напряму залежить від максимального заповнення корисними даними кожної надісланої дейтаграми. Однак передавання пакетів, розмір яких перевищує максимальну одиницю передавання (MTU) хоча б на одній проміжній ділянці, призводить до скидання кадрів або примусової IP-фрагментації, що різко знижує пропускну здатність та збільшує затримки.

Історично IP-мережі покладалися на класичний механізм Path MTU Discovery (PMTUD, RFC 1191 для IPv4 та RFC 8201 для IPv6). Цей алгоритм цілком залежить від генерування проміжними маршрутизаторами повідомлень ICMP «Destination Unreachable: Fragmentation Needed and DF set» (тип 3, код 4). У сучасному інтернеті міжмережеві екрани, корпоративні шлюзи безпеки та пристрої CGNAT операторів повсюдно блокують будь-які повідомлення ICMP. Коли пакет відкидається без повернення помилки відправнику, з'єднання потрапляє в чорну діру ICMP (ICMP Black Hole), спричиняючи глухі зависання сесій.

Для усунення цієї вразливості Інженерна рада інтернету (IETF) стандартизувала механізм Datagram Packetization Layer Path MTU Discovery (DPLPMTUD, RFC 8899). Переносячи процедуру зондування безпосередньо на транспортний рівень дейтаграм — у такі протоколи, як QUIC, DTLS або тунелі UDP, — DPLPMTUD визначає пропускну здатність каналу внутрішньосмугово, не потребуючи зовнішньої допомоги від ICMP.

Проблема чорних дір ICMP: чому класичний PMTUD безсилий в UDP-тунелях

Стандартна інфраструктура Ethernet використовує фіксований розмір фізичного MTU в 1500 байтів. У звичайному неінкапсульованому середовищі дані застосунку разом із 20 байтами заголовка IPv4 та 20 байтами TCP (або 8 байтами UDP) штатно вкладаються в рамки 1500-байтового кадру.

У разі надходження трафіку в зашифрований тунель VPN накладання захисних заголовків створює суттєві накладні витрати:

Стандартний мережевий кадр Ethernet (MTU 1500 байтів):
[Заголовок IP: 20B] [Заголовок UDP: 8B] [Корисні дані: 1472B]

Інкапсульований кадр тунелю UDP/QUIC (фізичний MTU 1500 байтів):
[Зовнішній IP: 20B] [Зовнішній UDP: 8B] [Заголовок тунелю/AEAD: 16B] [Тег Poly1305: 16B] [ВНУТРІШНІЙ ПАКЕТ: макс. 1440B]
Сумарні накладні витрати: від 60 до 80 байтів залежно від стека та адресації IPv6!

Якщо застосунок усередині тунелю намагається надіслати стандартний пакет у 1500 байтів, зовнішній інкапсульований пакет виростає до 1560–1580 байтів. Коли проміжні ланки мережі мають суворий ліміт у 1500 байтів (або менше, наприклад, 1492 байти в PPPoE чи 1420 байтів у мобільних мережах LTE/5G), такий пакет непомітно знищується.

Накладні витрати інкапсуляції та приховані загрози фрагментації

У класичному алгоритмі RFC 1191 маршрутизатор, що відкидає пакет із встановленим прапорцем Don't Fragment (DF), надсилає відправнику сповіщення ICMP. Якщо ця відповідь блокується мережевими фільтрами:

  1. Глухі зависання: Відправник не отримує інформації про те, що пакет не пройшов через габарити.
  2. Марні повторні передавання: Стек сприймає втрату як ознаку перевантаження мережі та знову й знову повторює надсилання того ж самого пакета аж до розриву за таймаутом.
  3. Фрагментація IP: Якщо тунель не виставляє біт DF, маршрутизатори розділяють пакет на рівні IP. Збирання фрагментів перевантажує пам'ять мережевого обладнання, підвищує ризик втрати (скидання одного фрагмента знищує весь пакет) і відкриває канал для атак на буфер збирання.

Архітектура DPLPMTUD: внутрішньосмугове зондування без службових повідомлень

Специфікація RFC 8899 усуває залежність від ICMP, виконуючи калібрування розмірів усередині рівня пакетування даних. Замість здогадок передавальний вузол активно досліджує межі фізичного шляху за допомогою спеціальних зондувальних пакетів (Probe Packets).

Процес спирається на три базові параметри:

  • BASE_PLPMTU: Гарантований мінімальний розмір пакета, який зобов'язана пропускати будь-яка сумісна мережа без фрагментації (1200 байтів для IPv6, 576 або 1200 байтів для IPv4).
  • PLPMTU: Поточний підтверджений розмір MTU, що успішно проходить фізичним маршрутом у даний момент.
  • PROBE_PLPMTU: Кандидатний розмір MTU, що перевищує поточний PLPMTU і надсилається для перевірки резерву пропускної здатності.
+-------------------------------------------------------------------------+
|                Схема зондувального пакета згідно з RFC 8899              |
+-------------------------------------------------------------------------+
| [Зовнішній заголовок IP] | [Зовнішній UDP] | [Заголовок тунелю / QUIC]  |
+-------------------------------------------------------------------------+
| [Корисні дані користувача чи фрейм] | [Заповнювальні байти PADDING...]  |
+-------------------------------------------------------------------------+
| <-- Реальні передані дані --------> | <-- Штучне розширення ----------> |
| <----------------------- Повний розмір PROBE_PLPMTU --------------------> |

Зондувальні пакети, заповнення байтами та явне підтвердження доставки

Зондувальний пакет формується двома шляхами:

  1. Доповнення реальних даних: До звичайного пакета з даними користувача додаються фрейми заповнення (наприклад, PADDING у QUIC) до досягнення цільового розміру PROBE_PLPMTU.
  2. Виділений сервісний зонд: Надсилається невеликий діагностичний фрейм, повністю доповнений баластними байтами без навантаження застосунку.

Відправник маркує зонд внутрішнім номером відстеження. Коли вузол-одержувач успішно приймає дейтаграму, він надсилає стандартне підтвердження доставки (кадр ACK або транспортну квитанцію тунелю) назад відправнику.

Оскільки підтвердження повертається самим зашифрованим каналом даних, його отримання незаперечно доводить, що всі транзитні комутатори та маршрутизатори без труднощів пропустили дейтаграму такого розміру. Якщо ж підтвердження не надходить протягом таймауту зондування (PTO), стек фіксує перевищення ліміту шляху без залучення ICMP.

Скінченний автомат DPLPMTUD: стратегії пошуку та відновлення після чорних дір

Стандарт RFC 8899 визначає процедуру дослідження через детермінований скінченний автомат із п'яти станів:

                  +--------------+
                  |   DISABLED   |
                  +--------------+
                         | (Увімкнення)
                         v
                  +--------------+
                  |     BASE     |<------------------------+
                  +--------------+                         |
                         | (Базовий MTU підтверджено)      |
                         v                                 | (Виявлено чорну діру)
                  +--------------+                         |
        +-------->|  SEARCHING   |-------------------------+
        |         +--------------+
        |                |
(Зонд підтверджено)      | (Пошук завершено)
        |                v
        |         +--------------+
        +---------| SEARCH_COMPL |
  (Зміна шляху)   +--------------+
  1. DISABLED: Зондування вимкнено, з'єднання працює на консервативному статичному значенні.
  2. BASE: Перевіряється базовий безпечний розмір BASE_PLPMTU (1200 байтів). У разі невдачі автомат переходить в ERROR.
  3. SEARCHING: Вузол активно надсилає зонди з розміром, більшим за поточний PLPMTU.
  4. SEARCH_COMPLETE: Розмір шляху визначено з необхідною точністю (наприклад, з кроком у 32 байти до межі скидання). Активний пошук призупиняється, а фоновий таймер періодично перевіряє стабільність каналу.
  5. ERROR: Зв'язок неможливий навіть на базовому рівні дейтаграм, що вказує на критичні негаразди маршрутизації.

Динамічний бінарний пошук проти табличних алгоритмів зондування

RFC 8899 описує дві ключові пошукові методики:

  • Пошук за таблицею (Table Search): Стек перебирає список поширених розмірів MTU в глобальній мережі: [1200, 1280, 1420, 1440, 1492, 1500, 9000]. Такий підхід збігається до оптимального значення всього за 2–4 цикли RTT.
  • Бінарний пошук (Binary Search): Вузол ділить навпіл діапазон між останнім успішним розміром (low) та найменшим відкинутим (high):

$$\text{Кандидат} = \left\lfloor \frac{\text{PLPMTU}{\text{успіх}} + \text{PLPMTU}{\text{скидання}}}{2} \right\rfloor$$

/* Псевдокод: крок бінарного пошуку DPLPMTUD згідно з RFC 8899 */
void dplpmtud_probe_step(struct dplpmtud_ctx *ctx)
{
    if ((ctx->high - ctx->current_plpmtu) <= SEARCH_STEP_THRESHOLD) {
        ctx->state = DPLPMTUD_SEARCH_COMPLETE;
        timer_set(&ctx->validation_timer, VALIDATION_INTERVAL_SEC);
        return;
    }

    ctx->probe_plpmtu = (ctx->current_plpmtu + ctx->high) / 2;
    struct packet *probe = build_padded_packet(ctx->probe_plpmtu);

    ctx->probe_count++;
    transmit_datagram(probe);
    timer_set(&ctx->probe_timer, ctx->smoothed_rtt * 2);
}

Якщо раніше успішні пакети раптово починають губитися (наприклад, через перемаршрутизацію трафіку провайдером), активується детектор чорних дір (Black Hole Detection). Автомат миттєво скидає робочий розмір до BASE_PLPMTU без розриву сесії, відновлюючи зв'язок перед новим циклом калібрування.

Практична реалізація в протоколі RiceGuard та шлюзах Core L3 VPN

Досягнення високих швидкостей у стільникових, кабельних та корпоративних сегментах вимагає постійного динамічного підлаштування параметрів інкапсуляції.

VPNRice глибоко інтегрує специфікацію RFC 8899 у мережевий стек:

  1. Зондування без ICMP у RiceGuard: Протокол RiceGuard використовує оптимізований табличний DPLPMTUD. Під час перемикання мобільного клієнта з вежі 5G (MTU 1420 байтів) на домашній Wi-Fi (MTU 1500 байтів) розмір кадру калібрується за 3 RTT без зависання застосунків.
  2. Виключення фрагментації в Core L3 VPN: Магістральні шлюзи аналізують транспортні квитанції в реальному часі. Синхронізація внутрішнього параметра MSS із фізичною ємністю каналу знижує навантаження на процесор і звільняє пам'ять ядра.
  3. Миттєва реакція на чорні діри: У разі прихованого звуження зовнішнього тунелю транзитним оператором RiceGuard фіксує втрату за два зонди й плавно відкочується до базового безпечного розміру, зберігаючи сесію активною.

Підсумки: максимальна утилізація каналу без крихких зовнішніх залежностей

Механізм DPLPMTUD (RFC 8899) кардинально підвищує надійність сучасних мережевих тунелів. Перенесення вимірювання пропускної здатності безпосередньо в потік дейтаграм і підтвердження доставки через транспортні квитанції захищають віртуальні мережі від руйнівного впливу чорних дір ICMP.

Автоматичне калібрування габаритів дейтаграм гарантує стабільне передавання даних на граничній швидкості фізичної лінії. Оцініть бездоганну стабільність і безпеку зв'язку за допомогою Завантажити VPNRice.