Fase de diseño 1: conectividad con sitios locales

La conectividad con centros de datos locales es el área de diseño más crítica para las redes de Azure VMware Solution. Entre los requisitos clave que se deben abordar se incluyen los siguientes:

• Alto rendimiento: las migraciones desde entornos locales de vSphere y las soluciones de recuperación ante desastres requieren mover grandes volúmenes de datos entre sitios locales y nubes privadas de Azure VMware Solution rápidamente.
• Baja latencia: las aplicaciones distribuidas pueden requerir una latencia baja para las conexiones entre máquinas virtuales de Azure VMware Solution y sistemas locales.
• Predictibilidad del rendimiento: para lograr un rendimiento y una latencia predecibles, las aplicaciones críticas para la empresa que se implementan en Azure VMware Solution podrían requerir servicios de conectividad dedicados (Azure ExpressRoute) entre sitios locales y la red de Microsoft.

En este artículo se describen las opciones admitidas por Azure VMware Solution para la conectividad con sitios locales:

• Global Reach de ExpressRoute
• Red privada virtual IPSec
• Configuración de VPN a través del emparejamiento privado de ExpressRoute

Las opciones se presentan por orden de para reducir la capacidad de cumplir los requisitos clave enumerados anteriormente. Se debe descartar una opción, y considerar la siguiente, únicamente si entra en conflicto con las restricciones no negociables de un escenario específico.

Este diagrama de flujo resume el proceso para elegir una opción de conectividad híbrida para Azure VMware Solution:

Global Reach de ExpressRoute

Global Reach de ExpressRoute es la opción de conectividad híbrida predeterminada compatible con Azure VMware Solution. Proporciona, con una complejidad mínima, conectividad de nivel 3 entre una nube privada de Azure VMware Solution y un sitio remoto conectado a un circuito ExpressRoute administrado por el cliente. También puede usar el circuito ExpressRoute administrado por el cliente para conectarse a los servicios nativos de Azure. Para mejorar la seguridad o reservar ancho de banda, también puede implementar un circuito independiente administrado por el cliente y dedicado exclusivamente al tráfico de Azure VMware Solution.

En el diagrama siguiente se muestra una topología de red que usa Global Reach para la conectividad con sitios locales. El tráfico entre las nubes privadas de Azure VMware Solution y los sitios locales no atraviesa las redes virtuales de Azure.

Nota:

Para lograr la máxima resistencia, se deben usar dos circuitos ExpressRoute administrados por el cliente en diferentes ubicaciones de emparejamiento para conectar centros de datos locales a la red troncal de Microsoft. En este caso, cada circuito ExpressRoute administrado por el cliente debe tener una conexión Global Reach a la nube privada de Azure VMware Solution (y a redes virtuales de Azure). Revise este artículo para obtener instrucciones sobre implementaciones de ExpressRoute resistentes.

Para obtener instrucciones sobre cómo conectar una nube privada de Azure VMware Solution a un circuito ExpressRoute administrado por el cliente mediante Global Reach, consulte Entornos locales del mismo nivel a Azure VMware Solution.

La conectividad de Global Reach aborda completamente los tres requisitos clave:

• Alto rendimiento: ExpressRoute permite conectarse a la red de Microsoft desde el entorno local a través de líneas dedicadas (hasta 10 Gbps para ExpressRoute basado en el proveedor o 100 Gbps para ExpressRoute Direct).
• Baja latencia: Global Reach permite enrutar el tráfico directamente desde el perímetro de la red de Microsoft a los clústeres de vSphere de Azure VMware Solution. Global Reach minimiza el número de saltos de red entre sitios locales y nubes privadas.
• Rendimiento predecible: cuando se usa Global Reach de ExpressRoute, el tráfico se enruta a través de vínculos que no experimentan problemas de congestión (hasta la capacidad máxima aprovisionada). Por lo tanto, el tiempo de ida y vuelta (RTT) entre las máquinas virtuales que se ejecutan en Azure VMware Solution y los hosts locales permanece constante en el tiempo.

No se puede usar Global Reach en escenarios en los que se aplican una o varias de las restricciones siguientes:

• Global Reach de ExpressRoute no está disponible en la región de Azure de la nube privada de Azure VMware Solution o en la ubicación de reunión del circuito ExpressRoute administrado por el cliente. No existen soluciones alternativas para esta limitación. Consulte Acerca de Global Reach de ExpressRoute para obtener información actualizada sobre la disponibilidad de Global Reach.

