Фрагментация IKEv2 RFC 7383: Устранение сбоев рукопожатия IPsec и черных дыр MTU

Построение защищенных туннелей «точка-точка» на базе IPsec опирается на протокол согласования ключей версии 2 (IKEv2, RFC 7296). Хотя IKEv2 продуктивно согласовывает криптографические ключи и ассоциации безопасности (SA) через порты UDP 500 и 4500, современные корпоративные требования безопасности привели к значительному увеличению размера пакетов. Внедрение развитой инфраструктуры открытых ключей (PKI) — с массивными ключами RSA-4096, цепочками промежуточных центров сертификации (CA) и ответами протокола OCSP — регулярно выталкивает фазу авторизации (IKE_AUTH) за пределы максимального размера передачи (MTU) физической сети. Исторически операционные системы делегировали фрагментацию крупногабаритных датаграмм сетевому уровню IP. Однако на реальных транзитных магистралях сетевые экраны систематически отбрасывают фрагментированные IP-пакеты, вызывая невидимые сбои авторизации и срыв сессии. Спецификация RFC 7383 решает данную системную проблему за счет переноса механизма фрагментации на уровень приложения непосредственно в ядро IKEv2.

Дилемма размера рукопожатия: Сертификаты PKI и барьер сетевого MTU

Сеанс IKEv2 начинается с этапа IKE_SA_INIT, на котором согласуются криптографические алгоритмы и завершается временный обмен ключами Диффи-Хеллмана. Поскольку IKE_SA_INIT пересылает компактные математические открытые значения и псевдослучайные последовательности (nonce), объем полезной нагрузки редко превышает 500 байт. Напротив, следующая фаза IKE_AUTH решает критические задачи аутентификации сторон и подтверждения владения приватными закрытыми ключами.

Инициатор (Initiator)                                    Ответчик (Responder)
┌───────────────────────────────────────────────┐         ┌───────────────────────────────────────────────┐
│ HDR, SAi1, KEi, Ni                            ├────────>│                                               │
│                                               │<────────┤ HDR, SAr1, KEr, Nr, [CERTREQ]                 │
│                                               │         └───────────────────────────────────────────────┘
│ Запрос IKE_AUTH (Часто > 3000 байт)           │
│ HDR, SK { IDi, CERT, CERTREQ, AUTH, SAi2... } ───> [Превышение лимита MTU: Требуется фрагментация]
└───────────────────────────────────────────────┘

Рост объема полезной нагрузки IKE_AUTH в современной инфраструктуре PKI

В средах с общим предварительным паролем (PSK) объем данных IKE_AUTH остается минимальным. Однако корпоративные стандарты нулевого доверия требуют обязательной взаимной проверки цифровых сертификатов X.509. Типичная структура цепочки сертификатов включает:

Сертификат узла (обычно от 1,2 до 1,8 КБ для алгоритма RSA-4096 или 600 байт для ECDSA).
Один или два промежуточных сертификата CA для подтверждения доверия к корневому центру (дополнительно от 1,5 до 3,0 КБ).
Списки отзыва сертификатов (CRL) или цифровые маркеры проверки статуса OCSP.
Криптографические подписи, вычисленные над всеми байтами начального обмена.

При упаковке в зашифрованную нагрузку (SK, Тип 46) вместе с векторами инициализации и контрольными суммами целостности (ICV), размер пакета IKE_AUTH составляет от 3500 до 5000 байт. Это существенно превосходит стандартное значение MTU 1500 байт в сетях IPv4 и регламентированный минимум 1280 байт для IPv6.

Причины отбрасывания фрагментов уровня IP сетевыми посредниками

Когда хост отправляет датаграмму UDP объемом 4000 байт через интерфейс с MTU 1500 байт, сетевой стек IP разделяет данные на несколько сетевых фрагментов:

Фрагмент 1: Содержит заголовок IP (20 байт), заголовок UDP (8 байт), заголовок IKEv2 (28 байт) и 1472 байта полезных данных.
Последующие фрагменты: Содержат заголовки IP и последовательные срезы данных, полностью лишаясь транспортного заголовка UDP.

