O kill switch continua bloqueando o tráfego após a VPN desconectar

O túnel sumiu, o ícone de rede parece normal e nada carrega. Você desconectou a VPN, desinstalou ou reiniciou, e o bloqueio que deveria proteger você durante uma queda continua de pé. A janela do cliente não explica, porque não é o cliente que bloqueia: a decisão foi gravada no kernel em seu nome, e nada ficou para removê-la. No Windows esse estado fica no Windows Filtering Platform; no Linux é um conjunto de regras em iptables ou nftables, muitas vezes com um snapshot que é reaplicado no boot. O que segue é a ordem que uso: ler o estado, excluir o objeto mais estreito que explica a falha e depois encontrar o que continua recolocando-o.

Um kill switch é estado do kernel, não uma configuração

Clientes de desktop implementam o bloqueio adicionando filtros que negam tráfego fora do túnel. No Windows são filtros WFP nas camadas connect-redirect e transport, e alguns são persistentes: são gravados no armazenamento de políticas do Base Filtering Engine e restaurados quando a máquina inicia, antes de qualquer software de VPN rodar. Os clientes diferem em quando limpam. Alguns removem filtros ao desconectar, outros só numa saída limpa, e outros só quando o kill switch é desligado primeiro. Desinstale com o bloqueio ativo, ou mate o processo, e os filtros ficam.

O equivalente no Linux é uma regra drop ou reject no caminho de saída, às vezes uma regra de forwarding, às vezes uma política de cadeia alterada. Essas regras sobrevivem ao processo que as adicionou porque são estado do kernel: mate o cliente, faça-o travar ou corte a energia, e o kernel continua descartando pacotes sem nada que desfaça isso. Um pacote de persistência acrescenta uma segunda camada de permanência ao tirar um snapshot do conjunto de regras atual e restaurá-lo no boot, então o próximo início começa com o bloqueio já instalado.

Leia o estado WFP antes de excluir qualquer coisa

O Windows traz as ferramentas necessárias. Abra um prompt elevado e faça o dump do estado da plataforma; o dump cai como wfpstate.xml no diretório de trabalho.

netsh wfp show state
netsh wfp show filters
Get-Service bfe

Procure no XML o nome do fornecedor que saiu, uma ação Block e a camada. Filtros em connect-redirect e transport são os que quebram o tráfego comum; um filtro numa camada receive-accept normalmente não é a causa. Se o Base Filtering Engine não estiver rodando de jeito nenhum, procure em outro lugar, porque nada mais pode aplicar esses filtros.

Confira também a visão comum do firewall, já que a maioria das pessoas inspeciona só uma das duas:

netsh advfirewall show allprofiles
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

Quando os perfis internos estão ligados e nenhuma regra corresponde ao tráfego que falha, o bloqueio vem de um provedor terceirizado, não do Windows Firewall. Essa distinção decide qual ferramenta você usará no reparo.

Leia as regras do Linux na sintaxe com que vai excluir

iptables -S imprime regras na mesma forma usada para adicioná-las, o que torna a saída diretamente reutilizável para uma exclusão. iptables -L -v -n adiciona contadores de pacotes, e esses contadores dizem se uma regra está de fato casando com suas requisições que falham ou apenas parada na cadeia.

sudo iptables -S
sudo ip6tables -S
sudo iptables -t nat -S

Leia as políticas das cadeias, não só as regras: -P OUTPUT DROP bloqueia tráfego mesmo quando nenhuma regra corresponde. Inspecione o IPv6 separadamente, porque um cliente que instala as duas famílias pode deixar o bloqueio IPv6 no lugar depois que as regras IPv4 somem, e o sintoma então depende de qual família uma aplicação prefere. Onde nftables estiver em uso, execute também nft list ruleset; as duas ferramentas coexistem por uma camada de compatibilidade, e uma listagem não mostra necessariamente toda regra capaz de descartar um pacote.

Exclua o objeto mais estreito que explica a falha

No Windows o primeiro passo ainda é o caminho de remoção do próprio fornecedor: execute o instalador de novo e use repair ou uninstall, ou rode a ferramenta de limpeza se o fornecedor publicar uma. Serviços e tarefas agendadas remanescentes são comuns, e uma tarefa que inicia o cliente no logon reinstala os filtros no próximo boot. Uma desinstalação que falha ao ler a chave de registro do cliente normalmente significa que um serviço ou tarefa ainda a segura, não que o registro esteja corrompido.

Get-ScheduledTask | Where-Object TaskName -like '*vpn*'
Get-Service | Where-Object DisplayName -like '*vpn*'

Filtros persistentes são o último recurso. Eles ficam sob HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, um valor por filtro com chave GUID. Exporte a chave primeiro, anote os GUIDs que remover, exclua apenas os valores que pertencem ao cliente que saiu, e então reinicie para que o motor reconstrua o estado. Não exclua a chave inteira e não desative o Base Filtering Engine: o Windows Firewall e o Defender dependem dele, e você trocaria uma indisponibilidade por uma pior.

reg export "HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent" C:\temp\bfe-backup.reg

No Linux, pegue a linha impressa por iptables -S e substitua -A por -D. Excluir a única regra que você identificou é melhor que esvaziar uma cadeia, porque sua própria política fica intacta.

sudo iptables -D OUTPUT -p udp -j REJECT

Se o drop estiver numa cadeia definida pelo usuário, exclua primeiro o salto para essa cadeia e remova a cadeia com -X depois. Pôr a política da cadeia em ACCEPT enquanto regras de drop ainda existem só ajuda pacotes que chegam à decisão de política. Esvaziar todas as tabelas é o último recurso: também remove regras que você adicionou por outros motivos, e com o ufw ativo deixa o serviço acreditando que possui cadeias que não existem mais.

Encontre o dono que recoloca tudo

Depois do reparo imediato, procure o que restauraria o estado. No Linux, verifique se uma unidade de persistência está ativa, se o cliente tem uma configuração de restaurar firewall no login e se existe um arquivo de regras salvo sob /etc. No Windows, verifique de novo entradas de inicialização, serviços e tarefas agendadas, então reinicie e releia o estado com os mesmos comandos de antes.

Se o bloqueio volta, a exclusão não era a correção; o dono era. Anote qual cliente ou serviço o instala e desative o recurso ali, em vez de lutar contra ele na camada de firewall depois de cada desconexão.

Verifique com tráfego real, não com um único ping

Teste uma resolução de nome, uma conexão TCP e uma sessão nova de navegador, depois reinicie e repita as mesmas três checagens. Um ping que funciona enquanto HTTPS falha aponta para um filtro na camada transport, não para a rede, e um bloqueio que só reaparece depois do reboot aponta para um dono que você ainda não encontrou.

Guarde as evidências: a chave BFE exportada, ou a saída de iptables -S capturada antes da mudança. Antes de dizer que está corrigido, confirme a camada de onde você removeu o objeto, o dono que poderia reinstalá-lo, o estado após um boot limpo e que a navegação comum funciona sem processo de VPN rodando. A página de manual do iptables(8) tem a sintaxe exata de exclusão e de política se você escrever a limpeza como script.