PSK L2TP/IPsec respins: întâi dialogul, apoi fișierele

Lipești cheia prepartajată din mesajul administratorului în dialogul NetworkManager, bifezi caseta pentru a o afișa, și ea se potrivește caracter cu caracter. Conexiunea se termină totuși cu o eroare de autentificare înainte ca tunelul să fie ridicat. Prima dată când am văzut asta am presupus că cheia este greșită; nu era. Alte două lucruri decid ce citește de fapt demonul: fișierul de secrete pe care modulul îl scrie pentru acea conexiune și dacă valoarea a trecut prin dialog neschimbată.

Traseul de mai jos urmărește cheia din câmp până în fișier, iar această ordine este cea care îți spune unde s-a pierdut. Fă-o pe mașina care eșuează, nu pe cea care funcționează, pentru că diferența dintre cele două este de obicei așezarea fișierelor, nu cheia.

Începe cu dialogul, dar nu te încrede în câmp

Deschide fila IPsec a conexiunii și scrie din nou cheia în loc să o lipești. O cheie copiată dintr-un mesaj de chat, dintr-un PDF sau dintr-un manager de parole poate sosi cu un salt de linie la final pe care câmpul nu îl afișează, iar caracterele vizibile arată în continuare corect.

Apasă controlul de afișare a parolei și uită-te la sfârșitul șirului, nu la mijloc. Dacă cursorul lasă o linie goală sub text, șterge-o și scrie din nou ultimul caracter. Acea singură corectură rezolvă o parte surprinzătoare din astfel de rapoarte și costă mai puțin decât citirea oricărui jurnal.

Dacă cheia vine dintr-un sistem de tichete care rupe liniile lungi, cere-o printr-un canal care nu le rupe. Compară lungimile cu administratorul în loc să te uiți la două șiruri alăturate; un caracter pierdut într-un punct de rupere este invizibil într-un font proporțional.

Urmărește cheia în /etc/ipsec.d

Modulul nu predă niciodată PSK-ul demonului IPsec ca argument pe linia de comandă. În schimb păstrează valoarea într-un fișier de secrete și se asigură că demonul îl include, adăugând o linie include în /etc/ipsec.secrets dacă nu există una. Ce ține dialogul este o intrare pentru fișierul generat, nu valoarea folosită.

Listează ce există înainte de a schimba ceva:

ipsec --version
sudo ls -l /etc/ipsec.d/*.secrets /etc/ipsec.d/ipsec.nm-l2tp.secrets 2>/dev/null
sudo grep -n "include" /etc/ipsec.secrets

Versiunile mai vechi ale modulului scriau un fișier pentru fiecare conexiune, numit după UUID-ul conexiunii, de exemplu /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. Ștergerea unui profil din applet nu șterge acel fișier în mod fiabil. Dacă un fișier vechi de la un server anterior este încă pe disc și încă inclus, demonul poate alege un secret care aparține unui profil pe care nu îl mai folosești, iar conexiunea eșuează deși câmpul vizibil este corect.

Înțelege ce a făcut modificarea 1.2.12 actualizărilor

Versiunea 1.2.12 a modulului a înlocuit fișierele de secrete pentru fiecare conexiune cu un singur fișier partajat, /etc/ipsec.d/ipsec.nm-l2tp.secrets. O actualizare nu curăță fișierele mai vechi după UUID, iar o linie include /etc/ipsec.d/*.secrets existentă le include în continuare. Versiunea 1.2.16 a schimbat tratarea propunerilor implicite, nu așezarea secretelor.

Această istorie explică de ce două mașini cu ceea ce pare același profil se comportă diferit. Cheia este identică; setul de fișiere pe care demonul le include nu este. Când înlături un fișier orfan, mută-l deoparte în loc să îl ștergi, confirmă conexiunea și abia apoi șterge-l, după ce starea funcțională este consemnată. Redenumirea păstrează valoarea veche recuperabilă dacă se dovedește că defecțiunea este în altă parte.

Separă caracterele pe care formatul de stocare nu le poate ține

Documentația strongSwan pentru șirul de secret partajat afirmă că valoarea nu poate conține un salt de linie sau un caracter de ghilimea dublă. O cheie lipită dintr-un document poate purta oricare dintre ele fără nicio diferență vizuală într-un dialog normal.

Din 1.2.12 valoarea stocată nu mai este text simplu. Modulul codifică PSK-ul în base64 înainte de a ajunge în fișier, iar notele de versiune prezintă acea codificare drept motivul pentru care ghilimeaua dublă este acum acceptabilă într-o cheie. Așadar ghilimeaua tastată în câmp este reprezentabilă; același lucru nu este valabil pentru fiecare caracter de control.

Lungimea este o altă constrângere. Nu există un minim universal în software-ul L2TP/IPsec: unii clienți acceptă chei mai scurte de douăzeci de caractere, iar unele gateway-uri impun un minim. Dacă o cheie scurtă este refuzată, regula aparține politicii serverului sau validării acelui client, iar ridicarea a ceva local nu o va schimba.

Citește care nivel de autentificare a eșuat

Rulează mai întâi ipsec --version, pentru că strongSwan și Libreswan folosesc nume de fișiere și sintaxă diferite, iar un sfat pentru unul poate dăuna celuilalt. Apoi citește etapa eșecului din mesajul clientului sau din jurnalul demonului: o plângere despre cheia prepartajată este un eveniment diferit de un nume de utilizator și o parolă refuzate.

PSK-ul autentifică extremitățile tunelului. Numele de utilizator și parola autentifică persoana din interiorul L2TP, iar PPP se ocupă de ele după ce asocierea IPsec este ridicată. Un PSK corect cu un cont greșit eșuează în continuare, iar schimbarea contului nu va repara o cheie pe care demonul nu a citit-o niciodată corect.

Când închizi tichetul, notează toate patru: versiunea modulului, fișierul de secrete folosit, dacă cheia a fost rescrisă sau lipită și nivelul numit în eroare. Atunci oricine va relua acest traseu mai târziu va putea sări direct la diferența dintre mașina care funcționează și cea care eșuează.