De ce a încetat OpenVPN să se conecteze după o actualizare de Ubuntu?

Profilurile VPN care funcționau săptămâna trecută se strică după o actualizare de versiune Ubuntu, iar jurnalul menționează rar actualizarea. Ceea ce numește este stratul care a eșuat: strângerea de mână TLS, cifrul negociat pentru canalul de date, pachetul instalat sau copia de OpenSSL pe care binarul o încarcă la pornire. Fiecare strat are forma sa de eroare și reparația sa, așa că clasificarea este prima lucrare, iar editarea a doua. Tratați profilul ca nevinovat până când jurnalul îl numește.

Care strat a eșuat: strângerea de mână, cifrul, pachetul sau biblioteca

Citiți jurnalul clientului înainte de a atinge profilul. prima eroare din ieșire este cea care identifică stratul; tot ce se tipărește după ea este de obicei consecința acelei prime eșuări. Când clientul nu pornește deloc, jurnalul VPN este fișierul greșit de deschis.

Reclamațiile despre certificate și semnături, sau un mesaj despre lungimea cheii, vin din canalul de control și din politica bibliotecii care îl guvernează. Un avertisment care începe cu DEPRECATED OPTION aparține în schimb negocierii canalului de date.

O linie de tipul Unrecognized option este o a treia categorie: noul binar nu mai acceptă o directivă pe care cel vechi o tolera, deci profilul trebuie rescris, nu biblioteca relaxată. Eșecurile de pachet arată din nou altfel, pentru că se produc înainte de a rula vreun cod de tunel. Un binar lipsă, un plugin care nu se încarcă sau un depozit care indică un nume de cod greșit produc toate acea formă. Patru simptome, patru locuri de verificat și aproape nicio suprapunere între reparații.

Când strângerea de mână eșuează, politica TLS respinge certificatul

Ubuntu 22.04 a mutat sistemul pe OpenSSL 3, iar nivelul de securitate implicit din acea ramură este mai strict cu semnăturile certificatelor și dimensiunile cheilor decât era 20.04. Un certificat CA semnat cu un digest mai vechi, sau o cheie sub pragul actual, eșuează acum în timpul strângerii de mână. Deoarece încă nimic nu a fost autentificat, eroarea se citește ca o parolă greșită sau un server mort.

Reparația îngustă atașează un șir de cifrare doar acestei conexiuni. În editorul de birou, deschideți profilul, mergeți la setările avansate și puneți DEFAULT:@SECLEVEL=0 în câmpul de cifrare TLS. Fișierul de chei NetworkManager ia aceeași valoare sub [vpn]:

[vpn]
tls-cipher=DEFAULT:@SECLEVEL=0

Reporniți NetworkManager și reconectați-vă, pentru că demonul memorează profilele analizate și altfel va continua să folosească copia pe care o are deja. Știți ce face linia înainte de a o păstra: acea setare este un prag peste mai mulți parametri de certificat și cheie, nu un nume de cifrare, așa că scăderea lui lărgește ce acceptă profilul individual. Notați ce server a cerut-o și renunțați la setare când operatorul reemite material actual. Modificarea /etc/ssl/openssl.cnf atinge același prag pentru fiecare program care citește acel fișier, ceea ce depășește mult VPN-ul.

OpenVPN 2.6 cere cifrul listat pentru negociere

Ubuntu 22.10 a adus OpenVPN 2.6, iar în acea versiune --cipher nu mai alege singur canalul de date. Cifrul trebuie să fie și în lista data-ciphers negociată, altfel clientul tipărește un avertisment de învechire și apoi nu reușește să ridice tunelul.

Pluginul NetworkManager din aceeași perioadă scria încă doar directiva veche. Acest detaliu împarte diagnosticul, pentru că un profil corectat manual se poate conecta dintr-un shell și totuși eșua din applet-ul de birou. Adăugați lista în fișierul de conexiune sub [vpn]:

data-ciphers=AES-256-CBC