Фрагмент 1 (Смещение 0):
┌───────────┬────────────┬─────────────┬────────────────────────────────────┐
│ Заголовок │ Заголовок  │ Заголовок   │ Зашифрованные данные IKE_AUTH      │
│ IP        │ UDP        │ IKEv2       │ (Часть 1)                          │
└───────────┴────────────┴─────────────┴────────────────────────────────────┘

Фрагмент 2 (Смещение 1472):
┌───────────┬───────────────────────────────────────────────────────────────┐
│ Заголовок │ Зашифрованные данные IKE_AUTH (Часть 2)                       │
│ IP        │                                                               │
└───────────┴───────────────────────────────────────────────────────────────┘
 (НЕТ ЗАГОЛОВКА UDP: Межсетевой экран не может определить порт источника/назначения)

Такая структура вызывает систематические потери при прохождении сетевых узлов:

Межсетевые экраны с отслеживанием состояний и шлюзы NAT: Оборудование отслеживает сессии по комбинации 4 параметров (IP источника, IP назначения, порт источника, порт назначения). Хвостовые фрагменты не имеют номеров портов UDP, поэтому шлюзы не могут сопоставить их с активной таблицей трансляции и сбрасывают пакеты.
Дисбаланс маршрутизации ECMP: Магистральные маршрутизаторы хешируют порты 4-го уровня для балансировки нагрузки между физическими линиями. Фрагменты без портов L4 направляются по альтернативным маршрутам, приводя к нарушению очередности и таймаутам сборки на стороне получателя.
Специфика IPv6: В сетях IPv6 промежуточным маршрутизаторам запрещено выполнять фрагментацию пакетов; она допускается только между конечными узлами через заголовки расширения. Корпоративные экраны часто намеренно блокируют пакеты с фрагментационными заголовками в целях защиты.

В результате фаза IKE_SA_INIT завершается мгновенно, тогда как IKE_AUTH исчезает на маршруте, приводя к зависанию процедуры согласования.

Архитектура RFC 7383: Механизм фрагментации уровня приложения внутри IKEv2

Спецификация RFC 7383, опубликованная в ноябре 2014 года, переносит процесс фрагментации с сетевого уровня 3 (IP) на прикладной уровень 7 (логика протокола IKEv2). Вместо ожидания обработки от сетевого оборудования, IKEv2 делит крупные сообщения на серию компактных самостоятельных датаграмм еще до передачи в сетевой сокет.

Уведомление о согласовании IKEV2_FRAGMENTATION_SUPPORTED

Фрагментация на прикладном уровне требует взаимного согласования. Узлы заявляют поддержку механизма в ходе IKE_SA_INIT при помощи уведомления IKEV2_FRAGMENTATION_SUPPORTED (Тип сообщения 16430):

Инициатор                                    Ответчик
┌────────────────────────────────┐         ┌────────────────────────────────┐
│ Запрос IKE_SA_INIT             │         │ Ответ IKE_SA_INIT              │
│   N(IKEV2_FRAGMENTATION_       ├────────>│   N(IKEV2_FRAGMENTATION_       │
│     SUPPORTED)                 │<────────┤     SUPPORTED)                 │
└────────────────────────────────┘         └────────────────────────────────┘

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

Зашифрованная фрагментированная нагрузка: Бинарный формат SKF (Тип 53)

При активной фрагментации негабаритные сообщения не помещаются в стандартную полезную нагрузку (SK, Тип 46). Исходная цепочка открытых данных делится на фрагменты, каждый из которых помещается в Зашифрованную фрагментированную полезную нагрузку (SKF, Тип 53):

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| След. нагрузка|C|  РЕЗЕРВ     |          Длина нагрузки       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Номер фрагмента       |         Всего фрагментов      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Вектор инициализации (IV)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Зашифрованные данные фрагмента                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Значение проверки целостности (ICV)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Назначение полей заголовка:

