Blog de Amazon Web Services (AWS)

Cómo resolver el agotamiento de IP’s privadas con una solución de NAT privada

Por Chandini Penmetsa, Arquitecta de Soluciones y
SaiJeevan Devireddy, Arquitecto de Soluciones

 

Introducción:

A medida que evolucionan nuestras necesidades informáticas, una de las preguntas más comunes que escuchamos de los clientes es, “¿cómo administro mi espacio de direcciones IP privado? Mis direcciones IP está a punto de quedar exhaustas”.

Es difícil asignar rangos de IP privados separados (RFC 1918) a diferentes unidades de negocio en una organización porque el rango de direcciones IPv4 disponible está restringido. Con la creciente popularidad de la arquitectura basada en micro-servicios, donde cada tarea o pod necesita su propia dirección IP, la necesidad de gestionar el direccionamiento IP es cada vez mayor. De igual manera, cuando una organización crece, crecen los requerimientos de direcciones IP. Y eventualmente se quedarán sin rangos de IP privados y se verán obligados a usar rangos de IP privados superpuestos en algunas unidades de negocio. Haciendo más difícil establecer conectividad entre unidades de negocio con rangos CIDR superpuestos.

Para superar las limitaciones de direcciones IP superpuestas, los clientes pueden implementar soluciones como AWS PrivateLink, IPv6 o usar dispositivos de NAT (Network Address Translation) auto-administrados para traducir direcciones IPv4 y permitir la comunicación entre redes con rangos CIDR superpuestos. En el último enfoque, la administración de reglas tipo NAT y la asignación de direcciones IP generará sobrecarga operativa.

Actualmente, AWS cuenta con una solución nativa de nube para proporcionar funcionalidad de traducción de direcciones IPv4 entre entornos privados, soportado por la nueva Private NAT Gateway. En este blog, vamos a ilustrar cómo utilizar un servicio administrado como Private NAT Gateway para maximizar el consumo de IPv4 privada y permitir la comunicación a través de redes con una sobrecarga operativa mínima.

 

 

Descripción general de la solución:

Esta solución ilustra un mecanismo para conservar y administrar la asignación de espacio de direcciones IP RFC1918 utilizando el concepto de rangos IP enrutables y no enrutables. Además, la solución describe cómo conectar rangos CIDR superpuestos utilizando un Private NAT Gateway que se encuentra en el espacio IP no superpuesto (o enrutable).

Si una unidad de negocio dentro de una organización desea desplegar una carga de trabajo que exija el uso de miles de direcciones IP, la carga de trabajo se implementará en el rango de direcciones IP no enrutables. El espacio IP no enrutable es utilizado por muchas otras unidades de negocio y la naturaleza superpuesta de este espacio lo hace no enrutable. A la carga de trabajo se le asignará un pequeño rango de direcciones IP enrutables por el equipo centralizado de Administración de Direcciones IP (IPAM). El rango IP enrutable asignado puede ser utilizado por las unidades de negocio individuales para conectarse a la red consolidada. Al identificar espacios IP enrutables y no enrutables, use rangos CIDR compatibles, ya que los bloques CIDR que se pueden unir como CIDR secundario a una VPC están restringidos en función del bloque CIDR primario de la VPC.

El siguiente diagrama (Figura 1) muestra cómo utilizar AWS Transit Gateway y Private NAT para resolver el problema de agotamiento de IP y habilitar la comunicación entre dos Amazon Virtual Private Clouds (VPC) con rangos CIDR superpuestos.

 

Figura 1: Diagrama de Arquitectura

 

Revisión de la Arquitectura:

En esta sección, usaremos rangos de direcciones IP enrutables y no enrutables para establecer la conectividad de VPC-A a VPC-B con CIDR superpuestos usando Private NAT Gateway. Este recorrido se divide en tres secciones de la siguiente manera:

  1. Identificar el espacio de direcciones IP enrutable
  2. Asignar el espacio de direcciones IP
  3. Configurar el enrutamiento para habilitar la conectividad

 

  1. Identificar el espacio de direcciones IP enrutable:

Para rangos de direcciones no enrutables, cualquier rango de direcciones IPv4, incluyendo RFC 1918 o rangos IP enrutables públicamente se puede usar como el bloque CIDR secundario de la VPC. Varios equipos pueden usar el mismo rango de direcciones secundarias y, por lo tanto, debe tratarse como no enrutable. Tenga en cuenta que existen algunas restricciones a la hora de asignar direcciones IP en una VPC.

