Autentificarea VPN se blochează după un Access-Challenge RADIUS

Parola este corectă, autentificarea VPN eșuează totuși, iar serverul RADIUS poate a făcut exact ce i s-a cerut. Gateway-ul a primit probabil un Access-Challenge, nu a afișat nimic util și apoi a expirat sau a tratat acel răspuns ca pe o respingere. Din partea clientului pare o acreditare greșită sau un tunel rupt. Cauza se află de obicei la mijlocul unei conversații pe care nimeni nu a capturat-o.

O autentificare, două schimburi RADIUS

Când backend-ul vrea un al doilea factor, nu răspunde la prima cerere cu acceptare sau respingere. Răspunde cu codul 11 și așteaptă următorul răspuns al utilizatorului, pe care gateway-ul trebuie să îl trimită înapoi într-o cerere de continuare. Acea continuare aparține aceleiași conversații de autentificare, nu unei noi încercări de autentificare.

Într-o configurare funcțională, utilizatorul vede un al doilea prompt: mai întâi parola, apoi un cod de unică folosință, sau un singur prompt combinat dacă operatorul a documentat unul. Într-o configurare defectă, al doilea prompt nu apare niciodată și autentificarea pur și simplu eșuează.

Acesta este simptomul de urmărit și este ușor de confirmat doar din partea clientului: dacă clientul VPN cere exact un secret și apoi respinge o parolă despre care știți că este validă, schimbul s-a încheiat probabil la provocare.

Ce transportă de fapt provocarea

Specificația RADIUS descrie codul 11 în secțiunea 4.4 și permite două atribute care contează aici. Reply-Message conține text destinat utilizatorului, iar State conține o valoare opacă pe care serverul vrea să o primească înapoi. NAS-ul nu trebuie să interpreteze State, doar să îl returneze neschimbat.

Cererea de continuare folosește un Identifier nou și un Request Authenticator nou și trebuie să transporte aceeași valoare State plus răspunsul utilizatorului. Serverul o asociază cu provocarea în așteptare prin acel State, de aceea un gateway care regenerează sau aruncă atributul nu poate finaliza ceremonia. Și response authenticator din fiecare răspuns trebuie validat, altfel NAS-ul ar trebui să arunce pachetul.

Secțiunea 4.4 adaugă detaliul care explică majoritatea eșecurilor silențioase: un NAS care nu poate susține provocări tratează Access-Challenge ca pe o respingere. Dacă serviciul VPN al gateway-ului este mai vechi decât acel suport sau îl omite, cererea backend-ului pentru un al doilea factor devine un «autentificare eșuată» imediat, fără niciun prompt.

Unde se pierde cererea înlănțuită

Primul suspect este calea promptului, nu acreditarea. Un portal care afișează un câmp OTP pentru autentificările web nu face automat același lucru pentru serviciul VPN, iar unele gateway-uri transmit o provocare doar clienților care anunță această capacitate. Testați același cont în ambele puncte de intrare; dacă portalul funcționează și VPN-ul nu, priviți predarea, nu tokenul.

Formatul de introducere este al doilea suspect. Concatenarea parolei și a codului fără separatorul documentat de furnizor, sau lăsarea unei acreditări salvate să redea un cod vechi, eșuează într-un mod care arată identic cu o parolă greșită. Folosiți promptul separat sau formatul combinat documentat de operator și nu improvizați niciodată un delimitator.

Există defecte specifice versiunii, dar o listă de versiuni corectate de acum ani nu este un diagnostic pentru implementarea de azi. Citiți notele de versiune ale software-ului pe care îl rulați efectiv și păstrați etapa de schimb observată ca dovadă.

Urmăriți o singură încercare de la cap la coadă

Reproduceți-o o dată, cu depanarea pe partea de server activată, și țineți orice altă sesiune în afara ferestrei de captură:

$ sudo radsniff -i eth0 -x -f 'udp port 1812'
$ sudo freeradius -X
$ radtest alice 'password' 127.0.0.1 0 testing123

În ieșire, căutați forma conversației, nu o singură linie. Un prim Access-Request cu Identifier 3, un Access-Challenge care transportă State, apoi un al doilea Access-Request cu Identifier 4 care repetă acel State și include răspunsul utilizatorului. Dacă a doua cerere lipsește, gateway-ul nu a continuat niciodată. Dacă sosește fără State, serverul nu o poate asocia cu provocarea în așteptare și de obicei o respinge.

Ascundeți acreditările, tokenurile și datele de identitate inutile când partajați urma și corelați evenimentele dintr-o singură încercare în loc să amestecați reluări din mai multe file de browser. Marca temporală este prietenul dumneavoastră aici; o provocare care sosește după ce clientul a renunțat pare o respingere pentru utilizator și un răspuns lent în jurnal.

Starea finală dorită este o conversație finalizată și autorizată, urmată de accesul la serviciu prevăzut. Un răspuns care sosește de la serverul RADIUS demonstrează mult mai puțin.