Ubuntu fica sem internet depois de remover um aplicativo VPN
Um cliente VPN removido pode deixar perfis do NetworkManager e uma interface fictícia. Esses órfãos mantêm uma rota padrão ou uma política de firewall.
Desinstalar o cliente VPN, reiniciar e então descobrir que o navegador não carrega nada é uma sequência comum no Ubuntu. O túnel sumiu, mas a política que direcionava o tráfego para ele não, e no Ubuntu esses restos costumam viver no NetworkManager e não no pacote. Um perfil de conexão e uma interface fictícia criados em tempo de execução não pertencem a nenhum pacote, então remover o pacote não os remove.
O túnel sumiu, a política não
Um kill switch funciona tornando a rede inutilizável sem o túnel. Quando o cliente é removido enquanto esse estado está ativo, não sobra nada que o desligue. O resultado parece exatamente um adaptador de rede quebrado e costuma ser um perfil que retém uma rota.
Por isso reinstalar às vezes restaura a conectividade: recria o processo que sabe desfazer a própria política. Um cliente removido enquanto seu interruptor estava ativo deixou um estado que ninguém mais limpa.
Leia os objetos que o pacote nunca possuiu
Leia o estado antes de alterá-lo. Liste dispositivos, conexões ativas e as duas tabelas de roteamento, e depois procure um dispositivo fictício que se declare conectado ou uma rota padrão apontando para um. IPv4 e IPv6 falham separadamente, então um ping que funciona para um endereço com a resolução de nomes quebrada aponta para outro objeto que uma rota morta. Um dispositivo fictício que retém uma rota padrão explica toda a queda sozinho.
nmcli device status
nmcli connection show --active
ip -4 route
ip -6 routeAnote o que encontrar, porque o conserto é apagar um objeto específico e não reiniciar tudo. Qualquer coisa mais ampla arrisca uma segunda queda. Essa é a diferença entre um reparo e um palpite.
Uma tabela de roteamento vazia com um dispositivo conectado é outra falha, e aponta para o DHCP e não para um perfil remanescente. Leia a concessão antes de editar qualquer coisa.
Apague o perfil, não o arquivo de chave
Apague o perfil pelo NetworkManager em vez de remover o arquivo de chave. Apagar o arquivo deixa o perfil na memória ativo até o próximo reinício, o que faz um reparo correto parecer pouco confiável. Depois reinicie o serviço e leia de novo a lista de dispositivos. É o reinício que torna a exclusão real.
sudo nmcli connection delete pvpn-killswitch
sudo systemctl restart NetworkManagerSe um link fictício sobreviver, remova também esse link e depois teste um endereço e um nome separadamente. Roteamento limpo com um nome falho aponta para DNS, enquanto um endereço falho aponta para uma rota ou um firewall.
Verifique o gancho de inicialização antes que ele se repita
Alguns restos se reinstalam a cada inicialização. Uma unidade escrita à mão ou um script if-up que adiciona regras de firewall continua fazendo isso depois que o pacote some, então a queda volta e o reparo anterior parece sorte. Procure nos arquivos de unidade e nos ganchos de rede antes de reiniciar de novo. O nome da unidade costuma entregar.
systemctl list-unit-files | grep -i vpn
grep -rl -i vpn /etc/systemd/system /etc/network/if-up.dRemova ou mascare o arquivo específico, reinicie uma vez e confirme que o estado sem túnel é o que você quer. Esse reinício final é o teste, porque um conserto que só dura até a próxima inicialização não é um conserto. Guarde a nota com a máquina depois. A referência do nmcli cobre os comandos de dispositivo e conexão usados acima.