• Existen requisitos de seguridad de red no negociables. Si un dispositivo de firewall no se puede implementar en el lado local del circuito ExpressRoute administrado por el cliente, el uso de Global Reach expone todos los segmentos de red de Azure VMware Solution, incluidas las redes de administración (administración de vCenter Server y NSX-T), a toda la red conectada al circuito. El escenario más típico en el que surge este problema es cuando los circuitos ExpressRoute administrados por el cliente se implementan sobre servicios de red MPLS (también conocido comomodelo de conectividad universal de ExpressRoute). :Este escenario se muestra aquí:

  

  Cuando la conectividad de ExpressRoute se implementa sobre redes IPVPN MPLS, es imposible implementar firewalls en una sola ubicación para inspeccionar todo el tráfico hacia y desde Azure VMware Solution. Normalmente, las organizaciones que usan redes MPLS implementan firewalls en centros de datos grandes, no en todos sus sitios (que pueden ser pequeñas sucursales, oficinas o almacenes).

VPN de IPSec

Puede implementar la conectividad entre nubes privadas de Azure VMware Solution y sitios locales mediante el enrutamiento del tráfico a través de una red virtual de tránsito en Azure. La red de tránsito está conectada a la nube privada de Azure VMware Solution a través del circuito ExpressRoute administrado. La red virtual de tránsito está conectada al sitio local a través de una VPN IPSec, como se muestra aquí:

Puede aplicar directivas de seguridad para las conexiones entre sitios locales y la nube privada de Azure VMware Solution (la línea discontinua del diagrama) mediante el enrutamiento del tráfico a través de un firewall, si el dispositivo VPN no proporciona características de firewall. Esta configuración requiere Azure Virtual WAN con intenciónde enrutamiento, como se describe en la sección Decidir dónde hospedar los dispositivos virtuales en Azure de este artículo.

Antes de implementar la conectividad IPSec entre sitios locales y redes virtuales de tránsito, debe tomar tres decisiones de diseño:

1. Determine qué servicio de red se va a usar como la superposición del túnel IPSec. Las opciones disponibles son la conectividad a Internet, el emparejamiento de Microsoft de ExpressRoute y el emparejamiento privado de ExpressRoute.
2. Determine dónde hospedar los dispositivos virtuales que terminan el túnel IPSec en el lado de Azure. Las opciones disponibles incluyen redes virtuales administradas por el cliente y centros de Virtual WAN.
3. Determine qué dispositivo virtual finaliza el túnel IPSec en el lado de Azure. La elección del dispositivo también determina la configuración de Azure necesaria para enrutar el tráfico entre el túnel IPSec y el circuito administrado de Azure VMware Solution. Las opciones disponibles son Azure VPN Gateway nativa y NVA IPSec de terceros (aplicaciones virtuales de red).

Este diagrama de flujo resume el proceso de toma de decisiones:

Los criterios para tomar estas decisiones se describen en las secciones siguientes.

Elegir un servicio de red subyacente

Se recomienda encarecidamente que tenga en cuenta las tres opciones para la subposición de VPN en el orden que se presenta aquí:

• Conexión a Internet. La dirección IP pública asignada al dispositivo VPN hospedado en la red virtual de tránsito actúa como punto de conexión remoto del túnel IPSec. Debido a su baja complejidad y costo, siempre debe probar y evaluar la conectividad a Internet para el rendimiento (rendimiento de IPSec factible). Solo debe descartar esta opción cuando el rendimiento observado sea demasiado bajo o incoherente. En el siguiente diagrama se muestra este patrón.

  

• Emparejamiento de Microsoft para ExpressRoute. Esta opción proporciona conectividad de nivel 3 a los puntos de conexión públicos de Azure a través de vínculos dedicados. Al igual que las conexiones a Internet, permite llegar a la dirección IP pública de un dispositivo VPN que actúa como punto de conexión remoto del túnel IPSec y se hospeda en la red virtual de tránsito. Solo debe descartar esta opción cuando no se cumplan los requisitos de enrutamiento del emparejamiento de Microsoft. En el siguiente diagrama se muestra este patrón.

  

