RRAS startet vor dem OpenVPN-Tunnel beim Booten

Der Server startet neu, OpenVPN startet, und RRAS kommt hoch, während der Adapter oder die Route, von denen es abhängt, noch fehlt. Ein manueller Neustart von RRAS eine Minute später behebt das, wodurch das Problem gelöst wirkt und das eigentliche verborgen bleibt. Hier werden zwei verschiedene Bedingungen verwechselt: Der vorausgesetzte Dienst läuft, und die Netzwerkressource, die RRAS tatsächlich braucht, ist nutzbar geworden. Eine Windows-Dienstabhängigkeit kann die erste Bedingung ausdrücken und niemals die zweite, daher bringt eine Abhängigkeit ohne definierte Ressource einen ordentlicheren Start und denselben Fehler.

Wie das Symptom bei einem Kaltstart aussieht

Das Erkennungszeichen ist der Unterschied zwischen Kaltstart und Neustart. Bei einem Kaltstart meldet RRAS, dass es läuft, während der Tunneladapter fehlt, die Route fehlt oder die Peer-Adresse noch nicht aufgelöst wird. Ein manueller Neustart gelingt dann, weil die Ressource zu diesem Zeitpunkt existiert und der Dienst einfach eine Welt neu liest, die er eine Minute zuvor nicht sehen konnte. Das Dienstprotokoll zeigt in beiden Fällen einen sauberen Start, weshalb die Ereignisanzeige allein dies selten erklärt.

Erfassen Sie beide Zustände, bevor Sie etwas ändern: was RRAS beim Start meldet und was in dem Moment existiert, in dem der manuelle Neustart gelingt. Sind diese beiden Beobachtungen identisch, ist die Startreihenfolge nicht Ihre Erklärung, und eine Abhängigkeit hilft nicht. Der Vergleich kostet zehn Minuten und spart eine Woche Rätselraten.

Eine Abhängigkeit, die aufgrund von „es funktioniert nach einem Neustart“ hinzugefügt wird, verzögert denselben Fehler nur um die Zeit, die der vorausgesetzte Dienst braucht, um RUNNING zu melden. Sie macht den Start auch schwerer nachvollziehbar, weil die Reihenfolgebedingung jetzt wie eine Erklärung aussieht. Fragen Sie, welches Objekt die Abhängigkeit garantiert und ob dieses Objekt dasjenige ist, das RRAS nicht sehen konnte.

Benennen Sie die Ressource, nicht nur den Dienst

Schreiben Sie die konkrete Sache auf, die fehlt. Es kann ein Tunneladapter mit einer Adresse sein, eine Route zu einem Peer-Subnetz, eine DNS-Antwort oder ein Zertifikat, das noch bereitgestellt wird. „Der VPN-Dienst läuft“ ist keine Ressourcenbeschreibung, und ein grünes Symbol in einem Client auch nicht. Solange Sie das Objekt und einen Befehl, der es zeigt, nicht benennen können, haben Sie die Bedingung nicht definiert, auf die Sie warten wollen.

Stellen Sie auch fest, wie diese OpenVPN-Instanz gestartet wird. Ein GUI-verwalteter Tunnel und ein dienstverwalteter Tunnel haben unterschiedliche Startlebenszyklen, und der Dienstname muss von der Maschine vor Ihnen kommen, nicht aus einem Beispiel für einen anderen Installer. Zählen Sie die Kandidaten auf, statt einem erinnerten Namen zu vertrauen.

Get-Service | Where-Object Name -match 'vpn|openvpn' | Select-Object Name, Status, StartType

Lesen Sie die Abhängigkeitskette, bevor Sie etwas hinzufügen

Der Dienststeuerungs-Manager meldet Zustände wie START_PENDING und RUNNING, und die SERVICE_STATUS reference definiert genau, was jedes Feld bedeutet. Keiner dieser Zustände verspricht, dass ein Peer, ein DNS-Name oder eine nachgelagerte Anwendung erreichbar ist. Diese Lücke ist der ganze Grund, warum dieser Fehler eine korrekt konfigurierte Abhängigkeit überlebt.

