Editar

Compartir a través de


Topología de red en estrella tipo hub-and-spoke en Azure

Azure Bastion
Azure Firewall
Azure Network Watcher
Azure Virtual Network
Azure VPN Gateway

Esta arquitectura de referencia implementa un patrón de red en estrella tipo hub-and-spoke con componentes de infraestructura de centro administrados por el cliente. Para ver una solución de infraestructura de centro administrada por Microsoft, consulte Topología de red en estrella tipo hub-and-spoke con Azure Virtual WAN.

Architecture

Diagrama en el que se muestra una topología de red virtual en estrella tipo hub-and-spoke en Azure con redes de radio conectadas a través del centro o directamente.

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo

Esta configuración de red en estrella tipo hub-and-spoke usa los siguientes elementos arquitectónicos:

  • Red virtual de concentrador. La red virtual del centro hospeda servicios compartidos de Azure. Las cargas de trabajo hospedadas en las redes virtuales de radio pueden usar estos servicios. La red virtual de centro es el punto central de conectividad para las redes entre entornos locales.

  • Redes virtuales de radio. Las redes virtuales de radio aíslan y administran cargas de trabajo por separado en cada radio. Cada carga de trabajo puede incluir varios niveles, con varias subredes que se conectan mediante equilibradores de carga de Azure. Los radios pueden existir en distintas suscripciones y representar entornos diferentes, como los de producción y no producción.

  • Conectividad de red virtual. Esta arquitectura conecta redes virtuales mediante conexiones de emparejamiento o grupos conectados. Las conexiones de emparejamiento y los grupos conectados son conexiones no transitivas de baja latencia entre las redes virtuales. Las redes virtuales emparejadas o conectadas pueden intercambiar tráfico a través de la red troncal de Azure sin necesidad de un enrutador. Azure Virtual Network Manager crea y administra los grupos de red y sus conexiones.

  • Host de Azure Bastion. Azure Bastion proporciona conectividad segura desde Azure Portal a las máquinas virtuales (VM) mediante el explorador. Un host de Azure Bastion implementado dentro de una red virtual de Azure puede acceder a las máquinas virtuales de esa red virtual o de redes virtuales conectadas.

  • Azure Firewall. Existe una instancia de Azure Firewall administrada en su propia subred.

  • Puerta de enlace de Azure VPN Gateway o Azure ExpressRoute. Una puerta de enlace de red virtual permite que una red virtual se conecte a un dispositivo de red privada virtual (VPN) o a un circuito de Azure ExpressRoute. La puerta de enlace proporciona conectividad de red entre entornos locales. Para obtener más información, consulte Conexión de una red local a una red virtual de Microsoft Azure y Extensión de una red local mediante VPN.

  • Dispositivo VPN. Un dispositivo o servicio VPN proporciona conectividad externa a la red entre entornos locales. El dispositivo VPN puede ser un dispositivo de hardware o una solución de software como el servicio de enrutamiento y acceso remoto (RRAS) de Windows Server. Para más información, consulte Guías de configuración de dispositivos y dispositivos VPN validados.

Componentes

  • Virtual Network Manager es un servicio de administración que le ayuda a agrupar, configurar, implementar y administrar redes virtuales a escala entre las suscripciones, regiones e inquilinos de Azure. Con Virtual Network Manager, puede definir grupos de redes virtuales para identificar y segmentar lógicamente las redes virtuales. Puede definir y aplicar configuraciones de conectividad y seguridad en todas las redes virtuales de un grupo de red a la vez.

  • Azure Virtual Network es el bloque de creación fundamental para las redes privadas en Azure. Virtual Network permite muchos recursos de Azure, como las máquinas virtuales de Azure, para la comunicación segura con otros usuarios, con Internet y con las redes entre entornos locales.

  • Azure Bastion es un servicio totalmente administrado que proporciona acceso más seguro y sin problemas por medio del Protocolo de escritorio remoto (RDP) y el protocolo Secure Shell (SSH) a las máquinas virtuales sin exponer sus direcciones IP públicas.

  • Azure Firewall es un servicio de seguridad de red administrado y basado en la nube que protege los recursos de la red virtual. Este servicio de firewall con estado tiene alta disponibilidad integrada y escalabilidad en la nube sin restricciones para ayudarle a crear, aplicar y registrar directivas de conectividad de red y aplicaciones en suscripciones y redes virtuales.

  • VPN Gateway es un tipo específico de puerta de enlace de red virtual que envía tráfico cifrado entre una red virtual y una ubicación local a través de la red pública de Internet. También puede usar VPN Gateway para enviar tráfico cifrado entre las redes virtuales de Azure a través de la red de Microsoft.

  • Azure Monitor puede recopilar y analizar datos de telemetría de los entornos entre locales, incluidos Azure y el entorno local, y actuar en función de ellos. Azure Monitor le ayuda a maximizar el rendimiento y la disponibilidad de las aplicaciones y a identificar de forma proactiva los problemas en cuestión de segundos.

