Какой адрес регистрировать как клиент RADIUS для NPS?

VPN-шлюзу, который передаёт аутентификацию в Windows NPS, нужен один объект на стороне NPS, прежде чем заработает любая политика пользователя: запись клиента RADIUS для шлюза. Большинство неудачных попыток регистрируют неверный адрес, потому что важен адрес, который шлюз использует на своём backend-пути, а не имя хоста, которое сотрудники вводят в приложении VPN. Если это значение неверно, NPS молча отбрасывает запрос, и со стороны клиента это выглядит как неверный пароль. Какой адрес принадлежит полю, решают три условия, поэтому разберитесь с ними до открытия консоли.

Регистрируйте шлюз, а не ноутбуки или пул

Объект клиента RADIUS представляет устройство сетевого доступа, которое отправляет запросы аутентификации. Это VPN-шлюз, а не каждый ноутбук с клиентом и не диапазон адресов, выдаваемых внутри туннелей.

Эти туннельные адреса никогда не появляются как источник запроса RADIUS, потому что запрос идёт по собственному сетевому пути шлюза. Регистрация записи пула клиентов создаёт политику, которая никогда не совпадёт, тогда как настоящий запрос приходит с адреса, о котором NPS никогда не слышал. Та же путаница заставляет людей добавлять домашний IP каждого сотрудника, что одновременно необслуживаемо и неверно.

Введённый адрес определяют три условия

Сначала найдите адрес источника, который шлюз действительно использует в сторону NPS. Шлюз с несколькими интерфейсами часто отправляет с интерфейса управления или backend, а не со своего публичного прослушивателя VPN. Во-вторых, проверьте, есть ли между ними NAT: если запрос транслируется, NPS видит транслированный адрес, и именно это значение нужно регистрировать. В-третьих, если два шлюза делят роль, каждому источнику запросов нужна своя запись клиента, потому что один объект с одним адресом покрывает только один из них.

Запись с двумя концами держит пару в порядке. В таблице ниже для иллюстрации используются частные адреса, поэтому замените их теми, которые действительно использует ваш путь.

Подтвердите источник, а не угадывайте его. Во время одной попытки смотрите журнал NPS или межсетевого экрана либо снимите трафик на хосте NPS командой sudo tcpdump -ni any udp port 1812. Адрес из этой записи — единственный защитимый ответ для записи клиента. Если у шлюза несколько возможных источников, зарегистрируйте каждый под его собственным понятным именем.

Общий секрет — это значение между шлюзом и NPS

Общий секрет удостоверяет связь устройств. Это не пароль пользователя, и он никогда не раздаётся сотрудникам и не встраивается в профили клиентов.

Выберите одно значение, введите его в обоих местах и храните там, где лежит резервная копия конфигурации шлюза. Несовпадение даёт запрос, который NPS отбрасывает без полезной ошибки, и в журнале шлюза это неотличимо от недоступного сервера. Меняйте его в окно обслуживания и обновляйте оба конца в одном изменении.

Подтвердите одной разрешённой заявкой

Используйте контролируемую учётную запись и сопоставьте одну попытку с обеих сторон. На шлюзе подтвердите, что запрос ушёл к нужному серверу; в NPS — что он пришёл от зарегистрированного клиента и совпал с ожидаемой политикой запросов на подключение. Тайм-аут и отказ означают разное, и трактовка обоих как проблемы с учётными данными теряет следующий час. Затем проверьте действительную, но неподходящую учётную запись и неверный пароль, потому что политика, принимающая всё, проходит и первую проверку.

Наконец, проверьте, что шлюз делает с возвращённой авторизацией. Регистрация клиента RADIUS лишь разрешает устройству участвовать; она не даёт каждой возникшей сессии доступ к LAN.

Держите диагностический вывод ограниченным: никаких общих секретов, никаких паролей пользователей, никаких полных полезных нагрузок пакетов в заявке в поддержку. Если проект требует, чтобы сервер NPS читал атрибуты каталога, это разрешение — отдельная административная задача от регистрации клиента, и при его отсутствии она отказывает иначе.