Topología de red y conectividad para Azure VMware Solution

• Los patrones de entrada mediante Application Gateway y Azure Firewall son similares para todos los escenarios.
• Puede usar NVA del equilibrador de carga L4-L7 en Azure VMware Solution.
• Puede usar el firewall de NSX-T con cualquiera de estos escenarios.

En las secciones siguientes se describen los cuatro escenarios de red más comunes para las nubes privadas de Azure VMware Solution. Esta lista no es exhaustiva. Para obtener más escenarios, consulte Implementación de NVA que admiten VXLAN con Azure Route Server y VNet de tránsito.

Escenario 1: centro de Virtual WAN protegido con propagación de ruta predeterminada

En este escenario se incluye el siguiente perfil de cliente, componentes arquitectónicos y consideraciones:

Perfil de cliente

Este escenario es ideal en las situaciones siguientes:

• No es necesario inspeccionar el tráfico entre Azure VMware Solution y Azure Virtual Network.
• No es necesario inspeccionar el tráfico entre Azure VMware Solution y los centros de datos locales.
• Es necesario inspeccionar el tráfico entre cargas de trabajo de Azure VMware Solution e Internet.

En este escenario, se consume Azure VMware Solution como oferta de plataforma como servicio (PaaS). No posee las direcciones IP públicas. Si es necesario, debe agregar servicios de entrada L4 y L7 orientados al público. Es posible que ya tenga o no conectividad de ExpressRoute entre centros de datos locales y Azure.

Componentes de la arquitectura

Puede implementar este escenario con:

• Azure Firewall en el centro de Virtual WAN protegido para firewalls.
• Application Gateway para el equilibrio de carga L7.
• DNAT L4 (Traducción de direcciones de red de destino) con Azure Firewall para traducir y filtrar el tráfico de entrada de red.
• Internet de salida mediante Azure Firewall en el centro de Virtual WAN.
• ExR, VPN o SD-WAN para la conectividad entre centros de datos locales y Azure VMware Solution.

Consideraciones

Si no quiere recibir el anuncio de ruta predeterminada 0.0.0.0/0 de Azure VMware Solution porque entra en conflicto con el entorno existente, debe realizar más acciones.

Azure Firewall en el centro de Virtual WAN seguro anuncia la ruta 0.0.0.0/0 a Azure VMware Solution. La ruta 0.0.0.0/0 también se anuncia localmente mediante Global Reach. Implemente un filtro de ruta local para evitar el aprendizaje de rutas 0.0.0.0/0. Si usa SD-WAN o VPN, este problema no se producirá.

Si actualmente se conecta a una topología en estrella tipo hub-and-spoke basada en red virtual mediante una puerta de enlace de ExpressRoute en lugar de directamente, la ruta 0.0.0.0/0 predeterminada del centro de Virtual WAN se propaga a la puerta de enlace y tiene prioridad sobre la ruta del sistema de Internet integrada en la red virtual. Para solucionar este problema, implemente una 0.0.0.0/00.0.0.0/0 en la red virtual para invalidar la ruta predeterminada aprendida.

Las conexiones de VPN, ExpressRoute o red virtual establecidas al centro de Virtual WAN seguro que no requieren ningún anuncio 0.0.0.0/0 también lo recibirán. Puede solucionar este problema de dos maneras:

• Filtre la ruta 0.0.0.0/0 con un dispositivo perimetral local.

• O:

  1. Desconecte la red de ExpressRoute, VPN o virtual.
  2. Habilite la propagación 0.0.0.0/0.
  3. Deshabilite la propagación 0.0.0.0/0 en esas conexiones específicas.
  4. Vuelva a conectar las conexiones.

Puede hospedar Application Gateway en una red virtual radial conectada al centro o en la red virtual del centro.

Escenario 2: NVA de terceros en Azure Virtual Network con Azure Route Server, con Global Reach deshabilitado

En este escenario se incluye el siguiente perfil de cliente, componentes arquitectónicos y consideraciones:

Perfil de cliente

Este escenario es ideal en las situaciones siguientes:

