EAP или клиентские сертификаты? Как выбрать аутентификацию IKEv2

Ваш шлюз может доказывать собственную подлинность сертификатом и вашу — через EAP, и это сочетание обычно, а не противоречиво. Два механизма отвечают на разные вопросы: та ли это конечная точка, которую я ожидаю, и разрешён ли этот пользователь или устройство. Наличие EAP в профиле не отключает проверку сервера. Именно чтение профиля как одной настройки заставляет людей сбрасывать не те учётные данные.

Определите, какое утверждение не прошло, прежде чем трогать любой из двух объектов. Этап отказа скажет об этом, если читать по порядку.

Два учётных данных, два утверждения

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

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

EAP — это контейнер, а не метод

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

Читайте метод и бэкенд вместе. Бэкенд определяет формат учётной записи, поведение при блокировке и то, что на самом деле меняет сброс пароля, и ничего из этого не видно в профиле клиента.

Смешанное развёртывание — это норма

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

Спросите у оператора документированные метод и формат учётной записи, вместо того чтобы выводить их из имён полей в клиенте.

Решение по этапу отказа

Упорядочьте наблюдения. Ошибка доверия до любого запроса к пользователю — это проблема серверного сертификата, и никакой пароль её не исправит. Запрос, за которым следует отказ, — это проблема аутентификации пользователя, и подозреваемые — метод EAP и бэкенд. Успешная аутентификация, за которой следует отказ child-SA, — ни то, ни другое.

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

Эксплуатация двух моделей

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

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

После того как личность принята

Аутентификация — это одни ворота. Дочерняя ассоциация безопасности, селекторы трафика, DNS и собственные разрешения приложения — это последующие ворота, и каждые отказывают на своих условиях. Принятая личность, которая никуда не доходит, — не проблема аутентификации.

Запишите метод, использованную учётную запись или сертификат и этап, который отказал. Эта заметка превращает следующий инцидент в поиск, а не в эксперимент.