Paano Nakarating ang Pag-login sa VPN sa RADIUS at sa Iyong Identity Provider
Sundan ang pag-login sa VPN mula sa client hanggang sa RADIUS request ng gateway, ang identity provider sa likod nito, at ang patakarang inilalapat pagkatapos ng pagtanggap.
Noong nakaraang linggo, nakapag-log in ang isang user sa VPN at napunta pa rin sa isang network kung saan walang niresolba. Sinabi ng client na konektado, sinabi ng gateway log na Access-Accept, at sinabi ng identity team na maayos ang account. Gumana ang pag-login; hindi gumana ang awtorisasyon sa likod nito. Kapag nabigo ang pag-login sa VPN, nilalakad ko ang landas na talagang tinatahak ng request — client, gateway, RADIUS server, identity provider — at humihinto ako sa unang hop na ang sagot ay hindi tugma sa susunod.
Hindi kailanman nagsasalita ng RADIUS ang client
Anuman ang ipakita ng app sa laptop, ang unang hop nito ay ang VPN protocol: IKEv2, OpenVPN, WireGuard o isang client na nakabatay sa TLS. Hindi lumilitaw ang RADIUS sa palitan na iyon. Nagpapatunay ang client sa gateway gamit ang sertipiko, username at password, o isang paraang EAP na dinadala sa loob ng setup ng tunnel.
Mahalaga iyon kapag nagbabasa ng log, dahil ang pangkalahatang error sa pagpapatunay na nakikita ng user ay ginagawa ng gateway pagkatapos nitong makipag-usap sa ibang bagay. Kung hindi kailanman nakarating ang client sa gateway, walang RADIUS request na i-debug, at ang isang oras sa RADIUS server ay nasayang. Tiyakin na bumangon ang tunnel bago hawakan ang backend.
Ang gateway ang RADIUS client
Kapag naabot ng setup ng tunnel ang puntong kailangang suriin ang mga kredensyal, nagiging network access server ang gateway. Gumagawa ito ng Access-Request: User-Name, password o EAP payload, NAS-IP-Address o NAS-Identifier, at Message-Authenticator kapag hinihingi ito ng paraan. Ang request ay pumupunta sa UDP 1812 bilang default, at ang accounting sa 1813. Gumagamit pa rin ang mas lumang deployment ng 1645 at 1646, kaya ang firewall rule na isinulat para sa isang pares ay nagpapaliwanag ng maraming tahimik na pagkabigo.
Nagbabahagi ang dalawang panig ng isang lihim, at hindi ito kredensyal ng user. Pinipirmahan nito ang palitan, at bawat sagot ay binibigyang-katibayan laban dito. I-configure ang lihim nang iba sa dalawang panig at hindi sasagot ang server ng maling lihim — itinatapon nito ang request o nabigo ang sagot sa pagpapatunay, kaya nag-uulat ang gateway ng timeout. Ang maling lihim at patay na server ay magkamukha mula sa gateway, kaya sinusubukan ko ang hop gamit ang client tool bago sisihin ang directory.
Maliit at luma ang protocol — tinutukoy ng RFC 2865 ang palitan ng pagpapatunay — ngunit ang mga attribute na dinadala nito ang batayan ng karamihan sa patakaran ng VPN.
# 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'Ang RADIUS server ay maaaring harapan lamang ng identity provider
Pinag-uusapan ng mga tao ang RADIUS at identity provider na parang isang kahon lang. Kadalasan ay hindi. Tinatanggap ng RADIUS server ang Access-Request at pagkatapos ay nagtatanong ng ibang bagay — Active Directory sa pamamagitan ng LDAP o Kerberos, lokal na user file o panlabas na serbisyo — bago sumagot. Ang FreeRADIUS na may LDAP o krb5 module, Windows NPS at Cisco ISE ay nakatayo lahat sa posisyong ito.
Ang pagkakaiba ang nagtatakda kung saan titingin. Ang tinanggihang password ay sagot ng identity provider na ipinapasa ng RADIUS. Ang timeout ay karaniwang bahagi ng RADIUS-to-directory: nag-expire na bind account, hindi maabot na directory, o request na itinuro sa maling backend. Kung may domain suffix ang username, maaaring mag-ruta ang server batay doon, at ang parehong account na ipinadala bilang CORP\alice at [email protected] ay maaaring mapunta sa magkaibang lugar. Sa Windows NPS, itinatala ng Security log ang 6272 para sa pagbibigay at 6273 para sa pagtanggi, na nagsasabi kung galing mismo sa NPS ang desisyon.
Basahin ang pagkabigo sa hop na gumawa nito
Isang mensaheng hindi makakonekta ang sumasaklaw sa apat na magkaibang pagkabigo. Bago baguhin ang anuman, itugma ang sintomas sa hop na gumawa nito.
| 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 |
Ang huling hilera ang nagpapadala ng mga tao sa maling team. Ang Access-Accept ay nangangahulugang tinanggap ang mga kredensyal; hindi ibig sabihin na nailagay ng gateway ang user sa tamang pool o naitulak ang mga ruta. Mahalaga lamang ang mga attribute ng grupo kung binabasa ito ng patakaran ng gateway. Nakakita ako ng tamang pag-login na napunta sa guest pool dahil ang group mapping ay naka-configure sa RADIUS side para sa ibang attribute kaysa sa sinusuri ng gateway.
Sundan ang isang pag-login mula simula hanggang dulo
Pumili ng isang test account at isang gateway, pagkatapos ay obserbahan ang parehong pagtatangka sa apat na punto. Simulan ang debug run sa RADIUS side — ipiniprint ng freeradius -X ang request at bawat module na hinahawakan nito — sundan ang authentication log ng gateway, at patakbuhin ang tcpdump para sa UDP exchange. Kumonekta nang isang beses at basahin ang apat na trace sa pagkakasunod-sunod.
Ang gusto mong makita ay pagkakasundo: tinanong ng gateway ang user na inaasahan mo, pinili ng RADIUS server ang backend na inaasahan mo, ibinalik ng backend na iyon ang desisyon, at tumutugma ang mga attribute sa sagot sa patakarang inilalapat ng gateway. Ang unang lugar kung saan hindi nagkakasundo ang mga trace ang iyong linya ng depekto. Kung walang attribute ng grupo ang sagot, nasa RADIUS side ang problema, hindi sa VPN profile; kung naroon ang attribute at binabalewala ito ng gateway, ang patakaran ng gateway ang problema.
Isang tala sa seguridad habang naroon ka. Pinoprotektahan ng shared secret ang palitan, ngunit hindi nito ine-encrypt ang karamihan sa mga attribute. Kung ang gateway at RADIUS server ay nasa magkaibang segment, ilagay ang hop na iyon sa RADIUS sa pamamagitan ng TLS o pribadong landas. Ang naka-encrypt na user tunnel ay walang sinasabi tungkol sa backend link.
Bago isara ang ticket, tiyakin ang apat na bagay. Naabot ng gateway ang RADIUS server sa port na aktwal na naka-configure. Tugma ang shared secret sa dalawang panig. Niresolba ng RADIUS server ang eksaktong anyo ng username na ipinapadala ng gateway. Dinadala ng pagtanggap ang mga attribute na kailangan ng patakaran ng gateway. Kapag totoo ang apat, ang pag-login na nabibigo pa rin ay problema ng patakaran ng gateway, hindi ng pagpapatunay.