Detalles del escenario

Esta arquitectura de referencia implementa un patrón de red en estrella tipo hub-and-spoke en el que la red virtual de centro actúa como punto central de conectividad con muchas redes virtuales de radio. Las redes virtuales de radio se conectan con el centro y se pueden usar para aislar las cargas de trabajo. También puede habilitar escenarios entre locales usando el centro para conectarse a las redes locales.

Esta arquitectura describe un patrón de red con componentes de infraestructura de centro administrados por el cliente. Para ver una solución de infraestructura de centro administrada por Microsoft, consulte Topología de red en estrella tipo hub-and-spoke con Azure Virtual WAN.

Las ventajas de usar una configuración en estrella tipo hub-and-spoke incluyen las siguientes:

  • Ahorros en costos
  • Superación de los límites de las suscripciones
  • Aislamiento de cargas de trabajo

Para obtener más información, consulte Topología de red en estrella tipo hub-and-spoke.

Posibles casos de uso

Algunos de los usos típicos de una arquitectura en estrella tipo hub-and-spoke incluyen cargas de trabajo que:

  • Tienen varios entornos que requieren servicios compartidos. Por ejemplo, puede que una carga de trabajo tenga entornos de desarrollo, pruebas y producción. Los servicios compartidos pueden incluir identificadores de DNS, protocolo de tiempo de red (NTP) o Active Directory Domain Services (AD DS). Los servicios compartidos se colocan en la red virtual de centro, mientras que cada entorno se implementa en un radio diferente para mantener el aislamiento.
  • No requieren conectividad entre sí, pero requieren acceso a servicios compartidos.
  • Requieren control central sobre la seguridad, como un firewall de red perimetral (también conocido como DMZ) en el centro con administración de cargas de trabajo segregada en cada radio.
  • Requieren un control central sobre la conectividad, como la conectividad selectiva o el aislamiento entre radios de determinados entornos o cargas de trabajo.

Recomendaciones

Las siguientes recomendaciones aplican para la mayoría de los escenarios. Siga estas recomendaciones a menos que tenga requisitos concretos que las invaliden.

Grupos de recursos, suscripciones y regiones

En esta solución de ejemplo se usa un único grupo de recursos de Azure. También puede implementar el centro y cada radio en diferentes grupos de recursos y suscripciones.

Cuando se emparejan redes virtuales en distintas suscripciones, las suscripciones pueden estar asociadas al mismo inquilino de Microsoft Entra o a uno diferente. Esta flexibilidad permite la administración descentralizada de cada carga de trabajo, al tiempo que se mantienen los servicios compartidos en el centro. Consulte Creación de un emparejamiento de red virtual: Resource Manager, diferentes suscripciones e inquilinos de Microsoft Entra.

Como regla general, lo mejor es tener al menos un centro por región. Esta configuración ayuda a evitar un único punto de error, por ejemplo, para evitar que los recursos de la región A se vean afectados en el nivel de red por una interrupción en la región B.

Subredes de la red virtual

En las siguientes recomendaciones se describe cómo se deben configurar las subredes de la red virtual.

GatewaySubnet

