Teste do kill switch: meça a lacuna, não apenas a reconexão

Uma reconexão que termina em um segundo diz que o cliente é rápido. Não diz se algo escapou enquanto o túnel estava fora. Uma reconexão que leva um minuto diz que o cliente é lento, e ainda não diz se o tráfego direto foi permitido na lacuna. São duas medições, e um teste de kill switch que só relata a primeira não testou o interruptor.

Duas observações, dois veredictos separados

A pergunta de disponibilidade é simples: quando o túnel voltou a ser utilizável, e se a aplicação protegida precisou de uma nova conexão para chegar lá. A pergunta de cumprimento é diferente: quais pacotes saíram da máquina entre o momento em que a proteção caiu e o momento em que voltou.

Responda às duas com registros separados. Uma linha diz que a lacuna durou um certo número de segundos. Outra linha diz se uma requisição sem proteção teve sucesso durante essa lacuna. Fundi-las num único aprovado ou reprovado esconde o caso que mais importa: uma reconexão rápida com um vazamento.

Construa uma sonda que você possa cronometrar

Use uma requisição inofensiva, barata e independente do canal de controle do próprio túnel. O laço abaixo imprime um carimbo de tempo, um status HTTP e o tempo decorrido uma vez por segundo, e falha ruidosamente em vez de travar:

while true; do
  printf '%s ' "$(date +%H:%M:%S)"
  curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 2 https://example.com || echo "curl-exit-$?"
  sleep 1
done

Leia os códigos de saída do curl, não apenas o status. Um 28 significa que a requisição esgotou o tempo, é assim que um caminho bloqueado se parece. Um 6 significa que a resolução de nomes falhou, o que é um achado diferente e muitas vezes o mais interessante. Um 200 com pouco tempo decorrido durante a lacuna significa que o tráfego foi autorizado a sair.

Escreva a saída num arquivo e guarde-o. O histórico do terminal não é prova, e a parte interessante costuma ser três linhas no meio.

Provoque uma falha real, não uma arrumada

Desconectar pelo menu do próprio cliente testa o caminho cooperativo, em que o cliente tem tempo de instalar suas regras de bloqueio. Mate o processo em vez disso, ou derrube o enlace subjacente, e você testa o caminho que uma falha real percorre.

Cada gatilho exercita um caminho de código diferente. Uma falha no lado do servidor, uma perda de enlace local e um travamento do cliente podem deixar estados diferentes, e um deles é provavelmente o caso que você acabará encontrando. Execute a sonda com pelo menos dois gatilhos e rotule os resultados por gatilho.

Leia o registro para ver como é o tráfego permitido

Um 200 ou uma falha rápida de conexão durante a lacuna é um vazamento, para qualquer direção que aponte. Tempos esgotados durante toda a lacuna são a forma esperada de uma política de bloqueio. Uma resolução de nomes que tem sucesso enquanto as conexões falham sugere que o resolver ainda está acessível, o que é um vazamento de outro tipo.

Os sockets existentes exigem cuidado. Um programa pode continuar usando uma conexão aberta antes da desconexão, então o tráfego aparentemente vivo pode não provar que um novo caminho foi permitido. A lista de sockets mostra se uma conexão é anterior ao evento:

ss -tunp | grep -E 'ESTAB|SYN-SENT'
ip route get 198.51.100.7
resolvectl status | sed -n '1,20p'

Compare a hora de início do socket com o carimbo de tempo da desconexão. Uma conexão mais antiga que a falha é prova de reutilização do socket, não de um vazamento, e relatá-la como falha manda a próxima pessoa caçar um bug que não existe.

Registre o resultado numa forma que sobreviva a uma atualização

Anote o gatilho, a lacuna em segundos, se alguma requisição não bloqueada teve sucesso, se a resolução de nomes teve sucesso e as versões do cliente e do sistema operacional. Esse conjunto de cinco fatos pode ser comparado entre versões, o que um parágrafo de prosa não consegue.

Execute o mesmo teste novamente depois de uma atualização do cliente ou de uma mudança de perfil, porque o comportamento de bloqueio é um detalhe de implementação e ele se move. O objetivo do registro é notar o movimento antes que ele vire um incidente, não certificar o cliente uma vez.