apt purge eliminó la VPN, pero el servicio sigue arrancando al inicio

apt purge dice que el paquete ya no está y, sin embargo, un túnel vuelve a aparecer en cada arranque. El journal sigue creciendo, las rutas regresan y la máquina se comporta como si no se hubiera eliminado nada. El instalador del proveedor puede escribir archivos que el gestor de paquetes nunca registró, así que desinstalar un paquete y desinstalar un producto son tareas distintas. El runbook siguiente separa los dos registros y termina la eliminación a propósito.

Dos instaladores, dos registros diferentes

Los paquetes Debian mantienen una lista de archivos, y una purge borra exactamente lo que esa lista nombra más la configuración del paquete. Un instalador de shell o un paquete .run no mantiene esa lista; escribe donde quiere, normalmente en /opt, /usr/local y /etc/systemd/system. Ninguna de esas rutas aparece en la lista de archivos de ningún paquete, así que dpkg ni las conoce ni las reporta. Acaba con dos propietarios de la instalación en un solo sistema de archivos y solo uno de ellos lleva la contabilidad.

Pregunte a dpkg por la ruta concreta antes de borrarla. Una ruta que rechaza es suya para eliminarla, y la misma respuesta le dice si una actualización posterior la devolvería.

dpkg -S /etc/systemd/system/acmevpn.service
systemctl list-unit-files | grep -i acmevpn

Una unidad y su enlace wants son archivos separados

Habilitar es un acto distinto de instalar. La unidad declara relaciones de destino en su sección [Install], y systemctl enable convierte esas declaraciones en enlaces simbólicos dentro del directorio .wants/ de cada destino. Ahora existen dos rutas: el archivo de la unidad y el enlace que la arrastra a un destino de arranque. Borre solo el archivo y el enlace apunta a la nada, lo que produce una queja al arrancar; borre solo el enlace y la unidad sigue siendo arrancable por nombre. Ambos deben desaparecer.

Elimínelos en orden y recargue después, para que systemd deje de retener las definiciones antiguas en memoria.

systemctl disable --now acmevpn.service
systemctl show -p FragmentPath -p ExecStart acmevpn.service
sudo rm /etc/systemd/system/acmevpn.service
sudo rm /etc/systemd/system/multi-user.target.wants/acmevpn.service
systemctl daemon-reload

Lea FragmentPath en lugar de suponer la ubicación, ya que el proveedor puede haber escrito en /usr/lib/systemd/system o /lib/systemd/system en vez de /etc. Borrar la copia que esperaba deja la efectiva en ejecución, y la corrección parece exitosa hasta la siguiente recarga. Vuelva a listar los archivos de unidad cuando termine la recarga y confirme que el nombre ya no aparece.

Encuentre el binario que mantiene viva la disposición

Una unidad habilitada sigue arrancando el demonio crea lo que crea la base de datos de paquetes. Ese proceso puede volver a levantar el túnel, añadir rutas otra vez o restaurar una regla de kill-switch, y el comportamiento parece sobrenatural hasta que inspecciona la disposición. Siga la ruta de ExecStart y compruebe si el binario sigue ahí, porque un ejecutable dejado bajo /opt es todo lo que la disposición necesita. Borrar la unidad detiene el arranque programado; no borra el programa.

Trate los directorios de estado con el mismo cuidado. Los tokens de cuenta, los perfiles generados y las listas de servidores en caché viven bajo /var/lib o en un directorio personal, y son credenciales, no caché desechable. Elimínelos una vez detenido el servicio, deliberadamente, y anote qué se llevó.

sudo ls -l /opt/acmevpn /usr/local/bin/acmevpn
sudo find /var/lib -maxdepth 2 -iname "*acme*"
systemctl is-enabled acmevpn.service

Elija un solo propietario del arranque y pruébelo

Tres candidatos pueden reclamar el arranque, e instalar los tres produce una carrera en lugar de una doble seguridad. Un archivo de inicio automático de escritorio solo se ejecuta después de que alguien inicie sesión, una unidad systemd se ejecuta antes pero necesita un cliente que funcione sin pantalla, y una entrada cron @reboot se dispara según un horario que puede ser incorrecto para un cliente de red. La CLI del proveedor puede además exigir un argumento de servidor, porque al arrancar no hay sesión previa que reanudar. Elija el candidato que encaje con cómo se autentica el cliente y descarte los demás.

Pruébelo reiniciando la máquina y mirando tres hechos independientes: el estado de la unidad, la lista de procesos y una conexión nueva a algo que pueda verificar. Un cliente que necesita un llavero o un inicio de sesión interactivo falla al arrancar incluso con un archivo de unidad correcto, y el journal lo dice si lo lee en lugar de solo el estado del servicio.

O bien dé al cliente una credencial que funcione sin preguntar, o bien arránquelo al iniciar sesión. Ambas opciones son defendibles, y combinarlas es cómo un túnel acaba con dos propietarios que se pelean por él.

Anote qué debe esperar la próxima purge

Anote dos hechos tras cualquier eliminación manual: qué instalador creó la disposición y qué propietario la arranca ahora. Esa nota convierte la próxima purge de sorpresa en un punto de una lista de comprobación, y sobrevive a la persona que hizo el trabajo.

Guárdela junto a la configuración del servicio y no en un directorio personal, y féchela, porque una actualización del proveedor puede restaurar una unidad que borró. Comparar systemctl list-unit-files con esa nota cada pocos meses detecta la restauración mientras aún es barata de corregir.