Um cão de guarda de ping não distingue um túnel quebrado de um saudável

Um ping para a internet prova menos do que parece. Sonde o túnel por dentro, conte as falhas antes de agir e trate a troca de servidor como uma decisão separada.

Três condições decidem se um cão de guarda ajuda ou prejudica: o que a sonda consegue distinguir, quantas falhas consecutivas justificam agir e se a ação é uma reconexão ou uma troca. Uma linha de cron que faz ping a um endereço público não responde bem a nenhuma delas. Ela reconecta túneis que estão bem e deixa túneis quebrados como estão, e faz as duas coisas sem registro. O desenho que vale a pena manter torna essas três escolhas explícitas.

A sonda é a parte que decide todo o resto.

O que um ping para a internet realmente prova

Fazer ping a um resolver público mostra que o caminho local da internet está vivo. Isso não prova que o túnel transporta tráfego, e num perfil de túnel completo o próprio ping passa pelo túnel, então uma resposta saudável e um túnel quebrado podem coexistir enquanto o cliente ainda encaminha pacotes. Se o perfil envia as consultas de nomes pelo túnel, uma falha de DNS é lida como um link morto e inicia uma reconexão que não pode consertar nada.

Nenhuma das duas direções do erro aparece no código de saída. Um cão de guarda construído sobre esse sinal é um lançamento de moeda com um agendamento cron.

Sonde algo que vive atrás do túnel

ip -brief addr show tun0
ip route get 10.100.20.10
nc -z -w3 10.100.20.10 443

Sonde por dentro, a verificação mais barata primeiro. A existência da interface diz que o túnel está no ar; uma busca de rota para um endereço interno conhecido diz que o tráfego entraria nela; uma sonda TCP para um host do outro lado diz que algo responde de verdade. Só os pedidos de eco enganam: muitos hosts internos respondem de bom grado ao TCP mas descartam ICMP, então um cão de guarda baseado em ping reconecta sem parar um túnel que nunca deixou de funcionar.

Mantenha a sonda limitada no tempo e dê a ela um estado de saída próprio. Uma sonda que fica pendurada trinta segundos transforma um cão de guarda num detector de queda com atraso embutido.

Escolha entre uma linha e um laço

* * * * * nc -z -w5 10.100.20.10 443 || myvpn reconnect

Uma entrada de cron é uma única linha sem memória, o que serve para um laptop em que uma reconexão extra não custa nada. Um laço supervisionado mantém um contador e só age depois de várias falhas, o que impede um link instável de disparar uma tempestade de reconexões. De qualquer forma, execute-o sob um supervisor para que sobreviva a um travamento e escreva no journal. Escolha pelo fato de uma reconexão espúria importar, não por qual versão é mais curta.

failures=0
while sleep 30; do
  if nc -z -w5 10.100.20.10 443; then failures=0
  else failures=$((failures+1)); fi
  if [ $failures -ge 3 ]; then myvpn reconnect; failures=0; fi
done

Esse laço conta falhas consecutivas em vez de uma fração numa janela. Uma janela exige um relógio e uma memória de amostras, e a maioria dos erros nos cães de guarda feitos à mão mora nessa aritmética.

A troca de servidor é outra decisão

Trocar de servidor é diferente de reconectar. Derrube primeiro o link antigo, porque um segundo cliente que comece enquanto o primeiro ainda segura o endereço vai colidir. Conte falhas consecutivas antes de trocar, limite as tentativas e sonde de novo quando o novo link estiver no ar, em vez de confiar no código de saída do comando connect. Uma configuração errada não deveria rodar por todos os servidores num laço.

Não sonde o endereço público do próprio servidor VPN de dentro de um túnel completo. Essa verificação depende da coisa que está testando, e relata sucesso enquanto o caminho que devia validar já sumiu.

Registre qual sonda rodou, o que ela devolveu e que ação veio depois. Esse registro transforma uma reconexão misteriosa num evento diagnosticável.

Artigos relacionados