• Emparejamiento privado de ExpressRoute. Esta opción proporciona conectividad de nivel 3 entre un sitio local y redes virtuales de Azure a través de vínculos dedicados. Por lo tanto, permite establecer un túnel IPSec desde el sitio local a la dirección IP privada de un dispositivo VPN hospedado en una red virtual. El emparejamiento privado de ExpressRoute podría introducir limitaciones de ancho de banda porque la puerta de enlace de ExpressRoute está en la ruta de acceso de datos. Puede usar FastPath de ExpressRoute para solucionar este problema. El emparejamiento privado también requiere una configuración de enrutamiento más compleja en el lado local. Para obtener más información, consulteConfiguración de una conexión VPN de sitio a sitio a través del emparejamiento privado de ExpressRoute. En el siguiente diagrama se muestra este patrón.

  

Decidir dónde hospedar los dispositivos virtuales en Azure

Las opciones disponibles incluyen redes virtuales administradas por el cliente y centros de Virtual WAN. Para tomar esta decisión, tenga en cuenta las características del entorno de Azure preexistente, si hay una, y cómo desea priorizar la reducción del esfuerzo de administración frente a su capacidad de adaptar la configuración a necesidades específicas. A continuación, se indican algunas consideraciones clave.

• Debe usar la infraestructura de red de Azure existente para la conectividad de Azure VMware Solution. Si ya existe una red en estrella tipo hub-spoke administrada por el cliente en la misma región que la nube privada de Azure VMware Solution, debe implementar los dispositivos de terminación IPSec en el centro existente. Si existe una red en estrella tipo hub-spoke basada en Virtual WAN en la misma región que la nube privada de Azure VMware Solution, debe usar el centro de Virtual WAN para la terminación IPSec.
• En una red en estrella tipo hub-spoke administrada por el cliente, para enrutar el tráfico entre un túnel IPSec y el circuito administrado de ExpressRoute, debe implementar una instancia de Azure Route Server en la red virtual del centro de conectividad y configurarla para permitir el tráficode rama a rama. No es posible enrutar el tráfico entre nubes privadas de Azure VMware Solution y sitios locales a través de dispositivos de firewall que se implementan en la red virtual.
• Los centros de conectividad de Virtual WAN admiten de forma nativa el enrutamiento del tráfico entre el túnel IPSec que está conectado al sitio local y el circuito ExpressRoute administrado de Azure VMware Solution.
• Si usa Virtual WAN, puede configurar la intención de enrutamiento y las directivas de enrutamiento para la inspección del tráfico. Puede usar Azure Firewall o soluciones de seguridad de terceros compatibles con Virtual WAN. Se recomienda revisar la disponibilidad regional y las limitaciones de la intención de enrutamiento.

Decidir qué dispositivo virtual finaliza el túnel IPSec

El túnel IPSec que proporciona conectividad al sitio local se puede finalizar mediante Azure VPN Gateway o por las NVA de terceros. Para tomar esta decisión, tenga en cuenta las características del entorno de Azure preexistente, si hay una, y cómo desea priorizar la reducción del esfuerzo de administración frente a su capacidad de adaptar la configuración a necesidades específicas. A continuación, se indican algunas consideraciones clave.

• Tanto en las redes hub-spoke administradas por el cliente como en las redes hub-spoke basadas en Virtual WAN, puede usar puede usar Azure VPN Gateway para terminar túneles IPSec conectados a sitios locales. Dado que son administradas por la plataforma, las puertas de enlace de VPN de Azure requieren un esfuerzo de administración mínimo. Puede usar puertas de enlace preexistentes incluso si admiten otros escenarios de conectividad. Debe revisar estos artículos para obtener información sobre la configuración admitida y el rendimiento esperado:

  • SKU de VPN Gateway y niveles de rendimiento previstos (independientes)
  • Requisitos de cifrado de VPN Gateway (independiente)
  • Configuración de VPN Gateway (Virtual WAN)
  • Requisitos de cifrado de VPN Gateway (Virtual WAN)

• Normalmente, las NVA de terceros se usan para finalizar túneles de sitios locales en las situaciones siguientes:

  • La NVA es el CPE (equipo local del cliente) de una solución SDWAN que se implementa tanto en Azure como en el sitio local.
  • La aplicación virtual de red es un firewall que aplica la directiva de seguridad necesaria para las conexiones entre el sitio local y Azure VMware Solution.

El uso de dispositivos de terceros puede proporcionar más flexibilidad y acceso a funciones de red avanzadas que no son compatibles con puertas de enlace VPN nativas, pero aumenta la complejidad. La alta disponibilidad se convierte en su responsabilidad. Debe implementar varias instancias.

Tránsito por emparejamiento privado de ExpressRoute

