Hvordan en VPN-pålogging når RADIUS og identitetsleverandøren din
Følg en VPN-pålogging fra klienten til gatewayens RADIUS-forespørsel, identitetsleverandøren bak den og policyen som brukes etter aksepten.
Forrige uke kunne en bruker logge på VPN og likevel ende på et nettverk der ingenting ble løst. Klienten sa tilkoblet, gateway-loggen sa Access-Accept, og identitetsteamet sa at kontoen var i orden. Påloggingen hadde fungert; autorisasjonen bak den ikke. Når en VPN-pålogging mislykkes, går jeg veien forespørselen faktisk tar — klient, gateway, RADIUS-server, identitetsleverandør — og stopper ved det første hoppet der svaret ikke stemmer med det neste.
Klienten snakker aldri RADIUS
Uansett hva appen på laptopen viser, er første hopp VPN-protokollen: IKEv2, OpenVPN, WireGuard eller en TLS-basert klient. RADIUS forekommer ikke i den utvekslingen. Klienten autentiserer seg mot gatewayen med et sertifikat, et brukernavn og passord, eller en EAP-metode som bæres inne i tunneloppsettet.
Det betyr noe når du leser logger, fordi den generiske autentiseringsfeilen brukeren ser, produseres av gatewayen etter at den allerede har snakket med noe annet. Hvis klienten aldri når gatewayen, finnes det ingen RADIUS-forespørsel å feilsøke, og en time på RADIUS-serveren er bortkastet. Bekreft at tunnelen i det hele tatt kom opp før du rører backenden.
Gatewayen er RADIUS-klienten
Når tunneloppsettet når punktet der legitimasjon må kontrolleres, blir gatewayen en nettverkstilgangsserver. Den bygger en Access-Request: User-Name, et passord eller EAP-nyttelast, NAS-IP-Address eller NAS-Identifier, og en Message-Authenticator når metoden krever det. Forespørselen går som standard til UDP 1812, og regnskap til 1813. Eldre installasjoner bruker fortsatt 1645 og 1646, så en brannmurregel skrevet for ett par forklarer mange stille feil.
Begge sider deler en hemmelighet, og den er ikke en brukerlegitimasjon. Den signerer utvekslingen, og hvert svar verifiseres mot den. Konfigurer hemmeligheten ulikt på de to sidene, og serveren svarer ikke med feil hemmelighet — den slipper forespørselen eller svaret feiler verifiseringen, så gatewayen rapporterer tidsavbrudd. En feil hemmelighet og en død server ser identiske ut fra gatewayen, derfor tester jeg hoppet med et klientverktøy før jeg klandrer katalogen.
Protokollen er liten og gammel — RFC 2865 definerer autentiseringsutvekslingen — men attributtene den bærer, er det mest VPN-policy bygges på.
# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123
# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'RADIUS-serveren er kanskje bare fronten for identitetsleverandøren
Folk snakker om RADIUS og identitetsleverandør som om de var samme boks. Ofte er de ikke det. RADIUS-serveren mottar Access-Request og spør deretter noe annet — Active Directory over LDAP eller Kerberos, en lokal brukerfil eller en ekstern tjeneste — før den svarer. FreeRADIUS med LDAP- eller krb5-modulen, Windows NPS og Cisco ISE står alle i denne posisjonen.
Forskjellen avgjør hvor du ser. Et avvist passord er et svar fra identitetsleverandøren som RADIUS videresender. Et tidsavbrudd er vanligvis strekningen RADIUS-til-katalog: en utløpt bind-konto, en utilgjengelig katalog eller en forespørsel rutet til feil backend. Hvis brukernavnet har et domenesuffiks, kan serveren rute på det, og samme konto sendt som CORP\alice og [email protected] kan ende på forskjellige steder. På Windows NPS registrerer Security-loggen 6272 for en innvilgelse og 6273 for en avvisning, noe som forteller om beslutningen i det hele tatt kom fra NPS.
Les feilen ved hoppet som produserte den
Én kan-ikke-koble-til-melding dekker fire forskjellige feil. Før du endrer noe, match symptomet til hoppet som produserte det.
| What you see | Where it comes from | First check |
|---|---|---|
| Gateway timeout, no reply | Shared secret mismatch, UDP 1812 blocked, unknown NAS, wrong server address | tcpdump at the gateway; radtest from the gateway host |
| Immediate reject | Credentials, account state, domain suffix, RADIUS policy | NPS 6273 or the FreeRADIUS auth log; test the account directly |
| Repeated challenge or MFA loop | Access-Challenge state not returned, or a token that expired mid-flow | Client prompt timing and the State attribute in debug output |
| Accept, then no access | Authorization attributes unmapped, wrong pool, route or ACL policy | Gateway policy and the attributes in the Access-Accept |
Den siste raden er den som sender folk til feil team. Access-Accept betyr at legitimasjonen ble akseptert; det betyr ikke at gatewayen har plassert brukeren i riktig pool eller dyttet ruter. Gruppeattributter betyr bare noe hvis gateway-policyen leser dem. Jeg har sett en korrekt pålogging ende i en gjestepool fordi gruppemappingen var konfigurert på RADIUS-siden for et annet attributt enn det gatewayen undersøker.
Følg én pålogging fra start til slutt
Velg én testkonto og én gateway, og se deretter det samme forsøket på alle fire punkter. Start en feilsøkingskjøring på RADIUS-siden — freeradius -X skriver ut forespørselen og hver modul den berører — følg gatewayens autentiseringslogg, og kjør tcpdump for UDP-utvekslingen. Koble til én gang og les de fire sporene i rekkefølge.
Det du vil se, er enighet: gatewayen spurte om brukeren du forventet, RADIUS-serveren valgte backenden du forventet, den backenden returnerte en beslutning, og attributtene i svaret samsvarer med policyen gatewayen bruker. Det første stedet sporene er uenige, er feilgrensen din. Hvis svaret ikke bærer et gruppeattributt, er problemet på RADIUS-siden, ikke i VPN-profilen; hvis attributtet er der og gatewayen ignorerer det, er gateway-policyen problemet.
En sikkerhetsmerknad mens du er der. Den delte hemmeligheten beskytter utvekslingen, men den krypterer ikke de fleste attributtene. Hvis gatewayen og RADIUS-serveren ligger i forskjellige segmenter, legg det hoppet på RADIUS over TLS eller en privat vei. En kryptert brukertunnel sier ingenting om backend-forbindelsen.
Før du lukker saken, bekreft fire ting. Gatewayen når RADIUS-serveren på porten den faktisk er konfigurert for. Den delte hemmeligheten stemmer på begge sider. RADIUS-serveren løser opp den nøyaktige brukernavnformen gatewayen sender. Aksepten bærer attributtene gateway-policyen trenger. Når alle fire holder, er en pålogging som fortsatt feiler et gateway-policyproblem, ikke et autentiseringsproblem.