Dezinstalarea clientului VPN, repornirea și apoi descoperirea că browserul nu poate încărca nimic este o succesiune obișnuită pe Ubuntu. Tunelul a dispărut, dar politica ce direcționa traficul spre el nu, iar pe Ubuntu aceste resturi stau de obicei în NetworkManager și nu în pachet. Un profil de conexiune și o interfață fictivă create în timpul rulării nu aparțin niciunui pachet, așa că eliminarea pachetului nu le elimină.

Tunelul a dispărut, politica nu

Un kill switch funcționează făcând rețeaua inutilizabilă fără tunel. Când clientul este eliminat în timp ce acea stare este activă, nu rămâne nimic care să o oprească. Rezultatul arată exact ca un adaptor de rețea stricat și de obicei este un profil care ține o rută.

De aceea reinstalarea restabilește uneori conectivitatea: recreează procesul care știe să își retragă propria politică. Un client eliminat în timp ce comutatorul era activ a lăsat o stare pe care nimeni nu o mai curăță.

Citiți obiectele pe care pachetul nu le-a deținut niciodată

Citiți starea înainte de a o schimba. Enumerați dispozitivele, conexiunile active și ambele tabele de rutare, apoi căutați un dispozitiv fictiv care se declară conectat sau o rută implicită care indică spre unul. IPv4 și IPv6 eșuează separat, așa că un ping care funcționează către o adresă cu rezolvarea numelor stricată indică alt obiect decât o rută moartă. Un dispozitiv fictiv care ține o rută implicită explică singur întreaga cădere.

nmcli device status
nmcli connection show --active
ip -4 route
ip -6 route

Notați ce găsiți, pentru că remedierea este ștergerea unui singur obiect anume și nu resetarea tuturor. Orice mai larg riscă o a doua cădere. Aceasta este diferența dintre o reparație și o presupunere.

Un tabel de rutare gol cu un dispozitiv conectat este altă defecțiune și indică DHCP, nu un profil rămas. Citiți lease-ul înainte de a edita ceva.

Ștergeți profilul, nu fișierul cheie

Ștergeți profilul prin NetworkManager în loc să eliminați fișierul cheie. Ștergerea fișierului lasă profilul în memorie activ până la următoarea repornire, ceea ce face o reparație corectă să pară nesigură. Apoi reporniți serviciul și recitiți lista de dispozitive. Repornirea este cea care face ștergerea reală.

sudo nmcli connection delete pvpn-killswitch
sudo systemctl restart NetworkManager

Dacă supraviețuiește o legătură fictivă, eliminați și acea legătură, apoi testați separat o adresă și un nume. Rutare curată cu un nume eșuat indică DNS, în timp ce o adresă eșuată indică o rută sau un firewall.

Verificați cârligul de pornire înainte să se repete

Unele resturi se reinstalează la fiecare pornire. O unitate scrisă de mână sau un script if-up care adaugă reguli de firewall continuă să facă asta după ce pachetul a dispărut, așa că întreruperea revine și reparația anterioară pare noroc. Căutați în fișierele unit și în cârligele de rețea înainte de a reporni. Numele unității este de obicei indiciul.

systemctl list-unit-files | grep -i vpn
grep -rl -i vpn /etc/systemd/system /etc/network/if-up.d

Eliminați sau mascați fișierul anume, apoi reporniți o dată și confirmați că starea fără tunel este cea dorită. Acea ultimă repornire este testul, pentru că o remediere care rezistă doar până la următoarea pornire nu este o remediere. Păstrați nota lângă mașină după aceea. Referința nmcli acoperă comenzile de dispozitiv și conexiune folosite mai sus.

Articole similare