Cum se traduce autentificarea hibridă IKEv1 în autentificarea utilizatorilor IKEv2

Orice profil VPN vechi care cere întâi un certificat de server și apoi un nume de utilizator poartă două evenimente de autentificare într-un singur schimb, iar această formă supraviețuiește protocolului care a introdus-o. Modul hibrid IKEv1 a fost construit exact pentru asta: gateway-ul se dovedește cu o cheie publică, iar utilizatorul se dovedește mai târziu prin XAuth. IKEv2 exprimă aceeași idee în doi pași cu alt mecanism, iar în aceste diferențe eșuează migrările. Niciun număr de versiune nu transformă unul în altul, iar copierea vechilor nume de opțiuni într-un profil nou produce un client care negociază și apoi nu autentifică nimic.

Ce făcea modul hibrid în interiorul IKEv1

Într-un profil hibrid, responder-ul semnează schimbul primei faze cu certificatul său, în timp ce inițiatorul nu prezintă niciunul în mod deliberat. Dovada identității este deci asimetrică, iar asta a permis unui gateway să-și păstreze PKI-ul existent în timp ce utilizatorii își păstrau parolele de director. După ce prima fază se încheie, XAuth rulează ca cerere și răspuns care transportă atributele de nume de utilizator și parolă în canalul ISAKMP deja criptat.

Observați unde ajunge încrederea. Certificatul răspunde la ce gateway a ajuns clientul; XAuth răspunde la ce utilizator vrea acces. Niciunul nu-l înlocuiește pe celălalt, iar un client configurat să accepte orice certificat de server a aruncat în liniște primul răspuns. Eticheta hibrid se folosește și pentru modul agresiv cu cheie prepartajată plus XAuth, o altă aranjare cu aceeași experiență de utilizator, așa că citiți profilul, nu numele. Ambele variante provin din schițe care nu au devenit niciodată standarde, și de aceea doi producători pot implementa modul hibrid și nu interoperă cu niciunul.

Cum ajunge IKEv2 la aceleași două dovezi

IKEv2 împarte munca între IKE_SA_INIT și IKE_AUTH. Primul schimb negociază propuneri și chei fără nicio identitate; al doilea transportă IDi, IDr și sarcinile AUTH. Sub EAP, prima sarcină AUTH a inițiatorului pleacă goală, responder-ul se autentifică mai întâi cu certificatul și semnătura sa, iar conversația EAP rulează apoi în mesajele IKE_AUTH.

Mecanismul care face asta sigur este materialul cheie. O metodă EAP reușită exportă o cheie de sesiune, iar sarcina AUTH finală a inițiatorului este calculată din ea, astfel încât dovada utilizatorului și cheile tunelului sunt legate. XAuth nu are echivalent: atributele sale sosesc după prima fază și nu contribuie cu nimic la chei. Exact acest gol a fost proiectat cadrul IKEv2 să-l închidă, și de aceea o autentificare IKEv2 funcțională validează certificatul serverului înainte de a cere ceva.

Această ordine este și un diagnostic util. Când un client se plânge de credențiale înainte de a vă fi arătat un certificat, nu face deloc un schimb EAP IKEv2.

Păstrați trei identități separate

O migrare merge prost când trei identități se prăbușesc într-un singur câmp. Există identitatea gateway-ului pe care clientul o validează, de obicei un nume DNS în subject sau SAN-ul certificatului. Există identitatea utilizatorului prezentată în EAP, care poate fi o autentificare de domeniu, o adresă sau un șir explicit de identitate EAP. Și există sursa de autorizare care mapează acel utilizator pe rețele și rute.

Sintaxa swanctl din strongSwan face separarea vizibilă: conexiunea setează remote { auth = pubkey } pentru gateway și local { auth = eap-mschapv2 } pentru utilizator, identitatea EAP fiind purtată separat.

Când identitatea utilizatorului din profilul nou diferă de vechile atribute XAuth, de exemplu un UPN în loc de un nume scurt, serverul de autentificare vede un utilizator necunoscut, iar defecțiunea arată ca o parolă greșită. Verificați șirul de identitate înainte de a verifica credențialele.

Mapați opțiunile, apoi așteptați-vă la capcane

Maparea este scurtă și fiecare rând are o capcană care apare doar la autentificare.

Niciunul dintre acele rânduri nu este o simplă redenumire. Sarcina de configurare livrează adrese și resolvere printr-o listă tipizată de atribute, în timp ce spațiul de atribute al XAuth a fost propria invenție; a le trata ca interschimbabile este felul în care un profil ajunge să ceară o setare pe care gateway-ul nu o va trimite niciodată.

Selectoarele de trafic merită propriul avertisment. IKEv1 exprima traficul interesant prin ID-uri de proxy legate de un schimb quick mode, în timp ce IKEv2 negociază selectoarele în timpul IKE_AUTH, iar responder-ul le poate îngusta. O nepotrivire produce un IKE SA stabilit fără child SA, pe care unii clienți îl afișează bucuroși ca fiind conectat.

Tratați vechea conexiune ca o graniță

RFC 9395 declară IKEv1 perimat, așa că o conexiune hibridă veche este o graniță de compatibilitate cu o dată, nu o fundație. Rulați ambele profiluri în paralel în timpul schimbării, pentru că testul care contează nu este dacă noul profil pornește, ci dacă același utilizator pe același dispozitiv ajunge la aceleași resurse.

Păstrați validarea certificatelor strictă până la capăt. Odată ce clientul nu își mai prezintă propriul certificat, tentația este să relaxați verificarea serverului până când handshake-ul se încheie, iar asta schimbă singura dovadă rămasă pe o pictogramă verde.

Notați patru lucruri înainte de a retrage vechiul profil: metoda EAP, șirul de identitate, sursa de autorizare și data la care se termină suportul.