Inserción de rutas predeterminada en redes virtuales de radio

Una de las arquitecturas más comunes de Azure es el diseño en estrella, donde las cargas de trabajo implementadas en una red virtual de radio envían tráfico a través de dispositivos de red compartida que existen en la red virtual de centro de conectividad. Las rutas definidas por el usuario (UDR) normalmente deben configurarse en las redes virtuales de radio para dirigir el tráfico hacia los dispositivos de seguridad del centro de conectividad. Sin embargo, este diseño requiere que los administradores administren estas rutas en muchos radios.

Azure Route Server ofrece un punto centralizado en el que las aplicaciones virtuales de red (NVA) pueden anunciar rutas que inserta en las redes virtuales de radio. De este modo, los administradores no tienen que crear y actualizar tablas de rutas en redes virtuales de radio.

Topología

En el diagrama siguiente se muestra un diseño radial simple con una red virtual de centro de conectividad y dos redes virtuales radiales. En el centro de conectividad se ha implementado una aplicación virtual de red y Route Server. Sin Route Server, las rutas definidas por el usuario tendrían que configurarse en todos los radios. Estos UDR normalmente contienen una ruta predeterminada para 0.0.0.0/0 que envía todo el tráfico desde las redes virtuales de radio a través de la NVA. Este escenario se puede usar, por ejemplo, para inspeccionar el tráfico con fines de seguridad.

En este escenario, con el Route Server en la red virtual central, no es necesario usar rutas definidas por el usuario. La NVA anuncia prefijos de red en Route Server, que las inserta para que aparezcan en las rutas efectivas en cualquier máquina virtual implementada en la red virtual del centro o en redes virtuales radiales emparejadas con la red virtual del centro con la opción Usar el servidor de ruta o la puerta de enlace de la red virtual remota.

Conectividad al entorno local a través de la aplicación virtual de red

Si la NVA se usa para proporcionar conectividad a la red local a través de VPN de IPsec o tecnologías SD-WAN, se puede usar el mismo mecanismo para atraer el tráfico desde los radios a la NVA. Además, la aplicación virtual de red puede aprender dinámicamente los prefijos de Azure desde Azure Route Server y anunciarlos con un protocolo de enrutamiento dinámico a un entorno local. En el diagrama siguiente se describe esta configuración:

Inspección del tráfico privado a través de la aplicación virtual de red

En las secciones anteriores se muestra el tráfico que inspecciona la aplicación virtual de red (NVA) mediante la inserción de una ruta predeterminada 0.0.0.0/0 desde la NVA en Route Server. Sin embargo, si solo quiere inspeccionar el tráfico radio a radio y radio a local a través de la NVA, debe considerar la posibilidad de que Azure Route Server no anuncie una ruta que tenga el mismo prefijo o más largo que el espacio de direcciones de red virtual aprendido de la NVA. Es decir, Azure Route Server no insertará estos prefijos en la red virtual y no se programarán en las NIC de las máquinas virtuales del centro de conectividad o de las redes virtuales de radio.

Sin embargo, Azure Route Server anunciará una subred mayor que el espacio de direcciones de la red virtual que se aprende de la NVA. Es posible anunciar desde la NVA una superred de lo que tiene en la red virtual. Por ejemplo, si la red virtual usa el espacio de direcciones RFC 1918 10.0.0.0/16, la NVA puede anunciar 10.0.0.0/8 a Azure Route Server y estos prefijos se insertarán en las redes virtuales en estrella. Se hace referencia a este comportamiento de red virtual en Acerca de BGP con VPN Gateway.

Importante

Si tiene un escenario en el que se anuncian prefijos con la misma longitud desde ExpressRoute y la NVA, Azure preferirá y programará las rutas aprendidas de ExpressRoute. Para obtener más información, consulte Preferencia de enrutamiento.

Conectividad al entorno local a través de puertas de enlace virtuales

Si existe una VPN o una puerta de enlace de ExpressRoute en la misma red virtual que Route Server y la NVA para proporcionar conectividad a redes locales, las rutas aprendidas por estas puertas de enlace se programarán también en las redes virtuales de radio. Estas rutas invalidan la ruta predeterminada (0.0.0.0/0) que inserta Route Server, ya que serían más específicas (máscaras de red más largas). En el diagrama siguiente se describe el diseño anterior, donde se ha agregado una puerta de enlace de ExpressRoute.

