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=$?"
TransitionExpected with the block onFailure signature
Manual disconnectDecoy stops answering within secondsDecoy still returns 200
Server or path failureBlocked, with no exemption for the old endpointDirect access during the gap
Quit the appClient-dependent; record what happensBlock disappears with the process
Wi-Fi to EthernetBlock holds until the tunnel returnsTraffic 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.

Artigos relacionados