Обмен IKEv2 проходит, а затем аутентификация срывается: где искать

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

Проверка 1: читайте этап, а не сообщение

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

Каждый порождает свою строку журнала на своей машине, и у каждого своё решение. Отказ клиента от сертификата сервера — это проблема доверия или именования на клиенте; отказ шлюза от сертификата клиента — проблема доверия на шлюзе; сбой EAP — проблема учётной записи или бэкенда. Сообщение, которое вы видите, обычно является сводкой клиента об одном из этих случаев, поэтому журнал шлюза так же важен, как и журнал клиента.

Проверка 2: какая идентичность проверялась

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

В терминах strongSwan это rightid на клиенте и собственная идентичность шлюза на другой стороне, и несовпадение приводит к отказу ещё до обсуждения EAP.

Шлюз отдельно может отклонить сертификат клиента, доказательство владения ключом или аутентификацию учётной записи, и эти три не взаимозаменяемы. Сброс пароля пользователя не обновляет сертификат устройства, а переустановка сертификата устройства не исправляет неверную идентичность сервера. При сбоях сертификатов сначала проверьте часы, затем цепочку доверия, затем ожидаемый идентификатор; клиент, часы которого расходятся на несколько минут, не проходит проверку срока действия, похожую на сбой доверия. swanctl --list-certs на обоих концах показывает, чем каждая сторона действительно располагает.

Проверка 3: если задействован EAP

Клиент и сервер должны договориться о поддерживаемом методе, а бэкенд должен принять предоставленную идентичность.

Имени пользователя может требоваться доменный суффикс или определённый формат учётной записи, который задаёт развёртывание, и этот формат документирован, а не угадывается. Указание документированных полей оператора быстрее перебора вариантов и позволяет избежать второй проблемы: повторные попытки могут вызвать блокировку учётной записи, которая затем скрывает исходный этап за новой ошибкой. Если метод — EAP-MSCHAPv2 против каталога, сбой может относиться к каталогу, а не к VPN.

Не проверяйте проблемы идентичности, отключая проверки идентичности. Это превращает диагностируемый сбой в недиагностируемый и оставляет соединение слабее, чем прежде.

Проверка 4: что происходит после успешного входа

Когда IKE_AUTH завершается, согласование CHILD_SA решает, какие селекторы трафика будут установлены, и именно там соединение может установиться и всё равно ничего не пропускать.

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

Проверка 5: что передать в поддержку

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

Запишите время с часовым поясом, версии клиента и шлюза, метод, строку идентичности, которая была предложена, а не пароль, и точный этап, который её отклонил. документация по настройке IKEv2 от strongSwan описывает параметры идентичности и EAP, которые определяют эти результаты, и это справочник, который нужно прочитать перед изменением поля. Затем измените одну вещь и заново проверьте новое соединение, потому что кэшированная сессия расскажет о старой конфигурации.