Vilken adress registrerar du som NPS RADIUS-klient?

En VPN-gateway som lämnar över autentisering till Windows NPS behöver ett objekt på NPS-sidan innan någon användarpolicy kan köra: en RADIUS-klientpost för gatewayen. De flesta misslyckade försök registrerar fel adress, eftersom adressen som spelar roll är den gatewayen använder på sin backend-väg, inte värdnamnet personalen skriver i sin VPN-app. Är värdet fel kastar NPS begäran tyst, vilket från klientsidan ser ut som ett felaktigt lösenord. Tre villkor avgör vilken adress som hör i fältet, så red ut dem innan du öppnar konsolen.

Registrera gatewayen, inte bärbara datorer eller poolen

RADIUS-klientobjektet representerar nätverksåtkomstsenheten som skickar autentiseringsbegäranden. Det är VPN-gatewayen, inte varje bärbar dator som kör klienten och inte adressintervallet som delas ut inuti tunnlarna.

Dessa tunneladresser visas aldrig som källa för en RADIUS-begäran, eftersom begäran färdas över gatewayens egen nätverksväg. Att registrera en poolpost ger en policy som aldrig kan matcha, medan den riktiga begäran kommer från en adress som NPS aldrig hört talas om. Samma förvirring får folk att lägga till hem-IP:n för varje anställd, vilket både är ohanterligt och fel.

Tre villkor avgör adressen du skriver in

Hitta först den källadress som gatewayen faktiskt använder mot NPS. En gateway med flera gränssnitt skickar ofta från ett hanterings- eller backend-gränssnitt i stället för sin offentliga VPN-lyssnare. Kontrollera för det andra om det finns NAT mellan dem: översätts begäran ser NPS den översatta adressen, och det är värdet som ska registreras. För det tredje, om två gatewayer delar rollen behöver varje begäranskälla sin egen klientpost, eftersom ett objekt med en adress bara täcker en av dem.

En post med två ändar håller paret i ordning. Tabellen nedan använder privata adresser som illustration, så byt ut dem mot dem din väg faktiskt använder.

Bekräfta källan i stället för att gissa den. Följ NPS- eller brandväggsloggen under ett försök, eller fånga på NPS-värden med sudo tcpdump -ni any udp port 1812. Adressen i den fångsten är det enda försvarbara svaret för klientposten. Har gatewayen flera möjliga källor, registrera var och en under sitt eget vänliga namn.

Den delade hemligheten är ett värde mellan gateway och NPS

Den delade hemligheten autentiserar enhetsförhållandet. Den är inte ett användarlösenord och delas aldrig med personalen eller bäddas in i klientprofiler.

Välj ett värde, skriv in det på båda ställena och förvara det där gatewayens konfigurationsbackup ligger. En avvikelse ger en begäran som NPS kastar utan ett användbart fel, och det går i gatewayens logg inte att skilja från en otillgänglig server. Rotera den i ett underhållsfönster och uppdatera båda ändarna i samma ändring.

Bekräfta med en tillåten begäran

Använd ett kontrollerat konto och korrelera ett enda försök på båda sidor. På gatewayen bekräftar du att begäran gick mot den avsedda servern; på NPS att den kom från den registrerade klienten och matchade den förväntade policyn för anslutningsbegäranden. Tidsgräns och avvisning betyder olika saker, och att behandla båda som ett inloggningsproblem kostar nästa timme. Testa sedan ett giltigt men ej behörigt konto och ett fel lösenord, eftersom en policy som accepterar allt också klarar det första testet.

Kontrollera slutligen vad gatewayen gör med den returnerade auktoriseringen. Att registrera en RADIUS-klient tillåter bara enheten att delta; det ger inte varje resulterande session åtkomst till LAN.

Håll diagnostikutdata avgränsad: inga delade hemligheter, inga användarlösenord, inga fullständiga paketnyttolaster i ett supportärende. Om designen kräver att NPS-servern läser katalogattribut, är den behörigheten en separat administrativ uppgift från klientregistreringen, och när den saknas misslyckas den på ett annat sätt.