Следующая нагрузка: В первом фрагменте (Номер = 1) поле содержит тип первой внутренней нагрузки (например, идентификатор IDi, Тип 35). В остальных фрагментах значение равно 0.
Номер фрагмента (16 бит): Порядковый номер фрагмента, начиная с 1 (1, 2, ..., Всего).
Всего фрагментов (16 бит): Общее число фрагментов, составляющих исходное сообщение.
IV, шифротекст и ICV: Каждый фрагмент снабжен собственной криптографической оболочкой.

Каждый сгенерированный фрагмент упаковывается как полноценный пакет UDP с собственным IP-заголовком, UDP-заголовком (порт 500 или 4500) и 28-байтным заголовком IKEv2. Для сетевых экранов это стандартный трафик UDP без фрагментации на уровне IP.

Криптографическая обработка: Пофрагментная аутентификация против атомарной сборки

Принципиальным аспектом безопасности RFC 7383 выступает независимое шифрование и аутентификация каждого фрагмента:

Разделение открытого текста: Отправитель подготавливает внутреннюю цепочку полезных нагрузок (IDi | CERT | AUTH | TSi | TSr), сопоставляет объем с MTU канала и нарезает открытый поток на N частей.
Индивидуальное шифрование и вычисление ICV: Каждая часть индивидуально шифруется сессионным ключом (SK_e), после чего рассчитывается контрольная сумма ICV, покрывающая заголовок IKE, служебные поля фрагмента и шифротекст.
Проверка до помещения в буфер: Получатель пакета SKF немедленно проверяет значение ICV. Если контрольная сумма нарушена, пакет сбрасывается на сетевом интерфейсе без выделения памяти в очереди сборки.
Сборка открытых данных: После успешной проверки и расшифровки всех N фрагментов получатель восстанавливает исходную цепочку данных и разбирает сообщение как единое целое.

Защита от атак повтора и отражение DoS-атак переполнения фрагментами

Обработка фрагментированного трафика создает риски атак типа «отказ в обслуживании» (DoS). Недобросовестные узлы могут направлять неполные наборы фрагментов с целью исчерпания оперативной памяти приемника.

RFC 7383 регламентирует строгие механизмы защиты:

Привязка к идентификатору сообщения (Message ID): Все фрагменты единого логического сообщения должны иметь абсолютно одинаковый Message ID в заголовке IKE. Приемник жестко связывает фрагменты с активным состоянием сессии (IKE_SA, Message_ID).
Фиксация счетчика сообщений: Значение Message ID не возрастает от фрагмента к фрагменту; оно увеличивается только после того, как все фрагменты сообщения полностью подтверждены.
Таймауты ожидания: Реализации задают жесткий лимит времени на сборку (обычно от 15 до 30 секунд). Незавершенные фрагменты удаляются из памяти при истечении интервала.
Фильтрация на скорости интерфейса: Наличие независимой подписи ICV позволяет отбрасывать поддельные или повторно переданные фрагменты без задействования глубоких буферов операционной системы.

Совместимость с NAT-Traversal (RFC 3948) и маркерами non-ESP на порту 4500

Удаленные подключения из домашних сетей или мобильного интернета используют технологию NAT-Traversal (RFC 3948), инкапсулирующую данные в порт UDP 4500.

Спецификация RFC 7383 полностью согласована с NAT-T:

Стандартный UDP-пакет на порту 500:
┌───────────┬────────────┬──────────────┬───────────────────────────────┐
│ Заголовок │ UDP (500)  │ Заголовок    │ Зашифрованный фрагмент SKF    │
│ IP        │            │ IKEv2        │                               │
└───────────┴────────────┴──────────────┴───────────────────────────────┘

Пакет NAT-T на порту 4500:
┌───────────┬────────────┬──────────────┬──────────────┬────────────────┐
│ Заголовок │ UDP (4500) │ Маркер       │ Заголовок    │ Фрагмент SKF   │
│ IP        │            │ non-ESP (0)  │ IKEv2        │                │
└───────────┴────────────┴──────────────┴──────────────┴────────────────┘
                         (4 нулевых байта)

