Topología de red hub-spoke en Azure

Esta arquitectura de referencia detalla una topología hub-spoke en Azure. La red virtual hub actúa como un punto central de conectividad a muchas redes virtuales spoke. El hub también puede utilizarse como punto de conectividad con sus redes locales. Las redes virtuales de radios se unen al concentrador y pueden utilizarse para aislar las cargas de trabajo.

Las ventajas de utilizar una configuración de concentrador y radios incluyen el ahorro de costes, la superación de los límites de suscripción y el aislamiento de las cargas de trabajo.

Despliegue de referencia

Este despliegue incluye una red virtual de concentrador y dos radios con peered. También se despliegan un Firewall Azure y un host Azure Bastion. Opcionalmente, el despliegue puede incluir máquinas virtuales en la primera red de radios y una puerta de enlace VPN.

az group create --name hub-spoke --location eastus

az deployment group create --resource-group hub-spoke \ --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/azure-hub-spoke/azuredeploy.json

New-AzResourceGroup -Name hub-spoke -Location eastus

New-AzResourceGroupDeployment -ResourceGroupName hub-spoke ` -TemplateUri https://raw.githubusercontent.com/mspnp/samples/master/solutions/azure-hub-spoke/azuredeploy.json

Para obtener información detallada y opciones de despliegue adicionales, consulte las Plantillas ARM utilizadas para desplegar esta solución.

Casos de uso

Los usos típicos de esta arquitectura incluyen:

• Cargas de trabajo desplegadas en diferentes entornos, como desarrollo, pruebas y producción, que requieren servicios compartidos como DNS, IDS, NTP o AD DS. Los servicios compartidos se colocan en la red virtual del concentrador, mientras que cada entorno se despliega en un radio para mantener el aislamiento.
• Cargas de trabajo que no requieren conectividad entre sí pero sí acceso a servicios compartidos.
• Empresas que requieren un control central sobre los aspectos de seguridad, como un firewall en el hub como DMZ, y una gestión segregada para las cargas de trabajo en cada spoke.

Arquitectura

La arquitectura consta de los siguientes componentes.

Red virtual del hub: La red virtual hub es el punto central de conectividad con su red local y un lugar para alojar servicios que pueden ser consumidos por las diferentes cargas de trabajo alojadas en las redes virtuales spoke.

Redes virtuales spoke: Las redes virtuales spoke se utilizan para aislar las cargas de trabajo en sus propias redes virtuales, gestionadas por separado de otras spokes. Cada carga de trabajo podría incluir varios niveles, con varias subredes conectadas a través de los equilibradores de carga de Azure.

Preparación de redes virtuales: Dos redes virtuales pueden conectarse utilizando una conexión de peering. Las conexiones peering son conexiones no transitivas y de baja latencia entre redes virtuales. Una vez peering, las redes virtuales intercambian tráfico utilizando el backbone de Azure sin necesidad de un router.

Bastion Host: Azure Bastion le permite conectarse de forma segura a una máquina virtual utilizando su navegador y el portal de Azure. Un host de Azure Bastion se despliega dentro de una red virtual de Azure y puede acceder a las máquinas virtuales de la VNet, o a las máquinas virtuales de las VNets con peered.

Azure Firewall: Azure Firewall es un firewall gestionado como servicio. La instancia de Firewall se coloca en su propia subred.

Puerta de enlace de red virtual VN o puerta de enlace ExpressRoute. La pasarela de red virtual permite que la red virtual se conecte al dispositivo VPN, o al circuito ExpressRoute, utilizado para la conectividad con su red local. Para obtener más información, consulte Conectar una red local a una red virtual de Microsoft Azure.

Dispositivo VPN. Un dispositivo o servicio que proporciona conectividad externa a la red local. El dispositivo VPN puede ser un dispositivo de hardware o una solución de software como el Servicio de enrutamiento y acceso remoto (RRAS) en Windows Server 2012. Para obtener más información, consulte Acerca de los dispositivos VPN para conexiones de puerta de enlace VPN de sitio a sitio.

Recomendaciones

Las siguientes recomendaciones se aplican a la mayoría de los escenarios. Siga estas recomendaciones a menos que tenga un requisito específico que las anule.

Grupos de recursos

La solución de ejemplo incluida en este documento utiliza un único grupo de recursos de Azure. En la práctica, el hub y cada spoke pueden implementarse en diferentes grupos de recursos e incluso en diferentes suscripciones. Cuando se emparejan redes virtuales en diferentes suscripciones, ambas suscripciones pueden asociarse con el mismo o diferente tenant de Azure Active Directory. Esto permite la gestión descentralizada de cada carga de trabajo mientras se comparten los servicios mantenidos en el centro.

Red virtual y GatewaySubnet

Cree una subred denominada GatewaySubnet, con un rango de direcciones de /27. La puerta de enlace de la red virtual requiere esta subred. La asignación de 32 direcciones a esta subred ayudará a evitar que se alcancen las limitaciones de tamaño de la puerta de enlace en el futuro.

Para obtener más información sobre la configuración de la puerta de enlace, consulte las siguientes arquitecturas de referencia, en función de su tipo de conexión:

• Red híbrida mediante ExpressRoute
• Red híbrida mediante una puerta de enlace VPN

Para una mayor disponibilidad, puede utilizar ExpressRoute más una VPN para la conmutación por error. Consulte Conectar una red local a Azure utilizando ExpressRoute con conmutación por error de VPN.

También se puede utilizar una topología hub-spoke sin una puerta de enlace si no necesita conectividad con su red local.

Peering de red virtual

El peering de red virtual es una relación no transitiva entre dos redes virtuales. Si necesita que los radios se conecten entre sí, considere la posibilidad de añadir una conexión de peering independiente entre esos radios.

Sin embargo, suponga que tiene varios radios que necesitan conectarse entre sí. En ese caso, se quedará sin posibles conexiones de peering muy rápidamente debido a la limitación del número de peerings de red virtual por red virtual. (Para más información, consulte Límites de la red. En este caso, considere la posibilidad de utilizar rutas definidas por el usuario (UDR) para forzar que el tráfico destinado a un radio se envíe a Azure Firewall o a un dispositivo virtual de red que actúe como enrutador en el centro. Esto permitirá que los radios se conecten entre sí.

También puede configurar los radios para que utilicen la puerta de enlace del concentrador para comunicarse con redes remotas. Para permitir que el tráfico de la pasarela fluya de los radios al concentrador y se conecte a redes remotas, debe:

• Configurar la conexión de peering en el concentrador para permitir el tránsito de la pasarela.
• Configurar la conexión de peering en cada radio para utilizar pasarelas remotas.
• Configurar todas las conexiones de peering para permitir el tráfico reenviado.

Para obtener información adicional sobre la creación de peering de redes virtuales, consulte Crear peerings de VNet.

Conectividad entre radios

Si necesita conectividad entre radios, considere la posibilidad de implementar un Azure Firewall u otro dispositivo virtual de red y cree rutas para reenviar el tráfico del radio al firewall / dispositivo virtual de red, que luego puede enrutar al segundo radio. En este escenario, debe configurar las conexiones de peering para permitir el tráfico reenviado.

También puede utilizar una puerta de enlace VPN para enrutar el tráfico entre radios, aunque esto afectará a la latencia y al rendimiento. Consulte Configurar el tránsito de la pasarela VPN para el peering de la red virtual para obtener detalles de configuración.

Considere qué servicios se comparten en el concentrador para garantizar que el concentrador se adapte a un mayor número de radios. Por ejemplo, si su concentrador proporciona servicios de cortafuegos, tenga en cuenta los límites de ancho de banda de su solución de cortafuegos cuando añada varios radios. Es posible que desee mover algunos de estos servicios compartidos a un segundo nivel de concentradores.

Consideraciones operativas

Considere lo siguiente cuando despliegue y gestione redes de concentradores y radios.

Supervisión de la red

Utilice Azure Network Watcher para supervisar y solucionar los componentes de la red, herramientas como Traffic Analytics le mostrarán los sistemas de sus redes virtuales que generan más tráfico para que pueda identificar visualmente los cuellos de botella antes de que degeneren en problemas. Network Performance Manager es la herramienta adecuada para supervisar la información sobre los circuitos de Microsoft ExpressRoute. El diagnóstico de VPN es otra herramienta que puede ayudar a solucionar los problemas de las conexiones VPN de sitio a sitio que conectan sus aplicaciones con los usuarios en las instalaciones.

Para obtener más información, consulte Azure Network Watcher en Azure Well-Architected Framework.

Consideraciones de costes

Considere los siguientes elementos relacionados con los costes al desplegar y gestionar redes hub y spoke.

Azure Firewall

En esta arquitectura, se despliega un Azure Firewall en la red hub. Cuando se utiliza como solución compartida y es consumida por varias cargas de trabajo, un Azure Firewall puede ahorrar hasta un 30-50% respecto a otro dispositivo virtual de red. Para obtener más información, consulte Azure Firewall vs network virtual appliance.

Virtual network peering

Puede utilizar virtual network peering para enrutar el tráfico entre redes virtuales utilizando direcciones IP privadas. Estos son algunos puntos:

• El tráfico de entrada y salida se cobra en ambos extremos de las redes peered.
• Las diferentes zonas tienen diferentes tasas de transferencia.

Por ejemplo, la transferencia de datos desde una red virtual en la zona 1 a otra red virtual en la zona 2, incurrirá en la tasa de transferencia de salida para la zona 1 y la tasa de entrada para la zona 2. Para obtener más información, consulte Precios de las redes virtuales.