Buenas prácticas para el diseño de IPv4 para su Amazon VPC

Por Claudia Izquierdo, Solutions Architect para Public Sector en AWS y Giovanni Rodríguez, Solutions Architect para Public Sector en AWS

Cada día son más las empresas aprovechando las ventajas de AWS para desplegar ágilmente sus aplicaciones. Por esto es primordial contar con conocimientos y recomendaciones básicas de diseño de red. En este blog nos enfocaremos en el diseño y buenas prácticas de direccionamiento IPv4 para Amazon VPC.  Amazon Virtual Private Cloud (Amazon VPC) es un servicio que permite lanzar recursos de AWS en una red virtual aislada de forma lógica. Puede controlar todos los aspectos del entorno de red virtual como la selección de su propio rango de direcciones IP, la creación de subredes y la configuración de tablas de enrutamiento y gateways de red. Puede utilizar tanto IPv4 como IPv6 para la mayoría de los recursos de la nube virtual privada, lo que ayuda a garantizar el acceso seguro y fácil a los recursos y las aplicaciones.

Este blogpost es parte de una serie de blogs para las buenas prácticas de redes en Amazon VPC, los otros temas de la serie son:

• Buenas prácticas para el diseño de IPv6 para su Amazon VPC.
• Buenas prácticas para la distribución de rutas en las tablas de enrutamiento para su Amazon VPC.
• Buenas prácticas para el diseño de NAT de su Amazon VPC

Internet Protocol (IP) es un protocolo de la capa de red del modelo OSI cuya finalidad es la comunicación bidireccional, inbound y outbound, para la transferencia de datos por medio de diferentes redes físicas estandarizadas. La versión 4 de IP (IPv4) es la más usada.

Modelo OSI

Una dirección IP por medio de un nombre numérico identifica a una interfaz de red. El direccionamiento IPv4 permite la conectividad y comunicación efectiva entre dispositivos de red lógicos y dispositivos de red físicos, por medio de dicho nombre numérico lógico que le es asignado a estos dispositivos para diferenciarlos entre sí (ver imagen Encabezado del protocolo IPv4 a continuación).

Encabezado del protocolo IPv4

Actualmente las direcciones IP son encontradas en versión 4 (IPv4) y versión 6 (IPv6). Las direcciones IPv6 iniciaron debido al crecimiento acelerado de internet, el cual generó el agotamiento prematuro de las direcciones IPv4. Éste es el motivo principal del inicio del direccionamiento IPv6, para permitir una mayor disponibilidad de direcciones IP. Una dirección IPv6 tiene una estructura de direccionamiento más extensa. Una comparación entre IPv4 e IPv6 es la siguiente:

Comparación en diseño entre una dirección IPv4 e IPv6

Se suele llamar simplemente direcciones IP a las direcciones IPv4.  También se suele llamar simplemente IP a una dirección IP.  Durante este blogpost seguiremos estas convenciones, y por tanto utilizaremos indistintamente estos términos.

Notación CIDR

Classless Inter-Domain Routing (CIDR) o prefijo de red es la representación por medio de un número con estructura A.B.C.D/X, donde “X” es un número entre 0 a 32 el cual se conforma por la suma de los bits 1 de la máscara de red y así representar y delimitar el segmento de red de una dirección IPv4. Los primeros cuatro números decimales se interpretan como una dirección IPv4, y el número tras la barra es el prefijo de red.

Por ejemplo:

Un dispositivo con la dirección IPv4 192.168.10.12/24 pertenece a la red 192.168.10.0/24

La máscara de red

Las direcciones IP tienen como funcionalidad ser un valor lógico que permita a los dispositivos leerlo, y distinguir el siguiente salto al que se deben de reenviar los paquetes del proceso que se está llevando a cabo en la red. Al mismo tiempo, a todo dispositivo de red le es asignada una dirección IP que pertenece a una red. La máscara de red es el valor utilizado para diferenciar la parte de red y la parte de host en una dirección IP, utiliza la misma sintaxis de una dirección IP. Además sus finalidad es delimitar la parte de red y host de una dirección IP, y esto lo logra usando bits en valor 1 para la parte de red y bits en valor 0 para la parte de host, como se puede observar en la tabla Diferentes variaciones en la máscara de red.

Al comprender el funcionamiento de la máscara de red podemos usar las diferentes variaciones para cambiar la cantidad de direcciones IP disponibles que puedan pertenecer a una misma red, a este proceso se le llama subnetting o VLSM (Variable Lenght Subnet Mask):

