Solicitar ao servidor x Responder do servidor y

Question

Eu preciso de alguns conselhos de vocês: Estou lidando com um software / balanceador de carga personalizado para o qual usaremos dois servidores principais e cerca de oito servidores escravos. Resumindo: o usuário envia uma requisição para o servidor principal, o servidor principal recebe e manipula os pedidos, envia uma requisição para um servidor escravo e o servidor escravo deve enviar os dados DIRETAMENTE ao "usuário".

Utilizador - > Servidor principal

Servidor principal - > Servidor escravo

Servidor escravo - > Usuário

• O motivo pelo qual os dados devem ser enviados diretamente para o usuário e não através do servidor principal é devido à largura de banda e ao baixo orçamento.

Agora tenho a seguinte ideia: -IPinIP, mas isso não é possível em Layer7 (até agora eu sei que existem alguns roteadores caros para isso) -IP Spoof, usando C / C ++, vamos fazer parecer que a resposta veio do servidor principal.

Mas eu estava pensando, talvez a resposta "servidor escravo - > Usuário" pudesse vir de um IP diferente sem causar problemas no firewall do usuário ou de seu anti-vírus. Não sei muito bem sobre firewalls / roteadores e / ou software antivírus "doméstico". Eu acho que a máquina do usuário não lidaria bem com isso?

    

Answer 1

Acredito que depende de como o balanceador de carga personalizado (eu acho que o servidor mestre, conforme indicado no seu esquema) e o aplicativo dos servidores escravos podem ser configurados. Existem dois princípios que são frequentemente vistos em balanceadores de carga para fazer um design real em torno do request / reply-routing:

1) Se você pode dizer ao servidor principal para não usar seu próprio endereço ip como o ip de origem, mas em vez disso o ip do cliente (como estava no pacote como ele veio para o servidor principal em primeiro lugar, conforme seu esquemático) ao passar o pacote para os escravos. O servidor escravo irá naturalmente enviar sua resposta diretamente para o cliente e não através do principal. Esta é uma função bastante comum para ver em balanceadores de carga, nós caras de rede, muitas vezes chamada de fonte reescreve "fonte nat" em vez de spoofing ip para distinguir a intenção benigna, e com o qual você deve ser capaz de fazer alguns googles interessantes sobre o assunto.

2) Outra opção de design é incorporar metainformation semelhante ao cabeçalho X-Forwarded-For em http ou o campo remote_addr / remote_host (não se lembra qual) em ajp que é usado para transportar o endereço IP do cliente original como parte do campo de dados, mesmo quando ele foi substituído por um endereço de host intermediário no pacote ip. Se algo semelhante for possível com o uso do protocolo que você está usando, seus servidores mestres precisariam injetar essa metainformação em um campo de escolha. O aplicativo em seus servidores escravos precisaria ser instruído a enviar a resposta para o endereço naquele campo, em vez de enviar para o endereço de origem no pacote de ip. Uma das vantagens desse design é que ele cria excelente logging, já que você obtém acesso a todos os endereços de nó que estiveram envolvidos em um fluxo específico.

Isto é por princípio, na prática você pode tropeçar um pouco se o cliente espera que a resposta do escravo faça parte da mesma sessão que a requisição (e assim por diante). Tudo depende das expectativas do protocolo que você está tentando passar e da infraestrutura que você tem em torno de seu serviço para confundir as coisas para você: -)