Wie richte ich einen dauerhaften TCP-Gender-Changer-Proxy ein?

Ich habe einen Anbieter (A), der uns Daten über eine eingehende TCP-Verbindung senden möchte. Leider kann der konsumierende Dienst (B) keine eingehenden TCP-Verbindungen empfangen. Es hat auch keine statische IP, eine weitere Anforderung.

Eine Möglichkeit, dies zu lösen, wäre ein Dienst, der den eingehenden TCP-A-Port mit einem anderen TCP-Port B verbindet, sodass der Verbraucher eine ausgehende Verbindung zu B herstellen kann.

Dies ist kein einzigartiges Problem [1] [2] , und mit socat kann ich etwas sehr nah an das bringen, was ich will:

socat -d -d -d -u TCP4-LISTEN:PORT-A,reuseaddr TCP4-LISTEN:PORT-B,reuseaddr

Dies hat jedoch die folgenden Probleme:

• Wenn B die Verbindung trennt, kann keine erneute Verbindung hergestellt werden. Mit TCP4-LISTEN:PORT-B,reuseaddr,forkkann es eine Verbindung herstellen, empfängt jedoch keine Daten.
• B kann keine Verbindung herstellen, bevor A eine Verbindung hergestellt hat (überwindbar)
• Es kann nur eine Verbindung hergestellt werden zu PORT-B(überwindbar)

Gibt es eine Möglichkeit, den Befehl so anzupassen, dass er "dauerhaft" und widerstandsfähig gegen Fehler wird?

Die wichtige Frage ist, wie A auf Verbindungsverlust oder auf Verweigerung der Verbindung reagiert. Alles, was nur davon ausgeht, dass eine einzelne TCP-Verbindung für immer bestehen bleibt, wird zerbrechlich. Das ist nur die Natur des Internets.

Wie wäre es mit der Einrichtung socatals [x]inetdService?

Sie würden xinetdin PORT-B hören und das starten, socat -u TCP4-LISTEN:PORT-A,reuseaddr STDIOsobald die B-Seite eine Verbindung herstellt.

xinetdleitet den eingehenden Verkehr von der B-Seite an die Standardeingabe von weiter socatund fängt die Standardausgabe von ab socatund leitet sie an die B-Seite weiter.

Wenn B die Verbindung trennt, kann der socatProzess beendet werden. xinetdstartet eine neue, sobald B wieder eine Verbindung herstellt. Während B getrennt ist, werden A Fehler "Verbindung verweigert" angezeigt.

Ich musste einmal etwas ganz Ähnliches auf einem alten HP-UX-System machen.

Die reale Welt ist chaotisch.

In der realen Welt sterben manchmal TCP-Verbindungen. Dies kann beispielsweise passieren, wenn eine Stateful Firewall oder NAT neu gestartet wird, wenn die Verbindung ohne Datenverkehr zu lange dauert und die zugrunde liegende Verbindung zu lange unterbrochen ist.

Außerdem sterben Verbindungen manchmal nicht symmetrisch, wenn sie sterben. Wenn eine Verbindung mit vielen Daten unterbrochen wird, wird der Absender wahrscheinlich feststellen, dass sie lange vor dem Empfänger tot ist. Dies hat einige Nebenwirkungen.

• Wenn die Verbindung vom Absender zum Empfänger initiiert wird, kann eine neue Verbindung eingehen, während die alte Verbindung anscheinend noch besteht.
• Wenn die Verbindung vom Empfänger zum Absender initiiert wird, kann es zu einer erheblichen Verzögerung zwischen dem Absender, der erkennt, dass die Verbindung unterbrochen ist, und dem Empfänger, der diese Tatsache erkennt und eine erneute Verbindung auslöst, kommen.

Darüber hinaus sind TCP-Verbindungen ein Strom von Bytes, KEIN Strom von Nachrichten. Wenn Ihre Verbindung unterbrochen wird, erhalten Sie möglicherweise eine Teilnachricht.

Das Nettoergebnis davon lässt mich zu dem Schluss kommen, dass eine robuste Lösung ein Verständnis des Anwendungsprotokolls erfordert, damit Ihre Lösung es verstehen kann.

1. So verbinden Sie die Streams, wenn eine neue Verbindung eingeht.
2. Ob Nachrichten gespeichert werden sollen, wenn die Datenquelle vom Datenempfänger verbunden wird, ist nicht bekannt.
3. Ob ein End-to-End-Bestätigungsmechanismus geeignet ist, um einen Nachrichtenverlust zu verhindern.
4. Gibt an, ob ein Ping-Mechanismus auf Anwendungsebene erforderlich ist, um die Erkennung toter Verbindungen zu beschleunigen.