VPN-ul se strică după o actualizare de client? Comparați negocierea

Actualizările înlocuiesc componenta care analizează profilul și negociază tunelul. Primul eșec după o actualizare este o dovadă despre o schimbare anume, nu o sentință despre versiune. Păstrarea acelei erori împreună cu versiunea și marca temporală este cel mai valoros pas pe care îl puteți face înainte de a reinstala ceva.

Două mecanisme explică majoritatea acestor rupturi. Separarea lor este munca.

Ce a schimbat negocierea sub dumneavoastră

OpenVPN negociază cifrul canalului de date în loc să îl ia dintr-o singură directivă, iar opțiunile care controlează această negociere și-au schimbat sensul între versiuni. Un profil scris pentru un client mai vechi se poate conecta și apoi poate să nu ajungă la un acord privind un canal de date, ceea ce se manifestă ca o deconectare în loc de o eroare clară de configurare. Versiunile mai noi și consolidează sau retrag comportamente moștenite și livrează un mod de compatibilitate pentru perechile care nu au migrat încă. Așadar o actualizare poate strica un profil funcțional fără să atingă un singur octet al fișierului.

Efectul asupra clientului este asimetric. Canalul de control urcă, autentificarea reușește, iar tunelul moare după aceea, ceea ce este semnătura unei nepotriviri de negociere și nu a unui profil respins.

Citiți versiunea instalată înainte de a teoretiza despre server. Acel șir este un fapt local pe care îl puteți verifica fără a cere cuiva acces.

Profilul poate fi analizat și poate însemna altceva

O directivă care supraviețuiește analizei nu este neapărat o directivă care încă face ce intenționa autorul ei. Opțiunile pot fi acceptate de dragul compatibilității și ignorate, redenumite sau aplicate într-un caz mai îngust decât înainte. Fiindcă nimic nu semnalează o eroare, profilul pare corect în timp ce comportamentul de dedesubt s-a schimbat. Tocmai acea tăcere face aceste regresii costisitoare.

Întrebați care linii sunt cu adevărat responsabile de rezultatul negociat, apoi comparați-le cu documentația versiunii pe care o rulați acum. Comparația aceea este scurtă și în ea stă diferența dintre o corectare și o revenire.

openvpn --version | head -n 2
openvpn --show-ciphers | head -n 10
grep -nE '^(cipher|data-ciphers|ncp-|tls-)' office.ovpn

Platforma s-a mișcat în același timp

Versiunile de client vin rareori singure. O actualizare a sistemului de operare, o solicitare de permisiune care acum cere o aprobare explicită sau o politică gestionată aplicată dispozitivului pot sosi în aceeași săptămână și pot produce o defecțiune pe care clientul este învinovățit. Platformele mobile adaugă un strat propriu, fiindcă aplicația cere sistemului un tunel, iar sistemul decide ce poate acel tunel să ruteze.

Notați acele schimbări separat pe cronologie. Când autentificarea reușește dar rutele sau rezolvarea numelor eșuează, etapa interesantă este cea de după strângerea de mână, iar slăbirea validării certificatului nu o va atinge.

Retestați evenimentul care a declanșat raportul

Reproduceți secvența originală, nu o versiune simplificată a ei: conexiunea inițială, aplicația care a eșuat și o reconectare obișnuită după o schimbare de rețea. Un tunel care urcă în condiții de test și totuși cade pe calea de reconectare nu este reparat, iar diferența indică de obicei unde se află defectul real. Un raport care omite pasul de reconectare închide un defect care este încă deschis.

Obțineți profilul acceptat al operatorului sau corectarea furnizorului prin canalul verificat, în loc să reveniți complet. O retrogradare amplă readuce și corectările de securitate pe care le aducea actualizarea, iar acest schimb merită rareori o singură conexiune funcțională.