OpenVPN Access Server: Dämon neu starten oder Einstellung anwenden

Zwei Befehle werden für das, was wie dieselbe Aufgabe auf OpenVPN Access Server aussieht, eingefügt, und sie tun Unterschiedliches. systemctl restart openvpnas stoppt und startet das gesamte Produkt. sacli start bringt die internen Dienste hoch, die die gerade geänderte Konfiguration lesen. Die Wahl zwischen ihnen ist keine Geschmacksfrage: Sie hängt davon ab, was die Dokumentation der Einstellung selbst sagt, ob Ihre Sitzung über den Server läuft, den Sie gleich neu starten, und ob Sie überhaupt das richtige Produkt ansehen.

Zwei Ebenen, ein Dämon

Access Server läuft als eine einzige systemd-Unit, openvpnas, und dieser Dämon beaufsichtigt die internen Dienste hinter der Weboberfläche und die VPN-Listener. sacli ist die Kommandozeilenschnittstelle derselben Installation unter /usr/local/openvpn_as/scripts/sacli, und sie kann diese internen Komponenten starten, stoppen und abfragen, ohne die Unit zu ersetzen.

Deshalb gibt es beide Befehle. Ein Neustart des Dämons führt alles erneut aus, einschließlich des Prozesses, der Client-Tunnel beendet. sacli start bittet den bereits laufenden Dämon, seine Komponenten hochzubringen, damit sie die neue Konfiguration lesen, und genau das verlangen die meisten Eigenschaftsänderungen.

Bedingung eins: was die Dokumentation der Einstellung sagt

Lesen Sie die Seite der Einstellung, die Sie geändert haben, nicht die einer Einstellung vom letzten Monat. Auf eine über ConfigPut geschriebene Eigenschaft folgt normalerweise sacli start, und dieses Paar ist der dokumentierte Anwendungsschritt. Eine Änderung am Verhalten auf Listener-Ebene oder alles, was die Seite als einen Dienstneustart erfordernd beschreibt, ist die Klasse, bei der der Neustart der Unit richtig ist.

Die beiden Befehle sind nicht austauschbar, deshalb ist das Fehlerbild beim Raten asymmetrisch. sacli start zu verwenden, wenn ein vollständiger Neustart nötig war, lässt einen alten Prozess weiter mit der vorherigen Konfiguration dienen, was so aussieht, als sei die Einstellung ignoriert worden. Ein vollständiger Neustart, wo sacli start gereicht hätte, wirft jeden verbundenen Client ohne Grund hinaus.

Bedingung zwei: liegt Ihre Sitzung im Tunnel

Wenn Sie Access Server über das VPN administrieren, das er bereitstellt, entfernt der Neustart die Verbindung, die Ihre Shell trägt. Der Befehl kann erst fertig werden, nachdem Ihre Sitzung stirbt, sodass Sie raten müssen, ob er gewirkt hat. sacli start kann eine Sitzung aus demselben Grund kurz unterbrechen, wenn die neu gestartete Komponente Ihren Datenverkehr verarbeitet.

Halten Sie vor beiden Befehlen einen Out-of-Band-Weg offen: eine Provider-Konsole, eine Hypervisor-Konsole oder eine serielle Sitzung. Diese Bedingung entscheidet, wann Sie den Befehl ausführen, nicht welchen, und sie ist es, die aus einer Änderung von zwei Minuten einen Ausfallbericht macht.

Bedingung drei: ist das das Produkt, für das Sie es halten

Access Server ist nicht Community OpenVPN. Eine Community-Installation betreibt Units wie openvpn@server oder openvpn-client@profile, mit Konfiguration in /etc/openvpn, und sacli gibt es dort nicht. Jede Unit mit openvpn im Namen auf einem gemeinsamen Host neu zu starten, ist der Weg, auf dem unabhängige Tunnel gemeinsam ausfallen.

Stellen Sie vor jeder Berührung fest: systemctl status openvpnas --no-pager beantwortet, ob Access Server das Laufende ist, sacli status listet seine internen Komponenten, und systemctl list-units --type=service listet Units, deren Namen openvpn enthalten. Zeigt der letzte Befehl Units mit Profilnamen, sind Sie beim Community-Produkt, und der Rest hiervon gilt für Sie nicht.

Anwenden, dann über active hinaus prüfen

Eine Unit, die active meldet, hat einen laufenden Prozess, was nicht dasselbe ist wie ein funktionierender Authentifizierungspfad. Prüfen Sie nach dem Anwendungsschritt sacli status für die Komponenten, die Sie neu starten erwartet haben, bestätigen Sie, dass der Wert mit sacli ConfigQuery gespeichert wurde, und führen Sie dann eine begrenzte Client-Anmeldung mit einem Testkonto durch.

Schließen Sie mit etwas auf Anwendungsebene ab: Erreichen Sie eine private Ressource durch den Tunnel, nicht nur einen Ping an die öffentliche Adresse des Servers. Ein Handshake, der gelingt, während die gepushte Route oder die DNS-Einstellung falsch ist, besteht jede Dienstprüfung und lässt die Person, die das Problem gemeldet hat, trotzdem scheitern.

die Dienstverwaltungs-Anleitung des Anbieters ist die Referenz dafür, welche Operationen zu sacli gehören, und es lohnt sich, sie zu öffnen, bevor Sie entscheiden, dass ein Neustart die sichere Option ist.

Die Entscheidung in einem Durchgang

Gehen Sie diese vier Zeilen durch und halten Sie bei der ersten an, die passt:

• Die Einstellungsseite nennt sacli start, oder Sie haben gerade ConfigPut ausgeführt: verwenden Sie sacli start.
• Die Seite verlangt einen Neustart, oder die Änderung betrifft Listener statt Eigenschaften: verwenden Sie systemctl restart openvpnas.
• Ihre Shell kommt über diesen Server: sorgen Sie zuerst für Konsolenzugang und führen Sie dann den Befehl aus, den die beiden Zeilen oben gewählt haben.
• Prüfung: sacli status, ConfigQuery für den Wert, eine Anmeldung, eine private Ressource. Der Dienststatus allein ist nicht die Ziellinie.

Zwei dieser Zeilen sind Prüfungen und zwei sind Handlungen, und das ist der Sinn der Reihenfolge. Können Sie die Produktfrage nicht beantworten, halten Sie an: Der Befehl, den Sie ausführen wollten, gehört zu einer anderen Installation, und der Tunnel, den Sie abschalten, wird nicht der gemeinte sein.