Get-Service -Name RemoteAccess | Select-Object Status, StartType
sc.exe qc RemoteAccess
Get-Service -Name RemoteAccess | Select-Object -ExpandProperty DependentServices

Die Zeile DEPENDENCIES aus sc.exe qc ist die Liste, die Sie erhalten müssen, weil sc.exe config RemoteAccess depend= die gesamte Liste ersetzt, statt sie zu ergänzen. Das Weglassen einer unabhängigen Voraussetzung beim Hinzufügen eines VPN-Dienstes erzeugt einen zweiten Fehler, der bei einem anderen Start auftritt und weit schwerer zu diagnostizieren ist als der ursprüngliche. Kopieren Sie die vorhandene Liste in Ihren Änderungsdatensatz, bevor Sie sie anfassen.

Abhängigkeiten ändern auch das Verhalten beim Herunterfahren, weil das Beenden einer Voraussetzung die Dienste beendet, die davon abhängen. Prüfen Sie, was bei der Wartung passiert, bevor Sie RRAS mit etwas verbinden, das häufig neu startet.

Machen Sie den Neustart von einer Bedingung abhängig, nicht von einem Timer

Eine feste Wartezeit geht davon aus, dass der Tunnel innerhalb dieses Fensters immer bereit ist, und genau diese Annahme scheitert beim Start, wenn ein Zertifikat langsam ist oder eine Verbindung ausgefallen ist. Prüfen Sie die Ressource selbst, mit einer Frist, und lassen Sie die Prüfung entscheiden, ob überhaupt ein Neustart nötig ist.

Get-NetAdapter | Where-Object Status -eq 'Up'
Get-NetRoute -DestinationPrefix 0.0.0.0/0
Get-WinEvent -LogName System -MaxEvents 40 |
  Where-Object ProviderName -eq 'Service Control Manager'

Eine geplante Aufgabe beim Start, die diese Prüfungen ausführt und RRAS nur dann neu startet, wenn Adapter oder Route noch fehlen, ist begrenzt, prüfbar und leicht zu entfernen. Die Alternative, RRAS bei jeder Neuverbindung neu zu starten, unterbricht gesunde Sitzungen und macht aus einer instabilen Verbindung eine Neustartschleife. Diese Schleife ist schlimmer als der ursprüngliche Fehler, weil sie nun Nutzer trifft, bei denen alles lief.

Geben Sie der Prüfung eine maximale Wartezeit, die dazu passt, wie lange der Tunnel auf Ihrer Hardware vernünftigerweise braucht, und lassen Sie die Aufgabe mit einem Status ungleich null enden, wenn sie aufgibt. Eine stille Aufgabe, die einfach aufhört zu versuchen, ist von einer erfolgreichen nicht zu unterscheiden.

Protokollieren Sie den Übergang, damit der nächste Start sich selbst erklärt

Erfassen Sie drei Zeitstempel in derselben Zeile: wann der abhängige Dienst RUNNING erreichte, wann die benötigte Ressource erschien und wann RRAS sie schließlich akzeptierte. Diese eine Zeile beantwortet die Frage, die der nächste Ingenieur stellen wird, und sie zu erzeugen kostet fast nichts. Ohne sie beginnt die nächste Untersuchung beim selben Rätselraten wie diese.

Stoppen Sie die Automatisierung nach einer festgelegten Anzahl von Versuchen und melden Sie einen Fehler, statt ewig zu wiederholen. Ein Start, der mit einer klaren Meldung „Ressource ist nie erschienen“ endet, ist mehr wert als einer, der einen Dienst im Dunkeln weiter neu startet. Wenn diese Meldung auftaucht, ist der Ressourcenname, den Sie im zweiten Abschnitt notiert haben, das, wonach die nächste Person suchen wird.