IKEv2 — это не одно рукопожатие: IKE SA, аутентификация, затем CHILD SA
Ответ шлюза доказывает доступность, а не личность. Проследите IKE_SA_INIT, IKE_AUTH и первый CHILD SA, затем проверьте, что должно быть верно до прохождения трафика.
Возможно, вы считаете, что соединение IKEv2 — это один обмен, заканчивающийся шифрованием трафика. На деле их минимум два, и первый никого не аутентифицирует. Стороны начинают с управляющих сообщений, договариваются о криптографических параметрах, доказывают личность и лишь затем согласуют состояние, переносящее пакеты приложений. Этот порядок объясняет несоответствие, о котором постоянно сообщают: шлюз отвечает, клиент показывает подключение, а приватное приложение по-прежнему уходит в таймаут. Ниже — что делает каждый этап и что должно быть верно после него.
Миф: если шлюз отвечает, вы подключены
Ответ на первое сообщение доказывает, что конечная точка достижима и готова говорить. Он не доказывает, что учётная запись принята, цепочка сертификатов проверена или установлена хоть какая-то политика данных.
Эти отказы случаются позже и дают другие симптомы. Отказ сертификата или сбой EAP приходит уже после успешного первого обмена, поэтому ping по UDP 500 и зелёный значок клиента говорят так мало.
IKE_SA_INIT: договоритесь о параметрах, а не о личности
Первый обмен несёт предложения для ассоциации безопасности IKE: алгоритмы шифрования и целостности, псевдослучайную функцию и группу Diffie-Hellman. Стороны также обмениваются nonce, и каждая выводит ключевой материал для IKE SA из общего секрета, который создают эти значения. Ничто в этом обмене не устанавливает, кто вторая сторона. Он устанавливает лишь, что обе стороны могут вычислить одни и те же ключи и согласны с предложением. Ответчик, которому не нравится ни одно предложение, отклоняет обмен здесь, поэтому расхождение версии или алгоритма выглядит как упавший сервер.
Созданная здесь IKE SA защищает все последующие управляющие обмены. Это её работа, и она отличается от защиты ваших пакетов.
IKE_AUTH: докажите личность, затем постройте первый CHILD SA
Второй обмен несёт личность. С сертификатами каждая сторона подписывает своим закрытым ключом и предъявляет цепочку, которую другая должна проверить; с EAP ответчик вызывает инициатора выбранным методом. Здесь наконец всплывают неверное имя сервера, истёкший сертификат или отклонённый пароль.
Обычно IKE_AUTH согласует и первый CHILD SA, поэтому защита данных договаривается в том же круге. Инициатор предлагает селекторы трафика, ответчик сужает или отклоняет их, а ключи пути данных выводятся из IKE SA. Значит, один обмен может отказать в двух совсем разных местах: в личности или в политике. Читайте уведомление или ошибку, а не общий сбой рукопожатия: лечится одно сертификатом, а другое — несовпадением подсети.
Две SA, две работы
| Ассоциация | Защищает | Поведение времени жизни |
|---|---|---|
| IKE SA | Управляющие обмены: перевыработка ключей, удаление, нагрузки конфигурации | Обновляется по собственному графику; путь данных может пережить изменение |
| CHILD SA | Трафик приложений, совпадающий с селекторами трафика | Обновляется независимо, часто чаще |
Их разделение объясняет два поведения, похожих на ошибки. Туннель может выглядеть установленным, пока в фоне сбоит перевыработка ключей, а CHILD SA может быть заменена без потери соединения у клиента.
В strongSwan справочник по конфигурации IKEv2 и swanctl --list-sas показывают оба уровня, а ip xfrm state вместе с ip xfrm policy показывают, что ядро установило на самом деле. Сравнение этих двух видов — самый быстрый способ увидеть, завершились ли переговоры или только казались завершёнными. Если демон перечисляет CHILD SA, для которой у ядра нет состояния, установка тихо не удалась. Если ядро держит состояние, о котором демон не знает, вы смотрите на остаток прошлой попытки.
Что ещё должно быть верно после подъёма туннеля
Селекторы трафика определяют, какие адреса охвачены. Если клиент предлагает одну подсеть, а сервер ждёт другую, CHILD SA устанавливается, но не несёт ничего полезного, и ошибка выглядит как проблема маршрутизации, а не переговоров. Затем локальный стек должен помочь: пересылка включена там, где хост маршрутизирует, маршруты в туннель, правила брандмауэра, пропускающие декапсулированные пакеты, и внутренний резолвер, если задействованы приватные имена. Каждый из них отказывает отдельно, и ни один не чинится перезапуском демона IKE.
Держите журнал на виду при диагностике: начальный обмен, затем проверка личности, затем аутентификация пользователя там, где она применяется, затем установка CHILD и наконец трафик приложения. Останавливается тот этап, который нужно исправить, и поздний сбой маршрутизации никогда не повод ослаблять уже пройденные проверки личности.