Ubuntu se queda sin internet después de quitar una aplicación VPN

Desinstalar el cliente VPN, reiniciar y luego descubrir que el navegador no carga nada es una secuencia habitual en Ubuntu. El túnel se ha ido, pero la política que dirigía el tráfico hacia él no, y en Ubuntu esos restos suelen vivir en NetworkManager y no en el paquete. Un perfil de conexión y una interfaz ficticia creados en tiempo de ejecución no pertenecen a ningún paquete, así que quitar el paquete no los quita.

El túnel se ha ido, la política no

Un kill switch funciona haciendo que la red sea inutilizable sin el túnel. Cuando se quita el cliente mientras ese estado está activo, no queda nada que lo desactive. El resultado parece exactamente un adaptador de red roto y suele ser un perfil que retiene una ruta.

Por eso reinstalar a veces restaura la conectividad: recrea el proceso que sabe deshacer su propia política. Un cliente quitado mientras su conmutador estaba activo dejó un estado que ya nadie limpia.

Lea los objetos que el paquete nunca poseyó

Lea el estado antes de cambiarlo. Enumere dispositivos, conexiones activas y ambas tablas de enrutamiento, y luego busque un dispositivo ficticio que se declare conectado o una ruta predeterminada que apunte a uno. IPv4 e IPv6 fallan por separado, así que un ping que funciona a una dirección con la resolución de nombres rota apunta a otro objeto que una ruta muerta. Un dispositivo ficticio que retiene una ruta predeterminada explica toda la caída por sí solo.

nmcli device status
nmcli connection show --active
ip -4 route
ip -6 route

Anote lo que encuentre, porque la solución es borrar un objeto concreto y no reiniciarlo todo. Cualquier cosa más amplia arriesga una segunda caída. Esa es la diferencia entre una reparación y una conjetura.

Una tabla de enrutamiento vacía con un dispositivo conectado es otra avería, y apunta a DHCP y no a un perfil sobrante. Lea la concesión antes de editar nada.

Borre el perfil, no el archivo de clave

Borre el perfil a través de NetworkManager en lugar de quitar el archivo de clave. Borrar el archivo deja el perfil en memoria activo hasta el próximo reinicio, lo que hace que una reparación correcta parezca poco fiable. Luego reinicie el servicio y vuelva a leer la lista de dispositivos. El reinicio es lo que hace real el borrado.

sudo nmcli connection delete pvpn-killswitch
sudo systemctl restart NetworkManager

Si sobrevive un enlace ficticio, quite también ese enlace y luego pruebe una dirección y un nombre por separado. Un enrutamiento limpio con un nombre fallido apunta a DNS, mientras que una dirección fallida apunta a una ruta o a un cortafuegos.

Revise el gancho de arranque antes de que se repita

Algunos restos se reinstalan en cada arranque. Una unidad escrita a mano o un script if-up que añade reglas de cortafuegos sigue haciéndolo después de que el paquete desaparezca, así que la caída vuelve y la reparación anterior parece suerte. Busque en los archivos de unidad y en los ganchos de red antes de reiniciar otra vez. El nombre de la unidad suele delatarlo.

systemctl list-unit-files | grep -i vpn
grep -rl -i vpn /etc/systemd/system /etc/network/if-up.d

Quite o enmascare el archivo concreto, reinicie una vez y confirme que el estado sin túnel es el que quiere. Ese reinicio final es la prueba, porque una solución que solo aguanta hasta el próximo arranque no es una solución. Guarde la nota con la máquina después. La referencia de nmcli cubre los comandos de dispositivo y conexión usados arriba.