Lief das up-Skript von OpenVPN zu früh, oder war es nie bereit?

Das up-Skript läuft, endet mit null, und die darin enthaltene Aufgabe erreicht keinen privaten Dienst, der zwei Sekunden später von einem Terminal aus einwandfrei funktioniert. Der Instinkt sagt Timing, und die übliche Reparatur ist eine Pause, die das Rennen verbirgt, ohne es zu verstehen. Die nützlichere Lesart ist, dass „up“ einen Hook benennt und keine Garantie für Bereitschaft. Er wird ausgelöst, wenn das Tunnelgerät konfiguriert wird, was früher ist als Routen, DNS und ganz sicher früher als jede Anwendung hinter dem Tunnel.

Der Shell-Test war erfolgreich, weil er lief, nachdem sich alles beruhigt hatte. Der Hook lief zu einem bestimmten Zeitpunkt.

Wo up in der Startreihenfolge steht

OpenVPN konfiguriert das Tunnelgerät und führt dann den up-Hook aus. Die Installation von Routen ist eine spätere Stufe und hat ihren eigenen Hook, weshalb eine routenabhängige Aufgabe in up ein Gerät ohne brauchbaren Pfad sehen kann. Legen Sie Routenarbeit in route-up, und das Timingproblem verschwindet normalerweise.

Das Handbuch dokumentiert diese Reihenfolge und die Umgebung, die jeder Hook erhält. Diese Reihenfolge ist die ganze Erklärung für die klassische Meldung „läuft aus meiner Shell“, und sie ist auch der Grund, warum dasselbe Skript auf einer Maschine bestehen und auf einer anderen mit einer langsameren Routenstufe scheitern kann. Keines der beiden Ergebnisse sagt etwas über die Qualität des Skripts.

DNS- und Anwendungsbereitschaft kommen noch später. Selbst installierte Routen sind kein Beweis dafür, dass der entfernte Endpunkt lauscht, dass ein Name aufgelöst wird oder dass eine Desktopsitzung für eine benutzergebundene Aufgabe existiert.

Was der Hook tatsächlich erbt

Ein Hook läuft unter dem Konto und der Umgebung des OpenVPN-Prozesses, was nicht dasselbe ist wie Ihre interaktive Shell. Ihr kann ein Sitzungsbus des Benutzers, eine Desktopumgebung oder ein Anmeldedatum fehlen, das erst bei der Anmeldung entsperrt wird. Notieren Sie, welche davon die Aufgabe tatsächlich braucht.

Das zählt für Aufgaben, die nach Netzwerk aussehen, aber von einem Benutzerkontext abhängen: das Einbinden einer Freigabe mit Benutzeranmeldedaten, das Einrichten eines Proxys pro Benutzer oder das Konfigurieren eines Druckers. Ein privilegierter Tunnel-Hook ist der falsche Ort dafür, und keine Menge Warten behebt eine fehlende Sitzung.

Wenn eine Aufgabe in einem Hook scheitert, notieren Sie das Konto, die Umgebung und den ersten fehlgeschlagenen Vorgang. Das trennt vorzeitiges Timing von einem Berechtigungs- oder Kontextproblem, und die beiden haben völlig unterschiedliche Reparaturen. Zwischen ihnen zu raten, macht aus einer Fünf-Minuten-Reparatur einen ganzen Nachmittag.

Warum eine hinzugefügte Pause keine Bereitschaftsprüfung ist

Eine Pause verzögert das Skript und verschiebt das Zeitfenster des Rennens. An einem schnellen Tag gelingt die Aufgabe; an einem langsamen Tag scheitert sie wieder, und der Fehler wird schwerer reproduzierbar, weil die Verzögerung zu funktionieren scheint. Eine Verzögerung, die nur unter leichter Last funktioniert, ist ein Zufall, keine Reparatur.

Wenn die Abhängigkeit eine Route ist, verwenden Sie den Hook, der der Routeninstallation entspricht. Wenn die Abhängigkeit ein Dienst hinter dem Tunnel ist, verwenden Sie eine begrenzte Prüfung, die auf genau diese Bedingung wartet und klar scheitert, wenn sie nie eintritt.

Halten Sie den Fehler explizit. Ein Hook, der mit null endet, während seine eigentliche Arbeit fehlgeschlagen ist, ist schlimmer als ein Hook, der scheitert, weil der Dienstmanager einen Erfolg vermerkt und niemand mehr hinsieht. Eine Logzeile aus dem Skript selbst ist der billigste Weg, das ehrlich zu halten.

Aufräumen und Neuverbinden verdienen dieselbe Sorgfalt

Ein Skript, das gemeinsamen Zustand ändert, braucht einen passenden Rückweg. Routen, Resolver-Einträge und Firewall-Markierungen, die ein Hook hinzufügt, sollten idempotent und umkehrbar sein, sonst stapelt ein Neuverbinden eine zweite Kopie auf die erste.

Neuverbindungen können Hooks auch häufiger ausführen als ein vollständiger Dienststart. Eine persistente Schnittstelle, die eine Sitzung wiederherstellt, kann den up- und route-up-Zyklus erneut auslösen, sodass ein Skript, das eine Ausführung pro Start annimmt, irgendwann fehlfunktioniert. Zählen Sie die Ausführungen im Log über einen Tag mit Flapping, um zu sehen, wie oft es wirklich läuft. Machen Sie das Skript dann sicher für so viele Ausführungen.

Testen Sie den Lebenszyklus, der fehlschlug, nicht einen späteren Befehl. Reproduzieren Sie den Start oder die Neuverbindung, beobachten Sie den Hook, und bestätigen Sie, dass die Aufgabe in dem Moment gelang, in dem er tatsächlich läuft. Ein anschließender Erfolg aus einer interaktiven Shell ist ein Beweis über die Abhängigkeit, kein Beweis, dass der Startpfad funktioniert.

Benennen Sie das Ereignis, von dem jede Aufgabe abhängt, und hängen Sie sie dann an dieses Ereignis. Alles andere ist eine Verzögerung, die sich als Prüfung ausgibt.