Jak skonfigurować trwały serwer proxy zmieniacza płci TCP?

Mam dostawcę (A), który chce przesyłać nam dane za pośrednictwem przychodzącego połączenia TCP. Niestety usługa odbierająca (B) nie może odbierać przychodzących połączeń TCP. Ponadto nie ma statycznego adresu IP, co jest kolejnym wymaganiem.

Jednym ze sposobów rozwiązania tego problemu jest usługa, która łączy przychodzący port TCP A z innym portem TCP B, dzięki czemu konsument może nawiązać połączenie wychodzące z B.

To nie jest wyjątkowy problem [1] [2] , a dzięki socat mogę stworzyć coś bardzo zbliżonego do tego, czego chcę:

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

Powoduje to jednak następujące problemy:

• Jeśli B rozłączy się, nie będzie można połączyć się ponownie. Dzięki TCP4-LISTEN:PORT-B,reuseaddr,forkmoże łączyć się, ale nie odbiera danych.
• B nie może się połączyć, zanim A nie ustanowi połączenia (do pokonania)
• Można ustanowić tylko jedno połączenie z PORT-B( do zwielokrotnienia)

Czy istnieje sposób na dostosowanie polecenia, aby stało się ono „trwałe” i odporne na awarie?

Ważne pytanie brzmi: w jaki sposób A zareaguje na utratę połączenia lub odmowę połączenia? Wszystko, co tylko zakłada, że ​​pojedyncze połączenie TCP pozostanie na zawsze, będzie kruche; taka jest natura internetu.

Jak na temat konfigurowania socatjako [x]inetdusługi?

Ustawiono xinetdby nasłuchiwać w PORT-B i uruchamiać, socat -u TCP4-LISTEN:PORT-A,reuseaddr STDIOgdy tylko strona B się połączy.

xinetdprzekaże ruch przychodzący ze strony B do standardowego wejścia socat, przechwyci standardowe wyjście socati przekaże go do strony B.

Jeśli B rozłączy się, socatproces może zostać zakończony; xinetdrozpocznie nowy, gdy tylko B połączy się ponownie. Gdy B jest odłączone, A będzie otrzymywać błędy „odmowa połączenia”.

Kiedyś musiałem zrobić coś podobnego na starym systemie HP-UX.

Prawdziwy świat jest brudny.

W prawdziwym świecie czasami umierają połączenia TCP, może się to zdarzyć na przykład, jeśli zapora stanowa lub NAT zostanie ponownie uruchomiony, jeśli połączenie będzie trwało zbyt długo bez ruchu, jeśli połączenie podstawowe nie działa zbyt długo.

Co więcej, czasami kiedy połączenia umierają, nie umierają symetrycznie. Jeśli połączenie z dużą ilością danych umrze, prawdopodobnie nadawca zauważy, że nie działa na długo przed tym, jak odbiorca to zrobi. Ma to kilka skutków ubocznych.

• Jeśli połączenie zostanie zainicjowane od nadawcy do odbiorcy, nowe połączenie może zostać nawiązane, podczas gdy stare połączenie najwyraźniej nadal działa.
• Jeśli połączenie jest inicjowane od odbiorcy do nadawcy, może wystąpić znaczne opóźnienie między nadawcą wykrywającym połączenie jest przerwane a odbiorcą wykrywaniem tego faktu i inicjowaniem ponownego połączenia.

Ponadto połączenia TCP są strumieniem bajtów, a NIE strumieniem wiadomości, więc gdy połączenie zostanie przerwane, możesz otrzymać częściową wiadomość.

Wynik netto tego prowadzi mnie do wniosku, że solidne rozwiązanie wymaga zrozumienia protokołu aplikacji, aby twoje rozwiązanie mogło zrozumieć.

1. Jak połączyć strumienie, gdy pojawi się nowe połączenie.
2. Nie wiadomo, czy wiadomości powinny być przechowywane, gdy źródło danych jest podłączone przez odbiorcę danych.
3. Czy mechanizm potwierdzania końca jest odpowiedni, aby zapobiec utracie wiadomości.
4. Czy potrzebny jest jakiś mechanizm „ping” na poziomie aplikacji, aby przyspieszyć wykrywanie martwych połączeń.