Kaip VPN prisijungimas pasiekia RADIUS ir jūsų tapatybės teikėją
Peržiūrėkite VPN prisijungimą nuo kliento iki vartų RADIUS užklausos, už jos esančio tapatybės teikėjo ir po priėmimo taikomos politikos.
Praėjusią savaitę naudotojas galėjo prisijungti prie VPN ir vis tiek atsidūrė tinkle, kuriame niekas nebuvo sprendžiama. Klientas sakė prisijungęs, vartų žurnalas sakė Access-Accept, o tapatybės komanda sakė, kad paskyra tvarkinga. Prisijungimas pavyko; autorizacija už jo – ne. Kai VPN prisijungimas nepavyksta, einu keliu, kurį užklausa iš tikrųjų nueina – klientas, vartai, RADIUS serveris, tapatybės teikėjas – ir sustoju prie pirmo šuolio, kurio atsakymas nesutampa su kitu.
Klientas niekada nekalba RADIUS
Ką bebūtų rodoma nešiojamojo kompiuterio programėlėje, pirmas jos šuolis yra VPN protokolas: IKEv2, OpenVPN, WireGuard arba TLS pagrindu veikiantis klientas. RADIUS tame pasikeitime neatsiranda. Klientas autentifikuojasi prie vartų sertifikatu, naudotojo vardu ir slaptažodžiu arba EAP metodu, perduodamu tunelio nustatymuose.
Tai svarbu skaitant žurnalus, nes bendrą autentifikavimo klaidą, kurią mato naudotojas, sukuria vartai po to, kai jau kalbėjosi su kuo nors kitu. Jei klientas niekada nepasiekia vartų, nėra RADIUS užklausos, kurią būtų galima derinti, ir valanda, praleista prie RADIUS serverio, yra prarasta. Patvirtinkite, kad tunelis apskritai pakilo, prieš liesdami backend.
Vartai yra RADIUS klientas
Kai tik tunelio nustatymas pasiekia tašką, kuriame reikia patikrinti prisijungimo duomenis, vartai tampa tinklo prieigos serveriu. Jis sudaro Access-Request: User-Name, slaptažodį arba EAP naudingąją apkrovą, NAS-IP-Address arba NAS-Identifier ir Message-Authenticator, kai metodas to reikalauja. Užklausa pagal nutylėjimą siunčiama į UDP 1812, o apskaita – į 1813. Senesni diegimai vis dar naudoja 1645 ir 1646, todėl vienai porai parašyta ugniasienės taisyklė paaiškina daug tylaus nepavykimo atvejų.
Abi pusės dalijasi paslaptimi, ir tai nėra naudotojo prisijungimo duomenys. Ji pasirašo pasikeitimą, ir kiekvienas atsakymas tikrinamas pagal ją. Nustatykite paslaptį skirtingai abiejose pusėse ir serveris neatsakys bloga paslaptis – jis išmeta užklausą arba atsakymas nepraeina patikros, todėl vartai praneša apie laiko limitą. Neteisinga paslaptis ir miręs serveris iš vartų atrodo vienodai, todėl šuolį tikrinu kliento įrankiu, prieš kaltindamas katalogą.
Protokolas mažas ir senas – RFC 2865 apibrėžia autentifikavimo pasikeitimą – bet jo perduodami atributai yra pagrindas, ant kurio pastatyta didžioji dalis VPN politikos.
# 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 serveris gali būti tik tapatybės teikėjo priekis
Žmonės kalba apie RADIUS ir tapatybės teikėją taip, tarsi tai būtų ta pati dėžė. Dažnai ne. RADIUS serveris gauna Access-Request ir tada prieš atsakydamas klausia ko nors kito – Active Directory per LDAP arba Kerberos, vietinio naudotojų failo ar išorinės paslaugos. FreeRADIUS su LDAP arba krb5 moduliu, Windows NPS ir Cisco ISE visi stovi šioje pozicijoje.
Skirtumas nulemia, kur žiūrėti. Atmestas slaptažodis yra tapatybės teikėjo atsakymas, kurį perduoda RADIUS. Laiko limitas paprastai yra atkarpa nuo RADIUS iki katalogo: pasibaigusi bind paskyra, nepasiekiamas katalogas arba užklausa, nukreipta į neteisingą backend. Jei naudotojo varde yra domeno priesaga, serveris gali pagal ją maršrutizuoti, ir ta pati paskyra, išsiųsta kaip CORP\alice ir [email protected], gali atsidurti skirtingose vietose. Windows NPS Security žurnale įrašomas 6272 už suteikimą ir 6273 už atmetimą, o tai pasako, ar sprendimas apskritai atėjo iš NPS.
Skaitykite nepavykimą tame šuolyje, kuris jį sukūrė
Vienas pranešimas nepavyksta prisijungti apima keturis skirtingus nepavykimus. Prieš ką nors keisdami, susiekite simptomą su šuoliu, kuris jį sukūrė.
| 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 |
Paskutinė eilutė yra ta, kuri nukreipia žmones pas neteisingą komandą. Access-Accept reiškia, kad prisijungimo duomenys priimti; tai nereiškia, kad vartai patalpino naudotoją į tinkamą baseiną arba pastūmė maršrutus. Grupės atributai svarbūs tik tada, kai vartų politika juos skaito. Mačiau, kaip teisingas prisijungimas atsidūrė svečių baseine, nes grupių susiejimas RADIUS pusėje buvo nustatytas kitam atributui nei tam, kurį tikrina vartai.
Sekite vieną prisijungimą nuo pradžios iki pabaigos
Pasirinkite vieną bandomąją paskyrą ir vienus vartus, tada stebėkite tą patį bandymą visuose keturiuose taškuose. RADIUS pusėje paleiskite derinimo eigą – freeradius -X išspausdina užklausą ir kiekvieną modulį, kurį paliečia – stebėkite vartų autentifikavimo žurnalą ir paleiskite tcpdump UDP pasikeitimui. Prisijunkite vieną kartą ir perskaitykite keturis pėdsakus iš eilės.
Norite pamatyti sutarimą: vartai klausė apie naudotoją, kurio tikėjotės, RADIUS serveris pasirinko backend, kurio tikėjotės, tas backend grąžino sprendimą, o atsakymo atributai atitinka politiką, kurią taiko vartai. Pirmoji vieta, kur pėdsakai nesutampa, yra jūsų gedimo linija. Jei atsakyme nėra grupės atributo, problema yra RADIUS pusėje, o ne VPN profilyje; jei atributas yra ir vartai jį ignoruoja, problema yra vartų politika.
Viena saugumo pastaba, kol ten esate. Bendrinama paslaptis apsaugo pasikeitimą, bet nešifruoja daugumos atributų. Jei vartai ir RADIUS serveris yra skirtinguose segmentuose, padėkite tą šuolį ant RADIUS per TLS arba privačiu keliu. Užšifruotas naudotojo tunelis nieko nesako apie backend ryšį.
Prieš uždarydami bilietą, patvirtinkite keturis dalykus. Vartai pasiekia RADIUS serverį tuo prievadu, kuriam iš tikrųjų sukonfigūruoti. Bendrinama paslaptis sutampa abiejose pusėse. RADIUS serveris išsprendžia tikslią naudotojo vardo formą, kurią siunčia vartai. Priėmimas perduoda atributus, kurių reikia vartų politikai. Kai visi keturi galioja, vis dar nepavykstantis prisijungimas yra vartų politikos, o ne autentifikavimo problema.