Hoe 'n VPN-aanmelding RADIUS en jou identiteitsverskaffer bereik
Volg 'n VPN-aanmelding van die kliënt na die deurgang se RADIUS-versoek, die identiteitsverskaffer daarachter, en die beleid wat ná die aanvaarding toegepas word.
Verlede week kon 'n gebruiker by die VPN aanmeld en tog op 'n netwerk beland waar niks opgelos het nie. Die kliënt het gesê verbind, die deurgang se logboek het Access-Accept gesê, en die identiteitspan het gesê die rekening is in orde. Die aanmelding het gewerk; die magtiging daarachter het nie. Wanneer 'n VPN-aanmelding misluk, volg ek die pad wat die versoek werklik neem — kliënt, deurgang, RADIUS-bediener, identiteitsverskaffer — en stop by die eerste sprong waar die antwoord met die volgende een verskil.
Die kliënt praat nooit RADIUS nie
Wat die program op die skootrekenaar ook al wys, sy eerste sprong is die VPN-protokol: IKEv2, OpenVPN, WireGuard of 'n TLS-gebaseerde kliënt. RADIUS verskyn nie in daardie uitruiling nie. Die kliënt verifieer hom by die deurgang met 'n sertifikaat, 'n gebruikersnaam en wagwoord, of 'n EAP-metode wat in die tonnelopstelling gedra word.
Dit maak saak wanneer jy logboeke lees, want die algemene verifikasiefout wat die gebruiker sien, word deur die deurgang geproduseer nadat dit reeds met iets anders gepraat het. As die kliënt nooit die deurgang bereik nie, bestaan daar geen RADIUS-versoek om te ontfout nie, en 'n uur op die RADIUS-bediener is vermors. Bevestig dat die tonnel hoegenaamd opgekom het voordat jy aan die agterkant raak.
Die deurgang is die RADIUS-kliënt
Sodra die tonnelopstelling die punt bereik waar geloofsbriewe nagegaan moet word, word die deurgang 'n netwerktoegangsbediener. Dit bou 'n Access-Request: User-Name, 'n wagwoord of EAP-lading, NAS-IP-Address of NAS-Identifier, en 'n Message-Authenticator wanneer die metode een vereis. Die versoek gaan by verstek na UDP 1812, en rekeningkunde na 1813. Ouer ontplooiings gebruik steeds 1645 en 1646, so 'n vuurmuurreël vir een paar verduidelik baie stille mislukkings.
Beide kante deel 'n geheim, en dit is nie 'n gebruiker se geloofsbrief nie. Dit onderteken die uitruiling, en elke antwoord word daarteen geverifieer. Stel die geheim verskillend op die twee kante in en die bediener antwoord nie met 'n slegte geheim nie — dit laat die versoek val of die antwoord misluk die verifikasie, so die deurgang rapporteer 'n tydsverloop. 'n Verkeerde geheim en 'n dooie bediener lyk identies van die deurgang af, daarom toets ek die sprong met 'n kliëntinstrument voordat ek die gids blameer.
Die protokol is klein en oud — RFC 2865 definieer die verifikasie-uitruiling — maar die eienskappe wat dit dra, is waarop die meeste VPN-beleid gebou is.
# 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'Die RADIUS-bediener staan dalk net voor die identiteitsverskaffer
Mense praat van RADIUS en identiteitsverskaffer asof dit dieselfde boks is. Dikwels is dit nie. Die RADIUS-bediener ontvang die Access-Request en vra dan iets anders — Active Directory oor LDAP of Kerberos, 'n plaaslike gebruikerslêer, of 'n eksterne diens — voordat dit antwoord. FreeRADIUS met die LDAP- of krb5-module, Windows NPS en Cisco ISE staan almal op hierdie posisie.
Die onderskeid bepaal waar jy kyk. 'n Verwerpte wagwoord is 'n identiteitsverskaffer-antwoord wat deur RADIUS deurgegee word. 'n Tydsverloop is gewoonlik die been van RADIUS na die gids: 'n vervalste bind-rekening, 'n onbereikbare gids, of 'n versoek wat na die verkeerde agterkant gerig is. As die gebruikersnaam 'n domein-agtervoegsel dra, kan die bediener daarop routeer, en dieselfde rekening gestuur as CORP\alice en [email protected] kan op verskillende plekke beland. Op Windows NPS teken die Security-log 6272 aan vir 'n toestaan en 6273 vir 'n weiering, wat jou vertel of die besluit hoegenaamd van NPS gekom het.
Lees die mislukking by die sprong wat dit veroorsaak het
Een kan-nie-verbind-boodskap dek vier verskillende mislukkings. Voordat jy iets verander, pas die simptoom by die sprong wat dit veroorsaak het.
| 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 |
Dit is die laaste ry wat mense na die verkeerde span stuur. Access-Accept beteken die geloofsbriewe is aanvaar; dit beteken nie die deurgang het die gebruiker in die regte poel geplaas of roetes gestoot nie. Groep-eienskappe maak net saak as die deurgangsbeleid dit lees. Ek het gesien hoe 'n korrekte aanmelding in 'n gaspoel beland omdat die groepkartering aan die RADIUS-kant vir 'n ander eienskap opgestel is as die een wat die deurgang ondersoek.
Volg een aanmelding van begin tot einde
Kies 'n enkele toetsrekening en een deurgang, en kyk dan na dieselfde poging by al vier punte. Begin 'n ontfoutloop aan die RADIUS-kant — freeradius -X druk die versoek en elke module wat dit raak — volg die deurgang se verifikasielogboek, en hardloop tcpdump vir die UDP-uitruiling. Verbind een keer en lees die vier spore in volgorde.
Wat jy wil sien, is ooreenstemming: die deurgang het gevra oor die gebruiker wat jy verwag het, die RADIUS-bediener het die agterkant gekies wat jy verwag het, daardie agterkant het 'n besluit teruggegee, en die eienskappe in die antwoord pas by die beleid wat die deurgang toepas. Die eerste plek waar die spore verskil, is jou foutlyn. As die antwoord geen groep-eienskap dra nie, is die probleem aan die RADIUS-kant, nie in die VPN-profiel nie; as die eienskap daar is en die deurgang ignoreer dit, is die deurgangsbeleid die probleem.
Een veiligheidsnota terwyl jy daar is. Die gedeelde geheim beskerm die uitruiling, maar dit versleutel nie die meeste eienskappe nie. As die deurgang en die RADIUS-bediener op verskillende segmente sit, plaas daardie sprong op RADIUS oor TLS of 'n privaat pad. 'n Versleutelde gebruikerstonnel sê niks oor die agterkant-skakel nie.
Voordat jy die kaartjie sluit, bevestig vier dinge. Die deurgang kan die RADIUS-bediener bereik op die poort waarvoor dit werklik opgestel is. Die gedeelde geheim stem aan beide kante ooreen. Die RADIUS-bediener los die presiese gebruikersnaamvorm op wat die deurgang stuur. Die aanvaarding dra die eienskappe wat die deurgangsbeleid nodig het. Wanneer al vier geld, is 'n aanmelding wat steeds misluk 'n deurgangsbeleidsprobleem, nie 'n verifikasieprobleem nie.