Diferentes variaciones de la máscara de red

El prefijo de red es la suma total de bits en valor 1 que conforman la sección de red de una dirección IP. En el ejemplo anterior el prefijo de red es 24:

Segmentación de una dirección IPv4

Los bits en valor 0 de la máscara de red representan al segmento de host y los bits en valor 1 el segmento de red. Así observamos que la red a la que pertenece el host 192.168.10.12/24 es la 192.168.10.X/24.

Direccionamiento IPv4 Público y Privado

Dentro de la clasificación de direccionamiento IPv4 en clase A, B y C encontramos las IPv4 públicas y privadas. Según el estándar RFC 1918 las direcciones utilizadas para el direccionamiento privado son los siguientes rangos:

Rango de direccionamiento IPv4 privado

Las redes privadas son las que pueden ser asignadas y repetidas dentro de intranets y así las direcciones IPv4 restantes de estas clases (como 52.72.29.133 ó 3.82.125.247 de AWS) son públicas y son aquellas que no se pueden repetir ya que son utilizadas para navegar en internet y así no causar confusión en la comunicación de extremo a extremo. Éste es el motivo de porqué también al momento de construir sus VPCs debe distribuir este rango de direccionamiento privado para las redes que decida utilizar en sus diseños.

NAT

NAT (Network Address Translation) es un método para traducir una dirección IP a otra y/o un número de puerto a otro.  El caso más común es traducir direcciones IPv4 privadas a públicas. El NAT opera al momento de que el tráfico de la red viaja a través de un dispositivo de frontera que ejecuta la traducción, y mantiene la trazabilidad de los paquetes en la comunicación bidireccional.

Adicionalmente al direccionamiento IP privado de una VPC, algunos servicios como las instancias EC2 pueden tener asignadas direcciones IP públicas (IPV4 o IPv6). De esta forma, por ejemplo, es posible iniciar una conexión por SSH desde internet a una instancia EC2 utilizando un emulador de terminal, una vez se han configurado las credenciales y permisos correspondientes. Las direcciones IPv6 son únicas de forma global y, por lo tanto, son públicas de manera predeterminada.

Si desea que su instancia pueda obtener acceso a internet pero también evitar que los recursos de internet inicien comunicaciones con su instancia, utilice un NAT Gateway en el caso de IPv4; o un Egress-Only Internet Gateway, en el caso de IPv6. Este escenario de NAT con IPv6 podría llevarse a cabo por la necesidad de enmascarar una dirección IPv6 con otra IPv6, o en procesos como NAT64 en donde se realiza el NAT de una dirección IPv6 a una IPv4 y viceversa. Por compatibilidad es necesario ese cambio para el transporte de los paquetes en una red ya que existen redes donde están construidos en una parte con IPv4 y en otra con IPv6. El NAT en IPv4 permite tener una única dirección IPv4 pública y así enmascarar a miles de direcciones IPv4 privadas y de esta forma navegar por internet. Esta técnica ha ayudado a disminuir el agotamiento de direcciones IPv4.

Las direcciones IP tienen que ser únicas en una misma red, es decir, no podemos traslaparlas. Para la conexión de dos redes (por ejemplo, en una migración de aplicaciones entre on-premise y AWS) es necesario que los CIDRs de intranet diferentes para no traslaparse. Sin embargo, éste no siempre es el caso, lo que conlleva al uso de NAT.

Distribución de direcciones IPv4

La distribución de direcciones IP dentro de una red se entiende con este ejemplo:

Distribución de direccionamiento utilizable IPv4

La dirección de red y la dirección de broadcast son reservadas de cada red y no pueden ser asignadas a dispositivos debido a que así es el diseño con el que fueron creadas las IPs. La dirección de red es utilizada para indicar la red a la que pertenecen las direcciones IPs utilizables que se asignan a los dispositivos de red y la dirección de broadcast es utilizada cuando se necesita realizar una comunicación a todos los dispositivos activos que pertenecen a esa red.

AWS reserva en cada subred, a la fecha de publicación de este blogpost, cinco (5) direcciones IP, por lo que el ejemplo anterior quedaría distribuido de la siguiente manera en una subred de Amazon VPC:

Distribución de direccionamiento utilizable IPv4 en una subred de Amazon VPC

Subnetting o VLSM

