Planeamiento del direccionamiento IP

Es importante que la organización tenga en cuenta el direccionamiento IP en Azure. Este planeamiento garantiza que el espacio de direcciones IP no se superponga entre las ubicaciones locales y las regiones de Azure.

Consideraciones de diseño:

• Los espacios de direcciones IP superpuestos entre las regiones locales y de Azure crearán importantes desafíos de contención.

• Azure VPN Gateway puede conectar sitios locales superpuestos con espacios de direcciones IP superpuestos a través de la funcionalidad de traducción de direcciones de red (NAT). Esta característica está disponible con carácter general en Azure Virtual WAN y en la versión independiente Azure VPN Gateway.

  

• Puede agregar un espacio de direcciones después de crear una red virtual. Este proceso no necesita una interrupción si la red virtual ya está conectada a otra red virtual a través del emparejamiento de redes virtuales. En su lugar, cada emparejamiento remoto necesita una operación de resincronización después de que el espacio de red haya cambiado.

• Azure reserva algunas direcciones IP dentro de cada subred. Céntrese en esas direcciones al cambiar el tamaño de las redes virtuales y las subredes englobadas.

• Algunos servicios de Azure requieren subredes dedicadas. Entre estos servicios se incluyen Azure Firewall y Azure VPN Gateway.

• Puede delegar las subredes a determinados servicios para crear instancias de un servicio dentro de la subred.

Recomendaciones de diseño:

• Planee de antemano los espacios de direcciones IP que no se superponen entre las regiones de Azure y las ubicaciones locales.

• Use las direcciones IP de la asignación de direcciones para las redes de Internet privadas, conocidas como direcciones RFC 1918.

• No use los siguientes intervalos de direcciones:

  • 224.0.0.0/4 (multidifusión)
  • 255.255.255.255/32 (difusión)
  • 127.0.0.0/8 (bucle invertido)
  • 169.254.0.0/16 (local de vínculo)
  • 168.63.129.16/32 (DNS interno)

• En entornos que tienen disponibilidad limitada de direcciones IP privadas, considere la posibilidad de usar IPv6. Las redes virtuales pueden ser solo IPv4 o de pila dual IPv4 + IPv6.

  

• No cree redes virtuales grandes como /16. Esto garantiza que no se desperdicia el espacio de direcciones IP. La subred IPv4 más pequeña admitida es /29 y la más grande es /2 cuando se utilizan definiciones de subred de enrutamiento entre dominios sin clase (CIDR). Las subredes IPv6 deben tener un tamaño exacto de /64.

• No cree redes virtuales sin planear el espacio de direcciones necesario de antemano.

• No use direcciones IP públicas para las redes virtuales, en especial si no pertenecen a su organización.

• Tenga en cuenta los servicios que va a usar, hay algunos servicios con IPs (Direcciones IP) reservadas, como AKS con redes de CNI

• Utilice zona de aterrizaje no enrutable redes virtuales de radios y el servicio Azure Private Link para evitar el agotamiento de IPv4.

Consideraciones sobre IPv6

Cada vez más organizaciones están adoptando IPv6 en sus entornos. El motivo de esta adopción es el agotamiento de espacios IPv4 públicos, la escasez de IPv4 privados, especialmente dentro de redes a gran escala, y la necesidad de proporcionar conectividad a clientes exclusivos de espacios IPv6. No hay ningún enfoque universal para adoptar IPv6. Sin embargo, hay procedimientos recomendados que se pueden seguir al planear IPv6 e implementarlo en las redes de Azure existentes.

Microsoft Cloud Adoption Framework para Azure ayuda a comprender las consideraciones que se deben tener en cuenta al crear sistemas en la nube. Para obtener información sobre los procedimientos recomendados de arquitectura para diseñar sistemas sostenibles, consulta Principios de diseño de zonas de aterrizaje de Azure. Para obtener recomendaciones detalladas y procedimientos recomendados sobre la arquitectura en la nube, incluidas implementaciones de arquitectura de referencia, diagramas y guías, consulta el Guía del Centro de Arquitectura para IPv6.

Consideraciones de diseño:

• Divide en fases la adopción de IPv6. Implementa IPv6 en función de tus necesidades empresariales. Recuerda que IPv4 e IPv6 pueden coexistir siempre que sea necesario.

