Cliente VPN desinstalado, pero el túnel sigue arrancando al iniciar

Su distribución elimina el paquete, su menú pierde la entrada y el túnel sigue levantándose tras el siguiente reinicio. Un cliente VPN comercial deja piezas que el gestor de paquetes nunca rastreó, así que una eliminación limpia no es lo mismo que una máquina limpia. Cuatro de esas piezas explican casi todas las conexiones fantasma: una unidad, un perfil de conexión, un asistente privilegiado y un repositorio del proveedor. Lea las cuatro antes de borrar nada y luego elimine cada una a través del componente que la posee.

Lo que el desinstalador nunca registró

Un gestor de paquetes elimina los archivos que él anotó y nada más. No tiene registro de un perfil de conexión que el cliente creó en tiempo de ejecución, de una unidad habilitada después de la instalación, ni de un asistente que se registró mientras corría con derechos elevados. Cada una de esas piezas pertenece a un subsistema distinto y cada una puede sobrevivir al paquete uno o varios reinicios. Esa brecha explica por qué un túnel puede estar sano mientras el software que lo produjo ya no está.

El residuo siempre tiene un dueño, ya sea systemd, NetworkManager, la configuración del repositorio o una entrada de inicio automático por usuario. Localizar primero al dueño es lo que evita que una limpieza acabe en una máquina a medio configurar. Borrar archivos directamente suele funcionar hasta que el dueño los regenera, y por eso los comandos de abajo empiezan con consultas.

Cuatro dueños, primero solo lectura

Empiece con consultas en lugar de borrados y anote los nombres exactos que aparecen. Los proveedores suelen distribuir una carga versionada junto a un metapaquete, así que un producto puede aparecer con dos nombres. Un nombre que sale en ambas listas es un solo producto con dos dueños, y hay que eliminar los dos. El primer lote cubre paquetes y unidades, que es donde la mayoría de los residuos se hace visible.

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

El segundo lote cubre los dos componentes que sobreviven con más frecuencia a una purga, a saber, el perfil de conexión y el repositorio del proveedor. Lea la columna UUID en lugar del nombre, porque los nombres duplicados son habituales y el comando de borrado espera el identificador. Vale la pena leer la línea del repositorio aunque no lo quite hoy, ya que un host de proveedor muerto puede romper una instalación ajena meses después. Ninguna de las dos listas cambia nada, y esa es la razón de ejecutarlas primero.

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 sigue vivo tras la purga es o bien una unidad activa o bien el hijo de otro programa. Lea la tabla de procesos y su cadena de padres antes de culpar a un servicio que ya no existe. Las entradas de inicio automático por usuario necesitan la misma pasada, y solo aparecen en un shell de inicio de sesión nuevo, no en una sesión root.

Tres verbos que no son intercambiables

Detener termina la ejecución actual, deshabilitar quita los enlaces de arranque y enmascarar apunta la unidad a /dev/null. Solo el tercero bloquea además la activación mediante un socket, un temporizador o una dependencia, lo que lo convierte en el más fuerte de los tres. El orden importa mientras aún decide qué hacer con la máquina. Enmascarar es el estado correcto durante esa decisión, porque falla ruidosamente en vez de arrancar en silencio en el siguiente inicio.

Desenmascare antes de reinstalar, o el paquete nuevo parecerá roto por un motivo que nadie anotó. La misma precaución vale para las diferencias de empaquetado: una compilación envía una unidad que se puede detener, mientras que otra no deja servicio alguno. Establezca qué empaquetado tiene antes de elegir un verbo, porque la ruta de limpieza difiere entre ellos.

Con comodines se borra el perfil equivocado

Borre el perfil con el UUID que anotó y nunca con un comodín. El directorio de keyfile también contiene todos los perfiles Wi-Fi y Ethernet de la máquina, así que una coincidencia amplia elimina cosas que todavía necesita. Un keyfile borrado a mano puede ser regenerado por la política que lo posea, lo que hace que el borrado parezca ineficaz.

nmcli connection delete uuid <uuid>

Exporte primero la puerta de enlace y la identidad si ese perfil es la única copia que aún conserva, ya que un borrado local no revoca nada en el servidor. El repositorio sigue la misma regla: elimine el único archivo del proveedor y su anillo de claves, luego actualice las listas de paquetes y reintente la instalación que realmente quería. Dejar una entrada obsoleta de terceros puede fijar una dependencia antigua o no responder en absoluto. Ambas eliminaciones son pequeñas y cualquiera puede deshacerse desde la copia que guarde.

Qué sigue ejecutándose tras el reinicio

Reinicie antes de declarar la victoria y luego busque artefactos en lugar de la aplicación. Una interfaz de túnel, una ruta dividida obsoleta y DNS por enlace que dejó el cliente antiguo necesitan cada una su propio comando. Las tres pueden sobrevivir a una purga que eliminó todos los paquetes con éxito.

ip link
ip route
resolvectl status

Abra también un shell de inicio de sesión nuevo, porque una entrada de inicio automático solo se activa allí. Luego lea /etc/NetworkManager/dispatcher.d/ en busca de un script que levante una conexión cada vez que una interfaz cambia de estado, lo que explica un túnel que vuelve sin servicio detrás. Si algo sigue marcando hacia fuera, siga el proceso hasta su padre en lugar de borrar archivos hasta que el síntoma cese. Limpiar la máquina y revocar la cuenta siguen siendo tareas separadas, y solo una de ellas está terminada cuando el reinicio parece tranquilo.