Como configurar um proxy de alterador de gênero TCP persistente?

Question

Eu tenho um provedor (A) que deseja enviar dados através de uma conexão TCP de entrada. Infelizmente, o serviço consumidor (B) não pode receber conexões TCP de entrada. Também não possui um IP estático, outro requisito.

Uma maneira de resolver isso seria um serviço que conecta a porta TCP A de entrada a outra porta TCP B, para que o consumidor possa estabelecer uma conexão de saída para B.

Este não é um problema exclusivo [1] [2] , e com o socat posso fazer algo muito próximo do que eu quero:

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

No entanto, isso tem os seguintes problemas:

• Se B desconectar, não poderá se reconectar. Com TCP4-LISTEN:PORT-B,reuseaddr,fork , ele pode se conectar, mas não recebe dados.
• B não pode se conectar antes que A tenha estabelecido uma conexão (superável)
• Apenas uma conexão pode ser estabelecida para PORT-B (superável)

Existe uma maneira de ajustar o comando de modo que se torne "permament" e resistente a falhas?

    

Answer 1

A questão importante é: como A reage à perda de conexão ou a conexão é recusada? Qualquer coisa que apenas considere que uma única conexão TCP permanecerá para sempre será frágil; essa é apenas a natureza da internet.

Que tal configurar o socat como [x]inetd service?

Você definiria xinetd para ouvir em PORT-B e inicie o socat -u TCP4-LISTEN:PORT-A,reuseaddr STDIO assim que o B-side se conectar.

xinetd transmitirá o tráfego de entrada do lado B para a entrada padrão de socat e obterá a saída padrão de socat e passará para o lado B.

Se B se desconectar, o processo socat poderá terminar; xinetd iniciará um novo assim que B se conectar novamente. Enquanto B está desconectado, A receberá erros de "conexão recusada".

Uma vez eu tive que fazer algo parecido em um antigo sistema HP-UX.

    

Answer 2

O mundo real é confuso.

No mundo real algumas vezes as conexões TCP morrem, isso pode acontecer, por exemplo, se um firewall com estado ou NAT for reinicializado, se a conexão ficar muito longa sem tráfego, se a conexão subjacente ficar inativa por muito tempo.

Além disso, às vezes, quando as conexões morrem, elas não morrem simetricamente. Se uma conexão que transporta muitos dados morre, é provável que o remetente note que está morto muito antes que o destinatário o faça. Isso tem alguns efeitos colaterais.

• Se a conexão for iniciada de remetente para destinatário, uma nova conexão poderá aparecer enquanto a conexão antiga estiver aparentemente viva.
• Se a conexão for iniciada de remetente para remetente, pode haver um atraso substancial entre o remetente detectar que a conexão está interrompida e o receptor detectar esse fato e disparar uma reconexão.

Além disso, as conexões TCP são um fluxo de bytes, NÃO um fluxo de mensagens, portanto, quando sua conexão for interrompida, você poderá receber uma mensagem parcial.

O resultado líquido disso me leva a concluir que uma solução robusta requer um entendimento do protocolo de aplicativo para que sua solução possa entender.

1. Como unir os fluxos quando uma nova conexão entra.
2. Se as mensagens devem ou não ser armazenadas quando a fonte de dados é conectada pelo destinatário de dados, não.
3. Se um mecanismo de reconhecimento de ponta a ponta é apropriado para evitar a perda de mensagens.
4. Se algum tipo de mecanismo "ping" de nível de aplicativo é necessário para acelerar a detecção de conexões inativas.