Para evitar que las redes virtuales de radio se programen con los prefijos locales aprendidos por la puerta de enlace VPN y ExpressRoute, puede deshabilitar "Propagar rutas de puerta de enlace" en las tablas de rutas de las subredes de radio. Para asegurarse de que la NVA inspecciona la red virtual al tráfico local, puede configurar una UDR 0.0.0.0/0 (ruta definida por el usuario) en las tablas de rutas de las subredes de radio con el próximo salto como NVA/Firewall en la red virtual del concentrador. Tenga en cuenta que deshabilitar la opción "Propagar rutas de puerta de enlace" impedirá que estas subredes radiales se enredarán dinámicamente desde Route Server.

De manera predeterminada, Route Server anuncia también todos los prefijos aprendidos de la NVA a ExpressRoute. Esto podría no ser deseado, por ejemplo debido a los límites de ruta de ExpressRoute. En ese caso, NVA puede anunciar sus rutas a Route Server, incluida la comunidad BGP no-advertise (con el valor 65535:65282). Cuando Route Server recibe rutas con esta comunidad de BGP, las inserta en las subredes, pero no las anunciará a ningún otro nodo BGP del mismo nivel (como puertas de enlace de ExpressRoute o VPN u otras NVA).

Coexistencia de SDWAN con ExpressRoute y Azure Firewall

Un caso concreto del diseño anterior es cuando los clientes insertan Azure Firewall en el flujo de tráfico para inspeccionar todo el tráfico dirigido a redes locales, ya sea a través de ExpressRoute o a través de dispositivos SD-WAN/VPN. En esta situación, todas las subredes de radio tienen tablas de rutas que impiden que los radios obtengan cualquier ruta de ExpressRoute o Route Server, y tienen rutas predeterminadas (0.0.0.0/0) con Azure Firewall como siguiente salto, como se muestra en el diagrama siguiente:

La subred de Azure Firewall aprende las rutas procedentes de ExpressRoute y NVA de VPN/SDWAN, y decide si se envía tráfico de una forma u otra. Como se describe en la sección anterior, si el dispositivo de NVA anuncia más de 1000 rutas a Route Server, tendría que enviar sus rutas BGP marcadas con la comunidad de BGP no-advertise. De este modo, los prefijos SDWAN no se insertarán de nuevo en el entorno local a través de Express-Route.

Nota:

Para cualquier tráfico procedente del entorno local destinado a puntos de conexión privados, este tráfico omitirá la aplicación virtual de red de firewall o Azure Firewall en el centro. Sin embargo, esto da como resultado el enrutamiento asimétrico (lo que puede provocar la pérdida de conectividad entre los puntos de conexión locales y privados) a medida que los puntos de conexión privados reenvían el tráfico local al firewall. Para garantizar la simetría de enrutamiento, habilite las directivas de red de tabla de ruta para puntos de conexión privados en las subredes donde se implementan los puntos de conexión privados.

Simetría de tráfico

Si se usan varias instancias de NVA en un escenario activo/activo para mejorar la resistencia o escalabilidad, la simetría del tráfico será un requisito si las NVA necesitan mantener el estado de las conexiones. Este es, por ejemplo, el caso de los firewalls de próxima generación.

• Para la conectividad de las máquinas virtuales de Azure a la red pública de Internet, la NVA usa la traducción de direcciones de red de origen (SNAT) para que el tráfico de salida tenga como origen la dirección IP pública de la NVA, con lo que se consigue la simetría del tráfico.
• Para el tráfico entrante desde Internet a las cargas de trabajo que se ejecutan en máquinas virtuales, además de la traducción de direcciones de red de destino (DNAT), las NVA deben realizar la traducción de direcciones de red de origen (SNAT), para asegurarse de que el tráfico devuelto de las máquinas virtuales llega a la misma instancia de NVA que procesó el primer paquete.
• En el caso de la conectividad de Azure a Azure, dado que la máquina virtual de origen tomará la decisión de enrutamiento independientemente del destino, actualmente se requiere SNAT para lograr la simetría del tráfico.

También se pueden implementar varias instancias de NVA en una configuración activa/pasiva, por ejemplo, si una de ellas anuncia rutas peores (con una ruta AS más larga) que la otra. En este caso, Azure Route Server solo insertará la ruta preferida en las máquinas virtuales de la red virtual y la ruta menos preferida solo se usará cuando la instancia principal de NVA deje de anunciarse a través de BGP.

También es importante tener en cuenta que Route Server no admite el tráfico de rutas de acceso a datos. Cuando se anuncian rutas a Route Server, la aplicación virtual de red debe anunciar rutas con el próximo salto como sí mismo, un equilibrador de carga delante de la NVA o un NVA/Firewall en la misma red virtual que la NVA.

Contenido relacionado

• Obtenga más información sobre la Compatibilidad de Azure Route Server con ExpressRoute y la VPN de Azure.
• Más información sobre la Configuración del emparejamiento entre Azure Route Server y la aplicación virtual de red.