Ubuntu rămâne fără internet după eliminarea unei aplicații VPN
Un client VPN eliminat poate lăsa profiluri NetworkManager și o interfață fictivă. Acești orfani mențin o rută implicită sau o politică de firewall.
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 routeNotaț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 NetworkManagerDacă 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.dEliminaț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.