O aplicativo VPN travou: o kill switch ainda está ativo?

Comece por onde o usuário começa: a janela do cliente sumiu, o ícone da bandeja desapareceu e o navegador ou carrega ou não carrega. Essa observação sozinha não pode dizer se o bloqueio sobreviveu. A resposta depende de qual componente guarda as regras, se esse componente morreu com a janela e se a plataforma mantém a aplicação fora do aplicativo. Avance da janela para o processo, depois para o firewall, depois para o caminho real.

Não reinicie primeiro; um reinício costuma destruir as evidências.

Comece pelo que ainda está em execução

Abra a lista de processos antes de tocar em qualquer coisa. Um cliente de desktop costuma se dividir em um processo de interface do usuário e um serviço ou daemon, e uma travada no primeiro não necessariamente interrompe o segundo. No Windows o serviço pode continuar listado, no Linux a unidade pode continuar ativa e no Android o túnel pertence ao sistema depois que o consentimento é dado. Leia esses três fatos nessa ordem.

Se o daemon está vivo, o túnel provavelmente também está, e a janela ausente é só cosmética.

Get-Process | Where-Object { $_.ProcessName -match 'vpn|wireguard|openvpn' }
Get-Service | Where-Object { $_.Name -match 'vpn|wireguard|openvpn' }
netsh wfp show state
systemctl status wg-quick@wg0 --no-pager
ps -eo pid,comm,args | grep -E 'openvpn|wg'
nft list ruleset | head -40

Leia o bloqueio em quem o aplica, não no aplicativo

Se o cliente implementa seu kill switch inserindo regras de firewall, essas regras pertencem ao sistema operacional e sobrevivem ao processo que as criou. Uma travada então deixa você bloqueado sem nenhuma interface para desligar isso, o que parece uma rede quebrada e não uma proteção. Se, em vez disso, o bloqueio vive dentro do caminho de pacotes do próprio cliente, matar o processo remove o bloqueio no mesmo instante.

O Android trata isso de outra forma ainda: a opção always-on VPN com lockdown é uma configuração da plataforma, então o bloqueio persiste independentemente do processo do aplicativo, e o sistema pode reiniciar o serviço. Consulte a documentação da plataforma para o comportamento exato em vez de supor que corresponde a um cliente de desktop.

Distinga uma saída limpa de uma travada

Um Quit normal costuma executar o caminho de desligamento do cliente, que remove regras e fecha o túnel de propósito. Uma travada pula esse caminho e deixa o que o aplicador já instalou. A diferença aparece nos carimbos de tempo das regras em relação à saída do processo, e na existência de uma interface de túnel antiga sem dono.

Essa distinção decide a sua recuperação: uma saída limpa pode precisar de uma conexão nova, enquanto uma travada pode precisar que as regras restantes sejam removidas pela ação de reparo suportada pelo cliente.

Recupere sem quebrar outros controles

Reinicie o cliente pelo fluxo de trabalho documentado e depois verifique as duas metades do requisito: o túnel transporta tráfego e o bloqueio ainda se aplica quando deve. Esvaziar todo o firewall para recuperar a conectividade também remove controles não relacionados, e essa troca raramente compensa.

Para uma travada repetida, reúna a versão do cliente, a compilação da plataforma e os registros limitados que o fornecedor pede. Um perfil de cliente, uma chave privada ou um log completo de conexão de outra conta não são necessários para um relatório de travada, e incluí-los transforma um caso de suporte em um problema de tratamento de dados.

Uma travada não é prova de vazamento. A prova é um pacote observado saindo por um caminho que a política deveria impedir, capturado no momento em que o cliente estava fora do ar. Teste isso de propósito, com um destino inofensivo, e anote qual camada de aplicação resistiu.