Topología de red radial

Este artículo explica cómo diseñar una red de tipo hub-and-spoke en Azure. Una red virtual central aloja servicios compartidos, mientras que las redes virtuales periféricas aisladas alojan cargas de trabajo individuales.

Lo que trata este artículo

Este artículo trata sobre los servicios compartidos de la red virtual central, el aislamiento de los radios y los patrones de enrutamiento (estándar, emparejamiento directo y basado en sellos). También aborda el tránsito de puerta de enlace para la conectividad híbrida y el escalado de topologías hub-and-spoke con Azure Virtual Network Manager.

Quién necesita este artículo

Lea este artículo si se aplican una o varias de estas condiciones:

• Necesita servicios de red compartidos como firewall, DNS, Bastion, VPN Gateway o ExpressRoute para varias cargas de trabajo.
• Quiere centralizar la inspección del tráfico, el control de enrutamiento o la administración en lugar de repetir esos servicios en cada red virtual.
• Necesitas una topología repetible para separar los servicios compartidos de la plataforma de las VNet de las cargas de trabajo.
• Es recomendable comparar el modelo hub-and-spoke con otros modelos de tránsito antes de estandarizar tu topología.

Si tiene una sola carga de trabajo sin requisitos de servicio compartido, comience con una topología de red plana en su lugar.

servicios y características de Azure

En la siguiente tabla se enumeran los servicios y características de Azure que admiten una topología hub-and-spoke:

Cómo funciona

En una topología hub-and-spoke:

1. Una red virtual de concentrador actúa como punto central de conectividad. Contiene servicios de red compartidos, como un firewall, una puerta de enlace y un host de Bastion.
2. Las redes virtuales de los radios establecen emparejamiento con el centro. Cada rama aloja una carga de trabajo: una aplicación, un entorno de equipo o un servicio aislado.
3. El emparejamiento entre VNets no es transitivo. Los radios pueden acceder al centro, pero no pueden comunicarse entre sí directamente a través del centro a menos que se configure el enrutamiento o el emparejamiento directo entre ellos.

¿Qué pasa en la red virtual del concentrador?

Use la tabla siguiente para determinar qué servicios colocar en el centro:

Diseño de la subred del hub

Normalmente, una red virtual de concentrador bien diseñada incluye estas subredes:

Para obtener instrucciones detalladas sobre el ajuste de tamaño de subred, consulte Redes virtuales y subredes.

Cómo elegir una variante

La topología hub-and-spoke tiene tres variantes comunes. Elija en función de los requisitos de aislamiento y comunicación:

Modelo hub-and-spoke estándar

Esta variante es la más común. Todo el tráfico de spoke a spoke pasa por el firewall del hub para su inspección. Los spokes se comunican únicamente a través del hub, nunca directamente.

Patrón de enrutamiento: Aplica una ruta definida por el usuario (UDR) a cada subred de los spokes, con la ruta predeterminada (0.0.0.0/0) apuntando a la dirección IP privada del firewall del hub. Esto obliga a que todo el tráfico saliente, incluido el de spoke a spoke, pase por el firewall para su registro y filtrado.

Límite de emparejamiento: Una sola red virtual de concentrador admite hasta 500 conexiones de emparejamiento (límite de plataforma estándar). Si utiliza Azure Virtual Network Manager (AVNM) con una configuración de conectividad de tipo hub-spoke, el límite aumenta a 1.000 spokes.

Hub-and-spoke con emparejamiento directo

En algunas arquitecturas, determinados pares de spokes necesitan una comunicación de baja latencia sin pasar por el firewall del hub. En estos casos, añade una interconexión directa de VNet entre el par de spokes o utiliza grupos conectados mediante AVNM.

Utiliza la interconexión directa entre spokes cuando:

• Dos cargas de trabajo intercambien datos de alto rendimiento (por ejemplo, la replicación de bases de datos entre spokes).
• La latencia del salto del firewall es inaceptable para una ruta de datos específica.
• Aceptes que el tráfico con interconexión directa eluda la inspección del firewall central.

Patrón de sellos (completamente aislado)

El patrón Stamps es una alternativa para escenarios que requieren aislamiento estricto de radio de explosión. Cada carga de trabajo se implementa en una red virtual totalmente independiente sin concentrador y sin emparejamiento con otras cargas de trabajo.

Cuándo usar sellos:

• El cumplimiento normativo exige que no exista ninguna ruta de red entre las cargas de trabajo.
• SaaS multiarrendatario en el que cada arrendatario dispone de una infraestructura independiente.
• Aislamiento máximo de errores: un error en un stamp no puede propagarse a los demás.

