He estado tratando de comprender cómo funciona el enrutamiento en una VPC de AWS con subredes públicas/privadas.
Tengo una configuración recomendada por Amazon con ELB y NAT en la subred pública y el servidor web en la subred privada. Tengo grupos de seguridad (SG) configurados segúnhttp://blogs.aws.amazon.com/security/blog/tag/NATy todo funciona como se esperaba. ¡Excelente!
Lo que todavía no entiendo es cómo se devuelven las respuestas HTTP desde la instancia del servidor web en la arquitectura anterior.
Entonces, llega una solicitud web desde la Internet pública a través de HTTP, 80 llega a ELB y ELB la lleva a la IP privada del servidor web, genial. Ahora el servidor web tiene que responder. Por lo que tengo entendido, la respuesta se realizará a través de 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 llega esta respuesta a la Internet pública? No puede pasar por la NAT. ¿Significa esto que la respuesta vuelve a enviarse a través del ELB? El diagrama de Amazon no indica que la flecha de dirección del tráfico del ELB sea bidireccional, ni la documentación del ELB indica que el ELB se comporta como una NAT con estado. ¿Lo hace?
Respuesta1
Las flechas en el diagrama sólo indican la dirección del establecimiento de la conexión, no el flujo de tráfico.
Sí, el tráfico de regreso pasa por el ELB.
Pero no es una NAT con estado, es un proxy de conexión TCP. Las máquinas ELB aceptan conexiones TCP en los puertos de escucha configurados, finalizan la sesión SSL si así está configurada y establecen una nueva conexión TCP con el servidor back-end. Si el oyente está configurado para HTTP, el ELB opera en un modo consciente de la carga útil analizando, registrando y reenviando solicitudes HTTP al back-end; de lo contrario, es independiente de la carga útil y establece una nueva conexión TCP 1:1 con el back-end. para cada conexión entrante y "unir las tuberías" (sin conocimiento ni modificación del 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 la del cliente original. Así es como el tráfico de respuesta regresa al ELB para regresar al cliente.
En modo http, el ELB agrega(o se agrega a) 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 e X-Forwarded-Portindicar el puerto de front-end.
Actualizar:lo anterior se refiere a un tipo de balanceador 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 equilibrador de capa 7 más nuevo, Application Load Balancer 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 se mejoran significativamente.
El tipo más nuevo de equilibrador de carga, el Network Load Balancer, es un equilibrador de capa 3. A diferencia de los otros dos, se comporta de manera muy similar a NAT dinámica, manejando conexiones entrantes (originadas externamente) únicamente, asignando source-addr+port a través de EIP-addr+port a instancia-privada-ip:adde+port - con el EIP vinculado 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.
Conceptualmente hablando, el Network Load Balancer parece modificar en realidad el comportamiento del Internet Gateway, que es, en sí mismo, un objeto lógico que no se puede desactivar, reemplazar ni experimentar una falla en ningún sentido significativo. Esto contrasta con ELB y ALB, que en realidad operan en instancias EC2 "ocultas". NLB opera en la propia infraestructura de red, según todas las apariencias.
Respuesta2
Según la documentación de AWS para NLB, es la capa 4, no la capa 3. Además, no es necesario que los servidores backend 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 destinos 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.