При обнаружении трансляции адресов сессия перемещается на порт 4500. На этом порту перед заголовком IKEv2 добавляется 4-байтный маркер Non-ESP Marker (0x00000000), разделяющий контрольные пакеты IKE и данные туннеля ESP. Фрагменты RFC 7383 содержат данный маркер, обеспечивая поддержание активных записей в таблицах трансляции NAT.

Инженерное внедрение: Интеграция стандарта RFC 7383 в архитектуру RiceGuard

В отказоустойчивой инфраструктуре VPNRice сетевой стек RiceGuard управляет динамической маршрутизацией между WireGuard в ядре Linux, OpenVPN и промышленным IPsec. Для подключений IPsec модуль RiceGuard активирует строгий режим поддержки RFC 7383.

┌────────────────────────────────────────────────────────┐
│             Диспетчер рукопожатий RiceGuard            │
└──────────────────────────┬─────────────────────────────┘
                           │
      Превышает ли исходящий IKE_AUTH лимит MTU канала?
                           │
             ┌─────────────┴─────────────┐
             │ ДА                        │ НЕТ
             ▼                           ▼
┌──────────────────────────┐   ┌─────────────────────────┐
│ Разделение на фрагменты  │   │ Стандартная упаковка в  │
│ SKF RFC 7383 (1240 байт) │   │ полезную нагрузку SK    │
└────────────┬─────────────┘   └────────────┬────────────┘
             │                              │
             └─────────────┬────────────────┘
                           │
                           ▼
┌────────────────────────────────────────────────────────┐
│             Отправка в UDP-сокет (Порты 500 / 4500)    │
│  - Отсутствие фрагментации на уровне IP                │
│  - Полная совместимость с таблицами NAT-T              │
│  - Исключение потерь в черных дырах MTU                │
└────────────────────────────────────────────────────────┘

Динамическое ограничение MTU и резервный канал RiceGuard с нулевыми потерями

В сетях сотовой связи 4G/5G и на каналах операторов реальный MTU часто ниже 1500 байт из-за накладных расходов протоколов инкапсуляции (GTP, PPPoE). Для гарантированного прохождения рукопожатия RiceGuard задействует адаптивный контроль:

Оптимальное ограничение размера фрагмента: RiceGuard ограничивает размер фрагментов RFC 7383 значением 1240 байт для IPv4 и 1200 байт для IPv6, что заведомо ниже лимита 1280 байт и предотвращает появление IP-фрагментов.
Автоматическое тестирование MTU: В ходе установления сессии система анализирует сообщения ICMP Fragmentation Needed и механизм PMTUD для оперативной корректировки границ разбиения.
Адаптивное переключение: Если внешний межсетевой экран блокирует трафик фрагментов UDP, RiceGuard переключает сессию на WireGuard или туннелирование через HTTPS, сохраняя связь без обрыва сеанса.

Практические замеры стабильности соединений в ограниченных операторских сетях

Для подтверждения практической эффективности RFC 7383 были выполнены серии тестов установления соединений с цепочками RSA-4096 (средний объем полезной нагрузки IKE_AUTH составил 4120 байт) в четырех сложных сценариях доступа:

Сетевая среда доступа	Успешность базового IKEv2 (без RFC 7383)	Успешность с фрагментацией RFC 7383	Среднее время рукопожатия	Основная причина сбоев базовой схемы
Корпоративный Wi-Fi (экран Palo Alto)	12.4%	100.0%	184 мс	Блокировка IP-фрагментов политикой безопасности
Сотовая сеть 5G (операторский CGNAT)	48.0%	100.0%	210 мс	Потеря хвостовых фрагментов без порта UDP
Спутниковый канал Starlink (плавающий MTU)	64.2%	100.0%	345 мс	Черная дыра MTU и сброс пакетов
Трансконтинентальный транзит (Токио-Лондон)	71.5%	100.0%	288 мс	Рассинхронизация очередей на маршрутах ECMP

Без использования RFC 7383 корпоративные сетевые экраны блокировали почти 88% попыток подключения из-за политик фильтрации IP-фрагментации. Активация RFC 7383 восстановила вероятность успешного соединения до 100% во всех тестовых средах, подтвердив критическую важность прикладной фрагментации для протоколов IPsec на основе сертификатов PKI.