strongSwan ESP-in-UDP: когда нет NAT, который нужно обнаружить

Обнаружение NAT находит трансляцию адресов, а не политику межсетевого экрана. Соединению площадки без NAT всё равно может потребоваться явный выбор ESP-in-UDP.

Обнаружение NAT отвечает на один вопрос: изменились ли адреса или порты в пути? Оно не отвечает, пропускает ли межсетевой экран протокол IP 50. Шлюзы площадки без какой-либо трансляции могут по-прежнему стоять за политикой, отбрасывающей native ESP, и это требование нужно настроить, а не обнаружить. Механизм — ESP-in-UDP, и это решение, а не запасной вариант, появляющийся сам собой.

Обнаружение — это арифметика над адресами, а не проверка межсетевого экрана

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

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

Таким образом, инкапсуляция — свойство настраиваемого соединения, а не результат, который стороны согласуют из поведения сети.

Как encap меняет обмен

В современной установке strongSwan, управляемой через swanctl.conf, параметр encap = yes на соединении влияет на обмен обнаружения NAT так, что обе стороны используют инкапсуляцию UDP для ESP. Защищённые пакеты затем идут внутри UDP, обычно на порту 4500, и оба конца должны договориться об этой схеме.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

Этот фрагмент относится внутрь настоящего определения соединения и не является полным профилем площадки. Оставьте адреса партнёра, аутентификацию и селекторы трафика child, которые вы уже используете; единственный добавленный ключ меняет то, как упаковываются защищённые данные, а не что они защищают.

Руководство strongSwan по NAT-traversal описывает это поведение, включая взаимодействие с плавающим портом при использовании MOBIKE.

Используйте параметр, который относится к вашему backend

У strongSwan два backend конфигурации, и ключ различается между ними. swanctl.conf соединение принимает encap, а устаревшее ipsec.conf соединение принимает forceencaps. Если вставить ключевое слово одного backend в другой, получится конфигурация, которая загружается без жалоб и ничего не меняет, что хуже ошибки.

Проверьте, какой демон действительно работает, прежде чем что-либо редактировать. Во многих дистрибутивах есть оба файла, потому что один — остаток прежней миграции, а активен тот, который запускает служебный юнит. Читайте этот юнит, а не угадывайте по временным меткам файлов. Проверка на пять секунд здесь избавляет от часов тестирования настройки, которую ничего не загрузило.

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

Проверяйте упакованные данные, а не только порт

Снимите дамп на шлюзе, пока идёт защищённый трафик, затем сравните это с собственным представлением strongSwan:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

Native ESP выглядит как протокол IP 50 и совсем не похож на UDP. Упакованный ESP выглядит как UDP-датаграммы на 4500, полезная нагрузка которых не IKE. Трафик IKE на том же порту не является доказательством инкапсуляции, потому что MOBIKE может перенести IKE туда, пока путь данных остаётся native, поэтому читайте полезную нагрузку, а не номер порта.

Учитывайте и MTU пути. Обёртка добавляет накладные расходы, и путь, который нёс native ESP, может потребовать корректировок при росте пакетов. Необходимая обработка ICMP должна уже быть частью проекта; инкапсуляция не устраняет эту зависимость.

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

Похожие статьи