Como testar a estabilidade de uma VPN sem registar a sua navegação

Quer saber se o túnel sobrevive a uma suspensão do portátil, a uma caminhada entre pontos de acesso, ou a uma hora de chamadas, e prefere não entregar a ninguém um registo de tudo o que lê enquanto o descobre. Três coisas respondem a isso: uma sonda fixa, os mesmos quatro factos amostrados segundo um horário e o evento que os alterou, registado. Dez minutos disso valem mais do que uma tarde a ver uma página que não carrega. O registo com que fica também é suficientemente curto para o anexar a um ticket sem ocultar metade.

Decida o que estável tem de significar

«A VPN caiu» são quatro falhas diferentes numa só palavra. O peer pode perder o handshake, a rota pode recuar para a gateway local, a resolução de nomes pode ir para um servidor que nunca responde pelo túnel, ou tudo isso pode estar saudável enquanto uma aplicação continua a falhar. Decida qual corresponde ao seu sintoma antes de recolher seja o que for, porque cada uma exige uma sonda diferente. Depois escolha um intervalo que consiga manter: uma amostra a cada trinta segundos durante dez minutos apanha um roaming sem transformar o teste em carga de trabalho.

Se a queixa for uma chamada que congela quando vai à cozinha, a propriedade de que precisa é se um pedido novo é concluído após o roaming. Isso verifica-se numa linha e não registra navegação nenhuma.

Fixe uma sonda inofensiva

Escolha um destino que lhe seja permitido consultar e que não esteja ligado às suas contas: um anfitrião de documentação, um ponto final de estado interno ou a própria gateway do túnel. Torne a operação repetível, por exemplo curl -s -o /dev/null -w "%{http_code} %{time_total}\n" https://example.com/, que imprime uma linha por tentativa. Mantenha esse formato de saída fixo durante toda a execução. Um código de estado e uma duração recolhidos da mesma forma duas vezes são o que torna duas execuções comparáveis.

Resista ao site em que realmente confia. Uma página de banco ou de webmail arrasta rastreadores, redirecionamentos e conteúdo pessoal para a medição, e imprime identificadores de sessão em tudo o que colar num ticket mais tarde. Use o mesmo destino durante toda a investigação e anote-o ao lado do intervalo.

Amostre os quatro factos

O estado do peer, a rota, o resolvedor e um pedido novo são as quatro observações, e cada uma tem uma fonte barata. No WireGuard, wg show wg0 latest-handshakes dá a marca temporal do peer e ip route get 1.1.1.1 mostra que interface o kernel usaria. No OpenVPN o mesmo estado está no ficheiro de estado escrito por --status /run/openvpn/status 10 ou por trás de state na interface de gestão. Um cliente Windows fica no PowerShell com Get-NetAdapter e Resolve-DnsName.

Ponha-os em ciclo num só terminal para que cada linha tenha uma marca temporal: for i in $(seq 1 20); do date -Is; wg show wg0 latest-handshakes; ip route get 1.1.1.1; sleep 30; done. Esse ciclo cobre três dos seis campos do registo; a versão do cliente entra uma vez no topo, e a marca temporal do evento é acrescentada quando o evento acontece.

O resolvedor é o facto que as pessoas saltam, e dig +short esconde-o, porque essa forma só imprime a resposta. Peça o servidor explicitamente com dig example.com | grep SERVER:, ou use nslookup example.com onde o dig não está instalado, que imprime o endereço do servidor para onde foi a consulta. Um handshake antigo num túnel inativo também não é automaticamente uma falha, já que o WireGuard só renova chaves quando há tráfego a proteger.

Provogue o evento, não uma fuga

Tome cinco minutos calmos como linha de base antes do evento que lhe interessa, seja fechar a tampa, caminhar até outro ponto de acesso ou mudar para o hotspot de um telemóvel. Anote a hora a que o provocou, para que as amostras dos dois lados possam ser alinhadas.

Sem essa marca temporal o registo mostra um vazio e ninguém pode dizer se foi o cliente ou a rede a fechá-lo. Duas execuções com o evento em locais diferentes valem mais do que dez sem ele. Use os controlos de desligar e voltar a ligar do próprio cliente. Não desative o kill switch nem empurre tráfego para fora do túnel para ver o que acontece, porque num portátil gerido isso é uma violação de política e na sua própria máquina cria exatamente a exposição que estava a testar.

Mantenha um registo pequeno o suficiente para o terminar

Seis campos por amostra: hora, versão do cliente, ponto final, rede de acesso, evento, resultado. Deixe de fora endereços web, cargas úteis, tokens e qualquer coisa que transporte um identificador de sessão, porque o registo é prova sobre o túnel e nada mais. Guarde-o ao lado do ciclo para que a próxima pessoa o possa voltar a executar sem perguntar o que significam as colunas.

Após uma alteração, repita o teste com a mesma sonda e o mesmo intervalo; se trocar o destino e a versão do cliente ao mesmo tempo, o resultado não pertence a nenhum dos dois. Uma execução limpa de dez minutos é prova para essas condições e esse destino, não uma promessa sobre a rede do hotel no próximo mês. Guarde o script e o modelo de registo onde os encontrar. As limitações documentadas do WireGuard merecem ser lidas antes de atribuir uma quebra ao protocolo.