Uso de Azure Firewall para enrutar una topología de múltiples centros y extremos

La topología de concentrador y radio es un patrón de arquitectura de red común en Azure que consolida los recursos de red y centraliza los servicios de red. Esta topología proporciona conectividad de red y seguridad a las redes virtuales implementadas en distintas suscripciones o inquilinos.

Puede implementar arquitecturas de concentrador y radio de dos maneras:

• Concentrador y radio autoadministrado (tradicional): usted mantiene el control total sobre las redes virtuales del concentrador y la configuración de enrutamiento.
• Virtual WAN: Microsoft administra las redes virtuales del centro y simplifica la administración a través de características como la intención de enrutamiento y las políticas de enrutamiento.

Este artículo se centra en topologías tipo 'hub-and-spoke' autoadministradas en las que tiene control y visibilidad completos sobre la red virtual del concentrador y la implementación de Azure Firewall.

Puede reducir la sobrecarga de administración de una implementación autoadministrada con topología de concentrador y radio mediante Azure Virtual Network Manager (AVNM). AVNM puede automatizar la configuración de azure Route Tables, pero el diseño general y las técnicas no cambian en comparación con el enfoque manual. El contenido de este artículo se aplica tanto si usa AVNM como si configura manualmente la topología de concentrador y radio autoadministrada.

Una alternativa a las tablas de rutas de Azure en las redes virtuales de radio es insertar rutas en subredes con Azure Route Server, como se documenta en Inserción de rutas predeterminada en redes virtuales de radio. Sin embargo, este patrón no se usa normalmente debido a la complejidad que puede surgir de la interacción entre Azure Route Server y VPN o puertas de enlace de red virtual de ExpressRoute.

En una configuración de concentrador y radio autoadministrada:

• Concentrador: una red virtual que actúa como punto de conectividad central a la red local a través de VPN, ExpressRoute o Software-Defined Wide Area Network (SD-WAN). Los dispositivos de seguridad de red, como los firewalls, se implementan en la red virtual del concentrador.
• Radios: redes virtuales que se emparejan al concentrador y hospedan las cargas de trabajo.

En el caso de las cargas de trabajo distribuidas entre varias regiones, por lo general, se implementa un concentrador por región para agregar el tráfico desde los radios en esa región. En el diagrama siguiente, se muestra una arquitectura de tipo concentrador y radio autoadministrada de dos regiones con dos redes virtuales radiales en cada región:

Arquitectura de concentrador y radio de una sola región

Para comprender el diseño de varias regiones, primero debe comprender los conceptos de una sola región. En el diagrama siguiente se muestra la configuración de la tabla de enrutamiento para la primera región:

Tenga en cuenta los requisitos de enrutamiento para cada flujo de tráfico potencial en el diseño de una sola región para comprender la configuración de ruta definida por el usuario:

