Como testar o kill switch de uma VPN sem contas reais
Faça um teste do kill switch com uma página chamariz e um perfil sobressalente: cubra cada tipo de interrupção, leia os códigos de saída do curl e separe um bloqueio real de uma falha de DNS.
Você não precisa de uma conta real para descobrir se um kill switch segura; é justamente a conta que o teste põe em risco. A verificação cria uma janela curta em que o tráfego pode ou não sair fora do túnel, então a carga deve ser algo que você possa perder. Hoje faço isso com uma página chamariz e um perfil de navegador sobressalente, e a resposta fica mais clara do que na rotina com navegador e webmail que eu usava antes. A seguir, sigo a mesma ordem que o cliente apresenta: a configuração, o destino, a transição e então a evidência.
O teste responde a uma pergunta estreita: durante esta transição, este aplicativo consegue alcançar a rede fora do túnel? ele não diz nada sobre se o resto da política é sensato. Mantenha o escopo assim pequeno e o resultado vale a pena ser anotado.
Encontre o interruptor e o escopo dele no cliente
Abra o cliente e localize a configuração de bloqueio antes de mudar qualquer estado de rede. Os fabricantes dão nomes diferentes: kill switch, modo de bloqueio, trava de rede, bloquear tráfego fora do túnel. O rótulo diz menos do que as opções dentro dele. O que importa é se o bloqueio se aplica sempre ou só quando o aplicativo decide que o túnel acabou de falhar, e se cobre todos os aplicativos ou uma lista selecionada.
Depois, liste as transições que seu cliente realmente consegue executar. Uma desconexão iniciada pelo usuário, sair do aplicativo e perder contato com o servidor são três caminhos de código diferentes na maioria dos clientes, e eles não compartilham uma única política de bloqueio. Alguns liberam o bloqueio quando o aplicativo sai. Outros deixam as regras de filtro instaladas até algo removê-las. Leia a referência de configurações do fabricante para a versão que você usa em vez de supor, e depois anote qual das três você está testando.
Anote também o perfil: protocolo, famílias de endereços e se o tunelamento dividido está ativado. A alegação de abranger o dispositivo inteiro não significa nada se o perfil exclui deliberadamente alguns aplicativos, e uma exclusão que você configurou não é vazamento. A referência de configurações do OpenVPN Connect é o tipo de página que nomeia qual chave muda qual comportamento, embora os rótulos variem por cliente.
Escolha um destino chamariz que também funcione sem o túnel
O chamariz precisa de duas propriedades, e pular qualquer uma delas produz um resultado ilegível. Ele precisa ser acessível diretamente quando o túnel está abaixo e o bloqueio está desligado, senão a informação de que parou de responder pode significar apenas que o host sumiu. E não pode exigir login, cookie ou pagamento, para que um vazamento custe uma linha de log em vez de uma sessão.
Uma página estática em um host que você controla é a escolha mais limpa. Uma máquina virtual sobressalente rodando um servidor HTTP simples é quase tão boa, e uma página pública de verificação de conectividade serve se você aceitar que a disponibilidade dela está fora do seu controle. Anote o endereço, a porta, a família de endereços e se a requisição precisa de resolução de nome, porque cada um desses vira uma variável que você pode precisar isolar depois.
Estabeleça a linha de base antes de tocar no interruptor. Com o túnel no ar, o chamariz deve responder pelo túnel, o que prova que a rota por política funciona. Com o túnel abaixo e o bloqueio desligado, ele deve responder diretamente, o que prova que o destino está vivo. Só então uma falha no estado bloqueado lhe diz alguma coisa.
Execute as transições em ordem fixa
Faça as transições uma de cada vez e dê a cada uma alguns segundos para assentar, porque os clientes costumam derrubar e reconstruir regras nessa lacuna. Executar a mesma verificação curta sempre mantém as observações comparáveis:
curl -sS -o /dev/null -w 'http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_exit=$?"
dig +short decoy.example
curl -6 -sS -o /dev/null -w 'v6_http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_v6_exit=$?"
| Transition | Expected with the block on | Failure signature |
|---|---|---|
| Manual disconnect | Decoy stops answering within seconds | Decoy still returns 200 |
| Server or path failure | Blocked, with no exemption for the old endpoint | Direct access during the gap |
| Quit the app | Client-dependent; record what happens | Block disappears with the process |
| Wi-Fi to Ethernet | Block holds until the tunnel returns | Traffic flows mid-change |
A linha de sair do aplicativo merece uma execução própria, mesmo que você nunca feche o cliente no uso normal. Se o bloqueio é liberado na saída, um travamento ou uma atualização forçada entrega a mesma exposição, e isso é um fato sobre a implantação, não sobre sua paciência. No Windows, as sondas equivalentes são Resolve-DnsName decoy.example e curl.exe -s -o NUL -w "%{http_code}" http://decoy.example/.
Separe um bloqueio de um resolvedor quebrado
Uma página que não carrega tem várias causas, e só uma delas é o interruptor funcionando. Se o nome não resolve, você descobriu que o DNS está bloqueado ou quebrado, não que o caminho de dados está bloqueado. Sonde também um endereço literal, para que a resposta não dependa de resolução.
Os códigos de saída do curl separam esses casos. 6 é falha de resolução de nome, 7 significa que a conexão foi recusada, 28 é timeout. Uma rota bloqueada costuma aparecer como timeout ou recusa contra um endereço literal, enquanto um bloqueio só de DNS deixa 6 e esconde todo o resto. Uma página em cache ou um portal cativo enganam o olho, por isso a evidência é o código de saída, não a tela.
Repita a sonda em IPv6 com um endereço literal. Um bloqueio que cobre IPv4 e ignora IPv6 é comum o bastante para merecer uma linha própria nas suas notas, e um cliente que desativa IPv6 fora do túnel deve falhar de forma limpa nas duas famílias.
Anote o escopo que o resultado cobre
Quando o túnel voltar, confirme a recuperação: o chamariz responde pelo túnel, o resolvedor devolve respostas e a política está onde você a deixou. Depois desfaça os experimentos. Uma regra temporária de firewall, uma rota de depuração ou um perfil de teste deixados no lugar confundem a próxima execução e podem sobreviver ao aplicativo.
Uma passagem cobre uma versão do cliente, um perfil, uma transição e uma família de endereços. Anote esses quatro com o resultado:
- Versão do cliente e plataforma, e se a configuração é por perfil ou global.
- Perfil, protocolo e quaisquer exclusões de tunelamento dividido.
- Transição testada e como você a acionou.
- Famílias de endereços e DNS, com os códigos de saída do curl para o estado bloqueado e o não bloqueado.
Se alguma linha estiver em branco, o teste não terminou. Roaming significa repetir a linha de mudança de rede. Um reinício sem supervisão significa verificar se as regras voltam, e isso é uma pergunta sobre a ordem de restauração, não sobre o interruptor. Repita a sequência após uma atualização do cliente, porque as chaves raramente mudam enquanto o comportamento por trás delas muda. Mantenha o chamariz por perto: não há nada a rotacionar e a próxima verificação leva cinco minutos.