Folosiți valoarea anunțată de server, nu pe cea pe care o țineți minte; un server care oferă AES-256-GCM nu va negocia cu o listă de client care numește doar CBC. Reporniți managerul și reconectați-vă, apoi repetați încercarea dintr-un shell cu cifrul transmis explicit atât pentru negociere, cât și pentru rezervă:

sudo openvpn --config client.ovpn --data-ciphers AES-256-CBC --data-ciphers-fallback AES-256-CBC

Dacă acea comandă ridică tunelul, serverul, certificatele și acreditările sunt toate sănătoase, iar singurul defect rămas este opțiunea salvată a managerului. Un avertisment despre directiva keysize ține de aceeași curățenie: comentați-o și păstrați fișierul original lângă profil.

Defectele de pachet și plugin arată ca defectele VPN

Nu fiecare eșec după actualizare este criptografic. Un depozit OpenVPN adăugat sub un nume de cod pe care versiunea nu îl folosește produce un pachet care nu se instalează niciodată, așa că comparați ce raportează lsb_release -a cu fișierul de listă adăugat. O componentă universe lipsă sau un buzunar de securitate produc un pachet care nu poate fi găsit deloc. Ambele cazuri lasă profilul neatins și tunelul imposibil.

Citiți eroarea managerului de pachete înainte de jurnalul VPN. Dacă clientul nu a fost niciodată instalat, nicio editare a profilului nu va produce o strângere de mână.

Profilurile cu doi factori care nu mai întreabă sunt versiunea pentru plugin a aceleiași povești. Provocarea vine de la un plugin de autentificare, iar o actualizare care l-a eliminat sau înlocuit lasă profilul intact în timp ce solicitarea dispare. Reinstalați pluginul acceptat în loc să ștergeți al doilea factor pentru ca conexiunea să funcționeze.

O bibliotecă de furnizor se poate ascunde în spatele unei erori de politică

Un tipar merită recunoscut pentru că învinge orice reparație de politică. Un instrument de configurare al unui furnizor de hardware poate instala propriile biblioteci OpenSSL și le poate plasa înaintea copiilor de sistem în calea de căutare a încărcătorului. Clientul pornește atunci împotriva unei biblioteci pe care nimeni nu a actualizat-o, iar eșecul de pornire arată exact ca un certificat respins.

Reinstalarea pachetului VPN nu schimbă care bibliotecă este găsită prima, iar coborârea nivelului TLS nu poate ajunge la o bibliotecă ce nu a venit niciodată din sistem. Întrebați încărcătorul ce obiecte criptografice rezolvă binarul de fapt:

ldd /usr/sbin/openvpn | grep -i -E 'ssl|crypto'

Eliminați sau redirecționați copia furnizorului, apoi rulați din nou aceeași verificare. Versiunea așteptată trebuie să fie cea în uz înainte de a reveni la profil.

Fixarea unui client mai vechi cumpără timp, nu o soluție

Păstrarea versiunii anterioare a clientului restaurează tunelul cât timp ține reținerea. De asemenea, îngheață actualizările de securitate pentru acel pachet și programează aceeași ruptură pentru următoarea actualizare, așa că tratați-o ca o soluție temporară datată, nu ca o rezolvare.

Dacă totuși îl fixați, țineți pachetul în mod explicit ca o actualizare nesupravegheată să nu poată anula fixarea, notați motivul și data de revizuire și setați o reamintire pentru următoarea versiune de profil a furnizorului. Condiția care merită urmărită este un profil de server care negociază un cifru actual; odată ce există, fixarea nu mai are nicio justificare. O fixare neregistrată, în schimb, devine o întrerupere pe care nimeni nu o poate explica șase luni mai târziu, pentru că persoana care a aplicat-o a plecat, iar fișierul nu înregistrează nimic.

Data viitoare când un VPN moare după o actualizare de versiune, puneți cinci întrebări în ordine: ce strat a produs prima eroare, politica TLS a respins certificatul, cifrul este negociabil în ambele sensuri, pachetul și pluginul său s-au instalat cu adevărat și ce bibliotecă încarcă procesul. Abia când toate cinci revin curate are sens o retrogradare.