Кой адрес регистрирате като 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 сървърът да чете атрибути от директорията, това разрешение е отделна административна задача от регистрацията на клиента и при липсата му се проваля по различен начин.