永続的なTCPジェンダーチェンジャープロキシを設定する方法

着信TCP接続を介してデータを送信したいプロバイダー（A）があります。残念ながら、消費サービス（B）はインバウンドTCP接続を受信できません。また、別の要件である静的IPもありません。

これを解決する1つの方法は、コンシューマがBへのアウトバウンド接続を確立できるように、着信TCP Aポートを別のTCPポートBに接続するサービスです。

これは固有の問題ではありません[1] [2]、そしてsocatで私は私が望むものに非常に近いものを作ることができます：

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

ただし、これには次の問題があります。

• Bが切断すると、再接続できません。を使用するとTCP4-LISTEN:PORT-B,reuseaddr,fork、接続できますが、データを受信しません。
• Aが接続を確立する前にBが接続できない（乗り越え可能）
• への接続は1つしか確立できませんPORT-B（乗り越え可能）

コマンドが「永続的」になり、障害に耐性を持つようにコマンドを調整する方法はありますか？

重要な質問は、Aが接続の喪失または接続の拒否にどのように反応するかです。単一のTCP接続が永遠に続くと想定しているものはすべて脆弱です。それがインターネットの性質です。

をサービスsocatとして設定してみ[x]inetdませんか？

xinetdPORT-Bでリッスンするように設定しsocat -u TCP4-LISTEN:PORT-A,reuseaddr STDIO、Bサイドが接続するとすぐにを開始します。

xinetd着信トラフィックをBサイドからの標準入力に渡しsocat、の標準出力をキャッチsocatしてBサイドに渡します。

Bが切断した場合、socatプロセスを終了することができます。xinetdBが再び接続するとすぐに新しいものを開始します。Bが切断されている間、Aは「接続拒否」エラーを受け取ります。

古いHP-UXシステムでも、かなり似たようなことをしなければなりませんでした。

実世界は乱雑です。

現実の世界では、TCP接続が停止することがあります。これは、たとえば、ステートフルファイアウォールまたはNATがリブートされた場合、接続がトラフィックなしで長すぎる場合、基礎となる接続が長時間停止している場合に発生します。

さらに、接続が停止したときに、対称的に停止しない場合があります。大量のデータを伝送する接続が停止した場合、受信者が停止するずっと前に、送信者が接続が停止していることに気付く可能性があります。これにはいくつかの副作用があります。

• 送信者から受信者への接続が開始された場合、古い接続がまだ存続している間に新しい接続が発生する可能性があります。
• 受信者から送信者への接続が開始された場合、送信者が接続の切断を検出してから受信者がその事実を検出して再接続をトリガーするまでにかなりの遅延が生じる可能性があります。

さらに、TCP接続はメッセージのストリームではなく、バイトのストリームであるため、接続が失敗すると、部分的なメッセージを受信する可能性があります。

この最終的な結果から、ソリューションを理解するには、堅牢なソリューションにはアプリケーションプロトコルを理解する必要があると結論づけられます。

1. 新しい接続が入ったときにストリームをスプライスする方法。
2. データソースがデータ受信者によって接続されているときにメッセージを格納する必要があるかどうか。
3. エンドツーエンドの確認応答メカニズムがメッセージの損失を防ぐのに適切かどうか。
4. デッド接続の検出を高速化するために、ある種のアプリケーションレベルの「ping」メカニズムが必要かどうか。