Ejemplo: Aislamiento de SaaS multitenant

Un proveedor de SaaS aloja a cada cliente empresarial en una instancia dedicada. Cada stamp contiene su propia VNet (10.x.0.0/16), Application Gateway, nivel de proceso y base de datos. No existe emparejamiento de VNet entre stamps, por lo que un grupo de seguridad de red (NSG) mal configurado o una carga de trabajo comprometida en el stamp del inquilino A no puede acceder a los recursos del inquilino B a través de la red. El proveedor administra los stamps mediante plantillas de Azure Resource Manager y los implementa en grupos de recursos independientes o en suscripciones independientes para inquilinos de gran tamaño. El intercambio de datos entre inquilinos, cuando sea necesario, usa un espacio de nombres Azure Service Bus compartido. Cada stamp accede a este espacio de nombres a través de puntos de conexión privados.

Desventajas:

• No hay servicios compartidos. Cada stamp necesita su propio firewall, puerta de enlace y host de Bastion (si es necesario), lo que aumenta el costo.
• No hay comunicación entre cargas de trabajo a través de redes privadas.
• La sobrecarga operativa aumenta porque administra redes independientes en lugar de una infraestructura centralizada.
• El coste aumenta linealmente con el número de sellos porque no se aplican los ahorros derivados de los servicios compartidos.

Si sus cargas de trabajo necesitan servicios compartidos o comunicación entre cargas de trabajo, utilice en su lugar la variante estándar hub-and-spoke.

Patrones de comunicación de spoke a spoke

Dado que el emparejamiento de VNet no es transitivo, la comunicación de spoke a spoke requiere un enrutamiento explícito. En esta sección se explica cómo fluye el tráfico entre los spokes mediante el firewall del hub.

Flujo de tráfico: del spoke A al spoke B a través del firewall del hub

En la secuencia siguiente se describe cómo un paquete viaja desde una máquina virtual en radio A (10.1.0.4) a una máquina virtual en radio B (10.2.0.4):

1. Una VM spoke envía un paquete destinado a 10.2.0.4. La tabla de rutas efectiva de la máquina virtual contiene una UDR con 0.0.0.0/0 → 10.0.1.4 (la dirección IP privada Azure Firewall).
2. El paquete atraviesa el enlace de interconexión de la VNet desde el nodo periférico A hasta la VNet del nodo central. La interconexión permite que el tráfico llegue a la subred del firewall.
3. Azure Firewall recibe el paquete en su interfaz interna. Evalúa el paquete con respecto a las reglas de red y las reglas de aplicación en orden de prioridad.
4. Si una regla permite el flujo, el firewall reenvía el paquete a 10.2.0.4. El paquete atraviesa el enlace de interconexión entre el nodo central y el nodo periférico B.
5. La máquina virtual Spoke B recibe el paquete. El tráfico de retorno sigue la misma ruta en sentido inverso. La UDR de Spoke B envía la respuesta a través del firewall.

Configuración de las tablas de rutas

Aplique estas tablas de rutas para habilitar el patrón anterior:

1. Cree una tabla de rutas para las subredes spoke. Desactive la propagación de rutas BGP si desea evitar que las rutas locales invaliden las UDR.
2. Agregue una ruta predeterminada (0.0.0.0/0) con el tipo VirtualAppliance de próximo salto y la dirección del próximo salto establecida en la dirección IP privada de Azure Firewall.
3. Asocie la tabla de rutas a cada subred spoke que necesite acceder a otras spokes o a Internet.
4. Crea reglas de red del firewall que permitan el tráfico específico de spoke a spoke. Por ejemplo, permita 10.1.0.0/16 → 10.2.0.0/16 en los puertos 443 y 1433.

Alternativa: grupos conectados de AVNM para la comunicación directa de spoke a spoke

Si no necesitas inspección del firewall entre spokes específicos, los grupos conectados de AVNM proporcionan un modelo de conectividad en malla. Los spokes del mismo grupo conectado se comunican directamente sin pasar por el hub. Esto reduce los requisitos de rendimiento de firewall y latencia, pero omite la inspección centralizada.

Tránsito a través de la puerta de enlace

El tránsito de puerta de enlace permite que todos los spokes compartan una única VPN Gateway o ExpressRoute implementada en el hub. Sin el tránsito de puerta de enlace, cada spoke necesita su propia puerta de enlace para acceder a las redes locales.

