SSH bricht im VPN jede Minute ab? Es ist nicht der Keepalive

SSH verbindet, funktioniert etwa eine Minute und friert dann jedes Mal nach ungefähr demselben Intervall ein. Die übliche Erklärung ist ein Idle-Timeout, also senken Leute die MTU und setzen Client-Keepalives. Eine WireGuard-Strecke, an der ich arbeitete, hatte das alles schon durch: eine kleinere Tunnel-MTU, Client-Alive-Einstellungen, einen konfigurierten Tunnel-Keepalive. Die Abbrüche gingen unverändert weiter. Die Ursache war eine asymmetrische LAN-Route, und das Muster lohnt sich zu erkennen, weil es jede timerbasierte Lösung aushebelt.

Ein Keepalive beweist, dass Ihr Host noch senden will. Er kann ein zustandsbehaftetes Gerät nicht dazu bringen, eine Antwort zu sehen, die es nie passiert.

Der Mythos: Keepalives beheben einen stillen Abbruch

SSH-Keepalives gibt es für eine Aufgabe: zu verhindern, dass etwas, das Stille zählt, eine untätige Sitzung wegräumt. Das tun sie gut. Sie lösen nicht das Problem eines zustandsbehafteten Geräts, das das erste Paket in eine Richtung sah und danach nie die Antwort, denn nichts, was der Client sendet, ändert, welche Schnittstelle die Antwort nutzt.

Eine MTU-Änderung ist der andere beliebte Fix, und sie hat denselben Fehlermodus. Eine kleinere MTU hilft bei Fragmentierung und Path-MTU-Problemen und ändert nichts an einer Route. Wenn Ihre Timer und Ihre MTU bereits vernünftig sind und der Abbruch weiterhin in einem wiederholbaren Intervall auftritt, sagt Ihnen das Intervall etwas über einen Timeout irgendwo, nicht über die Paketgröße. Notieren Sie das Intervall und vergleichen Sie es mit den Zustands-Timeouts auf jedem Gerät im Pfad.

Das Erkennungszeichen ist Regelmäßigkeit zusammen mit einer Sitzung, die innerhalb dieses Intervalls nutzbar bleibt. Idle-Timeouts schlagen zu, wenn nichts passiert; dieser schlägt zu, während Sie tippen.

Was das zusätzliche Gateway tatsächlich tut

Stellen Sie Laptop und VPN-Gateway ins selbe LAN, mit einer separaten LAN-Firewall als Standardgateway. Der Laptop schickt VPN-gebundenen Verkehr an die Firewall, die Firewall leitet ihn an das Gateway weiter, und die Antworten des Gateways gehen direkt über das LAN zurück zum Laptop. Der zweite Abschnitt passiert die Firewall nie, also hält ihre Zustandstabelle eine halbe Verbindung.

Die Adressen unten spiegeln diese Anordnung wider:

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

Weiterleitungen und Zustandsbehandlung machen dann aus einem funktionierenden Handshake eine Verbindung, die später statt sofort stirbt. Die Verzögerung ist der alternde Zustandseintrag oder eine strengere Prüfung, die fehlschlägt, deshalb wirkt das Intervall so mechanisch.

Nichts davon erscheint in der Client-Konfiguration, deshalb beginnt die Suche danach meist in der falschen Datei.

Wählen Sie einen bewussten Pfad

Für die obige Anordnung beseitigt das Routing des entfernten Subnetzes direkt zum VPN-Gateway die halbe Verbindung:

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

Das sind Beispieladressen. Der nächste Hop muss in Ihrem LAN erreichbar sein, das Präfix muss das beabsichtigte entfernte Netz sein, und der zweite Befehl zeigt Ihnen das Ergebnis, bevor Sie sich darauf verlassen. Liegt das Gateway nicht in Ihrem Subnetz, ist diese Route nicht der Fix, den Sie wollen.

Wenn die Firewall den Verkehr zwischen diesen Systemen kontrollieren soll, ist Routing daran vorbei das falsche Design. Lassen Sie stattdessen beide Richtungen die Grenze passieren und konfigurieren Sie die Routen auf jeder Seite so, dass der Rückweg passt. Das Ziel ist ein einziger bewusster Pfad, nicht weniger Zustandsprüfung.

Netgates Hinweise zum asymmetrischen Routing beschreiben dieselbe Asymmetrie auf Schnittstellenebene und die Zustandsprobleme, die sie erzeugt, also lesen Sie sie, bevor Sie die Zustandsbehandlung global lockern. Zeitgesteuerte Abbrüche wie dieser Fall sind für sich genommen kein Beweis. Behandeln Sie den Artikel als Beschreibung eines Fehlermodus und beweisen Sie dann, dass Ihr eigenes Netz dazu passt, bevor Sie die globale Zustandsrichtlinie ändern.

Testen Sie es von beiden Enden

Lesen Sie die Route des Laptops zum Ziel und die Route des Ziels zurück zum Laptop; das sind zwei getrennte Entscheidungen, und wahrscheinlich ist nur eine davon falsch. Ein Ping, der vom Gateway selbst gelingt, kann das Problem völlig verbergen, weil er auf der Maschine entsteht, deren Pfad bereits korrekt ist. Sie brauchen beide Richtungen, wie sie die beiden Enden der tatsächlichen Sitzung sehen.

Öffnen Sie nach dem Fix SSH erneut und halten Sie die Sitzung deutlich über das Intervall hinaus offen, das früher fehlschlug. Machen Sie die Route dann in der freigegebenen Netzwerkkonfiguration dauerhaft, denn ein einmaliger Befehl ist kein Neustartplan, und das Problem kehrt beim nächsten Neustart mit einem neuen Rätsel zurück.

Wann Asymmetrie in Ordnung ist

Asymmetrisches Routing ist in vielen Netzen normal und per Definition nicht kaputt. Es wird zum Problem, wenn Zustandsverfolgung, Übersetzung oder Richtlinie davon abhängen, einen Pfad zu sehen, den sie nicht sehen, und jedes davon hat ein anderes Gegenmittel. Prüfen Sie, was das mittlere Gerät tatsächlich verlangt, bevor Sie darum herum neu entwerfen.

Die dauerhafte Antwort benennt die beiden Pfade, das Gerät, das beide sehen muss, und die Route, die das möglich macht. Wenn Sie das Gerät nicht benennen können, haben Sie die Ursache noch nicht gefunden.