Un vigilante de ping no distingue un túnel roto de uno sano

Tres condiciones deciden si un vigilante ayuda o perjudica: qué puede distinguir la sonda, cuántos fallos consecutivos justifican actuar y si la acción es una reconexión o un cambio de servidor. Una línea de cron que hace ping a una dirección pública no responde bien a ninguna de las tres. Reconecta túneles que están bien y deja túneles que están rotos, y hace ambas cosas sin registro. El diseño que merece conservarse hace explícitas esas tres decisiones.

La sonda es la parte que decide todo lo demás.

Qué demuestra en realidad un ping a internet

Hacer ping a un resolutor público muestra que la ruta local de internet está viva. No demuestra que el túnel transporte tráfico, y en un perfil de túnel completo el ping viaja por el propio túnel, así que una respuesta sana y un túnel roto pueden coexistir mientras el cliente sigue reenviando paquetes. Si el perfil envía las consultas de nombres por el túnel, un fallo de DNS se lee como un enlace muerto e inicia una reconexión que no puede arreglar nada.

Ninguna de las dos direcciones del error aparece en el código de salida. Un vigilante construido sobre esa señal es un lanzamiento de moneda con una programación de cron.

Sondea algo que viva detrás del túnel

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

Sondea desde dentro, la comprobación más barata primero. Que la interfaz exista dice que el túnel está levantado; una consulta de ruta hacia una dirección interna conocida dice que el tráfico entraría en ella; una sonda TCP a un host del otro lado dice que algo responde de verdad. Solo las peticiones de eco engañan: muchos hosts internos responden encantados a TCP pero descartan ICMP, así que un vigilante basado en ping reconecta sin parar un túnel que nunca dejó de funcionar.

Mantén la sonda limitada en el tiempo y dale un estado de salida propio. Una sonda que se cuelga treinta segundos convierte al vigilante en un detector de caídas con retardo incorporado.

Elige entre una línea y un bucle

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

Una entrada de cron es una sola línea sin memoria, lo que encaja en un portátil donde una reconexión extra no cuesta nada. Un bucle supervisado lleva un contador y solo actúa tras varios fallos, lo que evita que un enlace inestable provoque una tormenta de reconexiones. En cualquier caso, ejecútalo bajo un supervisor para que sobreviva a un fallo y escriba en el registro. Elige según si importa una reconexión espuria, no según qué versión sea más corta.

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 cuenta fallos consecutivos en lugar de una fracción sobre una ventana. Una ventana necesita un reloj y una memoria de muestras, y la mayoría de los errores de los vigilantes hechos a mano viven en esa aritmética.

El cambio de servidor es otra decisión

Cambiar de servidor es distinto de reconectar. Rompe primero el enlace viejo, porque un segundo cliente que arranque mientras el primero aún tiene la dirección chocará. Cuenta fallos consecutivos antes de cambiar, limita los intentos y vuelve a sondear cuando el nuevo enlace esté levantado, en lugar de fiarte del código de salida del comando connect. Una configuración equivocada no debería recorrer todos los servidores en bucle.

No sondees la dirección pública del propio servidor VPN desde dentro de un túnel completo. Esa comprobación depende de lo que está probando e informa de éxito mientras el camino que debía validar ya no está.

Registra qué sonda se ejecutó, qué devolvió y qué acción siguió. Ese registro convierte una reconexión misteriosa en un suceso diagnosticable.