Testați recuperarea serverului VPN după repornire: ce verificați mai întâi

Reporniți serverul fără ca cineva să fie conectat, apoi conectați-vă dintr-o rețea pe care nu o controlați. Acest singur test răspunde dacă recuperarea este reală, pentru că un tunel care funcționează doar după ce cineva rulează o comandă manual nu este recuperare, este o reparație. Majoritatea verificărilor se opresc prea devreme: serviciul apare activ, interfața urcă, iar pagina tot nu se încarcă. Decalajul este aproape întotdeauna în persistența pieselor din jurul tunelului, nu în comanda tunelului în sine.

Patru proprietari, patru teste diferite

Înainte de repornire, numiți ce ar trebui să aducă tunelul înapoi. Testul pe care îl rulați și corecția pe care o aplicați depind amândouă de acel răspuns, iar există patru proprietari obișnuiți: o unitate systemd pentru serviciul VPN, o unitate de instanță wg-quick pentru o interfață WireGuard, un runtime de containere sau un profil de manager de rețea. Dacă nu puteți numi proprietarul, opriți-vă și găsiți-l, pentru că un test de repornire fără o cale de pornire așteptată vă spune doar că s-a întâmplat ceva.

Fiecare proprietar își ține configurația în alt loc. Un server OpenVPN administrat de systemd își citește configurația la pornire, deci ce este în fișier la boot este ce rulează. O interfață wg-quick își derivă adresele, rutele și DNS-ul din același fișier, ceea ce înseamnă că o interfață ridicată manual dintr-un shell și niciodată activată ca unitate nu va reveni. Un container își aduce înapoi punctul de intrare, dar nu modificările de firewall ale gazdei, decât dacă acestea trăiesc în afara containerului.

Mai întâi starea de bază, altfel rezultatul nu înseamnă nimic

Înregistrați starea funcțională cât timp funcționează: adrese pe tunel, rute pentru subrețeaua clienților, reguli NAT sau de forwardare, socketul de ascultare și sysctl-ul de forwardare. ip addr show wg0, ip route, nft list ruleset sau iptables-save, ss -lunp și sysctl net.ipv4.ip_forward sunt suficiente pe majoritatea gazdelor.

Notați cum este configurat serviciul să pornească, nu doar că rulează. systemctl is-enabled wg-quick@wg0 și systemctl is-active wg-quick@wg0 răspund la întrebări diferite, iar starea activată este cea care contează la boot, așa cum se descrie în systemctl(1). Pentru OpenVPN, verificați ce șablon folosește gazda, deoarece openvpn@server și openvpn-server@server sunt unități diferite cu valori implicite diferite.

Executați repornirea și citiți primul eșec

Reporniți intenționat, într-o fereastră aleasă de dumneavoastră, cu o consolă sau o cale în afara benzii deschisă. Urmăriți ordinea evenimentelor, nu starea finală: gazda este accesibilă, unitatea activată, interfața prezentă, rutele instalate, regulile de firewall prezente, ascultătorul legat, clientul acceptat. Primul pas care nu se întâmplă este constatarea; tot ce urmează este zgomot.

Un serviciu poate fi activ în timp ce tunelul este inutilizabil, iar acesta este cel mai frecvent fals succes. Pornirea se poate termina înainte ca rețeaua să fie online dacă unitatea așteaptă doar network.target în loc de network-online.target. Fișierele referite, cum ar fi certificatele, cheile sau un CRL, pot fi ilizibile în acel moment pentru că o montare sau o cale de secrete nu este încă pregătită. Niciuna dintre cele două probleme nu apare în systemctl status până nu citiți jurnalul unității.

Testați din afara gazdei. Un client din același LAN poate reuși printr-o rută pe care niciun client la distanță nu ar folosi-o vreodată, iar o sesiune SSH către mașină nu dovedește nimic despre tunel. Conectați-vă, rezolvați un nume intern, ajungeți la resursa privată, apoi reconectați-vă o dată pentru a confirma că starea de revocare și cheile încă se aplică.

Cele trei condiții care decid corecția dumneavoastră

Dacă tunelul revine, dar clienții nu ajung nicăieri, eșecul este în rutare sau în persistența NAT. Dacă clienții nici măcar nu pot finaliza un handshake, eșecul este în interfață sau în materialul de autentificare. Dacă serviciul nu pornește niciodată, eșecul este în fișierul unității sau în dependențele sale. Aceste trei ramuri duc la corecții diferite, de aceea o repornire oarbă fără stare de bază costă mai mult timp decât economisește.

Faceți corecția acolo unde setarea este deținută. Puneți forwardarea într-un sysctl drop-in, puneți regulile NAT în setul de reguli care se încarcă la boot, activați unitatea în loc să o porniți și țineți secretele pe o cale care există înainte ca unitatea să pornească. Adăugarea unei pauze la unitate ascunde o dependență în loc să o declare.

Notați rezultatul în runbook

Scrieți ce a revenit singur, ce a trebuit să porniți și cât a durat decalajul. Includeți comenzile exacte pe care le-ați folosit pentru verificare, astfel încât următoarea persoană să repete testul în loc să inventeze unul. Dacă vreun pas a avut nevoie de o comandă manuală, acea comandă aparține configurației, nu runbook-ului ca pas permanent.

Apoi programați următorul test după următoarea modificare a stivei de rețea a gazdei, nu pentru o dată de calendar peste șase luni. Modul de eșec împotriva căruia vă protejați este o comandă temporară care părea permanentă, iar acestea apar exact când cineva editează reguli de firewall sau mută un serviciu într-o unitate nouă.