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.

Con Route Server en la red virtual del centro de conectividad, 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, vea la próxima sección.

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.

No puede configurar las subredes de las redes virtuales de radio para que solo aprendan las rutas de Azure Route Server. Deshabilitar "Propagar rutas de puerta de enlace" en una tabla de rutas asociada a una subred impediría que ambos tipos de rutas (rutas de la puerta de enlace de red virtual y rutas de Azure Route Server) se insertasen en las NIC de esa subred.

De manera predeterminada, Route Server anuncia también todos los prefijos aprendidos de la NVA a ExpressRoute. Es posible que no quiera que esto ocurra, por ejemplo, debido a los límites de ruta de ExpressRoute o del propio Route Server. 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 200 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.

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.

Diferentes servidores de rutas para anunciar rutas a puertas de enlace de Virtual Network y a redes virtuales

Como se ha mostrado en las secciones anteriores, Azure Route Server tiene un doble papel:

• Aprende y anuncia rutas hacia y desde puertas de enlace de red virtual (VPN y ExpressRoute)
• Configura rutas aprendidas en su red virtual y en redes virtuales del mismo nivel directamente.

Esta funcionalidad dual suele ser interesante, pero en ocasiones puede ser perjudicial para ciertos requisitos. Por ejemplo, si el servidor de rutas se implementa en una red virtual con una NVA que anuncia una ruta 0.0.0.0/0 y una puerta de enlace de ExpressRoute que anuncia prefijos locales, configurará todas las rutas (tanto la 0.0.0.0/0 de la NVA como los prefijos locales) en las máquinas virtuales de su red virtual y las redes virtuales emparejadas directamente. Como consecuencia, dado que los prefijos locales serán más específicos que 0.0.0.0/0, el tráfico entre el entorno local y Azure omitirá la NVA. Si no se desea, las secciones anteriores de este artículo muestran cómo deshabilitar la propagación de BGP en las subredes de máquina virtual y configurar UDR.

Sin embargo, existe un enfoque alternativo y más dinámico. Es posible usar diferentes instancias de Azure Route Server para diferentes funcionalidades: una de ellas será responsable de interactuar con las puertas de enlace de red virtual y la otra de interactuar con el enrutamiento de red virtual. El siguiente diagrama muestra un posible diseño de esto:

Route Server 1 en el centro de conectividad se usa para insertar los prefijos de SDWAN en ExpressRoute. Dado que las redes virtuales de radio están emparejadas con la red virtual de concentrador sin Usar la puerta de enlace o el Route Server de la red virtual remota (en el emparejamiento de redes virtuales de radio) y Usar el servidor de ruta o la puerta de enlace de esta red virtual (tránsito de puerta de enlace en el emparejamiento de VNet del centro), las redes virtuales de radio no aprenden estas rutas (ni los prefijos sdWAN ni los prefijos de ExpressRoute).

Para propagar rutas a las redes virtuales de radio, la NVA usa Route Server 2, implementada en una nueva red virtual auxiliar. La aplicación virtual de red solo propagará una única ruta 0.0.0.0/0 a Route Server 2. Dado que las redes virtuales de radio están emparejadas con esta red virtual auxiliar con Usar el servidor de ruta o la puerta de enlace de la red virtual remota (en el emparejamiento de redes virtuales de radio) y Usar el servidor de ruta o la puerta de enlace de esta red virtual (tránsito de puerta de enlace en el emparejamiento de red virtual del centro), todas las máquinas virtuales de los radios aprenderán la ruta 0.0.0.0/0.

Tenga en cuenta que el próximo salto de la ruta 0.0.0.0/0 es la NVA, por lo que las redes virtuales de radio todavía deben ser del mismo nivel que la red virtual del centro de conectividad. Otro aspecto importante que hay que tener en cuenta es que la red virtual del concentrador debe emparejarse con la red virtual en la que se implementa Route Server 2; de lo contrario, no podrá crear la adyacencia BGP.

Si el tráfico de ExpressRoute a las redes virtuales de radio se va a enviar a una NVA de firewall para su inspección, aún es indispensable una tabla de rutas en GatewaySubnet, de lo contrario, la puerta de enlace de red virtual de ExpressRoute enviará paquetes a las máquinas virtuales mediante las rutas aprendidas del emparejamiento de red virtual. Las rutas de esta tabla de rutas deben coincidir con los prefijos de radio, y el próximo salto debe ser la dirección IP de la NVA del firewall (o el equilibrador de carga delante de las NVA del firewall, para la redundancia). La NVA de firewall puede ser la misma que la NVA de SDWAN en el diagrama anterior o puede ser un dispositivo diferente, como Azure Firewall, ya que la NVA de SDWAN puede anunciar rutas con el próximo salto que apunta a otras direcciones IP. En el diagrama siguiente se muestra este diseño con la adición de Azure Firewall:

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.

Este diseño permite la inserción automática de rutas en redes virtuales de radio sin interferencias de otras rutas aprendidas de ExpressRoute, VPN o un entorno SDWAN y la adición de las NVA de firewall para la inspección de tráfico.

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.