Кратко

  • Проект IPSECME от 1 октября теперь прямо описывает защищённое сообщение IKE, пришедшее по новому TCP-соединению с иным исходным IP-адресом и/или портом. Соединение используется только для IKE SA и не должно менять исходный адрес или порт ни одной созданной ею дочерней ESP SA.
  • Если ожидается двусторонний трафик, отсутствие входящих пакетов ESP может указывать на возможную проблему связности. Зашифрованный ESP ping остаётся альтернативной проверкой. Молчание не равно доказанному отказу, а успешный IKE-обмен не подтверждает доставку ESP.

Панель управления способна показывать успешное согласование VPN, хотя полезный трафик не проходит. Это не ошибка логики протокола: IKEv2 договаривается об ассоциациях безопасности, а ESP переносит защищённые пакеты. Обсуждаемый проект допускает TCP для объёмных управляющих обменов, сохраняя ESP на прямом IP или в UDP, если соответствующий путь открыт. Разделение убирает необходимость помещать весь ESP-трафик в TCP ради одного крупного обмена ключами. Но и состояние маршрутов становится разным: посредник может пропускать TCP и блокировать UDP либо держать их NAT-сопоставления разное время.

Содержательное изменение версии 08 видно при сопоставлении раздела о NAT с версией 07. Прежняя фраза говорила о защищённом сообщении IKE с нового исходного адреса или порта. Новая привязывает его к новому TCP-соединению с отличающимися исходным IP и/или портом. Узел вне NAT использует именно это соединение для IKE SA и не меняет по его причине сохранённый исходный адрес и порт ESP SA. Если же с нового источника придёт ESP-пакет, прошедший проверку целостности, для обновления ESP предусмотрено отдельное правило. Событие в управляющем канале не переносит автоматически конечную точку канала данных.

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

Вторая правка касается признака неполадок. Для потока, который должен идти в обе стороны, отсутствие входящих ESP-пакетов обозначает возможную проблему. Упоминавшийся прежде зашифрованный ESP ping остаётся способом отдельной проверки. Но и простой приложения, и намеренно односторонний обмен, и неверно поставленный датчик дадут похожую картину. В тексте нет разрешения автоматически обвинять межсетевой экран, NAT или злоумышленника лишь на основании тишины.

Другие правила проекта уже проводили ту же границу. TCP-соединение IKE не сохраняет UDP-сопоставление NAT для ESP: для него нужны отдельные keepalive-пакеты. Если IKE начинается по TCP, успешное согласование не является неявным доказательством доступности ESP. После создания дочерней SA инициатору следует проверить ESP-путь, если нет иных свидетельств. Если подтвердить его нельзя, он обязан удалить существующую IKE SA и создать новую по TCP без предложения отдельного транспорта для ESP. Такой переход обусловлен проверкой пути данных, а не общим индикатором «туннель поднят».

Datatracker характеризует документ как активный Internet-Draft рабочей группы, направленный на публикацию; это ещё не утверждённый RFC. Номер уведомления в тексте пока ожидает назначения. Из изученных источников не следует ни внедрение у определённого поставщика, ни реальный сбой. Проверяемый факт состоит в более строгой границе между новым соединением управления и состоянием передачи данных.

Источники