Яку адресу реєструвати як RADIUS-клієнт NPS?

VPN-шлюз, який передає автентифікацію Windows NPS, потребує одного об'єкта на боці NPS, перш ніж запрацює будь-яка політика користувача: запису RADIUS-клієнта для шлюзу. Більшість невдалих спроб реєструють неправильну адресу, бо важлива та адреса, яку шлюз використовує на своєму серверному шляху, а не ім'я хоста, яке співробітники вводять у свій VPN-застосунок. Помиліться з цим значенням — і NPS тихо відкине запит, що з боку клієнта виглядає як неправильний пароль. Яку адресу вводити, визначають три умови, тож з'ясуйте їх до відкриття консолі.

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

Об'єкт RADIUS-клієнта представляє мережевий пристрій доступу, який надсилає запити автентифікації. Це VPN-шлюз, а не кожен ноутбук із клієнтом і не діапазон адрес, що видаються всередині тунелів.

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

Адресу, яку ви вводите, визначають три умови

По-перше, знайдіть адресу джерела, яку шлюз насправді використовує в напрямку NPS. Багатоінтерфейсний шлюз часто надсилає з інтерфейсу керування або серверного інтерфейсу, а не з публічного VPN-прослуховувача. По-друге, перевірте, чи є NAT між ними: якщо запит транслюється, NPS бачить трансльовану адресу, і саме її треба реєструвати. По-третє, якщо роль поділяють два шлюзи, кожне джерело запиту потребує власного запису клієнта, бо один об'єкт з однією адресою охоплює лише один із них.

Двосторонній запис тримає пару прямою. Таблиця нижче використовує приватні адреси для ілюстрації, тож підставте ті, що їх насправді використовує ваш шлях.

Підтвердьте джерело, а не вгадуйте його. Стежте за журналом NPS або брандмауера під час однієї спроби або зніміть дамп на хості NPS за допомогою sudo tcpdump -ni any udp port 1812. Адреса в цьому дампі — єдина захищувана відповідь для запису клієнта. Якщо шлюз має кілька можливих джерел, зареєструйте кожне під власним зручним ім'ям.

Спільний секрет — це значення між шлюзом і NPS

Спільний секрет автентифікує зв'язок між пристроями. Це не пароль користувача, і його ніколи не роздають персоналу та не вбудовують у профілі клієнтів.

Виберіть одне значення, введіть його в обох місцях і зберігайте там, де лежить резервна копія конфігурації шлюзу. Невідповідність породжує запит, який NPS відкидає без корисного повідомлення про помилку, і це не відрізнити від недосяжного сервера в журналі шлюзу. Ротуйте його у вікно обслуговування й оновлюйте обидва кінці тією самою зміною.

Підтвердьте одним дозволеним запитом

Використовуйте контрольований обліковий запис і зіставте одну спробу з обох боків. На шлюзі підтвердьте, що запит пішов до потрібного сервера; на NPS — що він надійшов від зареєстрованого клієнта й відповідав очікуваній політиці запитів на підключення. Тайм-аут і відмова означають різні речі, і трактування обох як проблеми з обліковими даними марнує наступну годину. Потім перевірте чинний, але непридатний обліковий запис і неправильний пароль, бо політика, що приймає все, теж проходить перший тест.

Нарешті, перевірте, що шлюз робить з поверненим авторизаційним рішенням. Реєстрація RADIUS-клієнта лише дозволяє пристрою брати участь; вона не дає кожній отриманій сесії доступу до LAN.

Обмежуйте діагностичні дані: жодних спільних секретів, паролів користувачів чи повних корисних навантажень пакетів у заявці до підтримки. Якщо проєкт вимагає, щоб сервер NPS читав атрибути каталогу, цей дозвіл — окреме адміністративне завдання від реєстрації клієнта, і за його відсутності все ламається інакше.