TCP-Tunnel automatisch wieder verbinden

9

Ich habe eine unzuverlässige Netzwerkverbindung zwischen zwei Computern: Manchmal werden aktive TCP-Verbindungen aus Gründen unterbrochen, die außerhalb meiner Kontrolle liegen. Ich möchte eine zuverlässige TCP-Verbindung zwischen den beiden Maschinen herstellen.

Wenn das Netzwerk zuverlässig wäre, würde ich einfach laufen ssh -L 1234:localhost:1234 remotehost, während der Server Port 1234 überwacht remotehost, und den Client auf zeigen localhost:1234. Wenn die SSH-Verbindung jedoch unterbrochen wird, wird auch die weitergeleitete Verbindung unterbrochen. Wie kann ich veranlassen, dass die Verbindung zwischen dem Client und dem Server automatisch wiederhergestellt wird?

Nichtlösungen:

Dies gilt nicht für interaktive Anwendungen, daher gilt der Bildschirm nicht.
Hier geht es nicht nur darum, einen SSH-Tunnel automatisch wieder anzuschließen, la autossh . Ich möchte weiterhin dieselbe getunnelte TCP-Verbindung verwenden und keine neue starten.
Im Prinzip würde ein VPN den Trick tun. Aber es scheint übertrieben, wenn ich nur eine TCP-Verbindung möchte, und ich möchte eine Lösung, die auch dann funktioniert, wenn ich auf beiden Seiten keine Root-Berechtigungen habe.

Ich habe eine schwache Erinnerung an ein Programm namens rocks, das genau das getan hat, aber es scheint vom Web gefallen zu sein. Ich interessiere mich hauptsächlich für Linux auf beiden Seiten (obwohl ich erwarten würde, dass ein Programm auf dieser Ebene auf andere Unices portierbar ist), aber wenn Sie ein Programm kennen, das zwischen QNX und VMS funktioniert, umso besser.

— Gilles 'SO - hör auf böse zu sein'
quelle

Gilles, verwenden Sie TCP-Keepalives für Ihre SSH-Verbindungen? Wenn nicht, versuchen Sie dies zuerst ... einige NAT-Implementierungen stellen Verbindungen schnell ab

— Mike Pennington

@ Mike: Danke für den Tipp. Ich habe keinen unmittelbaren Bedarf, aber ich habe sowohl Situationen erlebt, in denen eine Zwischenroute kam und ging (TCP-Keepalives haben also mehr Schaden als Nutzen gebracht), als auch Situationen, in denen ein NAT mich überlastete und fallen ließ (TCP-Keepalives könnten also helfen). TCP-Keepalives wären für einen kontinuierlichen Stream sowieso nicht wichtig (z. B. scp), oder? Auf jeden Fall möchte ich diesen allgemeinen Punkt beibehalten: Was kann ich tun, wenn ich das nächste Mal mit einem schuppigen Netzwerk jeglicher Art konfrontiert bin?

— Gilles 'SO - hör auf böse zu sein'

Gilles, die Lösungen sind unterschiedlich für konstante Streams wie scp. Ich habe mit ssh keepalives basierend auf Ihrem Beispiel für die Portweiterleitung geantwortet. Re: flockig Downstream - Hop, gibt es nicht viel Sie tun können, andere als eine SSH - Sitzung mit Keep Alive erstellen, die mehr tolerant (dh erlaubt mehr gefallen Keep Alive mit ServerAliveInterval > 0und ServerAliveCountMax > 3). NAT erfordert niedrigere Keepalives-Intervalle. Das Hauptproblem besteht darin, das Problem zu identifizieren und entsprechend anzupassen. Geben Sie die Optionen ein, .ssh/configdamit sie immer für Sie da sind

— Mike Pennington,

@Mike: Einer meiner Anwendungsfälle besteht darin, dass der Client seine IP von einem überlasteten NAT erhält und dann selbst aktive Verbindungen zufällig abbricht (denken Sie an mehr P2P, als es sein sollte). Nach einigen Sekunden kann der Client die Verbindung wiederherstellen, erhält jedoch möglicherweise eine andere IP-Adresse. In diesem Fall kann die TCP-Verbindung auf keinen Fall überleben. Rocks kommt zurecht, aber ich würde etwas bevorzugen, das auf heutigen Systemen sofort kompiliert werden kann.

— Gilles 'SO - hör auf böse zu sein'

Im Fall von NAT, das Ihnen neue IPs gibt, können Sie nicht viel tun, als das NAT zu reparieren oder auf eine andere rocksImplementierung zu hoffen ... obwohl dies offensichtlich ein echter Kludge ist

— Mike Pennington

5

