EAP через VPN-шлюз: кто завершает метод

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

Два пути аутентификации, которые в журнале выглядят одинаково

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

На втором пути клиент и сервер аутентификации выполняют метод EAP от начала до конца, а шлюз передаёт между ними атрибуты EAP-Message. Шлюз по-прежнему завершает внешний разговор RADIUS, но логика метода живёт на двух концах.

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

Где метод действительно выполняется

RFC 3579 определяет схему сквозной передачи: NAS несёт пакеты EAP в атрибутах RADIUS и не нуждается в коде, специфичном для каждого типа EAP. Поэтому шлюз может поддерживать PEAP и EAP-TLS, не реализуя ни один из них.

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

Настройки аутентификации PPP принадлежат службе PPP. Они не перенастраивают молча каждый путь IPsec или устаревшего XAuth, использующий тот же сервер AAA, поэтому изменение, работающее для одного типа доступа, может оставить другой нетронутым.

Что должен поддерживать NAS

Сквозная передача переносит требование с кода метода на поддержку носителя. Шлюз должен уметь нести EAP через свой протокол VPN, а клиент RADIUS на нём — отправлять и принимать атрибуты EAP-Message нужных размеров.

В IKEv2 EAP является частью определённого потока аутентификации, и проверки подлинности и доверия сервера происходят из этого потока. Метка PEAP, заимствованная из развёртывания 802.1X, не переносится автоматически, потому что согласование вокруг неё другое.

У клиентской стороны тоже есть требования. Он должен быть настроен на метод, доверять сертификату сервера, который предъявляет метод, и иметь учётные данные, которые метод может использовать. Метод на основе сертификатов без клиентского сертификата терпит неудачу раньше, чем RADIUS что-либо увидит, и это проблема обеспечения, а не политики сервера.

Прочитайте одну попытку, прежде чем менять политику

Захватите одну одобренную попытку на шлюзе и на сервере аутентификации. Ищите атрибуты EAP-Message в запросе RADIUS. Их наличие говорит о том, что используется путь сквозной передачи; их отсутствие указывает на обмен учётными данными.

На шлюзе Linux захват на порту RADIUS показывает, какие атрибуты идут по линии:

sudo tcpdump -ni any -X 'udp port 1812' -c 20

Затем сравните точку отказа. Сбой на шлюзе до любого пакета RADIUS означает, что клиент и шлюз не договорились о методе. Отказ RADIUS с атрибутами EAP означает, что концы выполнили метод и один из них отклонил результат.

Планируйте миграцию как одно изменение от начала до конца

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

Запишите работающую комбинацию: протокол VPN, носитель EAP, метод партнёра, метод сервера, тип учётных данных и проверка подлинности сервера.

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