Pasos de configuración

1. Implemente una puerta de enlace vpn o ExpressRoute en el centro de conectividad GatewaySubnet.
2. En la conexión de emparejamiento del lado del hub (hub → spoke): habilita Permitir tránsito de puerta de enlace.
3. En la conexión de emparejamiento del lado del spoke (spoke → hub): habilite Usar puertas de enlace remotas.
4. Compruebe la propagación de rutas. Tras la configuración, compruebe las rutas activas en la NIC de una máquina virtual spoke. La tabla de rutas muestra los prefijos locales aprendidos a través de la puerta de enlace del hub con un tipo de siguiente salto de VNetGlobalPeering o VNetPeering.

Una vez configuradas, las rutas aprendidas por la puerta de enlace del nodo central (por ejemplo, prefijos locales de ExpressRoute) se propagan automáticamente a las tablas de enrutamiento de los nodos periféricos.

Limitaciones del tránsito por puerta de enlace

• El tránsito de puerta de enlace funciona con todos los niveles de VPN Gateway , excepto el nivel Básico. Si usa el VPN Gateway Básico, no puede compartirlo con redes virtuales emparejadas.
• Una red virtual spoke solo puede usar una puerta de enlace remota. No se puede habilitar Use remote gateways en un nodo periférico que tenga conexión de pares con varios nodos centrales.
• Si utilizas UDR para forzar el tráfico a través del firewall, asegúrate de que UDR no anule involuntariamente las rutas locales propagadas por la puerta de enlace. Establezca rutas más específicas para prefijos locales si es necesario.

Azure Virtual Network Manager a gran escala

Cuando su entorno crece más allá de unas pocas ramificaciones, la administración manual de las conexiones de emparejamiento y las tablas de rutas se vuelve compleja. AVNM proporciona automatización para topologías de tipo hub-spoke:

AVNM resulta especialmente útil cuando se administran topologías de tipo hub-spoke en varias regiones o se necesita una pertenencia dinámica a medida que se activan nuevas redes virtuales de tipo spoke.

Consideraciones sobre el escalado

A medida que crezca su topología de tipo hub-spoke, tenga en cuenta los siguientes límites de la plataforma y patrones organizativos:

Límites de emparejamiento y conectividad

Organización de la suscripción

• Separe los ramales en suscripciones específicas para cada carga de trabajo en entornos con más de 10 ramales. Esto aísla la facturación, el RBAC y los límites de cuota por equipo de carga de trabajo.
• Utilice una suscripción de conectividad dedicada para la VNet del centro, las puertas de enlace y el firewall. Este es el patrón recomendado por las zonas de aterrizaje de Azure (suscripción de plataforma).
• Agrupa las suscripciones en un grupo de administración para que AVNM pueda detectar y administrar dinámicamente las VNet spoke de todas las suscripciones mediante condiciones de Azure Policy.

Aplicación de la topología mediante Azure Policy

Utiliza Azure Policy para evitar desviaciones en la configuración:

• Deniega el emparejamiento con VNet que no sean hub. Asigna una directiva a nivel de grupo de administración que bloquee la creación de emparejamientos de VNet, a menos que el destino sea la VNet hub designada.
• Exige la asociación con UDR. Asigne una directiva que audite (o deniegue) las subredes spoke que no dispongan de una tabla de rutas que incluya la 0.0.0.0/0 → Firewall ruta.
• Exigir la pertenencia a grupos de AVNM. Utilice reglas de pertenencia dinámicas en AVNM basadas en etiquetas (por ejemplo, NetworkRole:Spoke) para que las nuevas VNet se inscriban automáticamente.

Ruta de migración de una estructura plana a una estructura hub-spoke

Si ha empezado con una topología de red plana y su entorno ha crecido para requerir servicios compartidos o segmentación entre cargas de trabajo, siga esta ruta de migración:

Paso 1: Planear la red virtual del centro

1. Asigne un nuevo espacio de direcciones para el centro (por ejemplo, 10.0.0.0/16) que no se superponga con la red virtual plana existente.
2. Determine qué servicios compartidos se van a implementar: firewall, puerta de enlace, Bastion, solucionador DNS.
3. Dimensione las subredes del concentrador según la tabla de diseño de subred del concentrador.

Paso 2: Implementación de servicios compartidos en el centro

