Client-Hook oder Server-Hook? Wo ein OpenVPN-Skript läuft

Die Aufgabe ist klar: Wenn sich ein Laptop verbindet, soll sich etwas auf dem Laptop ändern. Die Konfiguration, die bearbeitet wird, gehört zum Server, und genau dort bricht die Annahme. Ein Pfad in einer Serverdatei benennt eine Datei auf diesem Server, und noch so viel Push ändert nicht, wessen Prozess sie ausführt. Die Wahl zwischen den beiden Hooks ist vor allem eine Frage der Entscheidung, welche Maschine die Arbeit besitzt, und der Akzeptanz der daraus folgenden Grenzen.

Zwei Maschinen, zwei Fragen, die zuerst zu beantworten sind

Fragen Sie, wo die Zustandsänderung stattfinden muss, und dann, welches Ereignis ihr entspricht. Ist die Änderung eine Autorisierung pro Benutzer oder eine Konfigurationsentscheidung pro Client, gehört sie dorthin, wo das Benutzerverzeichnis bekannt ist: auf den Server. Ist die Änderung eine Route, eine Resolver-Einstellung oder ein lokaler Helfer auf einem Endpunkt, gehört sie auf den Endpunkt, und nur der Endpunkt kann sie ausführen.

Diese beiden Fragen in umgekehrter Reihenfolge zu beantworten, ist der Weg, auf dem Leute versuchen, eine Batchdatei auf einen Windows-Laptop zu pushen. Der Server weiß, wer sich verbunden hat; der Laptop weiß, wie sein eigener Netzwerk-Stack aussieht. Keiner hat die Informationen des anderen, und der Versuch scheitert meist still statt mit einem klaren Fehler.

Vor beiden lohnt eine dritte Frage: Bietet die Plattform den gewünschten Hook überhaupt an? Ein Gerät, das seine Konfiguration selbst erzeugt, bietet möglicherweise nicht dieselben Ereignisnamen, und ein Desktop-Client, der eine .ovpn-Datei importiert, ist nicht unbedingt derselbe Client, für den die Datei geschrieben wurde. Die Plattform zuerst zu bestätigen erspart es Ihnen, um einen Hook herum zu entwerfen, den es dort nicht gibt. Es sagt Ihnen auch, welche Dokumentation tatsächlich für die Maschine vor Ihnen gilt.

Die serverseitige Option: ein Ereignis pro Verbindung

Ein client-connect-Skript läuft im Prozesskontext des Servers, wenn sich ein authentifizierter Client verbindet, und erhält dokumentierte Verbindungsdetails wie den Common Name und die zugewiesene Adresse. Es ist der richtige Ort, um ein Konfigurationsfragment pro Client zu schreiben, eine Richtlinienentscheidung durchzusetzen oder Zustand zu erfassen, den der Server besitzt.

Der Unterschied, den Leute übersehen, ist der zwischen diesem Hook und einem Server-up-Hook. Der Up-Hook wird ausgelöst, wenn der Server sein Tunnelgerät öffnet, was auf einem Server mit mehreren Clients einmal beim Daemon-Start geschieht. Es ist kein Ereignis pro Anmeldung, und dort platzierter Code läuft beim Start des Dienstes statt beim Verbinden von Benutzern.

Auf einem Gerät mit Weboberfläche nutzen Sie den unterstützten Erweiterungsmechanismus, statt generierte Daemon-Dateien zu bearbeiten. Generierte Dateien werden beim nächsten Speichern neu geschrieben, und das Umschreiben entfernt Ihre Änderung still im ungünstigsten Moment. Bewahren Sie eine Kopie des Erweiterungstextes außerhalb des Geräts auf, damit ein Firmware-Update nicht auch die Absicht verliert.

Die clientseitige Option: Arbeit, die lokal laufen muss

Ein Community-Client kann ein lokales Skript ausführen, wenn das Tunnelgerät hochkommt, und erneut, wenn Routen installiert werden. Das sind zwei verschiedene Momente, und die falsche Wahl erzeugt das klassische Rennen, bei dem ein Helfer startet, bevor die Route existiert, von der er abhängt.

Der Helfer muss auf diesem Client vorhanden, für das Konto, das den Client ausführt, lesbar und ausführbar und durch eine ausdrückliche script-security-Einstellung erlaubt sein. Ein Skript, das funktioniert, wenn Sie den Client als Administrator starten, sagt nichts über einen Dienst vor der Anmeldung oder die Sitzung eines anderen Benutzers aus.

Auch die Benennung zählt. Der Up-Hook entspricht der Geräteerstellung und route-up der Routeninstallation, aber eine Aufgabe, die ein erreichbares privates Netzwerk braucht, sollte die Erreichbarkeit prüfen, statt anzunehmen, dass Geräteerstellung bedeutet, jede Route, jeder Resolver-Eintrag und jede Anwendung seien bereit.

Warum das Pushen von ausführbarem Code nicht zur Auswahl steht

Gepushte Optionen sind bewusst eingeschränkt, und Optionen, die Skripte ausführen, gehören zu den Kategorien, die der Server nicht weitergeben darf. Diese Einschränkung existiert, weil die Alternative es einem kompromittierten oder falsch konfigurierten Server erlauben würde, beliebige Befehle auf jedem Client auszuführen, der sich jemals verbindet.

Die lokale Freigabe der Skriptausführung ändert daran nichts. Ihre script-security-Einstellung erlaubt lokale Skripte, die Sie ausgewählt haben; sie berechtigt den Server nicht, neue zu liefern.

Wenn das Ziel nur darin besteht, VPN-Routen zu installieren, nutzen Sie die unterstützte Routenkonfiguration, statt ein Schema zur Fernausführung zu erfinden. Wenn das Ziel wirklich lokalen Code erfordert, verteilen Sie ihn über die Endpunkt-Management-Werkzeuge der Organisation und prüfen Sie ihn wie jede andere Software, die mit den Rechten des Benutzers läuft.

Was Sie prüfen sollten, bevor Sie einem der beiden Hooks vertrauen

Notieren Sie vier Dinge für jeden Hook: die Maschine, den Ereignisnamen, das Konto, unter dem er läuft, und die Zustandsänderung, die er erzeugen soll. Testen Sie dann die Verbindung, eine erneute Verbindung und den Aufräumpfad, denn ein Hook, der bei erneuter Verbindung Zustand verliert, ist schlimmer als einer, der nie lief.

Testen Sie unter dem Konto, das ihn tatsächlich ausführt, zu dem Zeitpunkt, an dem er tatsächlich ausgeführt wird. Das Handbuch openvpn(8) dokumentiert beide Hook-Familien und die Push-Beschränkungen; die Plattform, auf der Sie bereitstellen, dokumentiert, ob sie diese überhaupt anbietet. Ein Skript, das in einem interaktiven Administrator-Terminal erfolgreich ist, ist eine Hypothese, keine Verifikation.