La puerta de enlace de red virtual requiere esta subred. También puede usar una topología en estrella tipo hub-and-spoke sin puerta de enlace en caso de que no necesite conectividad de red entre locales.

Cree una subred denominada GatewaySubnet con un intervalo de direcciones de al menos /27. El intervalo de direcciones /27 proporciona suficientes opciones de configuración de escalabilidad a la subred para evitar alcanzar las limitaciones de tamaño de la puerta de enlace en el futuro. Para más información sobre cómo configurar la puerta de enlace, consulte Red híbrida mediante una puerta de enlace de VPN.

Para una mayor disponibilidad, puede utilizar ExpressRoute y una VPN para la conmutación por error. Vea Conexión de una red local a Azure mediante ExpressRoute con conmutación por error de VPN.

AzureFirewallSubnet

Cree una subred denominada AzureFirewallSubnet con un intervalo de direcciones de al menos /26. Independientemente de la escala, el intervalo de direcciones /26 es el tamaño recomendado y cubre las posibles limitaciones de tamaño en el futuro. Esta subred no admite grupos de seguridad de red (NSG).

Azure Firewall necesita esta subred. Si usa una aplicación virtual de red asociada (NVA), siga sus requisitos de red.

Conectividad de la red de radio

El emparejamiento de red virtual o los grupos conectados son relaciones no transitivas entre redes virtuales. Si necesita que las redes virtuales de radio se conecten entre sí, agregue una conexión de emparejamiento entre esos radios o colóquelas en el mismo grupo de red.

Conexiones de radio a través de Azure Firewall o NVA

El número de emparejamientos de red virtual por red virtual es limitado. Si tiene varios radios que necesitan conectarse entre sí, se podría quedar sin conexiones de emparejamiento. Los grupos conectados también tienen limitaciones. Para obtener más información, consulte Límites de la red y Límites de los grupos conectados.

En este escenario, considere la posibilidad de usar rutas definidas por el usuario (UDR) para forzar que el tráfico de radio se envíe a Azure Firewall o a una NVA que actúa como un enrutador en el centro. Este cambio permitirá que los radios se conecten entre sí. Para admitir esta configuración, debe implementar una instancia de Azure Firewall con la configuración de túnel forzado habilitada. Para más información, consulte Tunelización forzada de Azure Firewall.

La topología de este diseño arquitectónico facilita los flujos de salida. Aunque Azure Firewall se usa principalmente para la seguridad de salida, también puede ser un punto de entrada. Para obtener más consideraciones sobre el enrutamiento de entrada de NVA de centro, consulte Firewall y Application Gateway para redes virtuales.

Conexiones radiales a redes remotas a través de una puerta de enlace de centro

Para configurar los radios para que se comuniquen con redes remotas a través de una puerta de enlace de centro, puede usar emparejamientos de red virtual o grupos de red conectados.

Para usar emparejamientos de red virtual, en la configuración del Emparejamiento de red virtual:

  • Configure la conexión de emparejamiento en el centro para Permitir el tránsito de puerta de enlace.
  • Configure la conexión de emparejamiento en cada radio para usar la puerta de enlace de la red virtual remota.
  • Configure todas las conexiones de emparejamiento para Permitir el tráfico reenviado.

Para obtener más información, consulte Creación de un emparejamiento de red virtual.

Para usar grupos de red conectados:

  1. En Virtual Network Manager, cree un grupo de red y agregue las redes virtuales miembro.
  2. Creación de una configuración de conectividad en estrella tipo hub-and-spoke.
  3. Para los Grupos de red de radio, seleccione Centro como puerta de enlace.

Para obtener más información, consulte Creación de una topología en estrella tipo hub-and-spoke con Azure Virtual Network Manager.

Comunicaciones de red de radio

Hay dos maneras principales de permitir que las redes virtuales de radio se comuniquen entre sí:

  • Comunicación a través de una NVA como un firewall y un enrutador. Este método incurre en un salto entre los dos radios.
  • Comunicación mediante el emparejamiento de red virtual o la conectividad directa de Virtual Network Manager entre radios. Este enfoque no provoca un salto entre los dos radios y se recomienda para minimizar la latencia.