• Necesita un control más preciso sobre los firewalls fuera de la nube privada de Azure VMware Solution.
• Debe usar un dispositivo de seguridad del proveedor actual en entornos locales u otros entornos de Azure.
• Necesita varias direcciones IP públicas para los servicios de entrada y un bloque de direcciones IP predefinidas en Azure. En este escenario, no posee las IP públicas.
• Quiere inspeccionar el tráfico entre Azure VMware Solution y los centros de datos locales mediante NVA, y no puede usar Global Reach por motivos geopolíticos.
• Normalmente, necesita servicios de entrada L4 y L7 orientados al público para los servicios de Azure VMware Solution y también necesita conectividad saliente a Internet.

En este escenario, ya tiene conectividad de ExpressRoute entre centros de datos locales y Azure.

Componentes de la arquitectura

Puede implementar este escenario con:

• NVA de terceros hospedadas en una red virtual para firewalls y otras funciones de red.
• Azure Route Server para enrutar el tráfico entre Azure VMware Solution, centros de datos locales y redes virtuales.
• Application Gateway es la solución preferida para el equilibrio de carga HTTP/S L7.

En este escenario, debe deshabilitar ExpressRoute Global Reach. Las NVA son responsables de proporcionar internet de salida a Azure VMware Solution.

Consideraciones

En este escenario, se debe inspeccionar todo el tráfico de la red virtual del centro, que hospeda las NVA, por lo que debe deshabilitar ExpressRoute Global Reach. Global Reach permitiría que el tráfico de Azure VMware Solution fluyera directamente entre los enrutadores de ExpressRoute de Microsoft Enterprise Edge (MSEE) y, así, se omitiera la red virtual del centro.

Implemente Azure Route Server para asegurarse de enrutar el tráfico mediante el centro. Es responsable de implementar y administrar una solución de NVA, o de usar una existente.

Si necesita alta disponibilidad para las NVA, impleméntelas en una configuración activa-en espera para conservar el enrutamiento simétrico. Para más información, consulte la documentación del proveedor de NVA e implemente NVA de alta disponibilidad.

En el diagrama de arquitectura anterior se muestra una NVA con compatibilidad con VXLAN. Para las NVA incompatibles con VXLAN, consulte Implementación de una NVA no integrada en Virtual WAN sin VXLAN y una VNet de tránsito.

Escenario 3: salida desde Azure VMware Solution con o sin NSX-T o NVA

En este escenario se incluye el siguiente perfil de cliente, componentes arquitectónicos y consideraciones:

Perfil de cliente

Este escenario es ideal en las situaciones siguientes:

• Debe usar la plataforma NSX nativa, por lo que necesita una implementación de PaaS para Azure VMware Solution.
• O bien necesita una NVA de tipo traiga su propia licencia (BYOL) en Azure VMware Solution para la inspección del tráfico.
• Es posible que ya tenga o no conectividad de ExpressRoute entre centros de datos locales y Azure.
• Necesita servicios HTTP/S o L4 de entrada.

Todo el tráfico desde Azure VMware Solution a Azure Virtual Network, a Internet y a los centros de datos locales se canaliza por los enrutadores NSX de nivel 0 y 1 o las NVA.

Componentes de la arquitectura

Puede implementar este escenario con:

• Firewall distribuido (DFW) de NSX o NVA detrás del nivel 1 en Azure VMware Solution
• Application Gateway para el equilibrio de carga L7.
• DNAT L4 mediante Azure Firewall
• Salida de Internet de Azure VMware Solution

Consideraciones

Debe habilitar el acceso a Internet en Azure Portal. Con este diseño, la dirección IP de salida puede cambiar y no es determinista. Las direcciones IP públicas residen fuera de la NVA. La NVA de Azure VMware Solution tiene direcciones IP privadas y no determina la dirección IP pública de salida.

La NVA es BYOL y es su responsabilidad traer la licencia e implementar la alta disponibilidad para la NVA.

Consulte en la documentación de VMware las opciones de selección de ubicación de NVA y la información sobre la limitación de VMware de hasta ocho tarjetas de interfaz de red virtual (NIC) en una VM. Para más información, consulte Integración del firewall en Azure VMware Solution.

