Sem internet depois de desinstalar a VPN? Verifique três proprietários

O cliente sumiu e a máquina continua sem alcançar nada, o que tenta a nivelar o firewall e começar de novo. Não faça isso. O estado de bloqueio pode vir de três proprietários diferentes na mesma máquina, e cada um tem o seu próprio caminho de remoção. Esvaziar tudo de uma vez remove o objeto de que você queria se livrar junto com a proteção de que ainda precisa, e também destrói a evidência de qual proprietário causou o problema. Cinco verificações, em ordem, impedem isso.

Verificação 1: o que ainda está lá, e para que serve

Procure os três artefatos separadamente: um adaptador virtual que ainda existe, um filtro ou regra de firewall que ainda bloqueia, e uma rota ou regra de política que ainda aponta para um túnel que não existe mais. A presença deles não prova nada por si só, porque um interruptor de emergência intencional parece de fora igual a um abandonado.

Get-NetAdapter | Where-Object Status -eq 'Up'
Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object Action -eq 'Block'
ip route show
ip -4 rule show

Anote o horário em que a conectividade parou e se o cliente normal ainda consegue iniciar o túnel. Se o cliente consegue restaurar o túnel e o tráfego volta, o bloqueio está fazendo o seu trabalho e o problema está no estado do cliente, não numa regra remanescente.

Verificação 2: qual proprietário controla isso

Cada artefato tem um proprietário. O adaptador virtual pertence ao cliente VPN ou ao seu driver. O filtro pode pertencer ao cliente, ao firewall da própria plataforma ou a um produto de segurança gerenciado. A rota pode ter sido instalada pelo cliente no momento da conexão e deixada para trás.

Em equipamento gerenciado, verifique a política do dispositivo antes de tocar em qualquer coisa. Um filtro imposto por política será restaurado no próximo check-in, então uma remoção local compra uma hora e um relatório de conformidade. Essa conversa pertence ao administrador, não à interface do firewall.

Verificação 3: remova a coisa mais estreita que explica isso

Comece pelo caminho suportado pelo fornecedor: uma instalação de reparo ou uma desinstalação correta muitas vezes limpa bem o estado gerado, incluindo filtros que uma remoção manual deixaria passar. Leia as instruções de recuperação da versão instalada, porque a ordem importa e uma desinstalação após uma remoção falha se comporta de forma diferente.

Se a inspeção manual for realmente necessária, anote o nome da regra, a interface e a finalidade declarada antes de mudar qualquer coisa, e remova esse objeto pelo nome. Remover cada adaptador de rede ou esvaziar todo o conjunto de regras para atingir um único cliente é como um caso de suporte vira uma reconstrução.

Verificação 4: DNS e rotas sobrevivem aos adaptadores

O estado de resolução pode sobreviver ao túnel. Um resolvedor que ainda aponta para um endereço dentro de um túnel que não existe mais produz tempos limite que parecem exatamente uma queda do firewall, e a conclusão habitual é a errada.

resolvectl status
ip route get 1.1.1.1
nslookup example.com

Se o endereço for resolvido e uma conexão crua por IP funcionar, o DNS é o problema restante e não a filtragem. Se ambos falharem, volte à verificação um com a rota e o filtro na mão.

Verificação 5: teste os dois caminhos de novo e restaure o diagnóstico

Verifique primeiro a conectividade comum, depois cada perfil VPN restante através dos seus próprios controles: conecte, use, desconecte e confirme que o host voltou à conectividade simples. Esse vai e volta é o teste que prova que o bloqueio abandonado desapareceu e não apenas foi contornado.

Por fim, restaure qualquer alteração de diagnóstico feita pelo caminho. Uma limpeza bem-sucedida remove uma dependência abandonada; não remove a proteção geral do host e não deve deixar para trás um firewall permanentemente relaxado. Anote qual proprietário segurava o bloqueio, porque a próxima desinstalação produzirá os mesmos três candidatos.