Hvilken adresse registrerer du som NPS RADIUS-klient?

En VPN-gateway, der overlader godkendelse til Windows NPS, har brug for ét objekt på NPS-siden, før nogen brugerpolitik kan køre: en RADIUS-klientpost til gatewayen. De fleste mislykkede forsøg registrerer den forkerte adresse, fordi den afgørende adresse er den, gatewayen bruger på sin backend-vej, ikke det værtsnavn personalet skriver i deres VPN-app. Tager du fejl af den værdi, kasserer NPS tavst anmodningen, og det ser ud som en forkert adgangskode fra klientens side. Tre forhold afgør, hvilken adresse der hører i feltet, så find dem på plads, før du åbner konsollen.

Registrér gatewayen, ikke bærbare computere eller puljen

RADIUS-klientobjektet repræsenterer den netværksadgangsenhed, der sender godkendelsesanmodninger. Det er VPN-gatewayen, ikke hver bærbar computer, der kører klienten, og ikke det adresseområde, der uddeles inde i tunnelerne.

Disse tunneladresser optræder aldrig som kilden til en RADIUS-anmodning, fordi anmodningen rejser ad gatewayens egen netværksvej. At registrere en puljepost giver en politik, der aldrig kan matche, mens den rigtige anmodning ankommer fra en adresse, NPS aldrig har hørt om. Den samme forvirring får folk til at tilføje hver medarbejders hjemme-IP, hvilket både er uholdbart og forkert.

Tre forhold afgør den adresse, du indtaster

Find først den kildeadresse, gatewayen faktisk bruger mod NPS. En gateway med flere grænseflader sender ofte fra en administrations- eller backend-grænseflade i stedet for sin offentlige VPN-lytter. Kontrollér for det andet, om der er NAT mellem de to: hvis anmodningen oversættes, ser NPS den oversatte adresse, og det er værdien, der skal registreres. For det tredje, hvis to gateways deler rollen, har hver anmodningskilde brug for sin egen klientpost, fordi ét objekt med én adresse kun dækker én af dem.

En post med to ender holder parret på plads. Tabellen nedenfor bruger private adresser som illustration, så erstat dem med dem, din vej faktisk bruger.

Bekræft kilden i stedet for at gætte den. Hold øje med NPS- eller firewall-loggen under et forsøg, eller optag på NPS-værten med sudo tcpdump -ni any udp port 1812. Adressen i den optagelse er det eneste forsvarlige svar til klientposten. Har gatewayen flere mulige kilder, registrér hver af dem under sit eget venlige navn.

Den delte hemmelighed er en værdi mellem gateway og NPS

Den delte hemmelighed godkender enhedsforholdet. Den er ikke en brugeradgangskode og deles aldrig med personalet eller indlejres i klientprofiler.

Vælg én værdi, indtast den begge steder, og opbevar den, hvor gatewayens konfigurationsbackup ligger. Uoverensstemmelse giver en anmodning, som NPS dropper uden en brugbar fejl, og det kan i gatewayens log ikke skelnes fra en utilgængelig server. Rotér den i et vedligeholdelsesvindue, og opdatér begge ender i samme ændring.

Bekræft med én tilladt anmodning

Brug en kontrolleret konto, og korrelér ét forsøg på begge sider. På gatewayen bekræfter du, at anmodningen gik mod den tilsigtede server; på NPS bekræfter du, at den kom fra den registrerede klient og matchede den forventede politik for forbindelsesanmodninger. Timeout og afvisning betyder forskellige ting, og behandler man begge som et legitimationsproblem, spilder man den næste time. Test derefter en gyldig, men ikke berettiget konto og en forkert adgangskode, fordi en politik, der accepterer alt, også består den første test.

Kontrollér til sidst, hvad gatewayen gør med den returnerede autorisation. Registrering af en RADIUS-klient tillader kun enheden at deltage; den giver ikke hver resulterende session adgang til LAN.

Hold diagnostisk output afgrænset: ingen delte hemmeligheder, ingen brugeradgangskoder, ingen fulde pakkenyttelaster i en supportsag. Hvis designet kræver, at NPS-serveren læser katalogattributter, er den tilladelse en separat administrativ opgave fra klientregistreringen, og den fejler på en anden måde, når den mangler.