Escenario 4: salida desde Azure VMware Solution mediante un anuncio 0.0.0.0/0 desde el entorno local

En este escenario se incluye el siguiente perfil de cliente, componentes arquitectónicos y consideraciones:

Perfil de cliente

Este escenario es ideal en las situaciones siguientes:

• Quiere usar la NVA local y anunciar 0.0.0.0/0 desde el entorno local.
• Ya tiene o tendrá ExpressRoute entre centros de datos locales y Azure, con Global Reach habilitado.
• Necesita servicios de entrada HTTP/S o L4 orientados al público.

La inspección del tráfico de salida de Internet se controla de forma local. El centro de Azure Virtual WAN protegido realiza la inspección del tráfico entre Azure VMware Solution y Azure Virtual Network.

Componentes de la arquitectura

Puede implementar este escenario con:

• Application Gateway para el equilibrio de carga L7.
• DNAT L4 mediante Azure Firewall
• Salida de internet local
• ExpressRoute WAN para la conectividad entre centros de datos locales y Azure VMware Solution

Consideraciones

Con este diseño, las direcciones IP públicas de salida residen en el entorno local con la NVA local.

Si actualmente se conecta a una topología en estrella tipo hub-and-spoke basada en red virtual mediante una puerta de enlace de ExpressRoute en lugar de directamente, la ruta 0.0.0.0/0 predeterminada del centro de Virtual WAN se propaga a la puerta de enlace y tiene prioridad sobre la ruta del sistema de Internet integrada en la red virtual. Para solucionar este problema, implemente una 0.0.0.0/00.0.0.0/0 en la red virtual para invalidar la ruta predeterminada aprendida.

Recomendaciones y consideraciones generales de diseño

Estas son algunas consideraciones de diseño generales y recomendaciones para la conectividad y topología de red de Azure VMware Solution:

Topología de red en estrella tipo hub-and-spoke o Virtual WAN

Virtual WAN admite la conectividad de tránsito entre VPN y ExpressRoute, pero no la topología de red en estrella tipo hub-and-spoke.

Nubes privadas y clústeres

• Todos los clústeres pueden comunicarse dentro de una nube privada de Azure VMware Solution, ya que todos comparten el mismo espacio de direcciones /22.

• Todos los clústeres comparten también la misma configuración de conectividad, como Internet, ExpressRoute, HCX, IP pública y ExpressRoute Global Reach. Las cargas de trabajo de la aplicación también pueden compartir algunas configuraciones de red básicas, como segmentos de red, protocolo de configuración dinámica de host (DHCP) y sistema de nombres de dominio (DNS).

• Diseñe sus nubes privadas y clústeres de antemano antes de la implementación. El número de nubes privadas afecta directamente a los requisitos de red. Cada nube privada requiere su propio espacio de direcciones /22 para la administración de la nube privada y el segmento de direcciones IP para las cargas de trabajo de VM. Considere la posibilidad de definir esos espacios de direcciones de antemano.

• Hable con los equipos de redes y VMware sobre cómo segmentar y distribuir las nubes privadas, los clústeres y los segmentos de red para las cargas de trabajo. Plan previo para evitar malgastar direcciones IP.

• Para obtener más información sobre la administración de direcciones IP para nubes privadas, consulte Definición del segmento de direcciones IP para la administración de nubes privadas.

• Para obtener más información sobre la administración de direcciones IP para cargas de trabajo de VM, consulte Definición del segmento de direcciones IP para cargas de trabajo de VM.

DNS y DHCP

Para DHCP, use el servicio DHCP integrado en NSX o un servidor DHCP local en la nube privada. No devuelva el tráfico DHCP de difusión mediante WAN a las redes locales.

Para DNS, en función del escenario que adopte y sus requisitos, tiene diferentes opciones:

