Ubuntu queda sen internet despois de retirar unha aplicación VPN

Desinstalar o cliente VPN, reiniciar e despois descubrir que o navegador non carga nada é unha secuencia habitual en Ubuntu. O túnel desapareceu, pero a política que dirixía o tráfico cara a el non, e en Ubuntu eses restos adoitan vivir en NetworkManager e non no paquete. Un perfil de conexión e unha interface ficticia creados en tempo de execución non pertencen a ningún paquete, así que retirar o paquete non os retira.

O túnel desapareceu, a política non

Un kill switch funciona facendo que a rede sexa inutilizable sen o túnel. Cando se retira o cliente mentres ese estado está activo, non queda nada que o desactive. O resultado parece exactamente un adaptador de rede roto e adoita ser un perfil que retén unha ruta.

Por iso reinstalar ás veces restaura a conectividade: recrea o proceso que sabe desfacer a súa propia política. Un cliente retirado mentres o seu conmutador estaba activo deixou un estado que xa ninguén limpa.

Lea os obxectos que o paquete nunca posuíu

Lea o estado antes de cambialo. Enumere dispositivos, conexións activas e ambas as dúas táboas de enrutamento, e despois busque un dispositivo ficticio que se declare conectado ou unha ruta predeterminada que apunte a un. IPv4 e IPv6 fallan por separado, así que un ping que funciona a un enderezo coa resolución de nomes rota apunta a outro obxecto que unha ruta morta. Un dispositivo ficticio que retén unha ruta predeterminada explica toda a caída por si só.

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

Anote o que atope, porque a solución é borrar un obxecto concreto e non reinicializalo todo. Calquera cousa máis ampla arrisca unha segunda caída. Esa é a diferenza entre unha reparación e unha conxectura.

Unha táboa de enrutamento baleira cun dispositivo conectado é outra avaría, e apunta a DHCP e non a un perfil sobrante. Lea a concesión antes de editar nada.

Borrar o perfil, non o ficheiro de chave

Borrar o perfil a través de NetworkManager en lugar de retirar o ficheiro de chave. Borrar o ficheiro deixa o perfil en memoria activo ata o próximo reinicio, o que fai que unha reparación correcta pareza pouco fiable. Despois reinicie o servizo e volva ler a lista de dispositivos. O reinicio é o que fai real o borrado.

sudo nmcli connection delete pvpn-killswitch
sudo systemctl restart NetworkManager

Se sobrevive unha ligazón ficticia, retire tamén esa ligazón e despois probe un enderezo e un nome por separado. Un enrutamento limpo cun nome fallido apunta a DNS, mentres que un enderezo fallido apunta a unha ruta ou a un cortalumes.

Comprobe o gancho de arranque antes de que se repita

Algúns restos reinstálanse en cada arranque. Unha unidade escrita a man ou un script if-up que engade regras de cortalumes segue facéndoo despois de que o paquete desapareza, así que a caída volve e a reparación anterior parece sorte. Busque nos ficheiros de unidade e nos ganchos de rede antes de reiniciar outra vez. O nome da unidade adoita delatalo.

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

Retire ou enmascare o ficheiro concreto, reinicie unha vez e confirme que o estado sen túnel é o que quere. Ese reinicio final é a proba, porque unha solución que só aguanta ata o próximo arranque non é unha solución. Garde a nota coa máquina despois. A referencia de nmcli cobre os comandos de dispositivo e conexión usados arriba.