En este artículo se describe cómo minimizar el consumo de espacio de direcciones privadas cuando compila una red de gran tamaño en Azure. Es posible que tenga que minimizar el consumo de espacio de direcciones si no se establecen directivas de asignación adecuadas y se ha quedado sin direcciones IP privadas para asignarlas a redes virtuales de Azure. Este artículo presenta dos métodos para la administración adecuada de direcciones IP en Azure.
Detalles del escenario
Las redes corporativas por lo general usan espacios de direcciones que se encuentran en los rangos de direcciones IPv4 privadas que están definidas en el RFC 1918. Los intervalos de direcciones son 10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16. En entornos locales, estos intervalos proporcionan suficientes direcciones IP para satisfacer los requisitos de incluso las redes más grandes. Como resultado, muchas organizaciones desarrollan prácticas de administración de direcciones que priorizan las configuraciones de enrutamiento sencillas y los procesos ágiles para la asignación de IP. El uso eficaz del espacio de direcciones no es una prioridad.
En la nube, las redes híbridas de gran tamaño son fáciles de compilar, y algunos patrones arquitectónicos comunes, como los microservicios o la contenedorización, podrían dar lugar a un mayor consumo de direcciones IP. Por lo tanto, es importante ajustar esos procedimientos de administración de direcciones. En un entorno de nube, trate las direcciones IPv4 privadas como un recurso limitado.
Intervalos de direcciones IP de Azure Virtual Network
En las redes virtuales de Azure, se recomienda usar los bloques de direcciones definidos por RFC 1918. Estos bloques de direcciones son para redes privadas de uso general y no se pueden enrutar en la red pública de Internet.
Puede usar otros intervalos, pero antes de usar esos intervalos en la red virtual, lea la documentación de la entidad de números asignados a Internet (IANA) para comprender las posibles implicaciones para su entorno. Puede usar los siguientes rangos:
- Espacio de direcciones compartido definido por RFC 6598 para la traducción de direcciones de red (NAT) a nivel de operador que se trata como espacio de direcciones privado en Azure Virtual Network. El bloque de direcciones es 100.64.0.0/10.
- Direcciones IP públicas y enrutables de Internet que su organización no posee. Esta práctica no se recomienda porque los recursos de la red virtual no pueden acceder a los puntos de conexión de Internet que se exponen a través de las direcciones IP públicas.
- Bloques de direcciones de propósito especial definidos por IANA, como 192.0.0.0/24, 192.0.2.0/24, 192.88.99.0/24, 198.18.0.0/15, 198.51.100.0/24, 203.0.113.0/24, and 233.252.0.0/24.
Nota:
Windows bloquea el intervalo de direcciones IP de clase E 240.0.0.0/4 para asignarlo a una NIC y tiene problemas de compatibilidad en el caso de Linux. Por lo tanto, aunque puede ser posible asignar mediante programación un rango a una virtual network, no recomendamos su utilización en virtual network de Azure.
Nota:
Los intervalos anteriores no proporcionan una solución a largo plazo para las organizaciones que tienen problemas de agotamiento de IPv4. En ese caso, deberá minimizar el consumo de espacio de direcciones privado.
No puede usar los siguientes intervalos de direcciones IP en redes virtuales de Azure:
- 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)
Alineación de la zona de aterrizaje de Azure
Las recomendaciones de este artículo son para escenarios basados en la Arquitectura de la zona de aterrizaje de Azure. Las guías parten de la base de que:
- Cada región tiene una topología en estrella tipo hub-and-spoke.
- Las redes en estrella tipo hub-and-spoke que se encuentran en regiones diferentes se conectan entre sí a través del emparejamiento de red virtual global o las conexiones con el mismo circuito o circuitos de Azure ExpressRoute.
- Las redes hub-and-spoke se conectan a las sedes locales mediante una combinación de circuitos ExpressRoute y VPN de sitio a sitio.
El siguiente diagrama muestra un ejemplo de arquitectura. Las recomendaciones son igualmente aplicables a las redes que se basan en Azure Virtual WAN, que también tienen redes en estrella tipo hub-and-spoke en cada región.
Descargar un archivo PowerPoint de esta arquitectura.
En un escenario basado en la arquitectura de la zona de aterrizaje de Azure, las aplicaciones se implementan en su propia zona de aterrizaje. Cada zona de aterrizaje contiene una red virtual de radio que está emparejada con un centro regional. Las redes virtuales de radio son una parte integral de la red corporativa y se asignan direcciones IPv4 enrutables. Estas direcciones son únicas en toda la red corporativa. Por lo tanto, todos los componentes arquitectónicos que se implementan en Azure Virtual Network consumen direcciones IPv4 en el espacio de direcciones de la red corporativa, incluso si solo algunos componentes exponen puntos de conexión que deben ser accesibles desde toda la red corporativa. Estos componentes arquitectónicos pueden ser máquinas virtuales, aplicaciones virtuales de red (NVA) de terceros o servicios de plataforma como servicio (PaaS) insertados en red virtual.
Para el resto de este artículo, el componente front-end hace referencia a un componente de aplicación accesible desde toda la red corporativa o desde fuera de la zona de aterrizaje del componente. Se entiende por Componente back-end un componente de aplicación que no expone puntos de conexión en la red corporativa y que solo necesita ser accesible desde su propia zona de aterrizaje. Por ejemplo, una aplicación web que expone un punto de conexión es un componente de front-end y una base de datos que no expone un punto de conexión es un componente de back-end.
En las secciones siguientes se describen dos métodos para minimizar el consumo de espacio de direcciones privadas al crear redes grandes en Azure.
Método 1: Redes virtuales de radio de zona de aterrizaje no enrutables
La dirección IP RFC 1918 se bloquea fuera del espacio de direcciones IPv4 de 32 bits y los convierte en no enrutables en la red pública de Internet, por lo que puede reutilizarlos en varias redes privadas para la comunicación interna. Este método se basa en el mismo principio que se aplica al espacio de direcciones privado. Uno o varios intervalos de direcciones se tallan en todo el espacio de direcciones privadas que usa la organización y declaran que no se pueden enrutar dentro de la red corporativa de la organización. Los intervalos de direcciones se reutilizan en varias zonas de aterrizaje. Como resultado, cada zona de aterrizaje:
- Se asigna un espacio de direcciones enrutable que se compone de uno o varios intervalos de direcciones. Su organización administra de forma centralizada los intervalos de direcciones y los asigna de forma única a una zona de aterrizaje para comunicarse con la red corporativa. Las direcciones del espacio enrutable se asignan a los componentes front-end.
- Puede usar el espacio de direcciones no enrutable, que es los intervalos de direcciones que su organización declara no enrutables en la red corporativa. Puede usar estos intervalos reservados para la comunicación interna en todas las zonas de aterrizaje. Las direcciones del espacio no enrutable se asignan a los componentes de back-end.
En una red en estrella tipo hub-and-spoke de Azure administrada por el cliente o basada en Virtual WAN, dos o más redes virtuales radiales no pueden tener espacios de direcciones IP superpuestos. Los bloques de direcciones no enrutables no se pueden asignar a un radio de zona de aterrizaje. El emparejamiento de redes virtuales no es transitivo, por lo que una red virtual de radio de zona de aterrizaje puede emparejarse con una red virtual de radio de segundo nivel que tenga un espacio de direcciones no enrutable. En el diagrama siguiente se muestra la topología de red virtual dual para las zonas de aterrizaje.
Descargue un archivo PowerPoint de esta arquitectura.
Cada zona de aterrizaje de la aplicación contiene dos redes virtuales emparejadas. Una red virtual tiene direcciones IP enrutables y hospeda componentes de front-end. La otra red virtual tiene direcciones IP no enrutables y hospeda componentes back-end. El radio de la zona de aterrizaje enrutable se empareja con el centro regional. El radio de zona de aterrizaje no enrutable se empareja con el radio de zona de aterrizaje enrutable. El emparejamiento de redes virtuales no es transitivo, por lo que los prefijos no enrutables no son visibles para el centro regional o el resto de la red corporativa. Las redes virtuales enrutables no pueden usar los intervalos de direcciones no enrutables. Algunas organizaciones tienen espacio de direcciones fragmentado que ya está asignado a redes enrutables. Puede resultar difícil identificar bloques de direcciones grandes sin usar y declararlos no enrutables. En ese caso, considere las direcciones no utilizadas que no se incluyen en el espacio de direcciones RFC 1918. En el diagrama anterior se proporciona un ejemplo de direcciones NAT de nivel de operador, como RFC 6598, en redes virtuales de radio no enrutables.
Migración de una sola zona de aterrizaje de red virtual
El emparejamiento de redes virtuales proporciona conectividad completa de capa 3 entre dos redes virtuales emparejadas. Los componentes de aplicación implementados en zonas de aterrizaje de red virtual única tradicionales que se comunican entre sí a través de IP se pueden mover libremente entre redes virtuales radiales enrutables y no enrutables en una zona de aterrizaje. En esta sección se describen dos patrones de migración típicos.
Las siguientes aplicaciones se exponen a través de controladores de entrega de aplicaciones de capa 7:
Descargue un archivo PowerPoint de esta arquitectura.
Las aplicaciones expuestas a través de controladores de entrega de aplicaciones de capa 7 se pueden mover al radio no enrutable. El controlador de entrega de aplicaciones es el único componente front-end que debe residir en el radio de la zona de aterrizaje enrutable.
Las siguientes aplicaciones se exponen a través de un equilibrador de carga de Azure:
Descargue un archivo PowerPoint de esta arquitectura.
Si una aplicación expone sus puntos de conexión a través de un equilibrador de carga de Azure, las instancias de proceso que forman parte del grupo de back-end del equilibrador de carga deben permanecer en la misma red virtual. Los equilibradores de carga de Azure solo admiten instancias de back-end en su propia red virtual.
Dependencias de salida
Los componentes de back-end de una aplicación no necesitan ser accesibles ni recibir conexiones entrantes desde la red corporativa, pero a menudo tienen dependencias salientes. Es posible que los componentes del back-end necesiten conectarse a puntos de conexión que se encuentran fuera de sus zonas de aterrizaje en casos como la resolución DNS, los controladores de dominio de los servicios de dominio de Active Directory, el acceso a puntos de conexión de aplicaciones que están expuestos por otras zonas de aterrizaje o el acceso a instalaciones de registro o copia de seguridad.
Nota:
La comunicación de cliente a controladores de dominio (DC) de servicios de dominio de Active Directory (ADDS) sobre NAT ha sido probada y es compatible, la comunicación de DC a DC no ha sido probada y no es compatible, como se detalla más adelante en Descripción de los límites de compatibilidad para Active Directory sobre NAT.
Cuando los servicios inician conexiones en redes virtuales de radio no enrutables, debe implementar NAT de origen (SNAT) para las conexiones detrás de una dirección IP enrutable. Para implementar SNAT, implemente un dispositivo compatible con NAT en la red virtual de radio enrutable. Cada zona de aterrizaje ejecuta su propia NVA NAT dedicada. Hay dos opciones para implementar SNAT en una zona de aterrizaje: Azure Firewall o NVA de terceros. En ambos casos, todas las subredes del radio no enrutable deben estar asociadas a una tabla de rutas personalizada. Como se muestra en el diagrama siguiente, la tabla de rutas reenvía el tráfico a destinos fuera de la zona de aterrizaje al dispositivo SNAT. Azure NAT Gateway no admite SNAT para el tráfico destinado al espacio de direcciones IP privadas, como el espacio RFC 1918.
Descargue un archivo de PowerPoint de esta arquitectura.
Implementación de SNAT a través de Azure Firewall
Azure Firewall:
- Proporciona alta disponibilidad.
- Proporciona escalabilidad nativa y tres SKU diferentes. SNAT no es una tarea que consume muchos recursos, por lo que primero debe tener en cuenta la SKU básica. Para las zonas de aterrizaje que requieren grandes volúmenes de tráfico saliente desde el espacio de direcciones no enrutables, use la SKU estándar.
- Realiza SNAT para el tráfico detrás de las direcciones IP privadas de cualquiera de sus instancias. Cada instancia puede usar todos los puertos sin privilegios.
En el diagrama siguiente se muestra el diseño de la zona de aterrizaje para implementar SNAT en una topología de red en estrella tipo hub-and-spoke mediante Azure Firewall.
Descargue un archivo de PowerPoint de esta arquitectura.
Debe asociar todas las subredes del radio no enrutable a una tabla de rutas personalizada para enviar tráfico a destinos fuera de la zona de aterrizaje a Azure Firewall.
El diagrama siguiente muestra la disposición de la zona de aterrizaje para implementar SNAT en una red hub-and-spoke basada en Virtual WAN utilizando Azure Firewall.
Descargue un archivo de PowerPoint de esta arquitectura.
Debe asociar todas las subredes en el radio no enrutable o los radios que no están conectados a Virtual WAN, con una tabla de rutas personalizada para enviar tráfico a destinos fuera de la zona de aterrizaje a Azure Firewall.
Para ambos diseños, para proporcionar a los recursos del radio no enrutable acceso a direcciones IP enrutables fuera de su zona de destino, debe implementar Azure Firewall con la opción Realizar SNAT establecida en Siempre en cada radio enrutable de la zona de destino. Puede encontrar instrucciones sobre cómo configurar Azure Firewall para implementar SNAT en todas las conexiones recibidas en la documentación pública. En la captura de pantalla siguiente se muestra la configuración necesaria para usar Azure Firewall como un dispositivo NAT para las conexiones iniciadas por recursos en redes virtuales de radio no enrutables.
Implementación de SNAT a través de NVA de terceros
Las NVA de terceros con funcionalidades NAT están disponibles en Azure Marketplace. Proporcionan lo siguiente:
- Control granular sobre el escalado horizontal y el escalado horizontal.
- Control pormenorizado del grupo NAT.
- Directivas NAT personalizadas, como el uso de diferentes direcciones NAT en función de las propiedades de la conexión entrante, como la dirección IP de origen o de destino.
Tenga en cuenta las recomendaciones siguientes:
- Para lograr una alta disponibilidad, implemente clústeres con al menos dos NVA. Use un equilibrador de carga de Azure para distribuir las conexiones entrantes desde la red virtual de radio no enrutable a las NVA. Se requiere una regla de equilibrio de carga de puertos de alta disponibilidad porque el clúster implementa SNAT en todas las conexiones que salen de la zona de aterrizaje. Azure Standard Load Balancer admite reglas de equilibrio de carga de puertos de alta disponibilidad.
- La pila Azure SDN admite NVA de brazo único y de brazo doble. Se prefieren NVA de un solo brazo porque reducen el consumo de espacio de direcciones en las redes virtuales de radio enrutables.
El diagrama siguiente se muestra el diseño de la zona de aterrizaje para implementar SNAT en una topología de red en estrella tipo hub-and-spoke mediante NVA de terceros.
Descargue un archivo de PowerPoint de esta arquitectura.
En el diagrama siguiente se muestra el diseño de la zona de aterrizaje para implementar SNAT en una topología de red en estrella tipo hub-and-spoke basada en Virtual WAN mediante NVA de terceros.
Descargue un archivo de PowerPoint de esta arquitectura.
En el caso de los diseños de NVA de terceros, debe implementar varias instancias detrás de un equilibrador de carga de Azure para proporcionar alta disponibilidad. Se requiere la SKU estándar de Azure Load Balancer.
Método 2: servicios de Azure Private Link
Private Link proporciona acceso a las aplicaciones que se implementan en una red virtual que no está conectada a la red virtual. En el lado servidor, o la aplicación, la red virtual, se implementa un servicio Private Link y se asocia a un punto de conexión de aplicación que se expone en la dirección IP de front-end de un equilibrador de carga de SKU estándar de Azure interno. En la red virtual del lado cliente, se implementa un recurso de punto de conexión privado y se asocia al servicio Private Link. El punto de conexión privado expone el punto de conexión de la aplicación en las redes virtuales. Private Link proporciona la lógica de tunelización y NAT para enrutar el tráfico entre el lado cliente y el lado servidor. Para más información, consulte ¿Qué es Azure Private Link?
Private Link no requiere una conexión de capa 3 entre la red virtual del lado del cliente y la red virtual del lado del servidor. Las dos redes virtuales pueden tener espacios de direcciones IP superpuestos. Private Link permite la implementación de aplicaciones en redes virtuales aisladas dedicadas, todas ellas con el mismo espacio de direcciones no enrutable. Las aplicaciones se exponen como servicios Private Link en la red corporativa, que usa un espacio de direcciones enrutable. En el contexto de la arquitectura de la zona de aterrizaje de Azure, la topología de zona de aterrizaje resultante tiene:
- Una red virtual aislada que hospeda toda la aplicación y el servicio Private Link asociado a los puntos de conexión de la aplicación. El equipo de la aplicación define el espacio de direcciones de la red virtual.
- Una red virtual de radio con un espacio de direcciones enrutable que hospeda el punto de conexión privado asociado al servicio Private Link. La red virtual de radio está emparejada directamente con el centro regional.
En el diagrama siguiente se muestra la topología de zona de aterrizaje habilitada para Private Link.
Descargue un archivo de PowerPoint de esta arquitectura.
Uso de un servicio de Private Link para las dependencias salientes
Al implementar sus aplicaciones en redes virtuales de radio aisladas, utilice un servicio Private Link para las dependencias salientes. Defina puntos de conexión privados en la red virtual radial aislada y asócielos a un servicio Private Link en redes virtuales enrutables. El diagrama siguiente muestra el enfoque conceptual.
Descargue un archivo de PowerPoint de esta arquitectura.
En implementaciones reales, a gran escala, es posible que el método Private Link no se aplique:
- Si las aplicaciones implementadas en la red virtual aislada tienen varias dependencias salientes. Al implementar un servicio de Private Link y un punto de conexión privado para cada una de las dependencias salientes, aumenta la complejidad y las necesidades de administración.
- Si la dependencia saliente incluye puntos de conexión en la red enrutable que no pueden formar parte de un grupo backend de Azure Load Balancer, entonces Private Link no es aplicable.
Para superar estas dos limitaciones, implemente una solución proxy/NAT en el radio enrutable y haga que sea accesible desde la red virtual aislada mediante Private Link.
Descargue un archivo de PowerPoint de esta arquitectura.
Use un único punto de conexión privado o un servicio Private Link para exponer una solución de proxy o NAT implementada en la red enrutable. Las reglas de traducción de puertos y de traducción de direcciones están definidas en los NVA. Estas reglas permiten el uso de un único punto de conexión privado en la red virtual aislada para acceder a varias dependencias de la red enrutable.
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Creadores de entidad de seguridad:
- Federico Guerrini | Responsable técnico de EMEA
- Khush Kaviraj | Arquitecto de soluciones en la nube
- Jack Tracey | Arquitecto sénior de soluciones en la nube
Otros colaboradores:
- Jodi Martis | Escritor técnico
Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.
Pasos siguientes
- Implementación de Azure Firewall en una red virtual
- Configuración de SNAT en Azure Firewall
- Direcciones IP admitidas en Azure Virtual Network
- Azure Private Link
- Equilibrador de carga de Azure
- Emparejamiento de redes virtuales