Esta técnica nos permite optimizar la cantidad de hosts que constituyen una subred en IPv4 y al mismo tiempo contar con más subredes para distribuir en la red. Esta distribución de direcciones IP intrínsecamente segmenta la red y así también permite controlar de mejor manera el tráfico que viaja a través de las subredes y con ello hacerlo más seguro. Al realizar subnetting de la red privada de ejemplo, se distribuye de la siguiente forma:

Distribución de subredes de la red 192.168.10.0/24

VLSM es una técnica que personaliza las diferentes subredes en una red para optimizar el diseño de direccionamiento IPv4 por cada subred.

Los siguientes conceptos ayudarán a comprender el diseño de red en una VPC:

• Subred pública: aquella en la que los recursos que tienen acceso desde internet (inboud) y viceversa (outbound).
• Subred privada: aquella en la que los recursos pueden o no tener conexión a internet, y de ser necesario es solamente para permitir conexiones outbound (desde la subred hacia internet), por medio de NAT Gateway.
• Zona de disponibilidad (AZ): conjunto de varios data centers conectados entre sí. Cada AZ tiene por lo menos un centro de datos con alimentación, refrigeración y seguridad física independientes y está conectada con las demás AZs de la misma región a través de redes redundantes de latencia ultrabaja.
• Región: consta de varias AZs aisladas y separadas físicamente dentro de un área geográfica.

Vea un ejemplo en donde se necesita crear dos Amazon VPC con servicios desplegados en dos regiones diferentes, con alta disponibilidad en cada uno, y con capacidad de separar equipos con acceso desde internet de los equipos cuyo acceso debe estar restringido.  Para esto se emplea la técnica de VLSM de la siguiente manera:

Solicitud de la distribución de números de hosts por subred

VPC 1: 10.0.0.0/16

• Subred privada B.1: 2,000 host
• Subred privada B.2: 1,000 host
• Subred pública A.1: 500 host
• Subred pública A.2: 200 host

VPC 2: 172.16.0.0/16

• Subred privada D.1: 1,500 host
• Subred privada D.2: 600 host
• Subred pública C.1: 100 host
• Subred pública C.2: 50 host

Tabla de conversión binario a decimal de 8 bits 

Paso 1: Cálculo de máscara de red personalizada en cada subred

VPC 1: 10.0.0.0/16

• Subred privada B.1: 2¹¹ – 5   = 2,048 – 5          = 2,043 host
• Subred privada B.2: 2¹⁰ – 5   = 1,024 – 5          = 1,019 host
• Subred pública A.1: 2⁹ – 5     = 512 – 5             = 507 host
• Subred pública A.2: 2⁸ – 5     = 256 – 5             = 251 host

VPC 2: 172.16.0.0/16

• Subred privada D.1: 2¹¹ – 5   = 2,048 – 5          = 2,043 host
• Subred privada D.2: 2¹⁰ – 5   = 1,024 – 5          = 1,019 host
• Subred pública C.1: 2⁷ – 5     = 128 – 5             = 123 host
• Subred pública C.2: 2⁶ – 5     = 64 – 5                = 59 host

Paso 2: Asignar máscara de red personalizada a cada subred

VPC 1: 10.0.0.0/16

• Subred privada B.1: 32 – 11 = /21
• Subred privada B.2: 32 – 10 = /22
• Subred pública A.1: 32 – 9    = /23
• Subred pública A.2: 32 – 8    = /24

VPC 2: 172.16.0.0/16

• Subred privada D.1: 32 – 11 = /21
• Subred privada D.2: 32 – 10 = /22
• Subred pública C.1: 32 – 7    = /25
• Subred pública C.2: 32 – 6    = /26

Paso 3: Rangos de direccionamiento IP

Distribución de direccionamiento IPv4 en subredes en VPCs

Distribución final de direcciones IPv4 en las subredes

Otras consideraciones para diseñar el direccionamiento IPv4 en su Amazon VPC

Para el diseño adecuado de las direcciones IPv4 debe también debe tener en cuenta las siguientes consideraciones al trabajar con una Amazon VPC:

