ngx_stream_core_module e o usuário final ip

Question

Digamos que eu tenha algum serviço trabalhando em um nível TCP bruto e quero adicionar um balanceamento de carga a ele. Eu tentei usar ngx_stream_core_module . Embora os fluxos TCP sejam, de fato, intermediados por proxy para os servidores backend, descobri alguns problemas que não consigo resolver.

1. Meu serviço escreveu em node.js e é uma técnica comum para configurar o gerenciador de processos, como pm2, que reinicia o nó caso ele consuma muita memória. Mas isso obviamente encerrará todos os clientes conectados. Minha expectativa era que o nginx conectasse os usuários ao próximo servidor no upstream (bem, talvez seja muito > 2016, mas), mas minha conexão apenas se encerra.

2. Meu serviço exige que o ip do usuário final e a porta remota operem, mas no remoteAddress e no remotePort do soquete do aplicativo são apontados para a instância nginx local. Ou seja quando eu imprimi-lo para o buffer, vejo 127.0.0.1 quando a conexão é proxy e meu IP real quando eu me conecto diretamente ao nó. Eu vejo que o nginx suporta algumas variáveis de configuração (desde a v.1.11.2), e o $ remote_addr está entre elas. Mas eu não vejo nenhuma informação sobre como encaminhar essa variável para o upstream. A diretiva proxy_set_header está indisponível no fluxo e parece ok, pois não há "cabeçalhos" no TCP. Isso é possível?

3. Eu não sou um devops, mas um codificador, então eu ouvi sobre o haproxy, mas não tenho idéia se isso pode resolver esses dois problemas. Pode?

Para testes, usei o servidor dumb echo node.js, onde toda a parte de trabalho é reduzida para

server.on('connection', socket => {
    socket.write('Hello from ${instance}, ${socket.remoteAddress}:${socket.remotePort}\n');
});

E a parte relacionada da minha configuração do nginx é

stream {
    upstream echo {
        server localhost:9000;
        server localhost:9001;
    }

    server {
        listen 8080;
        proxy_connect_timeout 1s;
        proxy_timeout 2h;
        proxy_pass echo;
    }
}

Por fim, usei o netcat para verificar as coisas.

// direct connect
~|⇒  nc 95.85.15.120 9000
Hello, ::ffff:86.110.174.98:65408

// proxied connect
~|⇒  nc 95.85.15.120 8080
Hello, ::ffff:127.0.0.1:44056

Aqui estão os documentos do módulo .

    

Answer 1

1. Isso não é algo que funcione com o TCP, porque certamente quebrará praticamente qualquer protocolo que funcione ontop. Por exemplo, e se uma conexão for descartada no meio de alguma mensagem ou comando?

2. Você pode usar o protocolo de proxy para transferir os IPs originais, mas precisa ser compatível pelo seu backend.

   Ou você pode configurar vinculação a IPs de clientes :

   proxy_bind $remote_addr transparent;