Un chien de garde ping ne distingue pas un tunnel cassé d’un tunnel sain

Trois conditions décident si un chien de garde aide ou nuit : ce que la sonde peut distinguer, combien d’échecs consécutifs justifient une action, et si l’action est une reconnexion ou un basculement. Une ligne cron qui pingue une adresse publique ne répond bien à aucune des trois. Elle reconnecte des tunnels qui vont bien et laisse des tunnels cassés, et elle fait les deux sans aucune trace. La conception qui vaut la peine d’être gardée rend ces trois choix explicites.

La sonde est la partie qui décide de tout le reste.

Ce qu’un ping vers Internet prouve réellement

Pinguer un résolveur public montre que le chemin Internet local est vivant. Cela ne prouve pas que le tunnel transporte du trafic, et sur un profil de tunnel complet le ping lui-même traverse le tunnel, si bien qu’une réponse saine et un tunnel cassé peuvent coexister pendant que le client continue de transmettre des paquets. Si le profil envoie les recherches de noms par le tunnel, un échec DNS se lit comme un lien mort et lance une reconnexion qui ne peut rien réparer.

Aucune des deux directions de l’erreur n’apparaît dans le code de sortie. Un chien de garde bâti sur ce signal est un tirage au sort avec une planification cron.

Sondez quelque chose qui vit derrière le tunnel

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

Sondez de l’intérieur, la vérification la moins chère d’abord. L’existence de l’interface indique que le tunnel est monté ; une recherche de route vers une adresse interne connue indique que le trafic y entrerait ; une sonde TCP vers un hôte de l’autre côté indique que quelque chose répond vraiment. Les seules requêtes echo trompent : beaucoup d’hôtes internes répondent volontiers au TCP mais abandonnent l’ICMP, si bien qu’un chien de garde fondé sur le ping reconnecte sans cesse un tunnel qui n’a jamais cessé de fonctionner.

Gardez la sonde bornée dans le temps et donnez-lui un code de sortie distinct. Une sonde qui reste suspendue trente secondes transforme un chien de garde en détecteur de panne avec un délai intégré.

Choisissez entre une ligne et une boucle

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

Une entrée cron est une ligne unique sans mémoire, ce qui convient à un portable où une reconnexion supplémentaire ne coûte rien. Une boucle supervisée tient un compteur et n’agit qu’après plusieurs échecs, ce qui empêche un lien instable de déclencher une tempête de reconnexions. Dans tous les cas, exécutez-la sous un superviseur pour qu’elle survive à un plantage et écrive dans le journal. Choisissez selon l’importance d’une reconnexion parasite, non selon la version la plus courte.

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

Cette boucle compte les échecs consécutifs plutôt qu’une fraction sur une fenêtre. Une fenêtre exige une horloge et une mémoire d’échantillons, et la plupart des bogues des chiens de garde faits main vivent dans cette arithmétique.

Le basculement est une autre décision

Changer de serveur diffère d’une reconnexion. Coupez d’abord l’ancien lien, car un second client qui démarre alors que le premier tient encore l’adresse entrera en collision. Comptez les échecs consécutifs avant de basculer, plafonnez les tentatives et sondez de nouveau une fois le nouveau lien monté, au lieu de vous fier au code de sortie de la commande connect. Une configuration erronée ne devrait pas passer en boucle par tous les serveurs.

Ne sondez pas l’adresse publique du serveur VPN lui-même depuis l’intérieur d’un tunnel complet. Cette vérification dépend de ce qu’elle teste et signale un succès alors que le chemin qu’elle devait valider a disparu.

Notez quelle sonde a tourné, ce qu’elle a renvoyé et quelle action a suivi. Cette trace transforme une reconnexion mystérieuse en événement diagnosticable.