Comunicación a través de un NVA

Si necesita conectividad entre radios, considere la posibilidad de implementar Azure Firewall u otro NVA en el centro. A continuación, cree rutas para reenviar el tráfico de un radio al firewall o al dispositivo virtual de red, que puede realizar el enrutamiento al segundo radio. En este escenario, debe configurar las conexiones de emparejamiento para que permitan el tráfico reenviado.

Diagrama en el que se muestra el enrutamiento entre radios mediante Azure Firewall

También puede usar una puerta de enlace de VPN para enrutar el tráfico entre los radios, aunque esta decisión afecta a la latencia y el rendimiento. Para obtener los detalles de configuración, consulte Configuración del tránsito de puerta de enlace de VPN para el emparejamiento de red virtual.

Evalúe los servicios que comparte en el centro para asegurarse de que el centro se escale para tener un número mayor de radios. Por ejemplo, si el centro de conectividad proporciona servicios de firewall, tenga en cuenta los límites de ancho de banda de la solución de firewall al agregar varios radios. Puede mover algunos de estos servicios compartidos a un segundo nivel de centros.

Comunicación directa entre redes radiales

Para conectarse directamente entre redes virtuales de radio sin atravesar la red virtual de centro, puede crear conexiones de emparejamiento entre radios o habilitar la conectividad directa para el grupo de red. Es mejor limitar el emparejamiento o la conectividad directa a las redes virtuales de radio que forman parte del mismo entorno y carga de trabajo.

Al usar Virtual Network Manager, puede agregar redes virtuales de radio a grupos de red manualmente, o bien agregar redes automáticamente en función de las condiciones que defina. Para obtener más información, consulte Redes de radio a radio.

En el diagrama siguiente se muestra el uso de Virtual Network Manager para la conectividad directa entre radios.

Diagrama en el que se muestra el uso de Virtual Network Manager para la conectividad directa entre radios.

Recomendaciones de administración

Para administrar de forma centralizada los controles de conectividad y seguridad, use Virtual Network Manager para crear nuevas topologías de red virtual en estrella tipo hub-and-spoke o incorporar topologías existentes. El uso de Virtual Network Manager garantiza que las topologías de red en estrella tipo hub and spoke estén preparadas para un crecimiento futuro a gran escala en varias suscripciones, grupos de administración y regiones.

Entre los escenarios de casos de uso de ejemplo de Virtual Network Manager se incluyen los siguientes:

  • Democratización de la administración de redes virtuales de radio en grupos como unidades de negocio o equipos de aplicaciones. La democratización puede dar lugar a un gran número de requisitos de reglas de seguridad de red y conectividad entre redes virtuales.
  • Estandarización de varias arquitecturas de réplica en varias regiones de Azure para garantizar una superficie global para las aplicaciones.

Para garantizar unas reglas de seguridad de red y conectividad uniformes, puede usar grupos de red para agrupar las redes virtuales de cualquier suscripción, grupo de administración o región del mismo inquilino de Microsoft Entra. Puede incorporar automáticamente o manualmente redes virtuales a grupos de red a través de asignaciones de pertenencia dinámicas o estáticas.

La detectabilidad de las redes virtuales que Virtual Network Manager administra se define mediante ámbitos. Esta característica proporciona flexibilidad para un número deseado de instancias de Network Manager, lo que permite una mayor democratización de la administración de los grupos de redes virtuales.

Para conectar redes virtuales de radio en el mismo grupo de red entre sí, use Virtual Network Manager para implementar el emparejamiento de red virtual o la conectividad directa. Use la opción de malla global para ampliar la conectividad directa de malla a redes de radio de diferentes regiones. En el diagrama siguiente se muestra la conectividad de malla global entre regiones.

Diagrama en el que se muestra la conectividad directa de malla global de radio entre regiones.

