Clientul VPN a fost dezinstalat, dar tunelul pornește în continuare la boot

Distribuția dumneavoastră elimină pachetul, meniul își pierde intrarea, iar tunelul apare totuși după următoarea repornire. Un client VPN comercial lasă bucăți pe care managerul de pachete nu le-a urmărit niciodată, așa că o eliminare curată nu este același lucru cu o mașină curată. Patru dintre acele bucăți explică aproape fiecare conexiune fantomă: o unitate, un profil de conexiune, un helper privilegiat și un depozit al furnizorului. Citiți toate patru înainte de a șterge ceva, apoi eliminați fiecare prin componenta care o deține.

Ce nu a înregistrat niciodată dezinstalatorul

Un manager de pachete elimină fișierele pe care le-a notat el însuși și nimic altceva. Nu are nicio evidență a unui profil de conexiune creat de client în timpul rulării, a unei unități activate după instalare, sau a unui helper care s-a înregistrat în timp ce rula cu drepturi ridicate. Fiecare dintre acestea aparține unui subsistem diferit și fiecare poate supraviețui pachetului una sau mai multe reporniri. Acea lacună explică de ce un tunel poate fi sănătos în timp ce software-ul care l-a produs a dispărut.

Restul are întotdeauna un proprietar, fie că este systemd, NetworkManager, configurația depozitului sau o intrare de pornire automată pentru fiecare utilizator. Tocmai găsirea proprietarului mai întâi împiedică o curățare să devină o mașină pe jumătate configurată. Ștergerea directă a fișierelor funcționează de obicei până când proprietarul le regenerează, motiv pentru care comenzile de mai jos încep cu interogări.

Patru proprietari, mai întâi doar citire

Începeți cu interogări în loc de ștergeri și notați numele exacte care apar. Furnizorii livrează adesea un pachet versionat lângă un metapachet, așa că un produs poate apărea sub două nume. Un nume care apare în ambele liste este un singur produs cu doi proprietari, iar ambele trebuie eliminate. Primul lot acoperă pachete și unități, unde majoritatea resturilor devin vizibile.

dpkg -l | grep -i acmevpn
systemctl list-unit-files | grep -i acmevpn
systemctl list-units --type=service --state=running | grep -i acmevpn

Al doilea lot acoperă cele două componente care supraviețuiesc cel mai des unei curățări, anume profilul de conexiune și depozitul furnizorului. Citiți coloana UUID, nu numele, pentru că numele duplicate sunt frecvente, iar comanda de ștergere așteaptă identificatorul. Linia depozitului merită citită chiar dacă nu îl eliminați astăzi, deoarece un host de furnizor mort poate strica o instalare nelegată luni mai târziu. Niciuna dintre liste nu schimbă nimic, și exact de aceea sunt rulate primele.

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show --active
grep -ril acmevpn /etc/apt/sources.list.d/ /etc/apt/sources.list

Un proces încă viu după curățare este fie o unitate activă, fie copilul altui program. Citiți tabelul proceselor și lanțul său de părinți înainte de a da vina pe un serviciu care nu mai există. Intrările de pornire automată pentru fiecare utilizator au nevoie de aceeași trecere, și apar doar într-un shell de autentificare nou, nu într-o sesiune root.

Trei verbe care nu sunt interschimbabile

Oprirea încheie rularea curentă, dezactivarea elimină legăturile de la boot, iar mascarea îndreaptă unitatea spre /dev/null. Doar a treia blochează și activarea printr-un socket, un timer sau o dependență, ceea ce o face cea mai puternică dintre cele trei. Ordinea contează cât timp încă decideți ce faceți cu mașina. Mascarea este starea corectă în timpul acelei decizii, pentru că eșuează zgomotos în loc să pornească în tăcere la următorul boot.

Demascați înainte de reinstalare, altfel noul pachet va părea stricat dintr-un motiv pe care nimeni nu l-a notat. Aceeași prudență se aplică diferențelor de ambalare: o compilare livrează o unitate care poate fi oprită, în timp ce alta nu lasă niciun serviciu. Stabiliți ce ambalare aveți înainte de a alege un verb, pentru că traseul de curățare diferă.

Cu metacaractere ștergeți profilul greșit

Ștergeți profilul cu UUID-ul notat și niciodată cu un metacaracter. Directorul keyfile conține și fiecare profil Wi-Fi și Ethernet de pe mașină, așa că o potrivire largă elimină lucruri de care încă aveți nevoie. Un keyfile șters manual poate fi regenerat de politica ce îl deține, ceea ce face ștergerea să pară ineficientă.

nmcli connection delete uuid <uuid>

Exportați mai întâi gateway-ul și identitatea dacă acel profil este singura copie pe care o mai aveți, deoarece o ștergere locală nu revocă nimic pe server. Depozitul urmează aceeași regulă: eliminați singurul fișier al furnizorului și brelocul său de chei, apoi reîmprospătați listele de pachete și reîncercați instalarea pe care o doreați cu adevărat. Lăsarea unei intrări învechite de la terți poate fixa o dependență veche sau poate să nu răspundă deloc. Ambele eliminări sunt mici, iar oricare poate fi anulată din copia pe care o păstrați.

Ce încă rulează după repornire

Reporniți înainte de a declara victoria, apoi căutați artefacte și nu aplicația. O interfață de tunel, o rută despicată învechită și DNS pentru fiecare legătură lăsate de clientul vechi au fiecare nevoie de comanda proprie. Toate trei pot supraviețui unei curățări care a eliminat cu succes fiecare pachet.

ip link
ip route
resolvectl status

Deschideți și un shell de autentificare nou, pentru că o intrare de pornire automată se declanșează doar acolo. Apoi citiți /etc/NetworkManager/dispatcher.d/ pentru un script care ridică o conexiune ori de câte ori o interfață își schimbă starea, ceea ce explică un tunel care revine fără serviciu în spate. Dacă ceva încă apelează spre exterior, urmăriți procesul până la părintele lui în loc să ștergeți fișiere până când simptomul se oprește. Curățarea mașinii și revocarea contului rămân sarcini separate, și doar una dintre ele este terminată când repornirea pare liniștită.