Как вход в VPN доходит до RADIUS и вашего поставщика идентичности
Проследите вход в VPN от клиента до запроса RADIUS шлюза, поставщика идентичности за ним и политики, применяемой после принятия.
На прошлой неделе пользователь смог войти в VPN и всё же оказался в сети, где ничего не разрешалось. Клиент говорил подключено, журнал шлюза говорил Access-Accept, а команда идентичности говорила, что учётная запись в порядке. Вход сработал; авторизация за ним — нет. Когда вход в VPN не удаётся, я прохожу путь, который запрос действительно проходит — клиент, шлюз, сервер RADIUS, поставщик идентичности — и останавливаюсь на первом шаге, чей ответ не согласуется со следующим.
Клиент никогда не говорит на RADIUS
Что бы ни показывало приложение на ноутбуке, его первый шаг — протокол VPN: IKEv2, OpenVPN, WireGuard или клиент на основе TLS. RADIUS в этом обмене не появляется. Клиент аутентифицируется на шлюзе сертификатом, именем пользователя и паролем или методом EAP, передаваемым в настройке туннеля.
Это важно при чтении журналов, потому что общую ошибку аутентификации, которую видит пользователь, создаёт шлюз после того, как он уже поговорил с чем-то другим. Если клиент так и не доходит до шлюза, запроса RADIUS для отладки нет, и час, потраченный на сервере RADIUS, потерян. Убедитесь, что туннель вообще поднялся, прежде чем трогать бэкенд.
Шлюз — это клиент RADIUS
Как только настройка туннеля доходит до момента, когда нужно проверить учётные данные, шлюз становится сервером сетевого доступа. Он строит Access-Request: User-Name, пароль или полезную нагрузку EAP, NAS-IP-Address или NAS-Identifier и Message-Authenticator, когда метод этого требует. Запрос по умолчанию идёт на UDP 1812, а учёт — на 1813. Старые развёртывания всё ещё используют 1645 и 1646, поэтому правило брандмауэра, написанное для одной пары, объясняет множество тихих сбоев.
Обе стороны разделяют секрет, и это не учётные данные пользователя. Он подписывает обмен, и каждый ответ проверяется по нему. Настройте секрет по-разному на двух сторонах, и сервер не ответит «неверный секрет» — он отбрасывает запрос или ответ не проходит проверку, поэтому шлюз сообщает о тайм-ауте. Неверный секрет и мёртвый сервер выглядят со стороны шлюза одинаково, поэтому я проверяю этот шаг клиентским инструментом, прежде чем винить каталог.
Протокол мал и стар — RFC 2865 определяет обмен аутентификации — но атрибуты, которые он несёт, — это основа, на которой построена большая часть политики VPN.
# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123
# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'Сервер RADIUS может быть лишь фасадом поставщика идентичности
Люди говорят о RADIUS и поставщике идентичности так, будто это один и тот же ящик. Часто это не так. Сервер RADIUS получает Access-Request и затем, прежде чем ответить, спрашивает что-то ещё — Active Directory через LDAP или Kerberos, локальный файл пользователей или внешний сервис. FreeRADIUS с модулем LDAP или krb5, Windows NPS и Cisco ISE все стоят на этой позиции.
Это различие решает, куда смотреть. Отклонённый пароль — это ответ поставщика идентичности, переданный RADIUS. Тайм-аут обычно означает участок RADIUS–каталог: истёкшая учётная запись привязки, недоступный каталог или запрос, направленный на неверный бэкенд. Если имя пользователя несёт суффикс домена, сервер может маршрутизировать по нему, и одна и та же учётная запись, отправленная как CORP\alice и [email protected], может оказаться в разных местах. В Windows NPS журнал Security записывает 6272 при разрешении и 6273 при отказе, что говорит, пришло ли решение вообще от NPS.
Читайте сбой на том шаге, который его создал
Одно сообщение о невозможности подключиться охватывает четыре разных сбоя. Прежде чем что-то менять, сопоставьте симптом с шагом, который его создал.
| What you see | Where it comes from | First check |
|---|---|---|
| Gateway timeout, no reply | Shared secret mismatch, UDP 1812 blocked, unknown NAS, wrong server address | tcpdump at the gateway; radtest from the gateway host |
| Immediate reject | Credentials, account state, domain suffix, RADIUS policy | NPS 6273 or the FreeRADIUS auth log; test the account directly |
| Repeated challenge or MFA loop | Access-Challenge state not returned, or a token that expired mid-flow | Client prompt timing and the State attribute in debug output |
| Accept, then no access | Authorization attributes unmapped, wrong pool, route or ACL policy | Gateway policy and the attributes in the Access-Accept |
Именно последняя строка отправляет людей не к той команде. Access-Accept означает, что учётные данные приняты; это не значит, что шлюз поместил пользователя в нужный пул или протолкнул маршруты. Атрибуты группы важны только если политика шлюза их читает. Я видел, как корректный вход попадал в гостевой пул, потому что сопоставление групп на стороне RADIUS было настроено для другого атрибута, чем тот, который проверяет шлюз.
Проследите один вход от начала до конца
Выберите одну тестовую учётную запись и один шлюз, затем наблюдайте одну и ту же попытку во всех четырёх точках. Запустите отладку на стороне RADIUS — freeradius -X печатает запрос и каждый модуль, которого он касается — следите за журналом аутентификации шлюза и запустите tcpdump для обмена UDP. Подключитесь один раз и прочитайте четыре трассы по порядку.
Вы хотите увидеть согласие: шлюз спросил о пользователе, которого вы ожидали, сервер RADIUS выбрал бэкенд, который вы ожидали, этот бэкенд вернул решение, а атрибуты в ответе соответствуют политике, которую применяет шлюз. Первое место, где трассы расходятся, — ваша линия сбоя. Если ответ не несёт атрибута группы, проблема на стороне RADIUS, а не в профиле VPN; если атрибут есть, а шлюз его игнорирует, проблема в политике шлюза.
Одно замечание по безопасности, пока вы там. Общий секрет защищает обмен, но он не шифрует большинство атрибутов. Если шлюз и сервер RADIUS находятся в разных сегментах, поместите этот участок на RADIUS через TLS или по частному пути. Зашифрованный пользовательский туннель ничего не говорит о канале до бэкенда.
Прежде чем закрыть тикет, подтвердите четыре вещи. Шлюз достигает сервера RADIUS на том порту, для которого он действительно настроен. Общий секрет совпадает на обеих сторонах. Сервер RADIUS разрешает именно ту форму имени пользователя, которую отправляет шлюз. Принятие несёт атрибуты, нужные политике шлюза. Когда выполняются все четыре, вход, который всё ещё не удаётся, — это проблема политики шлюза, а не аутентификации.