Schimbul IKEv2 funcționează, apoi autentificarea eșuează: unde să cauți

Un client care primește un răspuns IKEv2 a dovedit că gateway-ul este accesibil, că ambele părți pot negocia o propunere și că schimbul inițial de chei s-a încheiat. Nu a dovedit însă că cineva este autentificat. Următorul schimb transportă identități, certificate sau EAP, și acolo se oprește de obicei conexiunea. Citirea verificării care a eșuat este întregul diagnostic, iar mesajul de eroare singur rareori spune asta.

Verificarea 1: citiți etapa, nu mesajul

O respingere poate veni din trei locuri: clientul refuză identitatea serverului, gateway-ul refuză dovada clientului și un serviciu extern de autentificare refuză contul.

Fiecare produce o altă linie de jurnal pe altă mașină și fiecare are altă soluție. O respingere a certificatului serverului pe partea clientului este o problemă de încredere sau de denumire la client; o respingere a certificatului clientului pe partea gateway-ului este o problemă de încredere la gateway; o eroare EAP este o problemă de cont sau de backend. Mesajul pe care îl vedeți este de obicei rezumatul clientului despre unul dintre aceste cazuri, motiv pentru care jurnalul gateway-ului contează la fel de mult ca cel al clientului.

Verificarea 2: ce identitate a fost verificată

Un client poate refuza certificatul serverului sau identitatea așteptată înainte de a se oferi vreo acreditare de utilizator, iar o adresă de server care funcționează nu înlocuiește acea verificare. Identificatorul așteptat de client trebuie să corespundă cu ceea ce prezintă gateway-ul, ceea ce este un fapt de configurare și nu un fapt de rețea.

În termenii strongSwan aceasta este rightid la client și identitatea proprie a gateway-ului de cealaltă parte, iar o nepotrivire eșuează înainte de a se discuta măcar EAP.

Gateway-ul, separat, poate refuza certificatul clientului, dovada cheii acestuia sau autentificarea contului, iar aceste trei nu sunt interschimbabile. Resetarea parolei unui utilizator nu reînnoiește un certificat de dispozitiv, iar reinstalarea unui certificat de dispozitiv nu repară o identitate greșită a serverului. Pentru eșecurile de certificat, verificați mai întâi ceasul, apoi lanțul de încredere, apoi identificatorul așteptat; un client al cărui ceas este decalat cu câteva minute eșuează la o verificare de valabilitate care pare o eroare de încredere. swanctl --list-certs la ambele capete arată ce deține de fapt fiecare parte.

Verificarea 3: dacă EAP este implicat

Clientul și serverul trebuie să convină asupra unei metode acceptate, iar backend-ul trebuie să accepte identitatea furnizată.

Un nume de utilizator poate avea nevoie de un sufix de domeniu sau de un format de cont specific cerut de implementare, iar formatul este documentat, nu de ghicit. Furnizarea câmpurilor documentate ale operatorului este mai rapidă decât încercarea variantelor și evită o a doua problemă: încercările repetate pot declanșa blocarea contului, care apoi ascunde etapa inițială în spatele unei noi erori. Dacă metoda este EAP-MSCHAPv2 împotriva unui director, eroarea poate aparține directorului și nu VPN-ului.

Nu testați problemele de identitate dezactivând verificările de identitate. Asta transformă o eroare diagnosticabilă într-una nediagnosticabilă și lasă conexiunea mai slabă decât înainte.

Verificarea 4: ce se întâmplă după o autentificare reușită

După ce IKE_AUTH se încheie, negocierea CHILD_SA decide ce selectori de trafic sunt instalați, și acolo o conexiune poate reuși și totuși să nu treacă nimic.

O autentificare care tocmai a început să funcționeze dezvăluie adesea o problemă de selector sau de rută care era ascunsă în spatele erorii de autentificare. Dacă tunelul urcă și o aplicație tot nu ajunge la destinație, priviți selectorii și rutele negociate, nu identitatea din nou. Schimbarea setărilor de identitate în acel moment vizează etapa greșită și de obicei strică o autentificare funcțională. Confirmați cu swanctl --list-sas, care arată copiii și selectorii lor separat de IKE SA.

Verificarea 5: ce să predați asistenței

O cronologie curățată și respingerea precisă valorează mai mult decât un export de diagnostic complet, iar exportul poate conține chei private sau acreditări pe care nu ar trebui să le partajați.

Notați ora cu fusul orar, versiunile clientului și ale gateway-ului, metoda, șirul de identitate oferit în locul parolei și etapa exactă care l-a respins. documentația de configurare IKEv2 a strongSwan descrie setările de identitate și EAP care determină aceste rezultate, și este referința de citit înainte de a schimba un câmp. Apoi schimbați un singur lucru și retestați o conexiune nouă, pentru că o sesiune din cache vă va spune despre configurația veche.