• En escenarios en los que las aplicaciones dependen de servicios de infraestructura como servicio (IaaS) que tienen compatibilidad completa con IPv6, como las máquinas virtuales (VM), es posible el uso nativo de un extremo a otro de IPv4 e IPv6. Esta configuración evita complicaciones de traducción y proporciona la mayor parte de la información al servidor y a la aplicación.

  Se pueden implementar instancias de Azure Load Balancer con conexión a Internet de la SKU básica con una dirección IPv6. Esta configuración permite conectividad IPv6 nativa de un extremo a otro entre los clientes de Internet públicos y Azure Virtual Machines a través del equilibrador de carga. Este enfoque también facilita conexiones salientes nativas de un extremo a otro entre máquinas virtuales y los clientes de Internet públicos con IPv6 habilitado. Ten en cuenta que este enfoque requiere que todos los dispositivos de la ruta de acceso controlen el tráfico IPv6.

  El enfoque nativo de un extremo a otro es más útil para la comunicación directa entre servidores o entre cliente y servidor. No es útil para la mayoría de los servicios web y las aplicaciones, que normalmente están protegidos por firewalls, firewalls de aplicaciones web o servidores proxy inversos.

• Es posible que algunas implementaciones y aplicaciones complejas que usan una combinación de servicios de terceros, servicios de plataforma como servicio (PaaS) y soluciones de back-end no admitan IPv6 nativo. En estos casos, debe usar NAT/NAT64 o una solución de proxy IPv6 para habilitar la comunicación entre IPv6 e IPv4.

• Cuando la complejidad de la arquitectura de la aplicación u otros factores como los costes de entrenamiento se consideran importantes, es posible que interese seguir usando la infraestructura de solo IPv4 en el back-end e implementar una aplicación virtual de red de terceros (NVA) IPv4 de pila doble o de puerta de enlace IPv6 para la entrega de servicios.

  Una implementación típica que usa una aplicación virtual de red podría tener este aspecto:

  

Recomendaciones de diseño:

Visto con más detalle, este es el aspecto que podría tener una arquitectura típica:

• Implemente la NVA en Virtual Machine Scale Sets con orquestación flexible (VMSS Flex) para lograr resistencia y exponerlas a Internet a través de Azure Load-Balancer, que tiene un front-end de direcciones IP públicas.

  Las aplicaciones virtuales de red aceptan tráfico IPv4 e IPv6 y lo traducen en tráfico solo IPv4 para acceder a la aplicación en la subred de la aplicación. El enfoque reduce la complejidad del equipo de la aplicación y reduce la superficie expuesta a ataques.

• Implementa Azure Front Door para el enrutamiento global del tráfico web.

  Las funcionalidades de Azure Front Door incluyen el proxy de solicitudes de cliente IPv6 y el tráfico a un back-end de solo IPv4, como se muestra aquí:

  

Estas son las principales diferencias entre el enfoque de aplicaciones virtuales de red y el enfoque de Azure Front Door:

• Las aplicaciones virtuales de red las administra el cliente, funcionan en la capa 4 del modelo OSI y se pueden implementar en la misma red virtual de Azure que la aplicación, con una interfaz privada y pública.
• Azure Front Door es un servicio PaaS global de Azure y funciona en la capa 7 (HTTP/HTTPS). El back-end de la aplicación es un servicio accesible desde Internet que se puede bloquear para aceptar solo el tráfico de Azure Front Door.

En entornos complejos, se puede usar una combinación de ambos. Las aplicaciones virtuales de red se usan dentro de una implementación regional. Azure Front Door se usa para enrutar el tráfico a una o varias implementaciones regionales en diferentes regiones de Azure u otras ubicaciones accesibles desde Internet. Para determinar la mejor solución, se recomienda revisar las funcionalidades de Azure Front Door y la documentación del producto.

Bloques CIDR de red virtual IPv6:

• Se puede asociar un único bloque de enrutamiento entre dominios sin clases (CIDR) IPv6 al crear una nueva red virtual en una implementación de Azure existente en la suscripción. El tamaño de la subred para IPv6 debe ser /64. El uso de este tamaño garantiza la compatibilidad futura si se decide habilitar el enrutamiento de la subred a una red en el entorno local. Algunos enrutadores solo pueden aceptar rutas IPv6 /64.
• Si se tiene una red virtual existente que solo admite IPv4 y los recursos de la subred que están configurados para usar solo IPv4, se puede habilitar la compatibilidad con IPv6 para la red virtual y los recursos. La red virtual puede funcionar en modo de pila doble, lo que permite a los recursos comunicarse a través de IPv4, IPv6 o ambos. Las comunicaciones a través de IPv4 y a través de IPv6 son independientes entre sí.
• No se puede inhabilitar la compatibilidad con IPv4 para la red virtual y las subredes. IPv4 es el sistema de direccionamiento IP predeterminado para las redes virtuales de Azure.
• Asocia un bloque CIDR IPv6 a tu red virtual y subred o BYOIP IPv6. La notación CIDR es un método para representar una dirección IP y su máscara de red. Los formatos de estas direcciones son los siguientes:
  • Una dirección IPv4 individual es de 32 bits, con cuatro grupos de hasta tres dígitos decimales. Por ejemplo, 10.0.1.0.
  • Un bloque CIDR IPv4 tiene cuatro grupos de hasta tres dígitos decimales, de 0 a 255, separados por puntos y seguidos de una barra diagonal y un número comprendido entre 0 y 32. Por ejemplo, 10.0.0.0/16.
  • Una dirección IPv6 individual es de 128 bits. Tiene ocho grupos de cuatro dígitos hexadecimales. Por ejemplo, 2001:0db8:85a3:0000:0000:8a2e:0370:7334.
  • Un bloque CIDR IPv6 tiene cuatro grupos de hasta cuatro dígitos hexadecimales, separados por dos puntos, seguidos de dos puntos y seguidos de una barra diagonal y un número comprendido entre 1 y 128. Por ejemplo, 2001:db8:1234:1a00::/64.