1. El buen diseño de una distribución de direccionamiento IPv4 indica que las redes que se desean comunicar o enviar tráfico entre sí no se deben de traslapar, por lo que esto también se debe de tomar en consideración en las arquitecturas híbridas en donde se tenga una conexión temporal o permanente hacia una red o redes on-premise.
2. La red y CIDR asignado a una VPC debe ser considerada inicialmente para que entregue la cantidad necesaria de subredes e IPs disponibles a utilizar en cada subred.
3. Amazon VPC permite trabajar con CIDR del rango /16 al /28 tanto para las VPCs como para las subredes. Se debe tomar en consideración que el prefijo de red de una subred debe ser mayor que el de la VPC en la que se encuentra. Como por ejemplo una red con CIDR /20 no puede tener subredes con CIDR /19.
4. No es posible cambiar la distribución de direcciones IPv4 asignada a una Amazon VPC después de su creación.
5. No es posible cambiar el bloque CIDR asignado a una VPC. Existe la opción de agregar un bloque de CIDR secundario (ver el link para conocer cuáles bloques CIDR es posible agregar según el bloque CIDR inicial asignado a una VPC) y así tener disponibilidad de otra red en la misma VPC desde la que se pueden distribuir más subredes.
6. Es obligatorio asignar un bloque CIDR IPv4 a una VPC, y opcionalmente se puede trabajar también con direccionamiento IPv6, conformando así una tecnología Dual-Stack, en donde las redes de IPv4 e IPv6 conviven en la misma VPC pero manejan procesos independientes.
7. Las VPCs son regionales y por defecto no se pueden tener más de cinco (5) VPCs por región. De ser necesario un mayor número de VPCs es posible ingresar un ticket para solicitar un aumento como caso de soporte a AWS. Para obtener más información, consulte Cuotas de Amazon VPC.
8. Cada subred de la VPC creada solamente se puede asignar a una (1) zona de disponibilidad.
9. Amazon VPC siempre reserva cinco (5) direcciones IPv4 por cada subred.
10. Cada cuenta de AWS tiene una VPC predeterminada en cada región, lista para usarse y crear instancias de EC2, con las siguientes características de red:
    • Una VPC con un bloque de CIDR de IPv4 de tamaño /16 (31.0.0/16) en cada región.
    • Cada zona de disponibilidad con una subred predeterminada de tamaño /20.
    • Un Internet Gateway conectado a la VPC predeterminada para la salida a internet de las subredes creadas.
    • Una ruta en la tabla de enrutamiento que apunta todo el tráfico (0.0.0/0) al Internet Gateway asignada a las subredes creadas por defecto.

Se recomienda no utilizar esta VPC predeterminada en arquitecturas o ambientes complejos, sino diseñar su propia VPC para evitar traslapes de direccionamiento IPv4 ya que todas las regiones utilizan el mismo rango para su VPC predeterminada.

Conclusiones y siguientes pasos

Las direcciones IPv4 permiten la comunicación efectiva entre los dispositivos lógicos y físicos de una red. Las buenas prácticas y conocimientos de diseño en IPv4 permiten evitar situaciones a futuro donde existan complicaciones o trabajos adicionales que llevar a cabo debido a una mala práctica en la distribución de direcciones IPv4 inicialmente.

Ahora ya puede diseñar y construir su Amazon VPC llevando a cabo las buenas prácticas y cálculos correspondientes para sus direcciones IPv4 desde el inicio.

Sobre los autores

Claudia Izquierdo es Arquitecta de Soluciones en Amazon Web Services para el Sector Público. Claudia ha ayudado a múltiples entidades de gobierno y organizaciones no gubernamentales en Latinoamérica a cumplir con sus misiones y objetivos de negocio. Le apasionan los temas de cloud, networking, seguridad y ciberseguridad de la información. Claudia también es una instructora Cisco premiada mundialmente y apoya en proyectos para más mujeres en tecnología.

Giovanni Rodríguez es Arquitecto de Soluciones en Amazon Web Services para el Sector Público.  Giovanni ha ayudado a múltiples entidades de gobierno, organizaciones no gubernamentales, y empresas privadas, en Latinoamérica, a cumplir con sus misiones y objetivos de negocio.  Le apasionan los temas de cloud, seguridad de la información, y analítica.

Revisores Técnicos

Mauricio Romero es Arquitecto de Soluciones Sr. en Amazon Web Services para el Sector Público.  Mauricio ha trabajado en diferentes proyectos de gobierno electrónico y transformación digital.  Le apasionan los temas de transformación digital, adopción de nube y seguridad de la información.

Laura es parte del equipo de AWS Solutions Architect desde junio de 2017. Comenzó en la oficina de Colombia, siendo la segunda contratada en AWS. En 2019, Laura se unió a los arquitectos de soluciones de AWS para el equipo de empresas medianas en el Reino Unido. Antes de Amazon, Laura trabajó en empresas como Cisco e IBM. Laura también es conocida por su pasión por las mujeres en los temas de TI e I&D.