☰

Die SSH-Verbindung friert am 4G-Hotspot ein, aber nicht bei jedem WLAN

tag-icon • tag-icon ssh openssh
Die SSH-Verbindung friert am 4G-Hotspot ein, aber nicht bei jedem WLAN

kurze Beschreibung

Ich beobachte seit Jahren ein seltsames Verhalten bei meiner SSH-Verbindung, habe aber bis heute nie daran gedacht, eine Frage zu stellen. Ich habe viel darüber gesucht, konnte aber keinen Grund finden.

Umfeld

  1. Grundsätzlich habe ich verschiedene AWS EC2-Instanzen in unterschiedlichen Regionen (wie Irland, Mumbai usw.) laufen.
  2. Ich habe einen Mac.
  3. Und ich befinde mich in Indien (falls es jemandem einfällt).

Problemstellung 1

Wenn mein Mac über ein 4G-Netzwerk mit einem persönlichen Hotspot (von einem Samsung-Gerät oder einem iPhone) verbunden ist, friert meine SSH-Verbindung nach ein paar Minuten (nicht mehr als 3) ein, wenn ich nicht an der SSH-Sitzung arbeite (im Grunde funktionierte die SSH-Verbindung perfekt). Ich muss also ständig die Pfeiltaste drücken, um sie aufrecht zu erhalten.

Problemstellung 2 (was kein Problem ist)

Aber wenn mein Mac mit einer WLAN-Breitbandverbindung verbunden ist, tritt dieses Problem nie auf. Meine SSH-Verbindung bleibt stundenlang bestehen, selbst nachdem ich meinen Mac aus dem Ruhezustand geweckt habe (den Deckel geöffnet habe).

Als ich heute erneut gegoogelt habe, bin ich auf verschiedene Artikel gestoßen, die Lösungen für die Verwendung von Optionen wie TCPKeepAliveoder bieten ServerAliveInterval:

  1. Was genau bewirken die Optionen „ServerAliveInterval“ und „ClientAliveInterval“ in sshd_config?
  2. Wie funktioniert TCP-Keepalive in SSH?
  3. https://raspberrypi.stackexchange.com/questions/8311/ssh-connection-timeout-when-connecting
  4. https://patrickmn.com/aside/how-to-keep-alive-ssh-sessions/

Ich konnte jedoch keinen Beitrag finden, der dieses Problem beschreibt. Hat jemand von euch eine Idee zu diesem Verhalten? Ich gebe euch gerne alle möglichen Details zu meiner 4G-Hotspot-Verbindung.

Antwort1

Ich würde vermuten, dass dies durch ein System verursacht wird, das Verbindungen zustandsabhängig verfolgt (und vergisst). Wenn NAT verwendet wird (und das ist sehr oft der Fall, wenn nicht IPv6 verwendet wird), benötigt das System, das NAT ausführt, normalerweise ein Gedächtnis, um sich zu merken, wohin Antworten zurückgesendet werden sollen. Für Ihr WLAN-Breitband verfügt das System, das NAT ausführt, möglicherweise über ein längeres Gedächtnis, um sich aktive Verbindungen zu merken (z. B. LinuxNetzfilter'SKontaktmerkt sich TCP-Verbindungen standardmäßig 5 Tage lang, während es sich UDP-Flüsse 2 oder 3 Minuten lang merkt). Das entsprechende System, das NAT auf Ihrem 4G-Pfad ausführt, hat wahrscheinlich einen kürzeren Speicher, etwas weniger als 3 Minuten.

Um dies zu umgehen, können Sie, wie Sie in Ihrer Frage festgestellt und verlinkt haben, den spezifischen SSH-Parameter festlegenServerAliveInterval das in regelmäßigen Abständen leere Daten (als SSH-Protokoll) sendet, wenn keine Aktivität stattfindet, ähnlich wieTCP-KeepAlive. Dadurch wird die Verbindung für das System, das NAT durchführt, immer als aktiv angesehen und es vergisst sie nicht. ~/.ssh/configSie könnten Ihrer Datei also Folgendes hinzufügen:

ServerAliveInterval 115

mit 115 ein Wert, der aus Vorsichtsgründen etwas unter 2 Minuten gewählt wurde: ein Wert, der unter der geschätzten Tracking-Dauer aktiver Verbindungen auf dem unsichtbaren NAT-Gerät im Pfad liegt, aber auch nicht zu niedrig ist (siehe später). Damit im schlimmsten Fall, wenn der Tracking-Status 5 Sekunden von der Löschung entfernt ist, er wieder auf die angenommene Lebensdauer von 120 Sekunden zurückkehrt.

Der Nachteil ist, dass (jedenfalls bei Ihrem WLAN-Breitbandzugang) der Client, wenn Sie die Verbindung für einige Zeit verlieren und sie dann wiederherstellen, möglicherweise denkt, der Remote-Server sei ausgefallen, und die Verbindung beendet. Sie können auch optimierenServerAliveCountMaxdafür, aber wenn der Standardwert 3 ist, würde es trotzdem etwa 3*115=345 s Verbindungsverlust, also mehr als 5 Minuten, erfordern, bevor die Chance besteht, dass dieses Problem auftritt.

Die Serverseite verfügt über ein ÄquivalentClientAliveIntervaldas Sie stattdessen dort in der sshd_configDatei festlegen können, und zwar zum gleichen Zweck. Dies hätte den zusätzlichen Vorteil, dass Geister-SSH-Clientverbindungen nicht für eine gewisse Zeit als noch verbunden angesehen werden, wenn die Clientseite ohnehin die Verbindung verloren hat.

verwandte Informationen