Puede asociar redes virtuales dentro de un grupo de red a un conjunto de líneas base de reglas de administración de seguridad. Las reglas de administración de seguridad del grupo de red impiden que los propietarios de redes virtuales de radio sobrescriban las reglas de seguridad de línea base, al tiempo que les permiten agregar sus propios conjuntos de reglas de seguridad y grupos de seguridad de red. Para obtener un ejemplo del uso de reglas de administración de seguridad en topologías en estrella tipo hub-and-spoke, consulte Tutorial: Creación de una red en estrella tipo hub-and-spoke protegida.

Para facilitar un lanzamiento controlado de los grupos de red, la conectividad y las reglas de seguridad, las implementaciones de configuración de Virtual Network Manager le ayudan a lanzar de forma segura los cambios de configuración potencialmente importantes en los entornos de estrella tipo hub-and-spoke. Para obtener más información, consulte Implementaciones de configuración en Azure Virtual Network Manager.

Para empezar a usar Virtual Network Manager, consulte Creación de una topología en estrella tipo hub-and-spoke con Azure Virtual Network Manager.

Consideraciones

Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar de seguridad.

Para garantizar un conjunto de líneas base de reglas de seguridad, asegúrese de asociar reglas de administración de seguridad con las redes virtuales en los grupos de red. Las reglas de administración de seguridad tienen prioridad sobre las reglas de NSG y se evalúan antes que éstas. Al igual que las reglas de NSG, las reglas de administración de seguridad admiten la priorización, las etiquetas de servicio y los protocolos L3-L4. Para obtener más información, consulte Reglas de administración de seguridad en Virtual Network Manager.

Use las implementaciones de Virtual Network Manager para facilitar el lanzamiento controlado de cambios potencialmente importantes en las reglas de seguridad del grupo de red.

Azure DDoS Protection, combinado con los procedimientos recomendados de diseño de aplicaciones, proporciona características mejoradas de mitigación de DDoS para ofrecer una mejor defensa frente a los ataques DDoS. Debe habilitar Azure DDOS Protection en cualquier red virtual perimetral.

Optimización de costos

La optimización de costos consiste en reducir los gastos innecesarios y mejorar la eficiencia operativa. Para más información, vea Información general del pilar de optimización de costos.

Tenga en cuenta los siguientes factores relacionados con los costos al implementar y administrar redes en estrella tipo hub-and-spoke. Para más información, consulte Precios de Virtual Network.

Costos asociados a Azure Firewall

Esta arquitectura implementa una instancia de Azure Firewall en la red de centro. El uso de una implementación de Azure Firewall como una solución compartida consumida por varias cargas de trabajo puede aportar un ahorro considerable en los costos en la nube en comparación con otros NVA. Para más información, consulte Azure Firewall frente a aplicaciones virtuales de red.

Para usar todos los recursos implementados de forma eficaz, elija el tamaño de Azure Firewall adecuado. Decida qué características necesita y qué nivel se adapta mejor a su conjunto actual de cargas de trabajo. Para obtener información sobre los SKU de Azure Firewall disponibles, consulte ¿Qué es Azure Firewall?

Costos asociados a la dirección IP privada

Puede usar direcciones IP privadas para enrutar el tráfico entre redes virtuales emparejadas o entre redes de grupos conectados. Se aplican las siguientes consideraciones relacionadas con los costos:

  • El tráfico de entrada y salida se cobra en ambos extremos de las redes emparejadas o conectadas. Por ejemplo, la transferencia de datos de una red virtual de la zona 1 a otra red virtual de la zona 2 incurrirá en una tasa de transferencia de salida de la zona 1 y una tasa de entrada de la zona 2.
  • Las distintas zonas tienen tasas de transferencia diferentes.

Planee el direccionamiento IP en función de los requisitos de emparejamiento y asegurarse de que el espacio de direcciones no se superponga entre ubicaciones locales y las ubicaciones de Azure.

Excelencia operativa

La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para más información, consulte Introducción al pilar de excelencia operativa.

Use Azure Network Watcher para supervisar y solucionar problemas relacionados con los componentes de red con las siguientes herramientas:

  • El Análisis de tráfico le muestra los sistemas de las redes virtuales que generan más tráfico. Puede identificar visualmente los cuellos de botella antes de que supongan un problema.
  • Network Performance Monitor supervisa la información sobre los circuitos de ExpressRoute.
  • Los diagnósticos de VPN ayudan a solucionar problemas de conexiones VPN de sitio a sitio que conectan las aplicaciones con los usuarios locales.

