O ELB também roteia o tráfego de resposta de saída no AWS

Question

Eu tenho tentado entender como o roteamento funciona em um AWS VPC com sub-redes públicas / privadas.

Eu tenho uma configuração conforme recomendada pela amazon com um ELB e NAT na sub-rede pública e o servidor da web na sub-rede privada. Tenho grupos de segurança (SG) configurados de acordo com o link e tudo funciona conforme o esperado. Ótimo!

O que eu ainda não entendo é como as respostas HTTP são retornadas da instância do servidor na arquitetura acima.

Assim, uma solicitação da web vem da Internet pública via HTTP, 80 acessos ELB e ELB levam isso para o IP privado do servidor da Web, legal. Agora o servidor da web tem que responder. Pelo que entendi a resposta será sobre uma porta TCP superior (1024-65535). O NAT SG só permite tráfego de saída através das portas 80 & 443. Então como é que esta resposta regressa à Internet pública? Não pode passar pelo NAT. Isso significa que a resposta volta pelo ELB. O diagrama da Amazon não indica a seta de direção do tráfego do ELB como bidirecional, nem a documentação do ELB declara que o ELB se comporta como um NAT com estado. Isso?

    

Answer 1

As setas no diagrama indicam apenas a direção do estabelecimento da conexão - não o fluxo de tráfego.

Sim, o tráfego de retorno volta pelo ELB.

Mas, não é um NAT com estado - é um proxy de conexão TCP. As máquinas ELB aceitam conexões TCP nas portas de escuta configuradas, encerrando a sessão SSL, se configurado, e estabelecem uma nova conexão TCP com o servidor de backend. Se o listener estiver configurado para HTTP, o ELB operará em um modo de reconhecimento de carga útil, registrando e encaminhando solicitações HTTP para o back-end, caso contrário, ele estará agindo em relação à carga útil, estabelecendo uma nova conexão TCP 1: 1 para o back-end para cada conexão de entrada e "ligar os canais juntos" (sem reconhecimento ou modificação no nível de HTTP).

De qualquer forma, o endereço de origem da conexão de entrada para seu aplicativo será o do nó ELB, não o cliente original. É assim que o tráfego de resposta retorna ao ELB para retornar ao cliente.

No modo http, o ELB adiciona (ou acrescenta ao ) o X-Forwarded-For header para que seu aplicativo possa identificar o IP do cliente original, bem como X-Forwarded-Proto: [ http | https ] para indicar se a conexão do cliente usa SSL e X-Forwarded-Port para indicar a porta front-end.

Atualização: acima refere-se a um tipo de balanceador de carga que agora é conhecido como "ELB Classic" ou ELB / 1.0 (encontrado na string de agente do usuário que envia com verificações de integridade HTTP). / p>

O mais novo balanceador de Camada 7, o Application Load Balancer ou o ELB / 2.0 opera de maneira semelhante, no que diz respeito ao fluxo de tráfego. O recurso de camada 4 (TCP "transparente") é removido do ALB e os recursos da camada 7 são aprimorados significativamente.

O mais novo tipo de balanceador de carga, o balanceador de carga de rede, é um balanceador de camada 3. Diferente dos outros dois, ele se comporta muito como o NAT dinâmico, lidando apenas com conexões de entrada (fora-originadas), mapeando source-addr + port através de EIP-addr + port para instância-private-ip: adde + port - com o EIP vinculado ao "balanceador" - e, diferentemente dos outros dois tipos de balanceadores, as instâncias precisam estar em sub-redes públicas e usar seus próprios IPs públicos para isso.

Conceitualmente falando, o balanceador de carga de rede parece realmente modificar o comportamento do gateway de Internet - que é, em si, um objeto lógico que não pode ser desabilitado, substituído ou experimentar uma falha em qualquer sentido significativo. Isso está em contraste com ELB e ALB, que realmente operam em instâncias do EC2 "ocultas". O NLB opera na própria infra-estrutura de rede, por todas as aparências.