Ausgesperrt vom VPN-Server: Halten Sie einen zweiten Weg offen
Ein defekter Tunnel sollte Ihnen nicht auch noch die Möglichkeit nehmen, den Server zu reparieren. Planen, testen und prüfen Sie einen unabhängigen Verwaltungsweg, bevor Sie ihn brauchen.
Sie öffnen die Konsole, ändern eine Firewall-Regel, und der Tunnel, über den Sie verbunden waren, verschwindet. Die Änderung war richtig, das Neuladen nicht, und jetzt ist der einzige Weg zurück in die Maschine der, den Sie gerade zerstört haben. Ein zweiter Weg hinein ist eine Designentscheidung, und er muss vor dem Ausfall existieren, nicht währenddessen.
Gehen Sie durch, was Ihnen noch bleibt
Beginnen Sie am Konsolenbildschirm vor Ihnen und listen Sie die Wege auf, die nicht vom Tunnel abhängen. Eine Web-Konsole des Anbieters mit einer seriellen Sitzung oder VNC ist einer. Eine Verwaltungsschnittstelle in einem getrennten Netz ist ein weiterer. Physischer Zugang ist ein dritter, und genau sein Fehlen entdecken Menschen im schlechtesten Moment.
| Path | Depends on | Usually fails when |
|---|---|---|
| Provider console | Account access and the provider's own API | Credentials live in a wiki only reachable over the tunnel |
| Management subnet | A second interface and its own routing | The bad change was a global route or firewall policy |
| Second tunnel | A different listener, port and credentials | Both listeners were changed in the same edit |
| Physical or local console | Being in the building | Nobody has been in the building for a year |
Lesen Sie die dritte Spalte als Fehlerliste und nicht als Abstraktion. Zwei dieser Wege versagen meist aus demselben Grund. Die Tabelle ist die Art, wie Sie das bemerken, bevor ein Ausfall es Ihnen erklärt.
Unabhängigkeit ist eine Frage der Abhängigkeiten
Ein Wiederherstellungskonto ist nicht unabhängig, wenn sein Passwort in einem Dienst liegt, den Sie über den Tunnel erreichen. Ein zweites VPN auf demselben Host, demselben Port und derselben Firewall-Richtlinie ist ebenfalls nicht unabhängig, denn die Änderung, die den ersten brach, bricht beide.
Gehen Sie die Kette hinunter und benennen Sie, was jeder Schritt braucht. Netzwerkerreichbarkeit, Namensauflösung, eine Authentifizierungsquelle und der Verwaltungsdienst selbst sind vier getrennte Abhängigkeiten, und ein Weg, der eine davon teilt, erbt diesen Fehler.
Der nie getestete Weg verdient ein eigenes Misstrauen. Eine Konsole, die monatelang nicht geöffnet wurde, kann eine Passwortzurücksetzung per E-Mail verlangen, und dieses Postfach kann auf der Maschine liegen, die Sie nicht erreichen. Testen Sie den Weg, solange alles läuft, und Sie finden das an einem ruhigen Nachmittag.
Nutzen Sie den zweiten Weg für eine kontrollierte Änderung
Nehmen Sie von der Konsole aus einen Snapshot oder kopieren Sie die Konfiguration, die Sie gleich bearbeiten. Ändern Sie eine Sache. Laden Sie den Dienst neu und lesen Sie das Ergebnis, bevor Sie etwas anderes anfassen, denn zwei Änderungen auf einmal machen aus einer Rettung ein Experiment.
Halten Sie die Rettungssitzung offen, während Sie das tun. Der ganze Wert des zweiten Wegs liegt darin, dass er das überlebt, was Sie ändern; wer sie zuerst schließt, entfernt die einzige Eigenschaft, die sie nützlich machte.
Prüfen Sie vom Rettungsweg aus, nicht aus dem Gedächtnis
Die entscheidende Prüfung ist, ob der normale Weg zurückkommt, und die Rettungssitzung ist der Ort, an dem Sie das der Reihe nach bestätigen:
systemctl status openvpn-server@server --no-pager ss -lntup | grep -E ':(1194|443)\b' nft list ruleset | sed -n '1,40p' journalctl -u openvpn-server@server --since '-10 min' --no-pager | tail -n 30
Lesen Sie zuerst den Dienststatus, dann den Listener, dann die Regeln, dann das Journal. Ein Dienst, der ohne Listener läuft, deutet auf die Dienstkonfiguration, während ein Listener ohne erreichbare Regeln auf die Filterung deutet. Die Reihenfolge zählt, weil jeder Schritt den nächsten einengt, und ein Sprung ins Journal bedeutet meist, Fehler zu lesen, die das Symptom und nicht die Ursache beschreiben.
Die systemctl-Dokumentation behandelt das hier verwendete Status- und Neustartverhalten, einschließlich der Frage, wie ein fehlgeschlagenes Neuladen den vorherigen Prozess weiterlaufen lässt. Eine stimmige Revision wiederherzustellen ist besser als wiederholtes Neuverbinden von einem Client, der den Server nicht reparieren kann. Wenn die vor der Änderung festgelegte Rücksetzbedingung erfüllt ist, stellen Sie wieder her und hören Sie auf.
Halten Sie das Verzeichnis aktuell
Überprüfen Sie die Zugangsliste, wenn sich Menschen oder Infrastruktur ändern. Testen Sie den Rettungsweg, solange alles läuft. Ziehen Sie die Konten zurück, die seit der letzten Umorganisation niemand benutzt hat. Zwei veraltete Konten und ein abgelaufenes Zertifikat sind eine kleine Aufräumaktion an einem Dienstag und ein Ausfall an einem Sonntag.
Halten Sie fest, wer welchen Weg nutzen darf, was er erlaubt und wie die Zugangsdaten gewechselt werden. Ein Rettungsweg ohne Verantwortlichen wird zu einem vergessenen Eingang, was eine andere Art von Fehler ist als ausgesperrt zu sein.