• Actualiza las tablas de rutas para enrutar el tráfico IPv6. Para el tráfico público, crea una ruta que enrute todo el tráfico IPv6 desde la subred a VPN Gateway o una puerta de enlace de Azure ExpressRoute.
• Actualiza las reglas del grupo de seguridad para incluir reglas para direcciones IPv6. Al hacerlo, se permite que el tráfico IPv6 fluya hacia y desde las instancias. Si se tienen reglas de grupo de seguridad de red para controlar el flujo de tráfico hacia y desde la subred, se deben incluir reglas para el tráfico IPv6.
• Si el tipo de instancia no admite IPv6, usa una pila dual o implementa una aplicación virtual de red, como se ha descrito anteriormente, que se traduce de IPv4 a IPv6.

Herramientas de administración de direcciones IP (IPAM)

El uso de una herramienta IPAM puede ayudarle con la planificación de direcciones IP en Azure, ya que proporciona una administración centralizada y visibilidad, evitando solapamientos y conflictos en los espacios de direcciones IP. Esta sección le guía a través de consideraciones y recomendaciones esenciales al adoptar una herramienta IPAM.

Consideraciones de diseño:

Hay numerosas herramientas de IPAM disponibles para su consideración, según sus requisitos y el tamaño de su organización. Las opciones van desde tener un inventario básico basado en Excel hasta una solución basada en la comunidad de código abierto o productos empresariales completos con características avanzadas y soporte técnico.

• Tenga en cuenta estos factores al evaluar qué herramienta IPAM implementar:

  • Características mínimas requeridas por su organización
  • Costo total de propiedad (TCO), incluidas las licencias y el mantenimiento continuo
  • Seguimientos de auditoría, registro y controles de acceso basados en roles
  • Autenticación y autorización a través de Microsoft Entra ID
  • Accesible a través de la API
  • Integraciones con otras herramientas y sistemas de administración de red
  • Soporte técnico de la comunidad activa o el nivel de soporte técnico del proveedor de software

• Considere la posibilidad de evaluar una herramienta IPAM de código abierto como Azure IPAM. Azure IPAM es una solución ligera basada en la plataforma Azure. Detecta automáticamente el uso de direcciones IP en el inquilino de Azure y le permite administrarlo todo desde una interfaz de usuario centralizada o a través de una API RESTful.

• Considere el modelo operativo de su organización y la propiedad de la herramienta IPAM. El objetivo de implementar una herramienta IPAM es simplificar el proceso de solicitar nuevos espacios de direcciones IP para los equipos de aplicaciones sin dependencias y cuellos de botella.

• Una parte importante de la funcionalidad de la herramienta IPAM es realizar un inventario del uso del espacio de direcciones IP y organizarlo lógicamente.

Recomendaciones de diseño:

• El proceso de reserva de espacios de direcciones IP no superpuestos debe admitir la solicitud de diferentes tamaños en función de las necesidades de las zonas de aterrizaje de aplicaciones individuales.

  • Por ejemplo, podría adoptar el tamaño camiseta para facilitar a los equipos de aplicación la descripción de sus necesidades:
    • Pequeño: /24 256 direcciones IP
    • Medio: /22 1024 direcciones IP
    • Grande: /20 4096 direcciones IP

• La herramienta IPAM debe tener una API para reservar espacios de direcciones IP no superpuestos para admitir un enfoque de infraestructura como código (IaC). Esta característica también es fundamental para la integración sin problemas de IPAM en el proceso de venta de suscripciones, lo que reduce el riesgo de errores y la necesidad de intervención manual.

  • Un ejemplo de un enfoque de IaC es Bicep con su funcionalidad de script de implementación o orígenes de datos de Terraform para capturar datos dinámicamente de la API de IPAM.

• Cree una disposición sistemática para los espacios de direcciones IP mediante su estructuración según las regiones de Azure y los arquetipos de carga de trabajo, lo que garantiza un inventario de red limpio y rastreable.

• El proceso de retirada de las cargas de trabajo debe incluir la eliminación de espacios de direcciones IP que ya no se usan, que posteriormente se pueden reasignar para las próximas cargas de trabajo nuevas, lo que promueve un uso eficaz de los recursos.