El emparejamiento privado de ExpressRoute es la opción más común para conectar un sitio local a una red virtual de Azure (o red en estrella tipo hub-spoke) en escenarios empresariales. La red virtual de Azure o la red virtual del centro de conectividad en topologías en estrella tipo hub-spoke contiene una puerta de enlace de ExpressRoute configurada con una conexión al circuito ExpressRoute. Esta configuración proporciona conectividad de nivel 3 entre la red virtual (o toda la red hub-spoke) y la red del sitio local. Sin embargo, no proporciona conectividad de nivel 3 de forma nativa a nubes privadas de Azure VMware Solution conectadas a la misma red virtual (o red virtual del concentrador) a través de un circuito ExpressRoute administrado. (Consulte Global Reach de ExpressRoute y nubesprivadas de Azure VMware Solution.)

Puede solucionar esta limitación mediante la implementación de más dispositivos de enrutamiento en la red virtual de Azure. Esto le permite enrutar el tráfico a través de aplicaciones virtuales de red de firewall hospedadas en la red virtual.

El tránsito a través del emparejamiento privado de ExpressRoute puede parecer deseable, pero agrega complejidad y afecta al rendimiento. Debe considerarlo solo cuando las VPN de Global Reach y IPSec de ExpressRoute (descritas en las secciones anteriores) no son aplicables.

Hay dos opciones de implementación:

• Red virtual única. Al usar esta opción, los circuitos administrados por el cliente y administrados por Azure VMware Solution están conectados a la misma puerta de enlace de ExpressRoute.
• Red virtual de tránsito auxiliar. Cuando se usa esta opción, el circuito ExpressRoute administrado por el cliente que proporciona conectividad al sitio local está conectado a la puerta de enlace de ExpressRoute (normalmente preexistente) en la red virtual del centro de conectividad. El circuito administrado de Azure VMware Solution está conectado a otra puerta de enlace de ExpressRoute que se implementa en una red virtual de tránsito auxiliar.

En las secciones siguientes se proporcionan detalles sobre las dos opciones de implementación, entre las que se incluyen:

• Inconvenientes entre el rendimiento, el costo (recursos necesarios de Azure) y la sobrecarga de administración.
• Implementación del plano de control (cómo se intercambian las rutas entre el sitio local y la nube privada).
• Implementación del plano de datos (cómo se enrutan los paquetes de red entre el sitio local y la nube privada).

Red virtual única

Cuando se usa el enfoque de red virtual única, tanto el circuito administrado de la nube privada de Azure VMware Solution como el circuito propiedad del cliente están conectados a la misma puerta de enlace de ExpressRoute, normalmente la red central. El tráfico entre la nube privada y el sitio local se puede enrutar a través de NVA de firewall que se implementan en la red central. La arquitectura de red virtual única se programa aquí:

El plano de control y el plano de datos se implementan como se describe aquí:

• Plano de control Una puerta de enlace de ExpressRoute que se implementa en la red virtual de Azure no puede propagar rutas entre el circuito administrado de Azure VMware Solution y el circuito ExpressRoute administrado por el cliente. Azure Route Server, con la configuración de rama a rama habilitada, se usa para insertar, en ambos circuitos, rutas para superredes que incluyen el espacio de direcciones de la nube privada de Azure VMware Solution (redes de administración y segmentos de carga de trabajo) y el espacio de direcciones local.

  Las superredes, en lugar de los prefijos exactos que componen esos espacios de direcciones, deben anunciarse, ya que los prefijos exactos ya están anunciados en la dirección opuesta por la nube privada de Azure VMware Solution y el sitio local. Puede usar superredes tan grandes como los prefijos RFC 1918 si son compatibles con la configuración de red de los sitios locales. En la mayoría de los casos, debe usar las superredes más pequeñas que incluyen el espacio de direcciones de la nube privada de Azure VMware Solution y el espacio de direcciones local. De esta forma se minimizan los riesgos de conflictos con la configuración de enrutamiento de los sitios locales.

  Las rutas de las superredes se originan en NVA compatibles con BGP. Los NVA están configuradas para establecer una sesión de BPG con Azure Route Server. Los NVA solo forman parte del plano de control y no enrutan el tráfico real entre el sitio local y la nube privada de Azure VMware Solution. La implementación del plano de control se representa mediante las líneas discontinuas de la ilustración anterior.