• Para un entorno exclusivamente en Azure VMware Solution, implemente una nueva infraestructura de DNS en la nube privada de Azure VMware Solution.
• Para Azure VMware Solution conectado a un entorno local, use la infraestructura de DNS existente. Si es necesario, implemente reenviadores DNS para extenderlos a Azure Virtual Network o, preferiblemente, a Azure VMware Solution. Para obtener más información, consulte Agregar un servicio de reenviador DNS.
• Para Azure VMware Solution conectado a entornos y servicios locales y de Azure, use servidores DNS existentes o reenviadores DNS en la red virtual del centro si están disponibles. También puede ampliar la infraestructura DNS local existente a la red virtual del centro de Azure. Para obtener más información, consulte el diagrama de zonas de aterrizaje de escala empresarial.

Para más información, consulte:

• Consideraciones sobre DHCP y la resolución de DNS
• Configuración de DHCP para Azure VMware Solution
• Configuración de DHCP en redes de VMware HCX extendido L2
• Configuración de un reenviador DNS en Azure Portal

Internet

La lista siguiente es una referencia rápida:

Entre las opciones de salida para habilitar Internet y filtrar e inspeccionar el tráfico se incluyen las siguientes:

• Azure Virtual Network, NVA y Azure Route Server mediante el acceso a Internet de Azure
• Ruta predeterminada local mediante el acceso a Internet local
• Centro protegido de Virtual WAN con Azure Firewall o NVA, mediante el acceso a Internet de Azure

Entre las opciones de entrada para entregar contenido y aplicaciones se incluyen las siguientes:

• Azure Application Gateway con L7, terminación de Capa de sockets seguros (SSL) y Web Application Firewall
• DNAT y equilibrador de carga mediante el entorno local
• Azure Virtual Network, NVA y Azure Route Server en varios escenarios
• Centro protegido de Virtual WAN con Azure Firewall, con L4 y DNAT
• Centro protegido de Virtual WAN con NVA en varios escenarios

ExpressRoute

La implementación de la nube privada integrada de Azure VMware Solution aprovisiona automáticamente un circuito ExpressRoute gratuito. Este circuito conecta Azure VMware Solution a D-MSEE.

Para la ubicación, considere la posibilidad de implementar Azure VMware Solution en regiones emparejadas de Azure cerca de los centros de datos.

Global Reach

• Global Reach es un complemento de ExpressRoute necesario para que Azure VMware Solution se comunique con centros de datos locales, Azure Virtual Network y Virtual WAN. La alternativa es diseñar la conectividad de red con Azure Route Server.

• Puede emparejar el circuito Azure VMware Solution ExpressRoute con otros circuitos de ExpressRoute mediante Global Reach sin cargo alguno.

• Puede usar Global Reach para emparejar circuitos de ExpressRoute mediante un ISP y para circuitos de ExpressRoute Direct.

• Global Reach no se admite para los circuitos locales de ExpressRoute. En el caso de ExpressRoute local, el tránsito de Azure VMware Solution a los centros de datos locales se realiza mediante NVA de terceros en una red virtual de Azure.

• Global Reach no está disponible en todas las ubicaciones.

Ancho de banda

Elija una SKU de puerta de enlace de red virtual para un ancho de banda óptimo entre Azure VMware Solution y Azure Virtual Network. Azure VMware Solution admite un máximo de cuatro circuitos de ExpressRoute a una puerta de enlace de ExpressRoute en una región.

Seguridad de las redes

La seguridad de red usa la inspección del tráfico y la creación de reflejo del puerto.

La inspección del tráfico de este a oeste dentro del SDDC usa NSX-T o NVA para inspeccionar el tráfico a Azure Virtual Network entre regiones.

La inspección del tráfico norte-sur inspecciona el flujo de tráfico bidireccional entre Azure VMware Solution y los centros de datos. La inspección del tráfico de norte a sur puede usar:

• NVA y Azure Route Server mediante Internet de Azure
• Ruta predeterminada local mediante Internet local
• Azure Firewall y Virtual WAN mediante Internet de Azure
• NSX-T dentro del SDDC mediante Internet de Azure VMware Solution
• NVA en Azure VMware Solution dentro del SDDC mediante Internet de Azure VMware Solution

Requisitos de puertos y protocolos

Configure todos los puertos necesarios para que un firewall local garantice el acceso adecuado a todos los componentes de la nube privada de Azure VMware Solution. Para obtener más información, consulte Puertos de red necesarios.

Acceso de administración de Azure VMware Solution

