Как NAT traversal упаковывает ESP в UDP

Два клиента за одним маршрутизатором общаются с одним шлюзом IPsec, и один постоянно отваливается, а другой держится. Родной ESP — это IP-протокол 50 без портов, поэтому транслятору не за что зацепить отображение, когда несколько клиентов делят один адрес. NAT traversal закрывает эту брешь, упаковывая ESP в UDP на 4500, и этот заголовок объясняет большинство последующих симптомов. Он также указывает на устройство, которое нужно изменить.

Почему плоскость данных переходит на порт 4500

При настройке IKEv2 сравнивает адреса и порты, которые каждая сторона считает используемыми, обмениваясь хешами в своих уведомлениях об обнаружении NAT. Когда хеши не совпадают, где-то на пути стоит транслятор, и обе стороны переводят защищённый трафик на инкапсуляцию UDP. Поэтому сеанс, столкнувшийся с транслятором, выглядит иначе, чем тот, что не столкнулся.

Обёртка — это конверт, а не смена протокола: ESP сохраняет свой заголовок, проверку целостности и шифрование, а UDP предоставляет только те порты, которые нужны транслятору. Порт 500 несёт обмен IKE; 4500 несёт инкапсулированные данные после обнаружения и часто более поздние сообщения IKE. Ни один из портов не делает поток TCP-соединением, и именно это допущение вводит в заблуждение большинство читающих захват.

Проверьте два этапа по порядку

Сначала докажите обмен управления, затем путь данных, и держите оба отдельно в своих заметках. Захват, показывающий трафик на 500 и никогда на 4500, обычно означает, что путь данных фильтруется, поэтому исправление относится к правилу межсетевого экрана, а не к клиенту.

Наблюдайте оба порта с помощью tcpdump -ni any 'udp port 500 or udp port 4500' и читайте таблицу трансляции на маршрутизаторе, пока сеанс активен. Таблица показывает исходный порт, который шлюз реально увидит, а захват на ноутбуке расходится с ней намеренно: ноутбук считает 500, тогда как шлюз видит 4500 с транслированным исходным портом, и оба правы. Тот же поток до и после трансляции:

client 192.0.2.10:500 -> router 203.0.113.7:62000 -> gateway 198.51.100.9:4500

Симптомы, которые объясняет обёртка, и два, которые не объясняет

Маршрутизатор, который разрешает обмен управления и блокирует инкапсулированные данные даёт отчёт «туннель поднят, но ничего не проходит». Таблицы отображений истекают, поэтому простаивающему сеансу нужен трафик поддержки, который стороны отправляют намеренно, и эти пакеты не являются проверками здоровья. Когда несколько клиентов за одним шлюзом падают вместе, исследуйте трансляцию этого шлюза и любую устаревшую функцию пропуска. Обёртка не объясняет приложение, падающее у каждого клиента после поднятия туннеля, и не объясняет предупреждение о сертификате на странице блокировки; и то и другое находится выше этого уровня.

Читайте таблицу отображений сразу для двух клиентов: если оба показывают один и тот же транслированный порт, устройство не разделяет их так, как требует шлюз. Режим пропуска, отдающий родной ESP только одному хосту, не эквивалентен обслуживанию нескольких транслированных клиентов, хотя поставщики описывают оба как дружественные к IPsec. Двойной NAT добавляет слой отображений и ещё одну точку истечения, но не рвёт исходящие соединения автоматически.

Трафик поддержки заслуживает отдельной строки в руководстве по эксплуатации, потому что именно он держит путь ответа открытым в периоды простоя. Включите его там, где поставщик это документирует, и проверяйте его первым, когда сеанс умирает после нескольких минут тишины, а не при первом использовании.

Смените владельца отображения, затем повторите тест

Следуйте поддерживаемым настройкам NAT traversal на обеих сторонах, а не угадывайте порт. Правка локального исходного порта у одного клиента не может изменить службу, слушающую на другом конце, и обычно ломает уже построенное отображение. Если клиент находится за устройством, которым вы не управляете, изменение принадлежит его владельцу.

После любого изменения повторите обе проверки этапов и подтвердите, что пакет данных проходит, а не только что экран состояния стал зелёным. Держите кортежи, вывод таблицы отображений и изменение правила в одной заметке, чтобы следующий человек не начинал заново с обмена управления. Заметки strongSwan о NAT traversal охватывают настройки инкапсуляции и поддержки за обоими этапами.