Cliente VPN desinstalado, pero o túnel segue arrincando no arranque
Un cliente VPN eliminado pode deixar unha unidade de systemd, un perfil gardado, un axudante e un repositorio apt. Inventaríe os catro antes de purgar calquera outra cousa.
A súa distribución elimina o paquete, o seu menú perde a entrada e o túnel segue levantándose tras o seguinte reinicio. Un cliente VPN comercial deixa pezas que o xestor de paquetes nunca rastreou, así que unha eliminación limpa non é o mesmo ca unha máquina limpa. Catro desas pezas explican case todas as conexións pantasma: unha unidade, un perfil de conexión, un axudante privilexiado e un repositorio do provedor. Lea as catro antes de borrar nada e logo elimine cada unha a través do compoñente que a posúe.
O que o desinstalador nunca rexistrou
Un xestor de paquetes elimina os ficheiros que el anotou e nada máis. Non ten rexistro dun perfil de conexión que o cliente creou en tempo de execución, de unha unidade habilitada despois da instalación, nin dun axudante que se rexistrou mentres corría con dereitos elevados. Cada unha desas pezas pertence a un subsistema distinto e cada unha pode sobrevivir ao paquete un ou varios reinicios. Esa fenda explica por que un túnel pode estar san mentres o software que o produciu xa non está.
O residuo sempre ten un dono, xa sexa systemd, NetworkManager, a configuración do repositorio ou unha entrada de inicio automático por usuario. Localizar primeiro o dono é o que evita que unha limpeza acabe nunha máquina a medio configurar. Borrar ficheiros directamente adoita funcionar ata que o dono os rexenera, e por iso os comandos de abaixo comezan con consultas.
Catro donos, primeiro só lectura
Comece con consultas en lugar de borrados e anote os nomes exactos que aparecen. Os provedores adoitan distribuír unha carga versionada xunto a un metapaquete, así que un produto pode aparecer con dous nomes. Un nome que sae nas dúas listas é un só produto con dous donos, e hai que eliminar os dous. O primeiro lote cobre paquetes e unidades, que é onde a maioría dos residuos se fai visible.
dpkg -l | grep -i acmevpn
systemctl list-unit-files | grep -i acmevpn
systemctl list-units --type=service --state=running | grep -i acmevpn
O segundo lote cobre os dous compoñentes que sobreviven con máis frecuencia a unha purga, a saber, o perfil de conexión e o repositorio do provedor. Lea a columna UUID en lugar do nome, porque os nomes duplicados son habituais e o comando de borrado espera o identificador. Paga a pena ler a liña do repositorio aínda que non o quite hoxe, xa que un host de provedor morto pode romper unha instalación allea meses despois. Ningunha das dúas listas cambia nada, e esa é a razón de executalas primeiro.
nmcli -f NAME,UUID,TYPE connection show
nmcli connection show --active
grep -ril acmevpn /etc/apt/sources.list.d/ /etc/apt/sources.list
Un proceso que segue vivo tras a purga é ou ben unha unidade activa ou ben o fillo doutro programa. Lea a táboa de procesos e a súa cadea de pais antes de culpar un servizo que xa non existe. As entradas de inicio automático por usuario necesitan a mesma pasada, e só aparecen nun shell de inicio de sesión novo, non nunha sesión root.
Tres verbos que non son intercambiables
Deter remata a execución actual, deshabilitar quita as ligazóns de arranque e enmascarar apunta a unidade a /dev/null. Só o terceiro bloquea ademais a activación mediante un socket, un temporizador ou unha dependencia, o que o converte no máis forte dos tres. A orde importa mentres aínda decide que facer coa máquina. Enmascarar é o estado correcto durante esa decisión, porque falla ruidosamente en vez de arrincar en silencio no seguinte inicio.
Desenmascare antes de reinstalar, ou o paquete novo parecerá roto por un motivo que ninguén anotou. A mesma precaución vale para as diferenzas de empaquetado: unha compilación envía unha unidade que se pode deter, mentres que outra non deixa servizo ningún. Estableza que empaquetado ten antes de elixir un verbo, porque a ruta de limpeza difire entre eles.
Cos comodíns bórrase o perfil equivocado
Borre o perfil co UUID que anotou e nunca cun comodín. O directorio de keyfile tamén contén todos os perfís Wi-Fi e Ethernet da máquina, así que unha coincidencia ampla elimina cousas que aínda necesita. Un keyfile borrado a man pode ser rexenerado pola política que o posúa, o que fai que o borrado pareza ineficaz.
nmcli connection delete uuid <uuid>
Exporte primeiro a porta de enlace e a identidade se ese perfil é a única copia que aínda conserva, xa que un borrado local non revoga nada no servidor. O repositorio segue a mesma regra: elimine o único ficheiro do provedor e o seu anel de chaves, logo actualice as listas de paquetes e volva tentar a instalación que realmente quería. Deixar unha entrada obsoleta de terceiros pode fixar unha dependencia antiga ou non responder en absoluto. As dúas eliminacións son pequenas e calquera pode desfacerse desde a copia que garde.
Que segue executándose tras o reinicio
Reinicie antes de declarar a vitoria e logo busque artefactos en lugar da aplicación. Unha interface de túnel, unha ruta dividida obsoleta e DNS por ligazón que deixou o cliente antigo necesitan cada unha o seu propio comando. As tres poden sobrevivir a unha purga que eliminou todos os paquetes con éxito.
ip link
ip route
resolvectl status
Abra tamén un shell de inicio de sesión novo, porque unha entrada de inicio automático só se activa alí. Logo lea /etc/NetworkManager/dispatcher.d/ buscando un script que levante unha conexión cada vez que unha interface cambia de estado, o que explica un túnel que volve sen servizo detrás. Se algo segue marcando cara a fóra, siga o proceso ata o seu pai en lugar de borrar ficheiros ata que o síntoma cese. Limpar a máquina e revogar a conta seguen sendo tarefas separadas, e só unha delas está terminada cando o reinicio parece tranquilo.