Современные виртуальные частные сети (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.