Análisis detallado del enrutamiento de Virtual WAN
Azure Virtual WAN es una solución de red que permite crear topologías de red sofisticadas fácilmente: abarca el enrutamiento en regiones de Azure entre redes virtuales de Azure y ubicaciones locales a través de VPN de punto a sitio, VPN de sitio a sitio, ExpressRoute y dispositivos SDWAN integrados, incluida la opción para proteger el tráfico. En la mayoría de los escenarios no es necesario conocer en detalle cómo funciona el enrutamiento interno de Virtual WAN, pero en determinadas situaciones puede resultar útil comprender los conceptos de enrutamiento de Virtual WAN.
En este documento se exploran escenarios de ejemplo de Virtual WAN que explican algunos de los comportamientos que pueden encontrar las organizaciones al interconectar sus redes virtuales y ramas en redes complejas. Los escenarios que se muestran en este artículo no son recomendaciones de diseño, son solo topologías de ejemplo diseñadas para mostrar funcionalidades determinadas de Virtual WAN.
Escenario 1: topología con preferencia de enrutamiento predeterminada
En el primer escenario de este artículo se analiza una topología con dos centros de conectividad de Virtual WAN, ExpressRoute, VPN y conectividad SDWAN. En cada centro de conectividad hay redes virtuales conectadas directamente (redes virtuales 11 y 21) e indirectamente mediante una aplicación virtual de red (redes virtuales 121, 122, 221 y 222). La red virtual 12 intercambia información de enrutamiento con el centro de conectividad 1 a través de BGP (consulte Emparejamiento de BGP con un centro de conectividad virtual) y la red virtual 22 tiene configuradas rutas estáticas, de modo que se puedan mostrar las diferencias entre ambas opciones.
En cada centro de conectividad, los dispositivos VPN y SDWAN sirven para un propósito doble: por un lado, anuncian sus propios prefijos individuales (10.4.1.0/24 a través de VPN en el centro de conectividad 1 y 10.5.3.0/24 a través de SDWAN en el centro de conectividad 2) y, por el otro, anuncian los mismos prefijos que los circuitos de ExpressRoute en la misma región (10.4.2.0/24 en el centro de conectividad 1 y 10.5.2.0/24 en el centro de conectividad 2). Esta diferencia se usará para demostrar cómo funciona la preferencia de enrutamiento del centro de conectividad de Virtual WAN.
Todas las conexiones de red virtual y rama están asociadas y se propagan a la tabla de rutas predeterminada. Aunque los centros de conectividad están protegidos (hay una instancia de Azure Firewall implementada en cada centro de conectividad), no están configurados para proteger el tráfico privado o de Internet. Si lo hace, todas las conexiones se propagan a la tabla de rutas None, lo que quitaría todas las rutas no estáticas de la tabla de rutas Default y resultaría contrario al propósito de este artículo, ya que la hoja de ruta efectiva en el portal estaría casi vacía (excepto en el caso de las rutas estáticas para enviar tráfico a la instancia de Azure Firewall).
Importante
En el diagrama anterior se muestran dos centros virtuales protegidos. Esta topología se admite con intención de enrutamiento. Para obtener más información, consulte Configuración de la intención de enrutamiento y las políticas de enrutamiento de Virtual WAN Hub.
De manera predeterminada, los centros de conectividad de Virtual WAN intercambian información entre sí para que se habilite la comunicación entre regiones. Puede inspeccionar las rutas efectivas en las tablas de rutas de Virtual WAN; por ejemplo, en la siguiente imagen se muestran las rutas efectivas en el centro de conectividad 1:
Estas rutas efectivas se anunciarán después mediante Virtual WAN a las ramas y las insertarán en las redes virtuales conectadas a los centros de conectividad virtuales, lo que hace innecesario el uso de las rutas definidas por el usuario. Al inspeccionar las rutas efectivas en un centro de conectividad virtual, los campos "Tipo de próximo salto" y "Origen" indicarán de dónde proceden las rutas. Por ejemplo, un tipo de próximo salto de "Conexión de red virtual" indica que el prefijo se define en una red virtual conectada directamente a Virtual WAN (redes virtuales 11 y 12 en la captura de pantalla anterior).
La NVA de la red virtual 12 inserta la ruta 10.1.20.0/22 a través de BGP, ya que el tipo de próximo salto "HubBgpConnection" implica (consulte Emparejamiento BGP con un centro virtual). Esta ruta de resumen abarca tanto la red virtual de radios indirectos 121 (10.1.21.0/24) como la red virtual 122 (10.1.22.0/24). Las redes virtuales y las ramas del centro de conectividad remoto son visibles con un próximo salto de hub2 y se pueden ver en la ruta de acceso de AS que el número de sistema autónomo 65520 se ha antepuesto dos veces a estas rutas entre centros de conectividad.
En el centro de conectividad 2 hay una aplicación virtual de red SDWAN integrada. Para obtener más información sobre las aplicaciones virtuales de red compatibles con esta integración, visite Acerca de las aplicaciones virtuales de red en un centro de conectividad de Virtual WAN. Tenga en cuenta que la ruta a la rama 10.5.3.0/24 SDWAN tiene un próximo salto de VPN_S2S_Gateway. Actualmente, este tipo de próximo salto puede indicar las rutas procedentes de una puerta de enlace de Azure Virtual Network o de aplicaciones virtuales de red integradas en el centro de conectividad.
En el centro de conectividad 2, la ruta de 10.2.20.0/22 a la red virtual 221 (10.2.21.0/24) y la red virtual 222 (10.2.22.0/24) de radios indirectos se instala como una ruta estática, como se indica en el origen defaultRouteTable. Si hace la comprobación de las rutas efectivas del centro de conectividad 1, esa ruta no se encuentra allí. El motivo es que las rutas estáticas no se propagan a través del BGP, pero deben configurarse en cada centro de conectividad. Por lo tanto, se requiere una ruta estática en el centro de conectividad 1 para proporcionar conectividad entre las redes virtuales y las ramas del centro de conectividad 1 a los radios indirectos del centro de conectividad 2 (redes virtuales 221 y 222):
Después de agregar la ruta estática, el centro de conectividad 1 también contendrá la ruta 10.2.20.0/22:
Escenario 2: Preferencia de enrutamiento de centro de conectividad y Global Reach
Incluso si el centro de conectividad 1 conoce el prefijo de ExpressRoute del circuito 2 (10.5.2.0/24) y el centro de conectividad 2 conoce el prefijo de ExpressRoute del circuito 1 (10.4.2.0/24), las rutas de ExpressRoute desde regiones remotas no se anuncian de nuevo en vínculos de ExpressRoute locales. Por lo tanto, Global Reach de ExpressRoute es necesario para que las ubicaciones de ExpressRoute se comuniquen entre sí:
Importante
En el diagrama anterior se muestran dos centros virtuales protegidos. Esta topología se admite con intención de enrutamiento. Para obtener más información, consulte Configuración de la intención de enrutamiento y las políticas de enrutamiento de Virtual WAN Hub.
Como se explica en Preferencia de enrutamiento de centro de conectividad virtual, Virtual WAN favorece las rutas procedentes de ExpressRoute de manera predeterminada. Dado que las rutas se anuncian del centro de conectividad 1 al circuito ExpressRoute 1, del circuito ExpressRoute 1 al circuito 2 y del circuito ExpressRoute 2 al centro de conectividad 2 (y viceversa), ahora los centros de conectividad virtuales prefieren esta ruta de acceso en lugar del vínculo más directo entre centros de conectividad. Las rutas efectivas del centro de conectividad 1 muestran lo siguiente:
Como puede ver en las rutas, Global Reach de ExpressRoute antepone el número de sistema autónomo de ExpressRoute (12076) varias veces antes de enviar rutas a Azure para que estas rutas sean menos preferibles. Sin embargo, la prioridad predeterminada de enrutamiento de centro de conectividad de Virtual WAN de ExpressRoute omite la longitud de la ruta de acceso de AS al tomar la decisión de enrutamiento.
Las rutas efectivas en el centro de conectividad 2 serán similares:
La preferencia de enrutamiento se puede cambiar a VPN o ruta de acceso de AS como se explica en Preferencia de enrutamiento de centro de conectividad virtual. Por ejemplo, puede establecer la preferencia en VPN como se muestra en esta imagen:
Con una preferencia de enrutamiento de centro de conectividad de VPN, las rutas efectivas en el centro de conectividad 1 tienen el siguiente aspecto:
En la imagen anterior se muestra que la ruta a 10.4.2.0/24 tiene ahora un próximo salto de VPN_S2S_Gateway, mientras que con la preferencia de enrutamiento predeterminada de ExpressRoute era ExpressRouteGateway. Sin embargo, en el centro de conectividad 2, la ruta a 10.5.2.0/24 seguirá apareciendo con un próximo salto de ExpressRoute, porque en este caso la ruta alternativa no procede de una instancia de VPN Gateway sino de una aplicación virtual de red integrada en el centro de conectividad:
Sin embargo, el tráfico entre centros de conectividad sigue prefiriendo las rutas que llegan a través de ExpressRoute. Para usar la conexión directa más eficaz entre los centros de conectividad, la preferencia de ruta se puede establecer en "Ruta de acceso AS" en ambos centros de conectividad:
Ahora, las rutas para radios y ramas remotos en el centro de conectividad 1 tendrán un próximo salto de Remote Hub según lo previsto:
Puede ver que el prefijo IP del centro de conectividad 2 (192.168.2.0/23) sigue apareciendo accesible a través del vínculo de Global Reach, pero esto no debería afectar al tráfico, ya que no debería haber tráfico dirigido a los dispositivos del centro de conectividad 2. Aunque esta ruta podría ser un problema si hubiera aplicaciones virtuales de red en ambos centros de conectividad que establecieran túneles SDWAN entre sí.
Sin embargo, tenga en cuenta que 10.4.2.0/24 ahora se prefiere sobre la instancia de VPN Gateway. Esto puede ocurrir si las rutas anunciadas a través de VPN tienen una ruta de acceso AS más corta que las rutas anunciadas a través de ExpressRoute. Después de configurar el dispositivo VPN local para anteponer su número de sistema autónomo (65501) a las rutas VPN para hacerlas menos preferibles, ahora el centro de conectividad 1 selecciona ExpressRoute como próximo salto para 10.4.2.0/24:
El centro de conectividad 2 mostrará una tabla similar para las rutas efectivas, donde las redes virtuales y las ramas del otro centro de conectividad ahora aparecen con Remote Hub como próximo salto:
Escenario 3: Conexión cruzada de los circuitos ExpressRoute a ambos centros de conectividad
Para agregar vínculos directos entre las regiones de Azure y las ubicaciones locales conectadas a través de ExpressRoute, a menudo es conveniente conectar un único circuito ExpressRoute a varios centros de conectividad de Virtual WAN en una topología que se describe algunas veces como un "lazo", como se muestra en la siguiente topología:
Importante
En el diagrama anterior se muestran dos centros virtuales protegidos. Esta topología se admite con intención de enrutamiento. Para obtener más información, consulte Configuración de intención y directivas de enrutamiento del centro de conectividad de Virtual WAN.
Virtual WAN muestra que ambos circuitos están conectados a ambos centros de conectividad:
Al volver a la preferencia predeterminada de enrutamiento de centro de conectividad de ExpressRoute, las rutas a ramas remotas y redes virtuales del centro de conectividad 1 mostrarán de nuevo ExpressRoute como próximo salto. Aunque esta vez el motivo no es Global Reach, sino el hecho de que los circuitos ExpressRoute devuelven los anuncios de ruta que obtienen desde un centro de conectividad a otro. Por ejemplo, las rutas eficaces del centro de conectividad 1 con preferencia de enrutamiento de ExpressRoute son las siguientes:
Al volver a cambiar la preferencia de enrutamiento del centro de conectividad a Ruta de acceso AS, se devuelven las rutas entre centros de conectividad a la ruta de acceso óptima mediante la conexión directa entre los centros de conectividad 1 y 2:
Pasos siguientes
Para obtener más información sobre Virtual WAN, vea:
- Preguntas más frecuentes sobre Virtual WAN