El espacio enrutable es cuidadosamente asignado por el equipo de administración de IP’s desde el pool de IP’s enrutables central. El espacio IP enrutable es único y se anuncia a la red consolidada de la organización a través de Transit Gateway o Virtual Private Gateway.

  1. Asignar el espacio de direcciones IP:

En este blog, el equipo del proyecto provee a las VPC el CIDR primario del rango enrutable y utiliza el rango CIDR no enrutable como el CIDR secundario. En este recorrido, las direcciones IP no enrutables y enrutables se asignan de la siguiente manera:

Para el rango de direcciones no enrutables hemos asignado 100.64.0.0/16, rango IP del Espacio de Direcciones Compartido (RFC 6598: es decir, 100.64.0.0/10) como el CIDR secundario tanto a VPC-A como a VPC-B. Para el rango de direcciones enrutables, hemos asignado 10.0.1.0/24 a VPC-A y 10.0.2.0/24 a VPC-B como rangos de direcciones principales desde RFC1918. Estos rangos CIDR se seleccionaron después de asegurar que son compatibles con las limitaciones para agregar un bloque CIDR secundario a VPC, como se describe en la sección “Descripción general de la solución”.

La asignación de direcciones IP tanto para VPC-A como para VPC-B se representa en el siguiente diagrama (Figura 2).

Figura 2: Asignación de direcciones IP

 

  1. Configurar el enrutamiento para habilitar la conectividad:

Ahora que hemos asignado los rangos de IP primario y secundario tanto para VPC-A como para VPC-B, configuremos el enrutamiento para habilitar la conectividad entre VPC-A y VPC-B. Estamos utilizando un Aplication Load Balancer (ALB) interno para exponer los recursos en la subred no enrutable dentro de VPC-B. Un Private NAT Gateway se implementa en VPC-A a NAT de origen, la IP no enrutable a una IP enrutable en VPC-A.

Para lograr este estado deseado de conectividad:

  1. El ALB se coloca en las subredes enrutables en VPC-B y las instancias de back-end en las subredes no enrutables en VPC-B.
  2. El Private NAT Gateway se crea en las subredes enrutables en VPC-A y la “SourceInstance-VPC-A” se crea en las subredes no enrutables en VPC-A para probar la conectividad.
  3. Se crea dos vinculaciones (attachments) de Transit Gateway (Transit Gateway Attachment), en subredes enrutables tanto de VPC-A como de VPC-B.

Ahora que entendemos la arquitectura, recorremos la vida de un paquete cuando “SourceInstance-VPC-A” en VPC-A se comunica con el ALB en VPC-B.

 

 

Figura 3: Flujo de paquetes

 

Flujo de paquetes desde SourceInstance-VPC-A al servidor web:

  • Paso 1: “SourceInstance-VPC-A” en VPC-A desea comunicarse con el servidor web en VPC-B, que se encuentra detrás del ALB en VPC-B. Como resultado, el paquete se origina en “SourceInstance-VPC-A” (IP de origen: 100.64.0.10/32) y se dirige al ALB. El “SourceInstance-VPC-A” realizará una búsqueda DNS en el nombre DNS de ALB para obtener la IP de destino (IP de destino: 10.0.2.x/32). El “Non-Routable Subnet-RT” en VPC-A está configurado para dirigir el tráfico destinado a 10.0.2.0/24 a la Private NAT Gateway.
  • Paso 2: El Private NAT Gateway traduce la IP de origen de una dirección IP no enrutable a una dirección IP enrutable y luego envía el tráfico al Transit Gateway Attachment en VPC-A ya que está asociada con la tabla de rutas “Routable Subnet-RT” en VPC-A.
  • Paso 3: Transit Gateway utiliza la ruta 10.0.2.0/24 y envía el tráfico a VPC-B Transit Gateway Attachment.
  • Paso 4: TGW ENI en VPC-B utiliza la ruta local VPC-B para reenviar el tráfico al ALB que luego reenvía el tráfico al servidor web detrás del ALB.

 