1. Cree la VNet de concentrador e implemente Azure Firewall (o la NVA que haya elegido).
2. Implemente la puerta de enlace vpn/ExpressRoute si necesita conectividad híbrida.
3. Implemente Azure Bastion para el acceso seguro a máquinas virtuales.
4. Configure el resolutor de DNS privado si utiliza DNS personalizado.

Paso 3: Migrar las cargas de trabajo a las redes spoke

1. Cree VNet spoke con nuevos espacios de direcciones para cada carga de trabajo. Si no puede reasignar las direcciones IP, puede mantener los rangos existentes siempre que no se superpongan con el hub.
2. Establezca una conexión entre cada spoke y el hub. Habilite el tránsito de puerta de enlace en el lado del hub y utilice puertas de enlace remotas en el lado de los spokes.
3. Aplique UDR a las subredes de los spokes con la ruta predeterminada apuntando al firewall del hub.
4. Mueva o vuelva a implementar máquinas virtuales y servicios desde la VNet plana a la subred de spoke adecuada. Utilice Azure Resource Mover o la reimplementación, dependiendo de la complejidad de la carga de trabajo.
5. Crea reglas de firewall para permitir los patrones de tráfico entre spokes y de spoke a Internet que antes permitías dentro de la VNet plana.

Paso 4: Retirar la red virtual plana

1. Comprueba que se pueda acceder a todas las cargas de trabajo a través de la nueva topología hub-spoke.
2. Actualice los registros DNS si han cambiado las direcciones IP privadas.
3. Retire la VNet plana antigua una vez haya migrado y validado todo el tráfico.

Cuándo considerar Virtual WAN en su lugar

Si la complejidad de su topología hub-and-spoke está aumentando, evalúe si Azure Virtual WAN ofrece una solución más adecuada:

Para obtener una comparación detallada, consulte Azure Virtual WAN topología.

Consideraciones de diseño

Prerequisites

Antes de diseñar una red hub-and-spoke:

• Complete su plan de red virtual y subred. Averigüe cuántos radios necesita y qué subredes requiere cada uno.
• Defina el esquema de direcciones IP. Los espacios de direcciones del centro y de los radios no deben solaparse.
• Tenga en cuenta que el emparejamiento de VNet no es transitivo: los radios no heredan la conectividad con otros radios a través del centro.

Consideraciones de seguridad

Una topología hub-and-spoke centraliza la aplicación de las medidas de seguridad en el hub. Aplique estos principios:

• Dirige todo el tráfico de los spokes a través del firewall del hub. Use UDR con la ruta predeterminada dirigida al firewall. Esta configuración garantiza que el firewall inspeccione y registre todos los flujos de tráfico entre spokes y entre spokes e Internet.
• Utiliza grupos de seguridad de red (NSG) en las subredes de los spokes como defensa en profundidad. Incluso con un firewall central, los grupos de seguridad de red en subredes radiales proporcionan una capa adicional de segmentación. Deniegue el tráfico lateral inesperado en el nivel de subred. Para obtener instrucciones de diseño de NSG, consulte Grupos de seguridad de red y grupos de seguridad de aplicaciones.
• Activa el tránsito de puerta de enlace con precaución. El tránsito de puerta de enlace expone las rutas locales a todos los radios. Asegúrese de que las reglas de firewall tenga en cuenta la conectividad expandida.
• Quite las direcciones IP públicas de las máquinas virtuales spoke. Azure Bastion en el centro proporciona acceso de administración seguro sin exponer máquinas virtuales a Internet.
• Trate cada radio como un límite de seguridad. Las cargas de trabajo de los distintos radios permanecen aisladas de forma predeterminada. La conectividad entre los spokes requiere rutas explícitas y reglas de cortafuegos.

Artículos relacionados

• Topología de red plana: para cargas de trabajo únicas que no necesitan servicios compartidos
• Topología de Azure Virtual WAN: para el enrutamiento administrado y la conectividad a gran escala
• Redes de varias regiones: para cargas de trabajo que abarcan varias regiones de Azure
• Redes virtuales y subredes: ajuste de tamaño de subred para los componentes del concentrador
• Planificación de direcciones IP: planificación CIDR para el nodo central y los nodos periféricos
• Grupos de seguridad de red y grupos de seguridad de aplicaciones: defensa en profundidad en las subredes de los nodos periféricos

Aprende más

• Topología de red hub-and-spoke en Azure
• Interconexión de redes virtuales
• Información general de Azure Firewall
• Introducción a Azure Virtual Network Manager
• Tránsito de la VPN Gateway para el emparejamiento
• Azure Bastion y el emparejamiento de red virtual

Pasos siguientes