Cum ajunge o conectare VPN la RADIUS și la furnizorul tău de identitate

Săptămâna trecută un utilizator a reușit să se conecteze la VPN și totuși a ajuns într-o rețea unde nimic nu se rezolva. Clientul spunea conectat, jurnalul gateway-ului spunea Access-Accept, iar echipa de identitate spunea că contul este în regulă. Conectarea funcționase; autorizarea din spatele ei nu. Când o conectare VPN eșuează, parcurg calea pe care cererea o urmează de fapt — client, gateway, server RADIUS, furnizor de identitate — și mă opresc la primul salt al cărui răspuns nu se potrivește cu următorul.

Clientul nu vorbește niciodată RADIUS

Indiferent ce arată aplicația de pe laptop, primul ei salt este protocolul VPN: IKEv2, OpenVPN, WireGuard sau un client bazat pe TLS. RADIUS nu apare în acel schimb. Clientul se autentifică la gateway cu un certificat, un nume de utilizator și o parolă, sau o metodă EAP transportată în configurația tunelului.

Asta contează când citiți jurnale, pentru că eroarea generică de autentificare pe care o vede utilizatorul este produsă de gateway după ce a vorbit deja cu altceva. Dacă clientul nu ajunge niciodată la gateway, nu există nicio cerere RADIUS de depanat, iar o oră petrecută pe serverul RADIUS este pierdută. Confirmați că tunelul a urcat măcar înainte de a atinge backend-ul.

Gateway-ul este clientul RADIUS

Imediat ce configurația tunelului ajunge în punctul în care acreditările trebuie verificate, gateway-ul devine un server de acces la rețea. Construiește o Access-Request: User-Name, o parolă sau payload EAP, NAS-IP-Address sau NAS-Identifier, și un Message-Authenticator când metoda cere unul. Cererea merge implicit la UDP 1812, iar contabilitatea la 1813. Implementările mai vechi folosesc încă 1645 și 1646, așa că o regulă de firewall scrisă pentru o pereche explică multe eșecuri silențioase.

Ambele părți împart un secret, iar acesta nu este o acreditare de utilizator. Semnează schimbul, iar fiecare răspuns este verificat față de el. Configurați secretul diferit pe cele două părți și serverul nu răspunde cu secret greșit — aruncă cererea sau răspunsul nu trece verificarea, așa că gateway-ul raportează un timeout. Un secret greșit și un server mort arată identic din gateway, de aceea testez saltul cu un instrument de client înainte să dau vina pe director.

Protocolul este mic și vechi — RFC 2865 definește schimbul de autentificare —, dar atributele pe care le transportă sunt baza pe care este construită cea mai mare parte a politicii 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'

Serverul RADIUS poate fi doar fațada furnizorului de identitate

Oamenii vorbesc despre RADIUS și furnizorul de identitate ca și cum ar fi aceeași cutie. De multe ori nu sunt. Serverul RADIUS primește Access-Request și apoi întreabă altceva — Active Directory prin LDAP sau Kerberos, un fișier local de utilizatori sau un serviciu extern — înainte să răspundă. FreeRADIUS cu modulul LDAP sau krb5, Windows NPS și Cisco ISE stau toate în această poziție.

Distincția decide unde priviți. O parolă respinsă este un răspuns al furnizorului de identitate transmis de RADIUS. Un timeout este de obicei porțiunea RADIUS-director: un cont bind expirat, un director inaccesibil sau o cerere direcționată către backend-ul greșit. Dacă numele de utilizator are un sufix de domeniu, serverul poate ruta pe el, iar același cont trimis ca CORP\alice și [email protected] poate ajunge în locuri diferite. În Windows NPS, jurnalul Security înregistrează 6272 pentru o acordare și 6273 pentru o refuzare, ceea ce spune dacă decizia a venit de la NPS.

Citiți eșecul la saltul care l-a produs

Un singur mesaj de nu se poate conecta acoperă patru eșecuri diferite. Înainte să schimbați ceva, potriviți simptomul cu saltul care l-a produs.

Ultimul rând este cel care trimite oamenii la echipa greșită. Access-Accept înseamnă că acreditările au fost acceptate; nu înseamnă că gateway-ul a plasat utilizatorul în pool-ul corect sau a împins rute. Atributele de grup contează doar dacă politica gateway-ului le citește. Am văzut o conectare corectă ajungând într-un pool de oaspeți pentru că maparea grupurilor era configurată pe partea RADIUS pentru un atribut diferit de cel pe care îl inspectează gateway-ul.

Urmați o conectare de la început la sfârșit

Alegeți un singur cont de test și un singur gateway, apoi observați aceeași încercare în toate cele patru puncte. Porniți o rulare de depanare pe partea RADIUS — freeradius -X tipărește cererea și fiecare modul pe care îl atinge — urmăriți jurnalul de autentificare al gateway-ului și rulați tcpdump pentru schimbul UDP. Conectați-vă o dată și citiți cele patru urme în ordine.

Ce vreți să vedeți este acordul: gateway-ul a întrebat despre utilizatorul pe care îl așteptați, serverul RADIUS a ales backend-ul pe care îl așteptați, acel backend a returnat o decizie, iar atributele din răspuns corespund politicii pe care o aplică gateway-ul. Primul loc unde urmele nu sunt de acord este linia voastră de defect. Dacă răspunsul nu poartă un atribut de grup, problema este pe partea RADIUS, nu în profilul VPN; dacă atributul există și gateway-ul îl ignoră, problema este politica gateway-ului.

O notă de securitate cât timp sunteți acolo. Secretul partajat protejează schimbul, dar nu criptează majoritatea atributelor. Dacă gateway-ul și serverul RADIUS sunt pe segmente diferite, puneți acel salt pe RADIUS prin TLS sau pe o cale privată. Un tunel de utilizator criptat nu spune nimic despre legătura către backend.

Înainte să închideți tichetul, confirmați patru lucruri. Gateway-ul ajunge la serverul RADIUS pe portul pentru care este configurat cu adevărat. Secretul partajat se potrivește pe ambele părți. Serverul RADIUS rezolvă forma exactă a numelui de utilizator pe care îl trimite gateway-ul. Acceptarea poartă atributele de care are nevoie politica gateway-ului. Când toate patru sunt valabile, o conectare care încă eșuează este o problemă de politică a gateway-ului, nu de autentificare.