SSH lauscht nach dem Neustart nicht: Die VPN-Adresse kommt zu spät

Sie binden SSH während der Einrichtung an die Tunneladresse, es funktioniert, und nach dem nächsten Neustart kann sich niemand anmelden, bis jemand den Dienst von Hand neu startet. Die Zugangsdaten sind nicht das Problem. Der Daemon hat den Kernel um eine Adresse gebeten, die es noch nicht gab, die Bindung schlug fehl, und die Meldung rauschte im Startprotokoll vorbei. Was wie ein Authentifizierungsproblem aussieht, ist ein Problem der Startreihenfolge.

Was der Bindungsfehler tatsächlich sagt

Ein lauschender Socket muss auf einer Adresse erstellt werden, die in diesem Moment existiert. Wenn die VPN-Schnittstelle später erscheint, hat ein Daemon, der nur an die Tunneladresse binden soll, nichts, woran er sich anhängen kann. Die Konfiguration bleibt syntaktisch gültig; die Umgebung war einfach nicht bereit. Ein Dienst, der seit einem manuellen Start läuft, durchläuft den Startpfad nie, weshalb der Fehler erst beim nächsten Neustart auftritt. Vergleichen Sie den Zeitstempel des fehlgeschlagenen Bindens mit dem Zeitstempel der Adresszuweisung, und die Reihenfolge wird offensichtlich.

Konfigurationsgültigkeit und Laufzeitbereitschaft sind getrennte Eigenschaften. Prüfen Sie beides, denn eine davon schlägt fehl, ohne etwas zu sagen.

Welcher Prozess den Port besitzt

Der Daemon ist nicht immer die Komponente, die den Listener erstellt. Socket-Aktivierung verlagert diese Verantwortung auf eine Unit, und ein Neustart des Daemons ändert dann nichts.

ss -ltnp 'sport = :22'
systemctl cat ssh.socket

Die Socket-Auflistung zeigt, welcher Prozess den Port hält und auf welcher Adresse, während der Unit-Dump zeigt, ob überhaupt eine Socket-Unit existiert. Wenn Aktivierung im Spiel ist, gehört die Adresse in die Socket-Unit, und die Daemon-Datei ist nicht maßgeblich. Lesen Sie das Startprotokoll für den echten Bindungsfehler, statt ihn aus dem Symptom abzuleiten. Eine fehlende Socket-Unit bedeutet einfach die klassische Anordnung, bei der der Daemon direkt bindet.

Machen Sie Bereitschaft explizit, nicht zu einem Schlaf

Eine feste Verzögerung ist eine Vermutung, die schnelle Hardware und langsame Netzwerke gleich behandelt. Drücken Sie stattdessen die Abhängigkeit aus: Warten Sie auf die Adresse, dann starten Sie.

ip -4 addr show dev tun0
systemctl edit ssh.service

Fügen Sie einen ExecStartPre-Befehl hinzu, der sich wiederholt, bis die Adresse erscheint, oder ordnen Sie die Unit nach dem spezifischen Netzwerkziel an, dem die Schnittstelle gehört. Beide Ansätze halten die Abhängigkeit an einer Stelle fest, die der nächste Administrator lesen kann. Die Schleife braucht eine Zeitüberschreitung, sonst hinterlässt ein fehlgeschlagenes VPN eine Unit, die hängt, statt einen Fehler zu melden. Bestätigen Sie dann, dass der Daemon die Tunneladresse bindet, während die gewöhnliche Schnittstelle weiterhin Ihren Filterregeln unterliegt.

Testen Sie einen sauberen Start und eine erneute Verbindung

Ein manueller Neustart, nachdem alles online ist, beweist nichts über die Startreihenfolge. Starten Sie die Maschine neu, wobei der Tunnel so konfiguriert ist, dass er automatisch hochkommt, und beobachten Sie, ob der Listener ohne Eingriff erscheint.

systemctl status ssh.service
ss -ltnp 'sport = :22'

Trennen Sie dann den Tunnel und stellen Sie ihn wieder her, denn eine erneute Verbindung kann die Adresse ändern, und eine fest codierte Bindung wird ihr nicht folgen. Halten Sie während der Tests einen außerbandigen Wiederherstellungsweg bereit, damit eine schlechte Reihenfolgeänderung Sie nicht vom Host aussperren kann.

Das Erfolgskriterium ist ein Listener, der unter seiner dokumentierten Abhängigkeit erscheint, nicht einer, dessen Neustart jemandem noch einfiel.