Wiederherstellung des VPN-Servers nach dem Neustart testen: Was zuerst zu prüfen ist

Starten Sie den Server neu, während niemand angemeldet ist, und verbinden Sie sich dann aus einem Netz, das Sie nicht kontrollieren. Dieser eine Test beantwortet, ob die Wiederherstellung echt ist, denn ein Tunnel, der erst funktioniert, nachdem jemand einen Befehl von Hand ausführt, ist keine Wiederherstellung, sondern eine Reparatur. Die meisten Prüfungen enden zu früh: Der Dienst zeigt sich als aktiv, die Schnittstelle kommt hoch, und die Seite lädt trotzdem nicht. Die Lücke liegt fast immer in der Persistenz der Teile rund um den Tunnel, nicht im Tunnelbefehl selbst.

Vier Verantwortliche, vier verschiedene Tests

Benennen Sie vor dem Neustart, was den Tunnel zurückbringen soll. Der Test, den Sie ausführen, und die Korrektur, die Sie anwenden, hängen beide von dieser Antwort ab, und es gibt vier übliche Verantwortliche: eine systemd-Unit für den VPN-Daemon, eine wg-quick-Instanz-Unit für eine WireGuard-Schnittstelle, eine Container-Runtime oder ein Netzwerkmanager-Profil. Wenn Sie den Verantwortlichen nicht benennen können, halten Sie an und finden ihn, denn ein Neustarttest ohne erwarteten Startpfad sagt Ihnen nur, dass etwas passiert ist.

Jeder Verantwortliche hält seine Konfiguration an einer anderen Stelle. Ein systemd-verwalteter OpenVPN-Server liest seine Konfiguration beim Start, also läuft das, was beim Booten in der Datei steht. Eine wg-quick-Schnittstelle leitet ihre Adressen, Routen und DNS aus derselben Datei ab, was bedeutet, dass eine Schnittstelle, die von Hand aus einer Shell hochgezogen und nie als Unit aktiviert wurde, nicht zurückkehrt. Ein Container bringt seinen Einstiegspunkt zurück, aber keine Firewall-Änderungen des Hosts, es sei denn, diese liegen außerhalb des Containers.

Zuerst die Baseline, sonst bedeutet das Ergebnis nichts

Erfassen Sie den funktionierenden Zustand, solange er funktioniert: Adressen auf dem Tunnel, Routen für das Client-Subnetz, NAT- oder Weiterleitungsregeln, den lauschenden Socket und das Weiterleitungs-sysctl. ip addr show wg0, ip route, nft list ruleset oder iptables-save, ss -lunp und sysctl net.ipv4.ip_forward reichen auf den meisten Hosts aus.

Halten Sie fest, wie der Dienst zum Starten konfiguriert ist, nicht nur, dass er läuft. systemctl is-enabled wg-quick@wg0 und systemctl is-active wg-quick@wg0 beantworten unterschiedliche Fragen, und der aktivierte Zustand ist der, der beim Booten zählt, wie in systemctl(1) beschrieben. Prüfen Sie bei OpenVPN, welche Vorlage der Host verwendet, da openvpn@server und openvpn-server@server unterschiedliche Units mit unterschiedlichen Standardwerten sind.

Den Neustart ausführen und den ersten Fehler lesen

Starten Sie bewusst neu, in einem von Ihnen gewählten Zeitfenster, mit einer geöffneten Konsole oder einem Out-of-Band-Zugang. Beobachten Sie die Reihenfolge der Ereignisse statt den Endzustand: Host erreichbar, Unit aktiviert, Schnittstelle vorhanden, Routen installiert, Firewallregeln vorhanden, Listener gebunden, Client akzeptiert. Der erste Schritt, der nicht geschieht, ist der Befund; alles danach ist Rauschen.

Ein Daemon kann aktiv sein, während der Tunnel unbrauchbar ist, und das ist der häufigste falsche Erfolg. Der Start kann abgeschlossen sein, bevor das Netz online ist, wenn die Unit nur auf network.target statt auf network-online.target wartet. Referenzierte Dateien wie Zertifikate, Schlüssel oder eine CRL können in diesem Moment unlesbar sein, weil ein Mount oder ein Geheimnispfad noch nicht bereit ist. Keines der beiden Probleme zeigt sich in systemctl status, bis Sie das Journal der Unit lesen.

Testen Sie von außerhalb des Hosts. Ein Client im selben LAN kann über eine Route erfolgreich sein, die kein entfernter Client je nutzen würde, und eine SSH-Sitzung zur Maschine beweist nichts über den Tunnel. Verbinden Sie sich, lösen Sie einen internen Namen auf, erreichen Sie die private Ressource und verbinden Sie sich dann einmal erneut, um zu bestätigen, dass Sperrstatus und Schlüssel weiterhin gelten.

Die drei Bedingungen, die Ihre Korrektur bestimmen

Wenn der Tunnel zurückkehrt, aber Clients nichts erreichen, liegt der Fehler in der Routenführung oder NAT-Persistenz. Wenn Clients nicht einmal einen Handshake abschließen können, liegt der Fehler in der Schnittstelle oder im Authentifizierungsmaterial. Wenn der Dienst nie startet, liegt der Fehler in der Unit-Datei oder ihren Abhängigkeiten. Diese drei Zweige führen zu unterschiedlichen Korrekturen, und deshalb kostet ein blinder Neustart ohne Baseline mehr Zeit, als er spart.

Nehmen Sie die Korrektur dort vor, wo die Einstellung beheimatet ist. Legen Sie Weiterleitung in ein sysctl-Drop-in, legen Sie NAT-Regeln in das Regelset, das beim Booten geladen wird, aktivieren Sie die Unit, statt sie zu starten, und halten Sie Geheimnisse auf einem Pfad, der vor dem Start der Unit existiert. Ein Sleep in der Unit versteckt eine Abhängigkeit, statt sie zu deklarieren.

Das Ergebnis im Runbook festhalten

Schreiben Sie auf, was von selbst zurückkam, was Sie starten mussten und wie lange die Lücke dauerte. Fügen Sie die genauen Befehle hinzu, mit denen Sie geprüft haben, damit die nächste Person den Test wiederholt, statt einen zu erfinden. Wenn ein Schritt einen manuellen Befehl brauchte, gehört dieser Befehl in die Konfiguration, nicht als dauerhafter Schritt ins Runbook.

Planen Sie den nächsten Test dann für nach der nächsten Änderung am Netzwerk-Stack des Hosts, nicht für ein Kalenderdatum in sechs Monaten. Der Fehlermodus, vor dem Sie sich schützen, ist ein temporärer Befehl, der sich dauerhaft anfühlte, und diese tauchen genau dann auf, wenn jemand Firewallregeln bearbeitet oder einen Dienst in eine neue Unit verschiebt.