Un vixiante de ping non distingue un túnel roto dun san

Tres condicións deciden se un vixiante axuda ou prexudica: que pode distinguir a sonda, cantos fallos consecutivos xustifican actuar e se a acción é unha reconexión ou un cambio de servidor. Unha liña de cron que fai ping a un enderezo público non responde ben a ningunha das tres. Reconecta túneles que están ben e deixa túneles que están rotos, e fai ambas as cousas sen rexistro. O deseño que paga a pena conservar fai explícitas esas tres decisións.

A sonda é a parte que decide todo o demais.

Que demostra realmente un ping a internet

Facer ping a un resolutor público mostra que a ruta local de internet está viva. Non demostra que o túnel transporte tráfico, e nun perfil de túnel completo o ping viaxa polo propio túnel, así que unha resposta sá e un túnel roto poden coexistir mentres o cliente segue reenviando paquetes. Se o perfil envía as consultas de nomes polo túnel, un fallo de DNS lese como unha ligazón morta e inicia unha reconexión que non pode arranxar nada.

Ningunha das dúas direccións do erro aparece no código de saída. Un vixiante construído sobre ese sinal é un lanzamento de moeda cunha programación de cron.

Sonda algo que viva detrás do túnel

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

Sonda desde dentro, a comprobación máis barata primeiro. Que a interface exista di que o túnel está levantado; unha consulta de ruta cara a un enderezo interno coñecido di que o tráfico entraría nel; unha sonda TCP a un host do outro lado di que algo responde de verdade. Só as peticións de eco enganan: moitos hosts internos responden de boa gana a TCP pero descartan ICMP, así que un vixiante baseado en ping reconecta sen parar un túnel que nunca deixou de funcionar.

Mantén a sonda limitada no tempo e dálle un estado de saída propio. Unha sonda que se colga trinta segundos converte o vixiante nun detector de caídas con retardo incorporado.

Escolle entre unha liña e un bucle

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

Unha entrada de cron é unha soa liña sen memoria, o que encaixa nun portátil onde unha reconexión extra non custa nada. Un bucle supervisado leva un contador e só actúa tras varios fallos, o que evita que unha ligazón inestable provoque unha tormenta de reconexións. En calquera caso, execútao baixo un supervisor para que sobreviva a un fallo e escriba no rexistro. Escolle segundo se importa unha reconexión espuria, non segundo que versión sexa máis 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

Ese bucle conta fallos consecutivos en lugar dunha fracción sobre unha ventá. Unha ventá necesita un reloxo e unha memoria de mostras, e a maioría dos erros dos vixiantes feitos á man viven nesa aritmética.

O cambio de servidor é outra decisión

Cambiar de servidor é distinto de reconectar. Corta primeiro a ligazón vella, porque un segundo cliente que arranque mentres o primeiro aínda ten o enderezo chocará. Conta fallos consecutivos antes de cambiar, limita os intentos e volve sondar cando a nova ligazón estea levantada, en lugar de fiarte do código de saída da orde connect. Unha configuración equivocada non debería percorrer todos os servidores en bucle.

Non sondes o enderezo público do propio servidor VPN desde dentro dun túnel completo. Esa comprobación depende do que está probando e informa de éxito mentres o camiño que debía validar xa non está.

Rexistra que sonda correu, que devolveu e que acción seguiu. Ese rexistro converte unha reconexión misteriosa nun suceso diagnosticable.