От strongSwan к AWS Site-to-Site: почему Child SA ничего не выбирает

Туннель IKE может быть поднят, а дочерняя ассоциация исключает ваши подсети. Сначала сравните локальный и удалённый CIDR в AWS с leftsubnet и rightsubnet.

Консоль показывает up, strongSwan сообщает об установленной ассоциации IKE, а пакеты всё равно не приходят. Сравнивать нужно не общий предварительный ключ, а пару префиксов, которые каждая сторона считает защищёнными туннелем. Пройдите проверки ниже по порядку, потому что первые две решают, может ли туннель вообще нести ваш трафик.

Переведите названия AWS в термины strongSwan

AWS описывает подключение со стороны клиента: адрес клиентского шлюза и локальный CIDR принадлежат вам, а удалённый CIDR относится к VPC. strongSwan называет два конца left и right, ваш префикс находится в leftsubnet, а префикс VPC — в rightsubnet. Перестановка одной пары даёт туннель, который согласует и выбирает неверный трафик.

Скачайте конфигурацию, которую AWS создаёт для подключения, и считайте её эталоном именно для этого подключения, включая адреса и префиксы туннеля. Если при создании оставить оба поля CIDR пустыми, сервис использует значение по умолчанию 0.0.0.0/0 с каждой стороны. Маршрутизатор с узким префиксом тогда никогда не совпадёт, поэтому либо заполните поля, либо намеренно расширьте селектор.

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

Зафиксируйте адрес, который AWS действительно видит

Маршрутизатор за NAT может отправлять IKE с интерфейса, о котором другая сторона никогда не знала. Адрес шлюза, записанный в AWS, должен быть тем, который AWS наблюдает в сети, а маршрутизатор нужно привязать к тому же локальному адресу вместо следования маршруту по умолчанию.

conn %default
    local_addrs = 203.0.113.10

В strongSwan local_addrs выбирает адрес источника для IKE, а старые конфигурации OpenSwan записывают ту же идею как left. Направьте его на интерфейс с публичным адресом, затем проверьте на самом устройстве NAT, что UDP 500 и 4500 доходят до этого хоста, потому что правило, оставшееся от прежнего маршрутизатора, молча их отбрасывает. Правильная пара селекторов с неверным адресом источника всё равно не работает, и журнал обвинит предложение. Именно эта путаница — причина, по которой адрес источника заслуживает отдельной проверки.

Подтвердите правило переадресации, а не предполагайте его, потому что правило, верное для прежнего маршрутизатора, часто остаётся.

Рассматривайте фазу 1 и фазу 2 отдельно

AWS показывает параметры IKE и ESP отдельными списками. Набор IKE, который принимают обе стороны, ничего не говорит о предложении ESP, потому что списки независимы. Прочитайте оба из созданной конфигурации и сравните их по одному.

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

Синтаксис не переносится между реализациями. Пару, работающую в OpenSwan, например phase2alg=aes_gcm с ike=aes256-sha1;modp1024, нужно перевести в форму esp= и ike= strongSwan, и имена алгоритмов различаются. Поскольку GCM аутентифицирует во время шифрования, ему не нужна отдельная трансформация целостности, в отличие от набора CBC в паре с SHA. Строка фазы 2, вставленная из одного демона в другой без перевода, даёт отказ, который читается как несовпадение селекторов.

Проверяйте дочернюю ассоциацию, а не индикатор туннеля

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

ipsec statusall

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

Проверьте с хоста внутри локального префикса до хоста внутри префикса VPC и проверьте обратный путь, а также любую группу безопасности или сетевой ACL на стороне AWS. Правильные селекторы не защищают пакет от более позднего отбрасывания.

Когда после совпадения селекторов всё ещё не работает

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

Запишите по одному входящему и одному исходящему пакету с каждой стороны, прежде чем менять очередное предложение.

Запишите селекторы, предложения фазы 1 и фазы 2 и адрес источника в заявку. Эти четыре значения объясняют большинство сбоев site-to-site без звонка.

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