SSH-ServerAliveInterval über ein VPN: Welche Seite sendet die Probe?

Die meisten Ratschläge zu SSH-Keepalives enden bei »fügen Sie ServerAliveInterval 30 hinzu« und lassen die nützlichen Teile weg. Das Schlüsselwort ist ein Timer auf der Clientseite, der nur auslöst, wenn der Kanal still war, er zählt unbeantwortete Probes statt Sekunden, und er lebt in einer Datei, in der der erste passende Wert gewinnt. Machen Sie bei diesen drei Eigenschaften einen Fehler, und eine gesunde VPN-Sitzung bricht trotzdem ab, während eine tote hängen bleibt.

Die beiden Richtungen gehören zu verschiedenen Daemons

ServerAliveInterval wird von Ihrem SSH-Client gelesen. ClientAliveInterval wird von sshd auf der Gegenseite gelesen und prüft in die andere Richtung, vom Server zum Client. Sie sind keine Aliasnamen und arbeiten nicht zusammen, das Setzen des einen hat also keine Wirkung auf das Verhalten der anderen Seite. Sie zu verwechseln ist der übliche Grund, warum eine Korrektur auf einem Host zu wirken scheint und auf dem nächsten nicht.

Beide akzeptieren null. Bei null sendet der Client überhaupt nichts, und auf der Serverseite deaktiviert ein ClientAliveCountMax von null die Trennung, die sonst auf unbeantwortete Prüfungen folgen würde.

Was eine Probe beweist und was nicht

Wenn das eingestellte Intervall verstreicht, ohne dass Daten vom Server eintreffen, sendet der Client eine kleine Anfrage über den bestehenden verschlüsselten Kanal und wartet auf eine Antwort. ServerAliveCountMax legt fest, wie viele davon unbeantwortet bleiben dürfen, bevor die Sitzung abgebaut wird. Mit einem Intervall von 60 und einem Zähler von 3 gibt der Client nach etwa drei Minuten Stille auf, und diese Zahl ist eine Eigenschaft Ihrer Konfiguration, kein Netzwerkstandard. Lassen Sie das Intervall auf dem Standardwert 0, wird nie eine Probe gesendet, weshalb ein Standardclient unbegrenzt auf einer toten Verbindung sitzen kann.

Da der Austausch im SSH-Transport läuft, beweist eine Antwort, dass der SSH-Prozess der Gegenseite noch liest und schreibt. Über das Programm, das Sie in dieser Sitzung gestartet haben, sagt sie nichts: Ein Datenbankclient, ein weitergeleiteter Port oder ein lang laufendes Skript können hängen, während der Transport fröhlich Probes beantwortet.

TCPKeepAlive ist ein separater Mechanismus eine Schicht tiefer. Der Kernel kümmert sich darum, er ist nicht verschlüsselt, und eine Gegenseite, deren SSH-Daemon hängt, kann ihn trotzdem erfüllen. Deshalb ist die Probe auf SSH-Ebene das aussagekräftigere Signal, wenn Ihnen die Sitzung wichtiger ist als der Socket.

Die Reihenfolge entscheidet, welcher Wert überlebt

OpenSSH verwendet den ersten Wert, den es für jeden Parameter erhält, daher muss ein spezifischer Host-Block vor jedem breiteren Block stehen, der ebenfalls passen würde. Setzen Sie Platzhalter-Standardwerte ans Ende der Datei, nicht an den Anfang, und denken Sie daran, dass ein weiter unten stehender Match-Block einen bereits gesetzten Wert nicht überschreiben kann. Die OpenSSH-Referenz zur Clientkonfiguration nennt die Regel des ersten Werts direkt, was man einmal lesen sollte, bevor man eine gemeinsam genutzte Konfiguration umbaut.

Kommandozeilenoptionen schlagen die Datei, was ein vorübergehendes Experiment billig macht:

ssh -o ServerAliveInterval=15 -o ServerAliveCountMax=4 office-shell

Um zu sehen, was der Client tatsächlich aufgelöst hat, statt was Sie glauben geschrieben zu haben, lassen Sie ihn die effektive Konfiguration ausgeben. Die Ausgabe enthält die zusammengeführten Werte für diesen Hostnamen und ist der schnellste Weg, einen verirrten früheren Block zu erwischen:

ssh -G office-shell | grep -i alive

Was Keepalives über einen Tunnel bewirken

Regelmäßiger Verkehr verhindert, dass eine zustandsbehaftete NAT- oder Firewall-Zuordnung abläuft, was auf einem VPN ein echter Vorteil ist, dessen Gateway inaktive Flüsse nach ein paar Minuten verwirft. Probes, die alle 60 Sekunden eintreffen, erneuern diese Zuordnung, ohne Anwendungsdaten zu tragen.

Einen Weg, der verschwunden ist, können sie nicht neu aufbauen. Verschwindet die Tunnelschnittstelle, scheitern die Probes wie alles andere, und die Sitzung endet, sobald der Zähler erschöpft ist. Lebendigkeitserkennung und Wiederherstellung des Wegs sind verschiedene Probleme, und nur das erste ist in ssh_config konfigurierbar. Was Intervall und Zähler Ihnen tatsächlich kaufen, ist, wie schnell der Client es bemerkt, und genau das erlebt ein Nutzer als Hänger.

Multiplext Verbindungen bringen eine Falte mit sich. Mit ControlMaster im Spiel gehören die Probes zur Masterverbindung, und eine neue Sitzung über einen bestehenden Master erbt, was dieser Master ausgehandelt hat. Wenn der Mux-Master hängt, prüft das Öffnen eines weiteren Fensters den Weg nicht erneut.

Die Einstellung von Anfang bis Ende bestätigen

Geben Sie auf dem Server die effektive Daemon-Konfiguration aus, statt die Datei zu lesen und zu raten, welches Include gewonnen hat:

sshd -T | grep -i clientalive

Beobachten Sie dann eine echte Sitzung mit aktivierter Debug-Ausgabe. Der Client druckt eine Timeout-Zeile, wenn der Zähler abläuft, und die Zeitstempel darum herum zeigen, ob die Stille durchgehend war oder die Probes überhaupt nie gesendet wurden. Eine Sitzung, die ohne Probe-Verkehr stirbt, hat das Schlüsselwort meist in einem Block, der nie gepasst hat.

Zwei Prüfungen lohnen sich für jeden Host, den Sie nur über einen Tunnel erreichen: Bestätigen Sie, dass das aufgelöste Intervall das beabsichtigte ist, und bestätigen Sie, dass dieses Intervall multipliziert mit dem Zähler kürzer ist als der Leerlauf-Timeout am VPN-Gateway. Ist die zweite Zahl größer, verwirft das Gateway den Fluss zuerst stillschweigend, und die SSH-Probe bekommt nie die Chance, etwas zu melden.