Кратко

  • Редакция 07 позволяет оставить IKEv2 на TCP, а ESP отправлять напрямую по IP или в UDP; наличие действующей Child SA не является доказательством достижимости ESP.
  • Переговоры, отдельное состояние NAT, защищённый ответ ESP, прикладной обмен и решение о переходе на TCP должны иметь разные квитанции: подлинность может сохраниться при полной недоступности.

У оператора есть все основания поверить зелёному индикатору. TCP-соединение установлено, узлы IKEv2 взаимно аутентифицированы, ключи выработаны, Child SA присутствует. И всё же приложение не получает ни одного защищённого пакета.

Контрольный поток прошёл по правилу для TCP. Нативный ESP попал под другое правило. Или NAT поддерживает состояние TCP для IKE, но не создал UDP-сопоставление для ESP на порту 4500. Состояние безопасности существует; работоспособный путь данных ещё не подтверждён.

Именно это различие фиксирует активный проект IPsecME Separate Transports for IKE and ESP. Редакция 07 относится к IETF stream, предназначена для Standards Track и в замороженной записи Datatracker имеет состояние «WG Consensus: Waiting for Write-Up». Это не RFC и не свидетельство внедрения.

IKEv2 исторически работает поверх UDP. RFC 9329 описал совместную упаковку IKE и ESP в TCP для сетей, где UDP не проходит. Одновременно постквантовые обмены увеличивают объём открытых ключей и управляющих сообщений. TCP удобен для большого обмена, но не обязательно оптимален для всего ESP-трафика. Проект отделяет транспорт управления от транспорта данных.

Стороны обмениваются уведомлением SEPARATE_TRANSPORTS. При взаимном согласии последующие IKE-сообщения остаются на TCP, а ESP идёт напрямую по IP либо в UDP при NAT. Если ответчик не подтвердил возможность, IKE и ESP продолжают вместе по TCP согласно RFC 9329.

Согласие означает возможность, а не доставку.

Если IKE_SA_INIT начался по UDP, успешный ответ уже даёт ограниченное доказательство доступности UDP. Если он начался по TCP, о доступности ESP из этого ничего не следует. Поэтому после создания Child SA инициатор должен проверить ESP, если у него нет иной равнозначной информации, например входящего защищённого трафика.

Проект специально разделяет безопасность и доступность. Отсутствие подтверждения ESP само по себе не ослабляет аутентификацию IKEv2 и криптографическую защиту Child SA. Ключи и личности могут быть правильными, а сервис — недоступным. Называть это провалом аутентификации неверно; объявлять туннель рабочим тоже нельзя.

NAT хранит состояние отдельно для каждого транспорта. TCP-соединение IKE не поддерживает UDP-сопоставление ESP. Для ESP требуются собственные keepalive. Корректный ESP-пакет с нового адреса может обновить связанные ESP SA, но не конечную точку IKE. Защищённое IKE-сообщение меняет управление, но не удостоверяет адрес ESP.

Один криптографический партнёр — две сетевые памяти.

При старте IKE по TCP редакция 07 предлагает проверку. Если обнаружен NAT, проверяется ESP в UDP 4500. Если NAT не найден, сначала пробуют нативный ESP, затем после короткой задержки — UDP, поскольку некоторые посредники блокируют IP без UDP- или TCP-заголовка. Выбирается первый ответивший путь, по логике, похожей на Happy Eyeballs.

Encrypted ESP Echo может дать такую квитанцию. Она доказывает прохождение защищённого запроса и ответа под конкретной SA. Она не доказывает все размеры пакетов, все Traffic Selectors, состояние сервиса за туннелем или успешный результат пользователя. После сетевого эха нужен представительный прикладной обмен.

Если ESP подтвердить нельзя, инициатор должен удалить текущую IKE SA и заново установить её по TCP, не предлагая раздельный ESP. Это возврат к связанному режиму RFC 9329. Локальная политика решает, допустим ли ESP поверх TCP или соединение следует прекратить. Аварийный доступ и высокопроизводительный поток могут получить разные ответы.

После смены адреса MOBIKE старое доказательство не действует на новом пути: там другие фильтры и NAT. Восстановление сессии тоже не должно сохранять выбор транспорта в ticket, поскольку клиент мог проснуться в другой сети. Ускоренное восстановление отношений безопасности не замораживает физическую среду.

Подход соответствует принципам Heng Lu: минимальная начальная спецификация передаёт только совместимую возможность, а будущее решение остаётся у стороны, которая видит будущие факты. Символическое состояние «SA создана» не выше наблюдаемого движения пакетов. Running-Code Primacy требует фактического исполнения.

Операционный журнал должен раздельно хранить транспорт IKE, принятие уведомления, результат NAT, вариант ESP, его mapping и keepalive, первый защищённый ответ, прикладной тест, разрешение fallback и повторную проверку после мобильности или восстановления. Сводка «VPN поднят» для такой схемы недостаточна.

Источники