Ist der alte ein nicht gewarteter zuverlässiger Sockel ( Rocks ), wonach Sie suchen?

— In stiller Verzweiflung durchhalten
quelle

Danke, Rocks ist in der Tat das, woran ich mich erinnerte. Natürlich würde ich etwas bevorzugen, das gepflegt wird.

— Gilles 'SO - hör auf böse zu sein'

1

Das einzige mir bekannte Standardprotokoll mit dieser Funktion ist MPTCP . Es ist für die Anwendungsschicht transparent, sodass SSH über MPTCP einfach funktionieren sollte. Es kann die zugrunde liegenden TCP-Verbindungen über verschiedene Pfade mit unterschiedlichen IPs ausführen, sodass es im Prinzip verwendet werden kann, um Ihre SSH-Verbindung in die VPN-Verbindung hinein und aus dieser heraus zu migrieren, je nachdem, ob die VPN-Verbindung besteht.

Ich weiß nicht viel über die Reife von MPTCP-Implementierungen, aber das Design des Protokolls sieht ziemlich robust aus.

Es sollte Ihre SSH-Verbindungen vor Verlust durch unzuverlässige Netzwerkkonnektivität schützen. Es schützt Sie nicht vor einem Mitm, der Ihre SSH-Verbindung unterbrechen möchte. Ein Mitm kann weiterhin beschädigte Daten einspeisen, die von SSH erkannt und die Verbindung unterbrochen werden.

Eine MPTCP-ähnliche Methode zum erneuten Verbinden, die in das SSH-Protokoll integriert ist, ist die Methode, die ich mir vorstellen kann, um eine Verbindung so lange wie möglich aufrechtzuerhalten. Ich glaube jedoch nicht, dass eine solche Funktion für das SSH-Protokoll entwickelt wurde.

— Kasperd
quelle

0

Sie können verwenden daemontools, um den SSH-Port vorwärts zu halten; Es wird nicht unbedingt Programme abhängig von der Verbindung am Leben halten, während sie unterbrochen ist (wie vermutlich, wenn ssh die Verbindung trennt, wird der lokale Port beginnen, ihre Verbindungen abzulehnen), aber es ist ein Start.

Ich vermute, es gibt einige iptablesTricks, wie das Verursachen, dass dieser Port Pakete DROPT, sobald die SSH-Weiterleitung verschwindet, sodass die Verbindungsprogramme nur wissen, dass Pakete verschwinden und nicht abgelehnt werden. Ich lerne daemontoolsmich nur (wieder), daher bin ich mir nicht sicher, ob Sie ein benutzerdefiniertes Skript ausführen können, wenn ein Dienst ausfällt, aber ich vermute, dass Sie dies können.

— Gordon Morehouse
quelle

-2

TCP macht das automatisch. Sie müssen nur die typischen praktischen Bereinigungs-Hacks deaktivieren oder schwächen, die zum Beenden sterbender TCP-Verbindungen verwendet werden. Deaktivieren Sie TCP Keepalive für Ihre Verbindung und erhöhen Sie das Limit für übermäßige Neuübertragungen erheblich. Schreiben Sie beispielsweise unter Linux eine große Anzahl in /proc/sys/net/ipv4/tcp_retries2.

In einem modernen Netzwerk vergisst eine Stateful Packet Inspection-Firewall jedoch wahrscheinlich eine TCP-Verbindung, die keine regelmäßigen Pakete austauscht, sodass es auf Ihrer Parade regnen kann.

— Aecolley
quelle

1

Es ist richtig, dass TCP die Situation bewältigen kann, solange jeder Endpunkt eine statische IP-Adresse hat und keine zustandsbehafteten Middleboxen vorhanden sind. In der Frage wird erwähnt reasons beyond my control, was ich als dynamische IP oder Stateful Middleboxes lese. In solchen Szenarien kann TCP Keepalive ein wenig helfen. Unabhängig davon, wie Sie TCP Keepalive konfigurieren, reicht es nicht aus, die Verbindung aufrechtzuerhalten, wenn eine Middlebox aufgrund eines Neustarts den Status verliert.

— Kasperd

@kasperd Ich stimme zu. In diesen Fällen ist es jedoch sinnlos zu versuchen, eine TCP-Verbindung offen zu halten. Daher nahm ich an, dass der Fragesteller nicht vor diesen besonderen Herausforderungen steht.

— Aecolley

Es ist nicht zwecklos, wenn Sie beide Endpunkte steuern und sie auf einen Stack mit MPTCP-Unterstützung aktualisieren können. Zusätzlich könnte eine Anwendungsschichtlösung auf TCP implementiert werden, ohne dass MPTCP erforderlich ist.

— Kasperd