¿El ELB también enruta el tráfico de respuesta saliente en AWS

He estado tratando de entender cómo funciona el enrutamiento en una AWS VPC con subredes públicas / privadas.

Tengo una configuración recomendada por Amazon con un ELB y NAT en la subred pública y el servidor web en la subred privada. Tengo grupos de seguridad (SG) configurados según http://blogs.aws.amazon.com/security/blog/tag/NAT y todo funciona como se esperaba. ¡Excelente!

Lo que aún no entiendo es cómo se devuelven las respuestas HTTP de la instancia del servidor web en la arquitectura anterior.

Entonces, una solicitud web llega desde Internet pública a través de HTTP, 80 hits ELB y ELB la lleva a la IP privada del servidor web, genial. Ahora el servidor web tiene que responder. Por lo que entiendo, la respuesta será sobre un puerto TCP superior diferente (1024-65535). El NAT SG solo permite el tráfico saliente a través de los puertos 80 y 443. Entonces, ¿cómo se devuelve esta respuesta al Internet público? No puede pasar por el NAT. ¿Esto significa que la respuesta se remonta a través del ELB? El diagrama de Amazon no indica que la flecha de dirección de tráfico de ELB sea bidireccional, ni la documentación de ELB indica que el ELB se comporta como un NAT con estado. ¿Lo hace?

Las flechas en el diagrama solo indican la dirección del establecimiento de la conexión, no el flujo de tráfico.

Sí, el tráfico de retorno vuelve a través del ELB.

Pero no es un NAT con estado, es un proxy de conexión TCP. Las máquinas ELB aceptan conexiones TCP en los puertos de escucha configurados, finalizando la sesión SSL si está configurada, y establecen una nueva conexión TCP al servidor de fondo. Si el oyente está configurado para HTTP, el ELB opera en un modo compatible con la carga útil analizando, registrando y reenviando solicitudes HTTP al back-end, de lo contrario es independiente de la carga útil, estableciendo una nueva conexión TCP 1: 1 al back-end para cada conexión entrante y "unir las tuberías" (sin reconocimiento o modificación a nivel HTTP).

De cualquier manera, la dirección de origen de la conexión entrante a su aplicación será la del nodo ELB, no el cliente original. Así es como el tráfico de respuesta regresa al ELB para regresar al cliente.

En el modo http, el ELB agrega (o agrega) el X-Forwarded-Forencabezado para que su aplicación pueda identificar la IP del cliente original, así como X-Forwarded-Proto: [ http | https ]para indicar si la conexión del cliente usa SSL y X-Forwarded-Portpara indicar el puerto front-end.

Actualización: lo anterior se refiere a un tipo de equilibrador de carga que ahora se conoce como "ELB Classic" o ELB / 1.0 (que se encuentra en la cadena del agente de usuario que envía con las comprobaciones de estado HTTP).

El nuevo equilibrador de capa 7, el equilibrador de carga de aplicaciones o ELB / 2.0 funciona de manera similar con respecto al flujo de tráfico. La capacidad de la Capa 4 (TCP "transparente") se elimina de ALB y las características de la capa 7 mejoran significativamente.

El último tipo de equilibrador de carga, el equilibrador de carga de red, es un equilibrador de capa 3. A diferencia de los otros dos, se comporta de manera muy similar a la NAT dinámica, manejando solo conexiones entrantes (originadas fuera), mapeando source-addr + port a través de EIP-addr + port a instance-private-ip: adde + port - con el EIP vinculados al "equilibrador", y a diferencia de los otros dos tipos de equilibradores, las instancias deben estar en subredes públicas y utilizar sus propias IP públicas para ello.

Hablando conceptualmente, el Network Load Balancer parece modificar realmente el comportamiento de Internet Gateway, que es, en sí mismo, un objeto lógico que no se puede deshabilitar, reemplazar o experimentar una falla en un sentido significativo. Esto contrasta con ELB y ALB, que realmente operan en instancias EC2 "ocultas". NLB opera en la infraestructura de red, en sí misma, según todas las apariencias.

De acuerdo con la documentación de AWS para NLB, es la capa 4, no la capa 3. Además, no se requiere que los servidores de fondo o de destino estén en una subred pública. De hecho, los rangos de direcciones IP de los grupos objetivo deben ser uno de los siguientes: Los siguientes son los posibles tipos de objetivos:

instancia Los objetivos se especifican por ID de instancia.

ip Los objetivos se especifican por dirección IP.

Cuando el tipo de destino es ip, puede especificar direcciones IP de uno de los siguientes bloques CIDR:

Las subredes de la VPC para el grupo objetivo

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

No puede especificar direcciones IP enrutables públicamente.

Espero que esto ayude.