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

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

Tenho tentado entender como funciona o roteamento em uma AWS VPC com sub-redes públicas/privadas.

Eu tenho uma configuração recomendada pela Amazon com ELB e NAT na sub-rede pública e o servidor web na sub-rede privada. Tenho grupos de segurança (SG) configurados conformehttp://blogs.aws.amazon.com/security/blog/tag/NATe tudo funciona conforme o esperado. Ótimo!

Arquitetura de referência com configuração da Amazon VPC

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

Então, uma solicitação da web chega da Internet pública por HTTP, 80 acessos ao ELB e o ELB a leva para o IP privado do servidor da web, legal. Agora o servidor web tem que responder. Pelo que entendi, a resposta será em uma porta TCP superior diferente (1024-65535). O NAT SG permite apenas tráfego de saída pelas portas 80 e 443. Então, como essa resposta volta para a 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 ELB como bidirecional, nem a documentação do ELB afirma que o ELB se comporta como um NAT com estado. Não é?

Responder1

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 assim configurada, e estabelecem uma nova conexão TCP com o servidor back-end. Se o ouvinte estiver configurado para HTTP, o ELB operará em um modo com reconhecimento de carga útil, analisando, registrando e encaminhando solicitações HTTP para o back-end, caso contrário, será independente de carga útil, estabelecendo uma nova conexão TCP 1:1 para o back-end para cada conexão de entrada e "amarrar os canais" (sem reconhecimento ou modificação no nível 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 do 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 X-Forwarded-Forcabeçalho 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-Portpara indicar a porta front-end.


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

O balanceador Layer 7 mais recente, Application Load Balancer ou ELB/2.0 opera de forma semelhante, no que diz respeito ao fluxo de tráfego. A capacidade da Camada 4 (TCP "transparente") foi removida do ALB e os recursos da camada 7 foram aprimorados significativamente.

O mais novo tipo de balanceador de carga, o Network Load Balancer, é um balanceador de Camada 3. Ao contrário dos outros dois, ele se comporta de maneira muito semelhante ao NAT dinâmico, lidando apenas com conexões de entrada (de origem externa), mapeando endereço de origem+porta através de EIP-addr+porta para instance-private-ip:adde+port - com o EIP vinculados 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 Network Load Balancer parece realmente modificar o comportamento do Internet Gateway – que é, em si, um objeto lógico que não pode ser desativado, substituído ou sofrer uma falha em qualquer sentido significativo. Isso contrasta com ELB e ALB, que na verdade operam em instâncias EC2 "ocultas". O NLB opera na própria infraestrutura de rede, ao que tudo indica.

Responder2

De acordo com a documentação da AWS para NLB, é a camada 4 e não a camada 3. Além disso, o back-end ou os servidores de destino não precisam estar em uma sub-rede pública. Na verdade, os intervalos de endereços IP dos grupos-alvo devem ser um dos seguintes: A seguir estão os possíveis tipos de alvo:

instância Os destinos são especificados pelo ID da instância.

ip Os alvos são especificados pelo endereço IP.

Quando o tipo de destino for ip, você poderá especificar endereços IP de um dos seguintes blocos CIDR:

As sub-redes da VPC para o grupo de destino

10.0.0.0/8 (RFC 1918)

100.64.0.0/10 (RFC 6598)

172.16.0.0/12 (RFC 1918)

192.168.0.0/16 (RFC 1918)

Importante

Você não pode especificar endereços IP roteáveis ​​publicamente.

Eu espero que isso ajude.

informação relacionada