De ce RADIUS vede o adresă IP în locul numelui de utilizator VPN

strongSwan poate pune identitatea IKE în RADIUS User-Name înainte de orice schimb EAP. Decideți cine solicită identitatea contului, apoi corelați o singură încercare.

Un client Windows IKEv2 se conectează, iar cererea RADIUS sosește cu o adresă acolo unde ar trebui să fie numele contului. Nimic nu a eșuat încă, și exact asta încurcă: gateway-ul raportează identitatea pe care clientul a prezentat-o la nivelul IKE. Numele de utilizator pe care îl vrea backend-ul dumneavoastră poate veni dintr-un schimb EAP separat care nu a avut loc încă. Decideți cine îl solicită înainte de a schimba contul.

Două identități călătoresc într-o singură conexiune

Într-o conexiune pot apărea două nume. Identitatea IKE identifică partenerul în timpul configurării tunelului, iar pluginul eap-radius o copiază inițial în RADIUS User-Name. Identitatea EAP este o altă valoare, folosită pentru autentificarea utilizatorului, și poate să nu fie trimisă niciodată dacă nimeni nu o cere.

De aceea jurnalul RADIUS poate arăta o adresă în timp ce contul există și parola este corectă. Backend-ul este întrebat despre stratul greșit. Atributul RADIUS este doar transportul pentru numele care a fost ales.

Rugați gateway-ul să ceară o identitate EAP

O configurație acceptată face gateway-ul să ceară identitatea EAP înainte de a preda autentificarea către RADIUS. În secțiunea de autentificare la distanță a conexiunii, setați metoda pe eap-radius și cereți explicit identitatea EAP. Fragmentul de mai jos aparține în interiorul unui bloc de conexiune existent, nu într-un fișier propriu. Confirmați conexiunea și backend-ul de configurare înainte de a copia sintaxa dintr-o altă implementare.

remote {
    auth = eap-radius
    eap_id = %any
}

Astfel, backend-ul primește identitatea pe care clientul o furnizează în schimbul EAP în locul adresei IKE. Nimic altceva la conexiune nu se schimbă.

Sau lăsați RADIUS să înceapă schimbul EAP

Cealaltă configurație lasă prima mișcare de partea RADIUS. Pluginul poate trimite o indicație EAP-Start în loc să aștepte un răspuns inițial de identitate, ceea ce permite serverului să conducă schimbul. Aceasta este configurație la nivel de plugin, deci afectează fiecare conexiune care folosește pluginul.

charon {
    plugins {
        eap-radius {
            eap_start = yes
        }
    }
}

Alegeți o configurație împreună cu operatorul RADIUS, în loc să le activați pe ambele și să sperați. Ele descriu fluxuri de lucru diferite, iar un server care se așteaptă să înceapă nu va gestiona neapărat un gateway care începe conversația. Documentația pluginului le descrie pe ambele, inclusiv ce identitate poartă fiecare pas.

Urmăriți o singură încercare în ambele jurnale

Corelați o singură încercare în ambele jurnale. Observați identitatea IKE, apoi dacă are loc un schimb EAP-Identity, apoi ce nume primește pasul de autentificare. Un backend care respinge adresa înainte de schimbul EAP poate opri procesul înainte ca identitatea dorită să fie văzută.

journalctl -u strongswan -f

Păstrați formatul exact al numelui de utilizator așteptat de sistemul de identitate, inclusiv prefixul de domeniu. Nu inventați niciodată un cont dintr-o valoare în formă de adresă și nu dezactivați niciodată autentificarea pentru a îndeplini o regulă de politică. O identitate EAP este un nume declarat, iar metoda trebuie încă să o dovedească. Scrieți numele rezultat în înregistrarea de test, astfel încât următoarea încercare să pornească de la o stare cunoscută.

Dacă fluxul corectat ajunge la contul corect și este încă respins, următoarea dovadă este metoda EAP și politica backend-ului, nu identitatea. Repetarea unei resetări de parolă nu poate repara o valoare aleasă la un strat de protocol anterior.

Articole similare