• Durante la implementación, considere la posibilidad de usar un host de Azure Bastion en Azure Virtual Network para acceder al entorno de Azure VMware Solution.

• Una vez establecido el enrutamiento al entorno local, la red de administración de Azure VMware Solution no respeta las rutas 0.0.0.0/0 de las redes locales, por lo que debe anunciar rutas más específicas para las redes locales.

Continuidad empresarial y recuperación ante desastres (BCDR) y migraciones

• Con las migraciones de VMware HCX, la puerta de enlace predeterminada es local. Para obtener más información, consulte Implementación y configuración de VMware HCX.

• La migración de VMware HCX puede usar la extensión HCX L2. Las migraciones que requieren la extensión de nivel 2 requieren ExpressRoute. VPN no es compatible. El tamaño máximo de la unidad de transmisión (MTU) debe ser 1350 para ajustarse a la sobrecarga de HCX. Para obtener más información sobre el diseño de extensiones de nivel 2, consulte Puente de nivel 2 en modo de administrador (VMware.com).

Pasos siguientes

• Para obtener más información sobre Azure VMware Solution en redes en estrella tipo hub-and-spoke, consulte Integración de Azure VMware Solution en una arquitectura en estrella tipo hub-and-spoke.

• Para obtener más información sobre los segmentos de red de VMware NSX, consulte Configuración de los componentes de red NSX mediante Azure VMware Solution.

• Para seguir aprendiendo sobre los principios arquitectónicos de la zona de aterrizaje de escala empresarial, las consideraciones de diseño y los procedimientos recomendados para Azure VMware Solution, consulte el siguiente artículo de la serie:

  Disciplinas de seguridad, gobernanza y cumplimiento de Azure VMware Solution

El uso del Centro de datos definido por software (SDDC) de VMware con el ecosistema en la nube de Azure presenta un conjunto único de consideraciones de diseño para escenarios híbridos y nativos en la nube. En este artículo se examinan las principales consideraciones y los procedimientos recomendados en relación con las redes y la conectividad hacia, desde y dentro de Azure y las implementaciones de Azure VMware Solution.

El artículo se basa en varios principios arquitectónicos de zonas de aterrizaje de escala empresarial de Cloud Adoption Framework y recomendaciones para administrar la topología de red y la conectividad a escala. Puede usar esta guía de área de diseño de escala empresarial para plataformas críticas de Azure VMware Solution. Las bases de diseño incluyen lo siguiente:

• Integración híbrida para la conectividad entre usuarios locales, multinube, perimetrales y globales. Para obtener más información, consulte Compatibilidad de la escala empresarial con la arquitectura híbrida y multinube.
• Rendimiento y confiabilidad a escala para una experiencia coherente y de baja latencia y escalabilidad para cargas de trabajo.
• Seguridad de red basada en confianza cero para proteger el perímetro de red y los flujos de tráfico. Para obtener más información, consulte Estrategias de seguridad de red de Azure.
• Extensibilidad para expandir fácilmente la superficie de red sin necesidad de repetir el trabajo de diseño.

Componentes y conceptos de red

• Azure Virtual Network es el bloque de creación fundamental para las redes privadas en Azure. Con Azure Virtual Network, muchos tipos de recursos de Azure, como Azure Virtual Machines (VM), pueden comunicarse de manera segura entre sí, con Internet y con centros de datos locales. Una red virtual es similar a una red tradicional que opera en su propio centro de datos, pero tiene ventajas de la infraestructura de Azure, como la escala, la disponibilidad y el aislamiento.

• Una aplicación virtual de red (NVA) es un dispositivo de red que admite funciones como la conectividad, la entrega de aplicaciones, la optimización de red de área extensa (WAN) y la seguridad. Las NVA incluyen Azure Firewall y Azure Load Balancer.

