Как настроить постоянный прокси-сервер смены пола TCP?

У меня есть провайдер (A), который хочет отправить нам данные через входящее TCP-соединение. К сожалению, потребительская служба (B) не может получать входящие TCP-соединения. Также у него нет статического IP, еще одно требование.

Одним из способов решения этой проблемы может быть служба, которая соединяет входящий порт TCP A с другим портом TCP B, чтобы потребитель мог установить исходящее соединение с 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он может подключиться, но не получает данные.
• B не может подключиться, пока A не установил соединение (преодолимо)
• Только одно соединение может быть установлено PORT-B(преодолимо)

Есть ли способ настроить команду так, чтобы она стала «постоянной» и устойчивой к сбоям?

Важный вопрос: как A будет реагировать на потерю соединения или на отказ в соединении? Все, что предполагает, что одно TCP-соединение будет работать вечно, будет хрупким; это просто природа интернета.

Как насчет настройки socatв качестве [x]inetdслужбы?

Вы настроите xinetdпрослушивание в PORT-B и начнете, socat -u TCP4-LISTEN:PORT-A,reuseaddr STDIOкак только B-сторона соединится.

xinetdпередаст входящий трафик со стороны B на стандартный ввод socat, перехватит стандартный вывод socatи передаст его стороне B.

Если B отключается, socatпроцесс может быть разрешен до конца; xinetdначнется новый, как только B подключится снова. Пока B отключен, A будет получать ошибки «Отказано в соединении».

Когда-то мне приходилось делать что-то похожее на старой системе HP-UX.

Реальный мир грязный.

В реальном мире иногда TCP-соединения умирают, это может произойти, например, если перезагружен брандмауэр с сохранением состояния или NAT, если соединение проходит слишком долго без трафика, если базовое соединение слишком долго не работает.

Кроме того, иногда, когда умирают соединения, они не умирают симметрично. Если соединение, содержащее большое количество данных, умирает, то, вероятно, отправитель заметит, что оно мертво задолго до того, как это сделает получатель. Это имеет несколько побочных эффектов.

• Если соединение инициируется от отправителя к получателю, может появиться новое соединение, в то время как старое соединение, по-видимому, еще живо.
• Если соединение инициируется от получателя к отправителю, то может существовать существенная задержка между отправителем, обнаружившим разрыв соединения, и получателем, обнаружившим этот факт и инициирующим переподключение.

Кроме того, TCP-соединения представляют собой поток байтов, а НЕ поток сообщений, поэтому, когда ваше соединение прерывается, вы можете получить частичное сообщение.

Итоговый результат этого приводит меня к выводу, что надежное решение требует понимания протокола приложения, чтобы ваше решение могло его понять.

1. Как объединить потоки, когда новое соединение входит.
2. Должны ли сообщения храниться, когда источник данных подключен получателем данных, нет.
3. Подходит ли сквозной механизм подтверждения для предотвращения потери сообщения.
4. Необходим ли какой-то механизм «ping» на уровне приложения для ускорения обнаружения обрывов соединений.