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 route

Anote 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 NetworkManager

Se 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.d

Remova 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.

Artigos relacionados