• Tráfico de radio a radio: los radios no están emparejados entre sí y el emparejamiento de redes virtuales no es transitivo. Cada extremo sabe cómo enrutar a la red virtual del concentrador de forma predeterminada, pero no a otros extremos. Una ruta para 0.0.0.0/0 aplicada a todas las subredes radiales cubre el tráfico de radio a radio.
• Tráfico de radio a Internet: la 0.0.0.0/0 ruta de la tabla de rutas de radio también cubre el tráfico enviado a la red pública de Internet. Esta ruta sobrescribe la ruta del sistema incluida en subredes públicas de forma predeterminada. Para más información, consulte Acceso de salida predeterminado en Azure.
• Tráfico de Internet a radio: el tráfico de Internet al radio suele pasar por Azure Firewall primero. Azure Firewall tiene configuradas reglas de traducción de direcciones de red de destino (DNAT), que también traduce la dirección IP de origen (traducción de direcciones de red de origen o SNAT). Las cargas de trabajo del entorno spoke ven el tráfico que proviene de la subred de Azure Firewall. El emparejamiento de red virtual crea rutas del sistema al concentrador (10.1.0.0/24), por lo que los radios saben cómo enrutar el tráfico de retorno.
• Tráfico del entorno local al radio y del radio al entorno local: considere cada dirección por separado:
  • Tráfico local al radio: : el tráfico llega desde la red local a la VPN o las puertas de enlace ExpressRoute. En el enrutamiento predeterminado de Azure, se crea una ruta del sistema en la GatewaySubnet (y otras subredes en la red virtual del concentrador) para cada radio. Debe invalidar estas rutas del sistema y establecer el próximo salto en la dirección IP privada de Azure Firewall. En este ejemplo, necesita dos rutas en una tabla de rutas asociada a la subred de puerta de enlace, una para cada radio (10.1.1.0/24 y 10.1.2.0/24). El uso de un resumen como 10.1.0.0/16 que abarca todas las redes virtuales radiales no funciona porque las rutas del sistema insertadas por los emparejamientos de red virtual en la subred de puerta de enlace son más específicas (/24 en comparación con el resumen de /16). Esta tabla de rutas debe tener habilitada la alternancia Propagar rutas de puerta de enlace (establecida en Sí), de lo contrario, el enrutamiento de puerta de enlace puede ser impredecible.
  • Tráfico del radio al entorno local: los emparejamientos de red virtual entre el concentrador y los radios deben tener Permitir tránsito de puerta de enlace habilitado en el lado del concentrador y Usar puertas de enlace remotas habilitado en el lado del radio. Esta configuración es necesaria para que las puertas de enlace VPN y ExpressRoute anuncien los prefijos de radio a través del Protocolo de puerta de enlace de borde (BGP) a las redes locales. Esta configuración también hace que los radios aprendan los prefijos locales anunciados a Azure de forma predeterminada. Dado que los prefijos locales son más específicos que la ruta 0.0.0.0/0 definida por el usuario en la tabla de rutas de radio, el tráfico de radios a local omitiría el firewall de forma predeterminada. Para evitar esta situación, establezca la opción Propagar rutas de puerta de enlace en No en la tabla de rutas radiales para que no se aprendan los prefijos locales y se utilice la ruta 0.0.0.0/0 para el tráfico hacia los entornos locales.

Puede administrar tanto la tabla de rutas asociada a las subredes de spoke como la tabla de rutas asociada al subred de gateway mediante Azure Virtual Network Manager para reducir la sobrecarga administrativa. Para más información, consulte Uso de Azure Firewall como próximo salto.

Cargas de trabajo de concentrador de red virtual

Si implementa cargas de trabajo en la red virtual del concentrador (como controladores de dominio de Active Directory, servidores DNS u otra infraestructura compartida), esto aumenta la complejidad del diseño tipo hub-and-spoke. Se recomienda evitar colocar cargas de trabajo en el concentrador y, en su lugar, implementarlas en un radio dedicado para servicios compartidos.

En esta sección se describe la configuración necesaria para las cargas de trabajo de concentrador para que pueda evaluar si esta complejidad es aceptable para sus requisitos. También se describe un error común que puede provocar caídas de paquetes y tráfico asimétrico.

En el diagrama siguiente se muestra un diseño de una sola región con una subred de carga de trabajo en la red virtual del concentrador:

El detalle crítico es que las rutas definidas por el usuario configuradas en la subred de la puerta de enlace y las subredes radiales se definen para la subred específica de carga de trabajo y no para todo el prefijo de la red virtual del concentrador:

• Configuración de la subred de la puerta de enlace: la configuración de una ruta en la subred de la puerta de enlace para toda la red virtual del concentrador (10.1.0.0/24 en este ejemplo) invalida la ruta del sistema para la red virtual del concentrador. Esto hace que el tráfico de control intra-subred entre las puertas de enlace VPN o ExpressRoute se envíe al firewall, lo que podría interrumpir el funcionamiento de la puerta de enlace.
• Configuración de subred radial: la configuración de una ruta en las subredes radiales para toda la red virtual del concentrador (10.1.0.0/24 en este ejemplo) anula la ruta del sistema creada por el emparejamiento con la red virtual del concentrador. Todo el tráfico enviado al concentrador se enviaría a Azure Firewall, incluido el tráfico procedente de Azure Firewall, como el tráfico de Internet al radio que pasa a través de la traducción de direcciones de red de origen (SNAT). Esta configuración presenta tráfico asimétrico y provoca caídas de paquetes.

Inspección del tráfico entre subredes

