OpenVPN unter Windows: den Tunnel automatisch starten und die Routen behalten

Hier verheddern sich zwei Anforderungen: Der Tunnel soll bevor sich jemand anmeldet hochkommen, und der Verkehr zu einem zweiten Standort soll ihm folgen. Das sind getrennte Probleme mit getrennten Mechanismen. Der Dienststart entscheidet das erste, die Lebensdauer der Route das zweite. Löst man das eine, bleibt das andere genau dort, wo es war.

Schritt eins: Legen Sie das Profil dorthin, wo der Dienst sucht

Der Windows-Dienst liest Profile aus einem festen Verzeichnis, und die GUI liest vom selben Ort, daher kann ein Profil, das beim Import funktioniert, beim Start trotzdem unsichtbar sein. Legen Sie die Dateien .ovpn in das config-Verzeichnis der Installation, das normalerweise unter Program Files liegt. Ein Profil im Downloads-Ordner eines Benutzers liegt völlig außerhalb des Bereichs des Dienstes.

Ältere Anleitungen verweisen auf einen config-auto-Ordner, den manche Builds der 2.5-Ära beachteten und spätere Versionen nicht. Deshalb kann ein Upgrade einen funktionierenden Autostart in Stille verwandeln, ohne dass im Protokoll etwas zu Anmeldedaten steht. Prüfen Sie, welches Verzeichnis der installierte Build tatsächlich liest, bevor Sie Dateien verschieben.

Bei mehreren Profilen auf einer Maschine geben Sie jedem über dev-node einen benannten Adapter. Sonst konkurrieren sie um dieselbe Schnittstelle, und das zweite scheitert auf eine Weise, die wie ein Problem mit den Anmeldedaten aussieht.

Schritt zwei: Starten Sie den Dienst statt des Taskleistensymbols

Wenn Sie den Dienst OpenVPN auf Automatic stellen, startet er beim Booten ohne Anmeldung. Das ist der Mechanismus, und das Taskleistensymbol gehört nicht dazu. Wenn der Dienst die Verbindung besitzt, zeigt die GUI möglicherweise kein Symbol und keinen Status, was zu erwarten und kein Fehler ist.

Die Folge ist, dass Trennen bedeutet, den Dienst zu stoppen, nicht auf Disconnect zu klicken. Sagen Sie es demjenigen, der die Maschine betreut, sonst dreht sich der erste Supportanruf um ein fehlendes Symbol.

Prüfen Sie, ob das Dienstkonto das Profil und das Schlüsselmaterial lesen kann. Ein Berechtigungsproblem beim Start sieht im Protokoll genau wie ein Authentifizierungsfehler aus.

Schritt drei: Binden Sie die Route an den Tunnel

Ein dauerhafter Eintrag ist hier das falsche Werkzeug. Eine Route mit -P überlebt Neustarts und, schlimmer, auch das Schließen des Tunnels. Bei abgeschaltetem VPN zeigt das Präfix weiterhin auf ein Gateway, das nicht mehr da ist, sodass der Host dieses Ziel nicht erreicht, bis jemand den Eintrag löscht.

Drei Alternativen verhalten sich korrekt. Schieben Sie die Route vom Server, der sie beim Verbinden hinzufügt und beim Trennen entfernt. Fügen Sie sie in einem route-up-Skript hinzu, das route_vpn_gateway liest, damit der nächste Hop aus dem ausgehandelten Tunnel kommt. Oder verwenden Sie Add-VpnConnectionRoute mit einem nativen Windows-VPN-Profil, das das Präfix an diese Verbindung bindet.

Bietet der Server mehr an, als dieser Standort braucht, weist route-nopull die geschobenen Routen zurück und lässt die Tabelle völlig lokal. Das passt zu einem gemeinsamen Profil, dessen Benutzer keine Unternehmens-Standardroute erhalten dürfen.

Schritt vier: Überstehen Sie einen Kaltstart

Den Dienst zu starten, bevor der Netzwerk-Stack existiert, erzeugt einen fehlgeschlagenen Versuch und keine Wiederholung. Automatic (Delayed Start) oder eine Abhängigkeit vom Netzwerkdienst entfernt dieses Rennen. Wiederholen Sie dann den Starttest und prüfen Sie, dass ein zweiter Versuch nicht mehr nötig ist.

Routen- und Adapteränderungen brauchen Administratorrechte. Eine Autostart-Verknüpfung pro Benutzer hat sie nicht, sodass ein Skript, das aus einer erhöhten Shell funktioniert, bei der Anmeldung stillschweigend nichts tun kann. Planen Sie es als Aufgabe mit den höchsten Rechten, oder lassen Sie den Dienst die Änderung übernehmen. Testen Sie es dann als der Benutzer, der sich tatsächlich anmeldet.

Testen Sie die Abfolge, die Sie tatsächlich ausrollen, nicht die, die Sie von Hand auslösen können. Ein Kaltstart ist der einzige Test, der die Reihenfolge prüft.

Schritt fünf: Prüfen Sie ohne die GUI

Prüfen Sie nach einem Neustart und einer Anmeldung drei Dinge, ohne die GUI zu öffnen. Der Adapter soll eine Adresse halten,die Routentabelle soll das Standortpräfix mit dem Tunnel-Gateway als nächstem Hop zeigen, und ein Ping an eine Adresse auf der Gegenseite soll antworten. Jede Prüfung entspricht einem anderen Mechanismus aus den Schritten oben.

Wenn der Adapter nie erscheint, ist der Treiber der Verdächtige und nicht das Profil. Diese beiden Fehler sehen im Protokoll völlig verschieden aus, und nur einer von ihnen reagiert auf eine Neuinstallation der Software.