Warum nc -uz nicht beweisen kann, dass ein OpenVPN-Server bereit ist

Der Aufruf von nc -uz gegen einen OpenVPN Server misst fast nichts, und das OpenBSD-Handbuch sagt es in seinen Einschränkungen: UDP-Scans in diesem Modus melden Erfolg, unabhängig davon, ob etwas lauscht. Der Exit-Status spiegelt das lokale Senden wider, nicht den entfernten Zustand, daher hält ein Supervisor, der ihm vertraut, einen toten Server als gesund markiert, solange die Prozesstabelle plausibel aussieht. Ein Ersatz beginnt mit der Entscheidung, welche Frage die Prüfung beantworten soll, denn Prozess, Listener, Authentifizierung und Erreichbarkeit der Anwendung sind vier verschiedene Beobachtungen. Eine Prüfung, die eine davon benennt, ist nützlich; eine Prüfung, die alle vier impliziert, ist eine Last.

Was eine UDP-Prüfung beobachten kann und was nicht

nc -uz sendet ein Datagramm und beendet sich, und der zurückgegebene Status beschreibt das lokale Senden. Ein geschlossener Port kann mit ICMP port unreachable antworten, aber das dokumentierte Verhalten dieses Scanmodus macht daraus keinen Fehler, und ein gefilterter Port liefert überhaupt keine Antwort. Stille und Erfolg bedeuten für den Aufrufer also dasselbe.

Damit ist die Prüfung ein Test des lokalen Stacks, nicht des Servers. Sie belegt nicht, dass der Host erreichbar ist, dass der Port gebunden ist, dass der OpenVPN-Prozess läuft oder dass sich ein Client authentifizieren könnte. Ein TCP-Verbindungstest ist stärker, weil der Handshake eine eindeutige Antwort gibt, aber nur wenn die Bereitstellung tatsächlich auf TCP lauscht. Die Prüfung auf TCP mit derselben Nummer umzustellen, testet einen Listener, den es vielleicht nicht gibt, und gegen einen reinen UDP-Server lässt es einen gesunden Dienst scheitern.

Die Prüfung an den konfigurierten Transport anzupassen, kommt vor dem Vertrauen in eines der beiden Ergebnisse. Eine UDP-Bereitstellung braucht ein anderes Signal, kein anderes Protokoll.

Drei Aufrufer, drei verschiedene Fragen

Bereitschaft hängt davon ab, wer fragt. Ein Dienstmanager, der einen abgestürzten Prozess neu startet, muss wissen, dass die Instanz gestartet ist und ihren Listener gebunden hat. Ein Load Balancer muss wissen, dass ein jetzt eintreffender Client angenommen würde. Ein Überwachungssystem muss wissen, dass der Pfad aus einem echten Netzwerk noch eine Sitzung zu einer erlaubten Ressource trägt.

Das ist nicht dieselbe Prüfung, und eine einzelne Prüfung kann nicht alle drei ehrlich abdecken. Wählen Sie zuerst den Aufrufer und dann den Beleg.

Bauen Sie die Prüfung aus der aktuellen Instanz

OpenVPN schreibt eine Startzeile, wenn eine Instanz die Initialisierung abschließt, und diese Zeile ist ein nützlicher Beleg für den lokalen Start. Lesen Sie sie aus dem aktuellen Start statt aus dem Ende einer fortgeschriebenen Datei, denn ein Erfolg von letzter Woche liest sich genau wie ein Erfolg von vor einer Minute. Ein Server kann die Initialisierung auch abschließen, bevor sich je ein Client verbunden hat, daher sagt die Zeile nichts über die Authentifizierung.

Für eine Startprüfung kombinieren Sie den Prozesszustand mit aktuellem Log-Beleg und einem Listener, der zum konfigurierten Transport passt. Die Prüfung sollte fehlschlagen, wenn der Prozess läuft, aber die Initialisierung nicht abgeschlossen hat, was bedeutet, dass die Log-Abfrage auf diesen Boot und diese Unit begrenzt sein muss.

systemctl is-active openvpn@server
sudo journalctl -u openvpn@server -b --no-pager | grep "Initialization Sequence Completed"
ss -lunp | grep 1194

Drei Ausgaben, drei Aussagen: die Unit ist aktiv, dieser Boot erzeugte die Initialisierungszeile, und etwas hält den UDP-Port. Keine davon sagt, dass ein Client sich verbinden kann. Halten Sie sie auf der Statusseite getrennt, damit ein Vorfall nicht zu einem einzigen grünen Punkt zusammenfällt.

Brechen Sie es absichtlich und beobachten Sie die Prüfung

Eine Prüfung ist erst vertrauenswürdig, wenn Sie sie haben scheitern sehen. Stoppen Sie den Server, führen Sie die Prüfung aus und bestätigen Sie das erwartete Ergebnis. Starten Sie ihn dann erneut und bestätigen Sie, dass sich die Prüfung ohne weitere Änderung erholt.

sudo systemctl stop openvpn@server
nc -uz 203.0.113.10 1194; echo "exit=$?"
ss -lunp | grep 1194
sudo systemctl start openvpn@server
ss -lunp | grep 1194

Lesen Sie den Block Zeile für Zeile. Der Netcat-Befehl gibt exit=0 aus, während nichts gebunden ist, und das ist das ganze Problem in einer Zeile. Das erste ss gibt nichts aus, der Neustart gelingt, und das zweite ss zeigt wieder den Listener. Wenn Ihre Prüfung gegen den gestoppten Server besteht, misst sie den lokalen Stack und sonst nichts.

Der umgekehrte Fehler zählt ebenso. Eine Prüfung, die gegen einen gesunden Server fehlschlägt, verursacht Neustarts, die nie nötig waren, und eine Neustartschleife ist selbst ein Ausfall. Testen Sie beide Richtungen, bevor Sie die Prüfung mit etwas verbinden, das darauf reagieren kann.

Was die Statuszeile sagen sollte

Halten Sie fest, welche Grenze jede Prüfung abdeckt: Prozess, Listener, Authentifizierung oder Anwendung. Eine Prüfung deckt selten mehr als eine ab, und eine Statusseite, die sie zu „up“ verdichtet, verbirgt den Unterschied, der während eines Vorfalls zählt. Verwenden Sie für den Netzwerkpfad einen echten Client mit einer eigenen Identität, lassen Sie ihn den Handshake und eine harmlose erlaubte Operation abschließen und trennen Sie ihn dann. Das übt Steuerkanal, Authentifizierungsrichtlinie und Listener in einem Schritt.

Halten Sie diese Identität von echten Nutzern getrennt und geben Sie ihr die minimalen Berechtigungen, die die Prüfung braucht. Eine Bereitschaftsprüfung mit breitem Zugriff ist eine neue Angriffsfläche, die aus Bequemlichkeit hinzugefügt wurde. Rotieren Sie ihre Anmeldedaten wie bei jedem anderen Konto, denn eine Prüfung, die aufhört zu authentifizieren, sieht genau aus wie ein Server, der aufgehört hat, Clients anzunehmen.

Benennen Sie die Grenze im Alarmtext, damit der erste Responder weiß, ob er die Unit, den Socket, das Zertifikat oder die Route ansehen soll. Einer Prüfung, die nicht sagen kann, was sie belegt hat, wird aus dem falschen Grund vertraut, und so hat die Netcat-Prüfung überhaupt überlebt.