En la configuración actual, el tráfico entre radios se envía al firewall, pero el tráfico intra-radio permanece dentro de la red virtual de radios y se controla mediante Grupos de Seguridad de Red. Este diseño considera que las redes virtuales son un límite de seguridad: el firewall solo inspecciona el tráfico que sale o entra en una red virtual.

Para inspeccionar el tráfico entre subredes de la misma red virtual de concentrador, modifique la tabla de rutas asociada a las subredes de concentrador, como se muestra en el diagrama siguiente.

En el diagrama anterior, se introducen dos subredes radiales en cada red virtual radial y se describen las tablas de rutas para los radios en la red virtual A2. El envío de tráfico entre subredes al firewall requiere que cada subred tenga una tabla de rutas independiente porque las rutas para instalar en cada subred son diferentes.

Para la subred A21, necesita estas dos rutas adicionales:

• Ruta a 10.1.2.0/24: invalida la ruta del sistema para el tráfico dentro de la red virtual. Sin otras rutas, todo el tráfico dentro de la red virtual se envía a Azure Firewall, incluso el tráfico entre máquinas virtuales de la misma subred.
• Ruta a 10.1.2.0/26 con el siguiente salto red virtual: una excepción a la ruta anterior, por lo que el tráfico dentro de esta subred específica no se envía al firewall, sino que se enruta localmente dentro de la red virtual. Esta ruta es específica de cada subred, por lo que necesita una tabla de rutas independiente para cada subred.

aplicaciones virtuales de red de SD-WAN

Si usa Aplicaciones Virtuales de Red (NVA) SD-WAN en lugar de puertas de enlace VPN o ExpressRoute, el diseño es similar al que se muestra en el siguiente diagrama:

Hay diferentes maneras de integrar SD-WAN NVA en Azure. Para más información, consulte integración SD-WAN con topologías de red de tipo hub-and-spoke de Azure. En este artículo se muestra la integración mediante Azure Route Server, uno de los métodos más comunes para enrutar el tráfico a SD-WAN redes. Las NVA de SD-WAN anuncian los prefijos locales en Azure Route Server a través de BGP. Azure Route Server inserta estos prefijos en la subred de Azure Firewall para que Azure Firewall tenga información de enrutamiento para redes locales. Los radios no aprenden los prefijos de la red local porque la opción "Propagar rutas de puerta de enlace" está deshabilitada en la tabla de rutas del radio.

Si no desea configurar el prefijo de cada red virtual radial en la tabla de rutas asociada a la subred de NVA, puede colocar las NVA de SD-WAN en su red virtual dedicada. La red virtual de NVA no aprende los prefijos de radio porque no están emparejados directamente y es posible una ruta de resumen, como se muestra en el diagrama siguiente:

Arquitectura centralizada tipo hub-and-spoke en varias regiones

Después de entender cómo funciona el tráfico dentro de una sola región con arquitectura de hub-and-spoke, extender el diseño a una arquitectura de múltiples regiones es algo sencillo. En el diagrama siguiente se muestra un diseño de red actualizado con concentradores en dos regiones (A y B):

La única adición a la configuración es las tablas de rutas asociadas a las subredes de Azure Firewall en cada región. Cada red virtual de centro solo conoce los prefijos de las redes virtuales emparejadas, por lo que no hay enrutamiento para los prefijos de los ramales remotos. Agregue rutas definidas por el usuario para cada subred de Azure Firewall para que el tráfico de cada región se enrute a la instancia de Azure Firewall correspondiente.

En este ejemplo, cada región se puede resumir fácilmente:

• Región A contiene prefijos en 10.1.0.0/16
• La región B contiene prefijos en 10.2.0.0/16

La definición de direcciones IP en cada región que se resume fácilmente hace que la configuración de enrutamiento sea más sencilla. De lo contrario, debe crear una ruta para cada radio remoto.

Habilite Propagar rutas de puerta de enlace en la tabla de rutas de subred de Azure Firewall para que el firewall pueda aprender rutas locales desde la VPN y las puertas de enlace ExpressRoute.

Para simplificar la administración de rutas definidas por el usuario en un entorno de varias regiones, puede usar Azure Virtual Network Manager. Para obtener más información, consulte Gestionar rutas personalizadas en varias topologías hub-and-spoke con AVNM.

Pasos siguientes

• Consulte el tutorial Implementación y configuración de Azure Firewall.