• Plano de datos. La implementación del plano de control que se describe anteriormente atrae el tráfico siguiente a la puerta de enlace de ExpressRoute:

  • Tráfico desde el sitio local destinado a la nube privada de Azure VMware Solution.
  • Tráfico desde la nube privada Azure VMware Solution con destino al sitio local.

  Si no se aplican las UDR a GatewaySubnet, el tráfico fluye directamente entre el sitio local y la nube privada Azure VMware Solution. Puede enrutar el tráfico a un próximo salto intermedio aplicando las UDR a GatewaySubnet. Los NVA de firewall que aplican las directivas de seguridad de red en las conexiones entre los sitios locales y las nubes privadas son un ejemplo típico. La implementación del plano de datos se representa mediante la línea sólida de la ilustración anterior.

Red virtual auxiliar

Puede usar una red virtual auxiliar para hospedar una segunda puerta de enlace de ExpressRoute conectada solo al circuito administrado de la nube privada de Azure VMware Solution. Si usa este método, el circuito administrado de la nube privada y el circuito administrado por el cliente se conectan a diferentes puertas de enlace de ExpressRoute. Se usan dos instancias de Azure Route Server para anunciar las rutas adecuadas a cada circuito y controlar la propagación de rutas entre la nube privada y el sitio local. No es necesario anunciar superredes, como sucede con la opción de red virtual única que se describe en la sección anterior. También se reduce la sobrecarga de administración de las UDR en GatewaySubnet. Este enfoque le habilita a enrutar el tráfico entre la nube privada y el sitio local a través de los NVA de firewall en la red virtual central. La implementación de la red virtual auxiliar se muestra en el diagrama siguiente:

El plano de control y el plano de datos se implementan como se describe aquí:

• Plano de control Para habilitar la propagación de rutas entre el circuito administrado de la nube privada de Azure VMware Solution y el circuito propiedad del cliente, necesita una instancia de Azure Route Server en cada red virtual. Dado que las dos instancias de Azure Route Server no pueden establecer una adyacencias BGP, se necesitan las NVA compatibles con BGP para propagar rutas entre ellas. Para lograr una alta disponibilidad, debe implementar al menos dos instancias de NVA. Puede agregar más instancias para aumentar el rendimiento. Las NVA con capacidad BGP deben tener dos NIC adjuntas a subredes diferentes. Las sesiones BGP hacia los dos servidores de rutas (en la red virtual auxiliar y la red virtual del central) deben establecerse a través de diferentes NIC.

  Las rutas originadas por la nube privada de Azure VMware Solution y por el sitio local se aprenden a través de circuitos ExpressRoute. Sus rutas de acceso de AS contienen el ASN 65515 (un ASN reservado de Azure que usan las puertas de enlace de ExpressRoute) y ASN 12076 (un ASN propiedad de Microsoft que usan los enrutadores perimetrales de Microsoft Enterprise en todas las ubicaciones de emparejamiento). Las NVA con capacidad BGP deben quitar las rutas AS para evitar que las rutas sean anuladas por la detección de bucles BGP. Para obtener más información sobre la configuración de BGP necesaria, consulte Implementación de la conectividad de Expressroute para AVS sin Global Reach. La implementación del plano de control se representa mediante las líneas discontinuas del diagrama anterior.

• Plano de datos. En la red virtual auxiliar, el tráfico entre la nube privada de Azure VMware Solution y el sitio local se enruta a través de las NVA compatibles con BGP. El tráfico hacia y desde la nube privada de Azure VMware Solution sale o entra en las NVA a través de la NIC que se usa para la sesión BGP con el servidor de rutas de la red virtual auxiliar. El tráfico hacia y desde el sitio local sale o entra en las NVA a través de la NIC que se usa para la sesión BGP con el servidor de rutas de la red virtual del concentrador. Esta NIC está adjunta a una subred que está asociada a una tabla de enrutamiento personalizada que:

  • Deshabilita el aprendizaje de rutas BGP desde el servidor de rutas (para evitar bucles).
  • Inserta el firewall de la red central en la ruta de datos.

  Para asegurarse de que el tráfico se enruta simétricamente a través del firewall central, los UDR para todos los prefijos que se usan en la nube privada Azure VMware Solution deben configurarse en la GatewaySubnet del centro. Para obtener más información, consulte Implementación de la conectividad de Expressroute para AVS sin Global Reach. La implementación del plano de datos se representa mediante la línea sólida del diagrama anterior.

Pasos siguientes

Obtenga información acerca de la conectividad entre Azure VMware Solution y las redes virtuales de Azure.

Conectividad entre Azure VMware Solution y redes virtuales de Azure