Pasos para devolver el tráfico del servidor web a la SourceInstance-VPC-A:

  • Paso 5: El servidor web detrás del ALB recibe la solicitud enviada por la instancia “SourceInstance-VPC-A” y devuelve una respuesta al ALB usando la ruta local VPC-B.
  • Paso 6: El ALB reenvía el tráfico de respuesta al accesorio de puerta de enlace de tránsito en VPC-B ya que está asociado con la tabla de rutas “Routable Subnet-RT” en VPC-B. Este tráfico de respuesta del ALB tiene la dirección IP de origen del ALB y la dirección IP de destino del Private NAT Gateway.
  • Paso 7: Transit Gateway utiliza la ruta 10.0.1.0/24 y envía el tráfico a VPC-A Transit Gateway Attachment.
  • Paso 8: El ENI TGW en VPC-A utiliza la ruta local para reenviar el tráfico al Private NAT Gateway, que luego traduce la IP de destino a la de la instancia “SourceInstance-VPC-A”. Este paquete se enruta a “SourceInstance-VPC-A” usando la ruta local.

 

Requisitos previos:

Para completar este laboratorio, necesita:

  1. Una cuenta de AWS
  2. Un usuario de IAM con acceso a los recursos de AWS, incluidos Systems Manager, AWS Transit Gateway, VPC y Amazon EC2.

 

Instrucciones de implementación:

En esta sección, demostramos cómo implementar la arquitectura de la figura 1, incluyendo Transit Gateway, VPC, Subredes, Private NAT Gateway, Transit Gateway Route Tables, VPC Route Tables, Application Load Balancer (ALB), EC2, etc., utilizando la plantilla de CloudFormation

 

  1. Haga clic en
  2. De forma predeterminada, el enlace lo lleva a la página Crear pila dentro de la consola de CloudFormation en la región del norte de Virginia (us-east-1) y la plantilla de CloudFormation de la solución se completa automáticamente. Puede cambiar la región en la esquina

    Figure 4: Crear pila de CloudFormation

  3. Ingrese un nombre para la pila en el Nombre de la pila y todos los parámetros requeridos se rellenan con los valores predeterminados. En nuestro entorno de demostración, hemos optado por nombrar a nuestra pila “PrivateNatGatewayDemo”. Haga clic en “Crear pila” para continuar.

Validación:

  1. Para conectarse a la instancia SourceInstance-VPC-A de forma segura mediante Session Manager, seleccione el ID de instancia en la consola EC2 y haga clic en el botón Conectar.
  2. Hay cuatro formas diferentes de conectarse a la instancia EC2. Seleccione la pestaña Administrador de sesiones y haga clic en Conectar que abre una nueva sesión basada en Shell en el navegador de su instancia. Tenga en cuenta que puede tardar unos minutos en poder conectarse a la instancia SourceInstance-VPC-A a través del Session Manager.

Figure 5: Conectar a EC2

  1. Para verificar que la “SourceInstance-VPC-A” pueda llegar al servicio web que se está ejecutando en VPC-B (100.64.0.0/24 subred no enrutable), utilice curl para conectar el nombre DNS ALB (Consulte el valor AlbHostName en la sección de salidas de la pila de CloudFormation).

curl <ALB DNS>

Limpieza:

Después de probar la conectividad, por favor, continúe y elimine la pila de CloudFormation para evitar cualquier costo asociado con los recursos lanzados por la plantilla de CloudFormation.

 

Conclusión:

En esta publicación, aprendió a usar rangos de IP CIDR enrutables y no enrutables junto con AWS Transit Gateway y Private NAT Gateway para abordar el problema de agotamiento de IP privada y habilitar la comunicación entre dos Amazon VPC con rangos CIDR superpuestos. Tenga en cuenta que esta ilustración muestra cómo establecer la conectividad entre dos VPC con CIDR superpuestos, lo mismo se puede extender a una VPC y una red local o a dos redes on-premise con CIDR superpuestos.

 

Este artículo fue traducido del Blog de AWS en Inglés

 

Sobre o autor

Chandini Penmetsa es arquitecta de infraestructura en la nube con AWS Professional Services. Le gusta ayudar a los clientes con la implementación de soluciones complicadas como parte de su viaje a la nube.

 

 

 

 

SaiJeevan Devireddy es arquitecto de soluciones en AWS y trabaja con socios del sector público. Le apasiona ayudar a los clientes a diseñar y construir sistemas de alta disponibilidad en AWS.

 

 

 

 

Traductor

Servio Reyes es arquitecto de soluciones en AWS México.

 

 

 

 

Revisores

Alejandro Guevara es Arquitecto de Soluciones en AWS México.

 

 

 

 

Efraín Castilla es arquitecto de soluciones con más de 20 años de experiencia en la industria. Su propósito es apoyar a los clientes de AWS en la creación de soluciones innovadoras utilizando los servicios de AWS, considerando las mejores prácticas.