También debe considerar la posibilidad de habilitar el registro de diagnóstico de Azure Firewall para conocer mejor las solicitudes DNS y los resultados de permitir o denegar en los registros.

Implementación de este escenario

Esta implementación incluye una red virtual de centro y dos radios conectados, e implementa también una instancia de Azure Firewall y un host de Azure Bastion. Opcionalmente, la implementación puede incluir máquinas virtuales en la primera red de radio y una puerta de enlace de VPN.

Puede elegir entre el emparejamiento de red virtual o los grupos conectados de Virtual Network Manager para crear las conexiones de red. Cada método tiene varias opciones de implementación.

Uso del emparejamiento de red virtual

  1. Ejecute el siguiente comando para crear un grupo de recursos denominado hub-spoke en la región eastus de la implementación. Para usar un shell insertado, seleccione Pruébelo.

    az group create --name hub-spoke --location eastus
    
  2. Ejecute el siguiente comando para descargar la plantilla de Bicep.

    curl https://raw.githubusercontent.com/mspnp/samples/main/solutions/azure-hub-spoke/bicep/main.bicep > main.bicep
    
  3. Ejecute el siguiente comando para implementar la configuración de red en estrella tipo hub-and-spoke, los emparejamientos de red virtual entre el centro y los radios y un host de Azure Bastion. Cuando se le solicite, escriba un nombre de usuario y una contraseña. Puede usar este nombre de usuario y contraseña para acceder a las máquinas virtuales de las redes de radio.

    az deployment group create --resource-group hub-spoke --template-file main.bicep
    

Para obtener información detallada y más opciones de implementación, consulte las plantillas de ARM y Bicep de estrella tipo hub-and-spoke que implementan esta solución.

Uso de grupos conectados de Virtual Network Manager

  1. Ejecute el siguiente comando para crear un grupo de recursos para la implementación. Para usar un shell insertado, seleccione Pruébelo.

    az group create --name hub-spoke --location eastus
    
  2. Ejecute el siguiente comando para descargar la plantilla de Bicep.

    curl https://raw.githubusercontent.com/mspnp/samples/main/solutions/azure-hub-spoke-connected-group/bicep/main.bicep > main.bicep
    
  3. Ejecute los comandos siguientes para descargar todos los módulos necesarios en un nuevo directorio.

    mkdir modules
    
    curl https://raw.githubusercontent.com/mspnp/samples/main/solutions/azure-hub-spoke-connected-group/bicep/modules/avnm.bicep > modules/avnm.bicep
    curl https://raw.githubusercontent.com/mspnp/samples/main/solutions/azure-hub-spoke-connected-group/bicep/modules/avnmDeploymentScript.bicep > modules/avnmDeploymentScript.bicep
    curl https://raw.githubusercontent.com/mspnp/samples/main/solutions/azure-hub-spoke-connected-group/bicep/modules/hub.bicep > modules/hub.bicep
    curl https://raw.githubusercontent.com/mspnp/samples/main/solutions/azure-hub-spoke-connected-group/bicep/modules/spoke.bicep > modules/spoke.bicep
    
  4. Ejecute el comando siguiente para implementar la configuración de red en estrella tipo hub-and-spoke, las conexiones de red virtual entre el centro y los radios y un host de Bastion. Cuando se le solicite, escriba un nombre de usuario y una contraseña. Puede usar este nombre de usuario y contraseña para acceder a las máquinas virtuales de las redes de radio.

    az deployment group create --resource-group hub-spoke --template-file main.bicep
    

Para obtener información detallada y más opciones de implementación, consulte las plantillas de ARM y Bicep de estrella tipo hub-and-spoke que implementan esta solución.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

Alejandra Palacios | Ingeniera sénior de clientes

Otros colaboradores:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

Explore las siguientes arquitecturas relacionadas: