Ein Ping-Wächter unterscheidet keinen kaputten Tunnel von einem gesunden
Ein Ping ins Internet beweist weniger, als es scheint. Prüfe den Tunnel von innen, zähle Fehlschläge vor dem Handeln und behandle den Wechsel auf einen anderen Server als eigene Entscheidung.
Drei Bedingungen entscheiden, ob ein Wächter hilft oder schadet: was die Sonde unterscheiden kann, wie viele aufeinanderfolgende Fehlschläge ein Handeln rechtfertigen und ob das Handeln ein Wiederverbinden oder ein Wechsel ist. Eine Cron-Zeile, die eine öffentliche Adresse anpingt, beantwortet keine davon gut. Sie verbindet Tunnel neu, die in Ordnung sind, und lässt Tunnel liegen, die kaputt sind, und beides tut sie ohne Aufzeichnung. Das Design, das es zu behalten lohnt, macht diese drei Entscheidungen ausdrücklich.
Die Sonde ist der Teil, der alles andere entscheidet.
Was ein Ping ins Internet tatsächlich beweist
Ein Ping an einen öffentlichen Resolver zeigt, dass der lokale Internetweg lebt. Er beweist nicht, dass der Tunnel Verkehr trägt, und bei einem Profil mit vollem Tunnel wandert der Ping selbst durch den Tunnel, sodass eine gesunde Antwort und ein kaputter Tunnel gleichzeitig bestehen können, während der Client noch Pakete weiterleitet. Leitet das Profil Namensabfragen durch den Tunnel, wird ein DNS-Fehler als tote Verbindung gelesen und startet ein Wiederverbinden, das nichts reparieren kann.
Keine der beiden Richtungen des Fehlers erscheint im Exit-Code. Ein Wächter, der auf diesem Signal aufbaut, ist ein Münzwurf mit Cron-Zeitplan.
Prüfe etwas, das hinter dem Tunnel lebt
ip -brief addr show tun0 ip route get 10.100.20.10 nc -z -w3 10.100.20.10 443
Von innen prüfen, die billigste Kontrolle zuerst. Ob die Schnittstelle existiert, sagt, dass der Tunnel steht; ein Routenabruf zu einer bekannten internen Adresse sagt, dass Verkehr hineingehen würde; eine TCP-Sonde zu einem Host auf der anderen Seite sagt, dass wirklich etwas antwortet. Echo-Anfragen allein täuschen: Viele interne Hosts antworten bereitwillig auf TCP, verwerfen aber ICMP, sodass ein Wächter auf Ping-Basis einen Tunnel immer wieder neu verbindet, der nie aufgehört hat zu funktionieren.
Halte die Sonde zeitlich begrenzt und gib ihr einen eigenen Exit-Status. Eine Sonde, die dreißig Sekunden hängt, macht einen Wächter zu einem Ausfallmelder mit eingebauter Verzögerung.
Wähle zwischen einer Zeile und einer Schleife
* * * * * nc -z -w5 10.100.20.10 443 || myvpn reconnect
Ein Cron-Eintrag ist eine einzelne Zeile ohne Gedächtnis, was zu einem Laptop passt, bei dem ein zusätzliches Wiederverbinden nichts kostet. Eine überwachte Schleife führt einen Zähler und handelt erst nach mehreren Fehlschlägen, was verhindert, dass eine wackelige Verbindung einen Sturm von Wiederverbindungen auslöst. In jedem Fall sollte sie unter einem Supervisor laufen, damit sie einen Absturz übersteht und ins Journal schreibt. Entscheide danach, ob ein überflüssiges Wiederverbinden zählt, nicht danach, welche Version kürzer ist.
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
Diese Schleife zählt aufeinanderfolgende Fehlschläge statt eines Anteils über ein Fenster. Ein Fenster braucht eine Uhr und ein Gedächtnis von Stichproben, und die meisten Fehler in handgebauten Wächtern stecken in dieser Arithmetik.
Der Wechsel ist eine andere Entscheidung
Server zu wechseln ist etwas anderes als wiederzuverbinden. Reiße zuerst die alte Verbindung ab, denn ein zweiter Client, der startet, während der erste die Adresse noch hält, wird kollidieren. Zähle aufeinanderfolgende Fehlschläge vor dem Wechsel, begrenze die Versuche und prüfe erneut, sobald die neue Verbindung steht, statt dem Exit-Status des connect-Befehls zu vertrauen. Eine falsche Konfiguration sollte nicht in einer Schleife durch jeden Server rotieren.
Prüfe nicht die eigene öffentliche Adresse des VPN-Servers aus einem vollen Tunnel heraus. Diese Kontrolle hängt von dem ab, was sie testet, und meldet Erfolg, während der Weg, den sie bestätigen sollte, verschwunden ist.
Halte fest, welche Sonde lief, was sie zurückgab und welche Aktion folgte. Diese Aufzeichnung macht aus einem rätselhaften Wiederverbinden ein diagnostizierbares Ereignis.