NPS: установка и настройка сервера сетевых политик для RADIUS, Wi-Fi и VPN

Network Policy Server (NPS) в Windows Server централизует аутентификацию, авторизацию и учет сетевых подключений через RADIUS. С его помощью точки доступа Wi-Fi, VPN-шлюзы и коммутаторы 802.1X передают запросы на сервер политик, а NPS проверяет учетные данные через Active Directory и возвращает разрешение или отказ.

Рабочая схема выглядит так: клиент подключается к Wi-Fi, VPN или порту коммутатора, сетевое устройство отправляет RADIUS-запрос на NPS по UDP 1812, NPS сопоставляет запрос с политиками и проверяет пользователя или сертификат в домене. Для учета подключений используют UDP 1813. Точка доступа, контроллер, VPN-шлюз или коммутатор в этой схеме выступает RADIUS-клиентом.

Практическая настройка включает установку роли Network Policy Server, регистрацию NPS в Active Directory, добавление RADIUS-клиентов, выпуск сертификата для EAP, создание политик запросов подключения и сетевых политик. После этого проверяют журналы событий, коды отказа, доступность UDP-портов, синхронизацию времени и членство пользователя в доменных группах.

Правильное расположение роутера в помещении

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

В корпоративной сети RADIUS-клиентом часто выступает не бытовой роутер, а отдельная точка доступа или беспроводной контроллер. Адрес именно этого устройства нужно добавить в консоль NPS. Если контроллер отправляет запросы от собственного IP-адреса, в NPS указывают адрес контроллера, а не адрес каждой управляемой точки доступа.

Перед установкой NPS подготовьте:

• сервер Windows Server 2016, 2019, 2022 или более новой поддерживаемой версии с фиксированным IP-адресом;
• доступ к Active Directory и DNS домена;
• доменные группы для разрешенных пользователей, например WiFi-Users и VPN-Users;
• IP-адреса точек доступа, контроллера, VPN-шлюза или коммутаторов;
• отдельный общий секрет RADIUS для каждого сетевого устройства;
• сертификат сервера с назначением Server Authentication для PEAP или EAP-TLS;
• синхронизацию времени между NPS, контроллерами домена, сетевыми устройствами и клиентами.

Установите роль через Server Manager: выберите Add Roles and Features, тип установки Role-based or feature-based installation, нужный сервер и роль Network Policy and Access Services. На шаге выбора служб отметьте Network Policy Server, завершите установку и откройте консоль NPS.

В консоли NPS щелкните правой кнопкой по пункту NPS (Local) и выберите регистрацию сервера в Active Directory. Эта операция дает NPS возможность получать сведения о доменных учетных записях и группах. Если сервер не зарегистрирован или не может связаться с контроллером домена, проверка пользователя завершится ошибкой независимо от настроек Wi-Fi.

Добавьте сетевое устройство в разделе RADIUS Clients and Servers, пункт RADIUS Clients:

1. Укажите понятное имя клиента, например AP-Floor-1 или RRAS-VPN.
2. Введите IP-адрес, с которого устройство отправляет RADIUS-запросы.
3. Выберите поставщика RADIUS Standard, если оборудование не требует специального профиля.
4. Создайте длинный случайный общий секрет и задайте его тем же значением на сетевом устройстве.
5. Сохраните запись и повторите процедуру для каждого независимого источника RADIUS-запросов.

На межсетевом экране NPS разрешите входящие UDP 1812 для аутентификации и UDP 1813 для учета. Ограничьте источник правил адресами зарегистрированных RADIUS-клиентов. Открытие этих портов для всей сети увеличивает поверхность атаки и усложняет поиск ошибочного источника запросов.

В NPS используются два уровня правил. Connection Request Policy определяет, куда обрабатывать запрос: на этом сервере или на удаленном RADIUS-сервере. Network Policy решает, разрешать ли подключение и какие методы аутентификации применять. Сначала NPS проверяет порядок правил сверху вниз и использует первое совпадение.

Для Wi-Fi на точке доступа выберите WPA2-Enterprise или WPA3-Enterprise, задайте адрес NPS, UDP-порт 1812 и общий секрет. На клиентских устройствах установите доверие к центру сертификации, который выпустил сертификат NPS. При PEAP пользователи проходят проверку учетной записью домена. При EAP-TLS клиент предъявляет личный сертификат, а пароль можно исключить из процесса входа.

Для VPN на сервере RRAS откройте свойства сервера, перейдите к настройкам аутентификации и добавьте NPS как RADIUS-сервер аутентификации. При необходимости настройте отдельный сервер учета. IP-адрес RRAS добавьте в список RADIUS-клиентов NPS с тем же общим секретом. В сетевой политике используйте условие NAS Port Type = Virtual (VPN) и группу VPN-Users.

Настройка частотных диапазонов 2.4 ГГц и 5 ГГц

NPS не управляет частотами, мощностью передатчика или шириной радиоканала. Эти параметры задают на точке доступа или контроллере. NPS отвечает за допуск к SSID: клиент проходит 802.1X, точка доступа передает запрос, а сервер принимает решение.

Создайте отдельный корпоративный SSID, например Corp-8021X, и привяжите его к политике NPS. Гостевую сеть не смешивайте с корпоративной политикой: для нее обычно применяют изолированный VLAN и отдельный механизм доступа.

Связка 802.1X состоит из трех ролей:

1. Supplicant, клиент Windows, смартфон или другое устройство, которое запрашивает доступ.
2. Authenticator, точка доступа, контроллер или коммутатор, который блокирует трафик до завершения проверки.
3. Authentication Server, NPS, который проверяет учетные данные через Active Directory или сертификатную инфраструктуру.

Для PEAP выберите сертификат NPS с назначением Server Authentication и именем, которое клиент может проверить. На клиентах включите проверку сертификата сервера и укажите доверенный центр сертификации. Отключение этой проверки ускоряет подключение только внешне, но позволяет подменить RADIUS-сервер и перехватить учетные данные.

Для EAP-TLS выдайте сертификаты пользователям или компьютерам через шаблон AD CS, проверьте наличие Client Authentication и убедитесь, что срок действия сертификата не истек. Политика NPS должна разрешать нужный метод EAP, а клиент должен иметь закрытый ключ сертификата.

В условиях сетевой политики задайте группу Active Directory. Например, политика WiFi-Employees может разрешать доступ группе WiFi-Users, а политика WiFi-Admins добавит отдельные ограничения для администраторов. Разместите более узкие политики выше общих правил, иначе широкое совпадение завершит обработку раньше.

Выбор свободного канала Wi-Fi

Канал выбирают по результатам радиообследования, а не по настройкам NPS. Для 2.4 ГГц в стандартной схеме используют каналы 1, 6 и 11 с шириной 20 МГц. Соседние перекрывающиеся каналы создают больше помех, чем два устройства на одном чистом канале.

В диапазоне 5 ГГц планируйте каналы с учетом плотности точек доступа и поддержки DFS. Клиенты могут временно потерять соединение при обнаружении погодного радара на DFS-канале, а часть старых устройств такие каналы не видит. Для офиса с большим количеством точек доступа ширина 20 или 40 МГц часто дает стабильнее результат, чем максимальные 80 МГц.

Проблемы радио и проблемы RADIUS проявляются по-разному:

• при помехах клиент видит SSID, но теряет соединение или получает низкую скорость;
• при ошибке общего секрета точка доступа отправляет запрос, а NPS отклоняет его или не принимает;
• при отсутствии маршрута или блокировке UDP 1812 запрос не появляется в журнале NPS;
• при ошибке сертификата клиент видит SSID, но прекращает 802.1X-аутентификацию до выдачи доступа.

На клиенте Windows выполните netsh wlan show interfaces, чтобы проверить SSID, канал, тип радио и качество сигнала. В консоли NPS одновременно откройте журнал событий и сравните время попытки подключения с событиями 6272, 6273 и 6274. Если событий нет, ищите проблему между точкой доступа и сервером: адрес источника, маршрут, общий секрет или межсетевой экран.

Если событие есть, изучите поле Reason Code и текст причины. Код 16 обычно указывает на ошибку имени пользователя или пароля. Код 23 часто означает, что запрос не совпал с сетевой политикой. Проверяйте тип NAS-порта, членство пользователя в группе, порядок правил и выбранный метод EAP.

Обновление прошивки и перезагрузка оборудования

Обновляйте Windows Server, точки доступа, контроллеры и VPN-шлюзы по отдельному плану. После обновления сетевого устройства проверьте, что сохранились адрес NPS, UDP-порты, общий секрет, режим WPA-Enterprise и параметры сертификатов. Смена прошивки иногда сбрасывает часть RADIUS-настроек или меняет IP-адрес источника запроса.

На NPS проверьте службу IAS. Она отвечает за обработку запросов Network Policy Server. Для диагностики состояния и последних событий можно использовать PowerShell:

Get-Service IAS
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=6272,6273,6274} -MaxEvents 20
Restart-Service IAS

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

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

netsh nps export filename="C:\Temp\nps-backup.xml" exportPSK=YES

Проверьте срок действия сертификата NPS в хранилище локального компьютера. Сертификат для PEAP должен иметь закрытый ключ, подходящее имя и назначение Server Authentication. При EAP-TLS дополнительно проверяют сертификаты клиентов, цепочку доверия и отзыв сертификатов.

После перезагрузки выполните короткий контрольный сценарий: подключите тестового пользователя к корпоративному SSID, проверьте доступ к нужному внутреннему ресурсу, проверьте отказ пользователя без группы и убедитесь, что запись появилась в журнале NPS.

Использование репитеров и Mesh-систем

Репитер или Mesh-точка может передавать RADIUS-запрос самостоятельно либо через контроллер. В первом варианте каждая точка должна быть зарегистрирована в NPS со своим IP-адресом и секретом. Во втором варианте добавляют IP-адрес контроллера, если именно он отправляет запросы на NPS.

Проверьте исходный адрес пакета на сервере. Если Mesh-узел выполняет NAT, NPS видит адрес NAT-шлюза, а не адрес беспроводной точки. В список RADIUS-клиентов нужно внести фактический адрес источника. Одинаковый SSID не означает одинаковый RADIUS-клиент.

Для Mesh-сети заранее проверьте связь между узлами, задержку беспроводного backhaul и переход клиента между точками. При роуминге повторная 802.1X-аутентификация может зависеть от поддержки PMK-кэширования и настроек контроллера. NPS при этом продолжает проверять запросы по тем же политикам.

VPN можно подключить к той же инфраструктуре NPS. RRAS, аппаратный VPN-шлюз или облачный шлюз регистрируют как отдельный RADIUS-клиент. Для него создают отдельную политику с группой VPN-Users, разрешенными методами EAP и ограничениями по времени или типу устройства. Не объединяйте Wi-Fi и VPN в одно широкое правило без условия NAS Port Type.

Для тестовой лаборатории с контроллером домена, NPS и вспомогательными сервисами можно использовать облачную инфраструктуру Timeweb Cloud. Перед размещением проверьте доступность нужного образа Windows Server, лицензионные условия и сетевые правила для доменных служб.

Замена антенн и проверка кабелей

Замена антенны, патч-корда или PoE-инжектора не меняет правила NPS, но может устранить потерю пакетов и нестабильность точки доступа. Начинайте диагностику с физического уровня, затем проверяйте RADIUS и только после этого корректируйте политики.

1. Убедитесь, что точка доступа или контроллер имеет ожидаемый IP-адрес.
2. Проверьте, что этот адрес указан в разделе RADIUS Clients на NPS.
3. Сверьте общий секрет посимвольно, включая регистр и пробелы.
4. Проверьте разрешение UDP 1812 на пути от устройства до NPS.
5. Для учета подключений проверьте UDP 1813 и настройки accounting на сетевом устройстве.
6. Проверьте DNS-имя NPS, если оборудование настроено на имя, а не на IP-адрес.
7. Сверьте время на всех участниках. Большой сдвиг ломает Kerberos и проверку сертификатов.
8. Проверьте доступ NPS к контроллеру домена, DNS и глобальному каталогу.
9. Проверьте членство пользователя в группе и факт применения групповой политики.
10. Сопоставьте момент отказа с событиями 6273 или 6274 и изучите текст причины.

Если NPS не видит запросы, захват трафика на сервере должен показать, приходят ли UDP-пакеты на порт 1812. Отсутствие пакетов указывает на маршрут, ACL, NAT или неверный адрес RADIUS-сервера. Наличие запроса при отсутствии ответа на клиенте чаще связано с общим секретом, политикой межсетевого экрана или ошибкой обработки запроса.

Если запрос зарегистрирован как отказ, проверьте три уровня последовательно: совпадение Connection Request Policy, совпадение Network Policy и проверку учетных данных или сертификата. Такой порядок сокращает диагностику и не требует менять сразу несколько параметров.

Что важно запомнить

Минимальная рабочая конфигурация для корпоративного Wi-Fi выглядит так: точка доступа зарегистрирована в NPS, SSID работает в режиме WPA-Enterprise, NPS доверяет Active Directory, сервер имеет сертификат для EAP, а политика разрешает нужную доменную группу. Для VPN добавляют RRAS как отдельный RADIUS-клиент и создают правило с типом порта Virtual (VPN).

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

Продолжить чтение

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

Если RADIUS-клиент задан именем, а не IP-адресом, сначала проверьте DNS. Практические настройки DNS на сетевом оборудовании собраны в руководстве по настройке DNS на роутере.

Веб-панель роутера, контроллера и NPS не должна быть доступна из гостевой сети. Дополнительные меры защиты сетевых интерфейсов описаны в материале о защите веб-интерфейсов роутера, сервера и сетевых устройств.