Hvilken adresse registrerer du som NPS RADIUS-klient?

En VPN-gateway som overlater autentisering til Windows NPS trenger ett objekt på NPS-siden før noen brukerpolicy kan kjøre: en RADIUS-klientoppføring for gatewayen. De fleste mislykkede forsøk registrerer feil adresse, fordi adressen som betyr noe er den gatewayen bruker på backend-banen sin, ikke vertsnavnet personalet skriver i VPN-appen. Er den verdien feil, forkaster NPS forespørselen i stillhet, og det ser ut som et feil passord fra klientsiden. Tre forhold avgjør hvilken adresse som hører i feltet, så finn dem ut før du åpner konsollen.

Registrer gatewayen, ikke de bærbare eller poolen

RADIUS-klientobjektet representerer nettverkstilgangsenheten som sender autentiseringsforespørsler. Det er VPN-gatewayen, ikke hver bærbar som kjører klienten, og ikke adresseområdet som deles ut inne i tunnelene.

Disse tunneladressene vises aldri som kilden til en RADIUS-forespørsel, fordi forespørselen går over gatewayens egen nettverksbane. Å registrere en pooloppføring gir en policy som aldri kan matche, mens den ekte forespørselen kommer fra en adresse NPS aldri har hørt om. Den samme forvirringen får folk til å legge til hjemme-IP-en til hver ansatt, noe som både er uhåndterlig og feil.

Tre forhold avgjør adressen du skriver inn

Finn først kildeadressen gatewayen faktisk bruker mot NPS. En gateway med flere grensesnitt sender ofte fra et administrasjons- eller backend-grensesnitt i stedet for sin offentlige VPN-lytter. Kontroller for det andre om det er NAT mellom dem: blir forespørselen oversatt, ser NPS den oversatte adressen, og det er verdien som skal registreres. For det tredje, hvis to gatewayer deler rollen, trenger hver forespørselskilde sin egen klientoppføring, fordi ett objekt med én adresse bare dekker én av dem.

En oppføring med to ender holder paret i orden. Tabellen nedenfor bruker private adresser som illustrasjon, så bytt dem ut med dem banen din faktisk bruker.

Bekreft kilden i stedet for å gjette den. Følg med på NPS- eller brannmurloggen under ett forsøk, eller ta opp på NPS-verten med sudo tcpdump -ni any udp port 1812. Adressen i den opptaket er det eneste forsvarlige svaret for klientoppføringen. Har gatewayen flere mulige kilder, registrer hver av dem under sitt eget vennlige navn.

Den delte hemmeligheten er en verdi mellom gateway og NPS

Den delte hemmeligheten autentiserer enhetsforholdet. Den er ikke et brukerpassord og deles aldri med personalet eller bygges inn i klientprofiler.

Velg én verdi, skriv den inn begge steder, og oppbevar den der sikkerhetskopien av gatewayens konfigurasjon ligger. Uoverensstemmelse gir en forespørsel som NPS forkaster uten en nyttig feil, og det kan i gatewayens logg ikke skilles fra en utilgjengelig server. Roter den i et vedlikeholdsvindu og oppdater begge ender i samme endring.

Bekreft med én tillatt forespørsel

Bruk en kontrollert konto og korreler ett forsøk på begge sider. På gatewayen bekrefter du at forespørselen gikk mot den tiltenkte serveren; på NPS at den kom fra den registrerte klienten og samsvarte med den forventede policyen for tilkoblingsforespørsler. Tidsavbrudd og avvisning betyr forskjellige ting, og å behandle begge som et påloggingsproblem kaster bort den neste timen. Test deretter en gyldig, men ikke kvalifisert konto og et feil passord, fordi en policy som godtar alt også består den første testen.

Til slutt, kontroller hva gatewayen gjør med autorisasjonen som returneres. Å registrere en RADIUS-klient lar bare enheten delta; det gir ikke hver resulterende sesjon tilgang til LAN.

Hold diagnostisk utdata avgrenset: ingen delte hemmeligheter, ingen brukerpassord, ingen hele pakkenyttelaster i en støttesak. Hvis designet krever at NPS-serveren leser katalogattributter, er den tillatelsen en egen administrativ oppgave fra klientregistreringen, og når den mangler feiler den på en annen måte.