• Azure Virtual WAN es un servicio de red que agrupa muchas funciones de red, seguridad y enrutamiento en una única interfaz operativa. Estas son algunas de ellas:

  • Automatización de la conectividad de rama desde dispositivos asociados de Virtual WAN, como SD-WAN o redes privadas virtuales (VPN) basadas en equipos locales del cliente (CPE)
  • Conectividad de VPN de sitio a sitio
  • Conectividad de VPN de punto a sitio de usuario remoto
  • Conectividad privada de Azure ExpressRoute
  • Conectividad dentro de la nube, como conectividad transitiva para redes virtuales
  • Interconectividad de ExpressRoute para VPN
  • Enrutamiento
  • Azure Firewall
  • Cifrado para conectividad privada

• En la topología de red en estrella tipo hub-and-spoke, una red virtual de centro sirve como punto central de conectividad para varias redes virtuales de radio. El centro también puede ser el punto de conectividad con los centros de datos locales. Las redes virtuales de radio se emparejan con el centro y se pueden usar para aislar las cargas de trabajo.

• VXLAN (LAN de extensión virtual) es una tecnología de virtualización de red para escalar redes en la nube. VXLAN genera una red virtual para superponer una red de área local (LAN) mediante la tecnología de nivel 3 (L3) para ampliar la red.

• La extensión de nivel 2 (L2) extiende una LAN virtual o un dominio de difusión de red entre dos sitios. La extensión L2 tiene muchos nombres, como la interconexión del centro de datos (DCI), la extensión del centro de datos (DCE), la red de nivel 2 ampliada, la red de nivel 2 extendida, la VLAN extendida, la VLAN ampliada, la implementación extendida o la VPN de nivel 2.

• El nivel 4 (L4) hace referencia al cuarto nivel del modelo de interconexión de sistemas abiertos (OSI). L4 proporciona una transmisión o transferencia transparente de datos entre sistemas finales o hosts. L4 es responsable de la recuperación de errores de un extremo a otro, así como del control del flujo. Algunos de los principales protocolos que se usan en L4 son:

  • Protocolo de datagramas de usuario (UDP)
  • UDP básico
  • UDP cíclico (CUDP)
  • UDP confiable (RUDP)
  • Protocolo de transacción de AppleTalk (ATP)
  • TCP de múltiples rutas (MPTCP)
  • Protocolo de control de transmisión (TCP)
  • Intercambio de paquetes secuenciado (SPX)

• El nivel 7 es el séptimo y último nivel del modelo de OSI, denominado nivel de aplicación. El nivel 7 identifica las partes que se comunican y la calidad del servicio entre ellas. El nivel 7 controla la privacidad y la autenticación del usuario, e identifica las restricciones de la sintaxis de datos. Este nivel es completamente específico de la aplicación. Las llamadas a la API y las respuestas pertenecen a este nivel. Algunos de los principales protocolos de L7 son HTTP, HTTPS y SMTP.

Escenarios de redes

El diseño e implementación de funcionalidades de red es fundamental para establecer la zona de aterrizaje de Azure VMware Solution. Los servicios y productos de redes de Azure admiten una amplia variedad de funcionalidades. Qué arquitectura elegir y cómo estructurar los servicios depende de las cargas de trabajo, la gobernanza y los requisitos de la organización.

Los siguientes requisitos y consideraciones clave afectan a la decisión sobre la implementación de Azure VMware Solution:

• Requisitos de entrada de Internet HTTP/S o no HTTP/S en aplicaciones de Azure VMware Solution

• Consideraciones sobre la ruta de acceso de salida de Internet

• Extensión L2 para migraciones

• Uso de NVA en la arquitectura actual

• Conectividad de Azure VMware Solution con una red virtual de centro estándar o un centro de Virtual WAN

• Conectividad privada de ExpressRoute desde centros de datos locales a Azure VMware Solution y si ExpressRoute Global Reach está habilitado

• Requisitos de inspección de tráfico para:

  • Entrada de Internet en las aplicaciones de Azure VMware Solution
  • Acceso de entrada de Azure VMware Solution a Internet
  • Acceso de Azure VMware Solution a centros de datos locales
  • Acceso de Azure VMware Solution a Azure Virtual Network
  • Tráfico en la nube privada de Azure VMware Solution

En la tabla siguiente se proporcionan recomendaciones y consideraciones para los cuatro escenarios de red más comunes basados en los requisitos de inspección del tráfico de Azure VMware Solution.