Как гибридная аутентификация IKEv1 переходит в аутентификацию пользователей IKEv2
Гибридный режим отделял доказательство шлюза от доказательства пользователя. Переход на IKEv2 сохраняет это разделение, но меняет обмен, метод EAP и проверки сертификата.
Каждый старый профиль VPN, который сначала запрашивает сертификат сервера, а затем имя пользователя, несёт два события аутентификации в одном обмене, и эта форма переживает протокол, который её ввёл. Гибридный режим IKEv1 был создан именно для этого: шлюз доказывает себя открытым ключом, а пользователь доказывает себя позже через XAuth. IKEv2 выражает ту же двухшаговую идею другим механизмом, и именно в этих различиях миграции терпят неудачу. Никакой номер версии не превращает одно в другое, а копирование старых имён параметров в новый профиль даёт клиент, который согласует параметры и затем ничего не аутентифицирует.
Что гибридный режим делал внутри IKEv1
В гибридном профиле отвечающая сторона подписывает обмен первой фазы своим сертификатом, а инициатор намеренно не предъявляет никакого. Доказательство личности поэтому асимметрично, и именно это позволило шлюзу сохранить существующую PKI, а пользователям — свои каталоговые пароли. Когда первая фаза завершена, XAuth выполняется как запрос и ответ, которые несут атрибуты имени пользователя и пароля внутри уже зашифрованного канала ISAKMP.
Обратите внимание, где оказывается доверие. Сертификат отвечает на вопрос, к какому шлюзу пришёл клиент; XAuth отвечает на вопрос, какой пользователь хочет доступ. Ни одно не заменяет другое, а клиент, настроенный принимать любой сертификат сервера, молча отбросил первый ответ. Метку «гибридный» используют и для агрессивного режима с предварительно общим ключом плюс XAuth — другой схемы с тем же пользовательским опытом, поэтому читайте профиль, а не название. Оба варианта происходят из черновиков, так и не ставших стандартами, и поэтому два производителя могут реализовать гибридный режим и не взаимодействовать ни с кем.
Как IKEv2 приходит к тем же двум доказательствам
IKEv2 делит работу между IKE_SA_INIT и IKE_AUTH. Первый обмен согласует предложения и ключи вообще без идентичностей; второй несёт IDi, IDr и полезные нагрузки AUTH. При EAP первая нагрузка AUTH инициатора уходит пустой, отвечающая сторона аутентифицируется первой своим сертификатом и подписью, а затем разговор EAP идёт внутри сообщений IKE_AUTH.
Механизм, который делает это безопасным, — ключевой материал. Успешный метод EAP экспортирует ключ сеанса, и итоговая нагрузка AUTH инициатора вычисляется из него, так что доказательство пользователя и ключи туннеля связаны. У XAuth аналога нет: его атрибуты приходят после первой фазы и ничего не вносят в ключи. Именно этот разрыв и был задуман закрыть каркас IKEv2, и поэтому работающий вход IKEv2 проверяет сертификат сервера, прежде чем что-либо спросить.
Этот порядок — ещё и полезная диагностика. Когда клиент жалуется на учётные данные, не показав вам сертификат, он вообще не выполняет обмен EAP в IKEv2.
Держите три идентичности раздельно
Миграция идёт не так, когда три идентичности сливаются в одно поле. Есть идентичность шлюза, которую проверяет клиент, обычно имя DNS в subject или SAN сертификата. Есть идентичность пользователя, предъявляемая в EAP, — возможно, доменный вход, адрес или явная строка идентичности EAP. И есть источник авторизации, который сопоставляет этого пользователя сетям и маршрутам.
Синтаксис swanctl в strongSwan делает разделение видимым: подключение задаёт remote { auth = pubkey } для шлюза и local { auth = eap-mschapv2 } для пользователя, а идентичность EAP передаётся отдельно.
Когда идентичность пользователя в новом профиле отличается от старых атрибутов XAuth, например UPN вместо короткого имени, сервер аутентификации видит неизвестного пользователя, и сбой выглядит как неверный пароль. Проверяйте строку идентичности раньше, чем учётные данные.
Сопоставьте параметры и ждите ловушек
Сопоставление короткое, и в каждой строке есть ловушка, которая проявляется только при аутентификации.
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
Ни одна из этих строк не является простым переименованием. Нагрузка конфигурации доставляет адреса и резолверы через типизированный список атрибутов, тогда как пространство атрибутов XAuth было собственным изобретением; считать их взаимозаменяемыми — так профиль и начинает просить параметр, который шлюз никогда не пришлёт.
Селекторы трафика заслуживают отдельного предупреждения. IKEv1 выражал интересующий трафик через идентификаторы прокси, привязанные к обмену quick mode, тогда как IKEv2 согласует селекторы во время IKE_AUTH, и отвечающая сторона может их сузить. Несовпадение даёт установленный IKE SA без child SA, который некоторые клиенты радостно показывают как подключённый.
Считайте старое подключение границей
RFC 9395 объявляет IKEv1 устаревшим, поэтому старое гибридное подключение — граница совместимости с датой, а не фундамент. Запускайте оба профиля параллельно на время перехода, потому что важный тест — не поднимается ли новый профиль, а попадает ли тот же пользователь на том же устройстве к тем же ресурсам.
Держите проверку сертификатов строгой до конца. Как только клиент перестаёт предъявлять собственный сертификат, возникает соблазн ослабить проверку сервера, пока рукопожатие не пройдёт, а это меняет единственное оставшееся доказательство на зелёный значок.
Запишите четыре вещи, прежде чем выводить старый профиль: метод EAP, строку идентичности, источник авторизации и дату окончания поддержки.