Implementación de NVA de alta disponibilidad

En este artículo se describen formas comunes de implementar un conjunto de aplicaciones virtuales de red (NVA) para lograr alta disponibilidad en Azure. Normalmente, una NVA controla el flujo de tráfico entre segmentos de red que tienen diferentes niveles de seguridad. Por ejemplo, puede usar una NVA entre una red virtual de red perimetral y la red pública de Internet, o para conectar ubicaciones externas a Azure a través de una red privada virtual (VPN) o dispositivos WAN definidos por software (SD-WAN).

En este artículo se da por supuesto que tiene un conocimiento básico de las redes de Azure, los equilibradores de carga de Azure, el enrutamiento del tráfico de red virtual y las rutas definidas por el usuario (UDR).

Muchos patrones de diseño usan NVAs para inspeccionar el tráfico entre diferentes zonas de seguridad. Estos patrones podrían utilizar actividades no generadoras de valor para los siguientes fines:

• Para inspeccionar el tráfico de salida de las máquinas virtuales a Internet y evitar la filtración de datos.

• Para inspeccionar el tráfico de entrada desde Internet a las máquinas virtuales y evitar ataques.

• Para filtrar el tráfico entre máquinas virtuales en Azure para evitar movimientos laterales de sistemas en peligro.

• Para filtrar el tráfico entre sistemas locales y máquinas virtuales de Azure, especialmente si pertenecen a distintos niveles de seguridad. Por ejemplo, Azure hospeda la red perimetral, mientras que el entorno local hospeda las aplicaciones internas.

• Para finalizar túneles VPN o SD-WAN desde ubicaciones externas, como redes locales u otras nubes públicas.

Puede añadir los siguientes dispositivos virtuales de red (NVAs) a un diseño de Azure mediante los modelos presentados en este artículo.

• Firewalls de red
• Servidores proxy inversos de capa 4
• Puntos de conexión VPN de seguridad de protocolo de Internet (IPsec)
• Dispositivos SD-WAN
• Servidores proxy inversos basados en web que tienen funcionalidad de Firewall de aplicaciones web
• Servidores proxy de Internet para restringir a qué páginas de Internet se puede acceder desde Azure
• Equilibradores de carga de capa 7

Las NVA nativas de Azure, como Azure Firewall y Azure Application Gateway, usan los diseños que se explican más adelante en este artículo. Debe comprender estas opciones desde una perspectiva de diseño y con fines de solución de problemas de red.

Los NVA suelen requerir alta disponibilidad porque controlan la comunicación entre segmentos de red. Si las NVAs dejan de estar disponibles, el tráfico de red no puede fluir y las aplicaciones dejan de funcionar. Interrupciones programadas y no programadas ocasionalmente apagan instancias de NVA, de forma similar a otras máquinas virtuales de Azure o en otras nubes. Las instancias de NVA pueden apagarse incluso si las configura con SSD Premium de Azure, que proporcionan un acuerdo de nivel de servicio para una sola instancia en Azure. Las aplicaciones de alta disponibilidad requieren al menos dos NVA para ayudar a garantizar la conectividad.

Al elegir la mejor opción para implementar una aplicación virtual de red en una red virtual de Azure, el aspecto más importante es si el proveedor de NVA ha evaluado y validado su diseño. El proveedor también debe proporcionar la configuración de NVA necesaria para integrar la aplicación virtual de red en Azure. Si el proveedor de NVA proporciona varias opciones de diseño admitidas, tenga en cuenta los siguientes factores para tomar la decisión:

• Tiempo de convergencia: El tiempo que tarda cada diseño en redirigir el tráfico lejos de una instancia de NVA fallida

• Compatibilidad con topologías: Las configuraciones de NVA que admite cada opción de diseño, como activa/activa, activa/en espera, o clústeres de NVA escalables que tienen una unidad adicional para la redundancia.

• Simetría de tráfico: Si un diseño determinado obliga a la NVA a realizar la traducción de direcciones de red de origen (SNAT) en los paquetes para evitar el enrutamiento asimétrico, o si el diseño exige la simetría del tráfico por otros medios

Nota:

Este artículo se centra en diseños en estrella tipo hub-and-spoke. En este artículo no se trata de Azure Virtual WAN porque tiene pautas más prescriptivas para implementar NVAs, dependiendo de si un hub de Virtual WAN admite una NVA específica. Para más información, consulte las NVAs en un hub de WAN virtual.

En las secciones siguientes se describen las arquitecturas comunes que puede usar para integrar aplicaciones virtuales de red en una red en estrella tipo hub-and-spoke.

Introducción a las arquitecturas de alta disponibilidad

Solución	Ventajas	Consideraciones
Equilibrador de carga de Azure	Esta solución admite configuraciones activas, activas y activas o en espera, y NVA de escalabilidad horizontal con un buen tiempo de convergencia.	La aplicación virtual de red debe proporcionar un puerto para los sondeos de estado, especialmente para las implementaciones activas o en espera. Para dispositivos con estado, como firewalls que requieren simetría de tráfico, los flujos hacia y desde Internet requieren SNAT.
Azure Route Server	La NVA debe admitir el Protocolo de puerta de enlace de borde (BGP). Esta solución admite NVA activas, activas o en espera y escalabilidad horizontal.	La simetría del tráfico requiere SNAT en esta solución.
Gateway Load Balancer de Azure	La simetría del tráfico se garantiza sin SNAT. Las aplicaciones virtuales de red se pueden compartir entre inquilinos. Esta solución tiene un buen tiempo de convergencia y admite NVA activas, activas o en espera y escalabilidad horizontal.	Esta solución admite flujos hacia y desde Internet y no admite flujos East-West.
Dirección IP privada dinámica y UDR	La NVA no requiere características especiales. Esta solución garantiza el tráfico simétrico.	Esta solución solo es para diseños activos/pasivos. Tiene un tiempo de convergencia alto de uno a dos minutos.

Equilibrador de carga

El diseño de Load Balancer usa dos equilibradores de carga de Azure para exponer un clúster de NVA al resto de la red. El enfoque se adapta tanto a NVA con estado como sin estado.

• Un balanceador de carga interno redirige el tráfico interno de Azure y el local a los dispositivos virtuales de red (NVA). Este equilibrador de carga interno se configura con reglas de puertos de alta disponibilidad para que cada puerto de Protocolo de control de transmisión (TCP) y protocolo de datagrama de usuario (UDP) se redirija a las instancias de NVA.

• Un equilibrador de carga público expone las NVA a Internet. Los puertos de alta disponibilidad son para el tráfico entrante, por lo que cada puerto TCP/UDP debe abrirse en una regla de equilibrio de carga dedicada.

En el diagrama siguiente se muestra la secuencia de saltos que los paquetes toman de Internet a un servidor de aplicaciones de una red virtual de radio. Estos paquetes atraviesan una aplicación virtual de red (NVA) de firewall para controlar el tráfico hacia y desde Internet, también denominado Tráfico vertical de arriba abajo.

En este diagrama se muestra un concentrador y dos radios. El centro contiene una subred de puerta de enlace y una subred de NVA. La subred de puerta de enlace contiene una puerta de enlace de VPN o Azure ExpressRoute. La subred de NVA contiene un equilibrador de carga interno de Azure y NVA. Cada radio contiene un servidor de aplicaciones. Spoke2 tiene una nota que lee la tabla de rutas de radio 0.0.0.0/0 a 10.0.0.36 y deshabilita la propagación de la puerta de enlace. El tráfico entrante fluye desde la red pública de Internet a las NVA a través del equilibrador de carga de Azure público. A continuación, este tráfico fluye al servidor de aplicaciones en Spoke2. Devuelve flujos de tráfico desde este servidor de aplicaciones a las NVA a través del equilibrador de carga interno de Azure. A continuación, este tráfico fluye a la red pública de Internet.

Descargue un archivo de Visio de esta arquitectura.

Para enviar tráfico desde radios a la red pública de Internet a través de las NVA, este diseño usa una UDR para 0.0.0.0/0. El próximo salto es la dirección IP del equilibrador de carga interno.

Para el tráfico entre Azure y la red pública de Internet, cada dirección del flujo de tráfico cruza un equilibrador de carga de Azure diferente. Este proceso ocurre incluso cuando el firewall NVA tiene una sola tarjeta de interfaz de red (NIC) para las redes públicas e internas, ya que el paquete de entrada pasa por el equilibrador de carga público de Azure y el paquete de salida pasa por el equilibrador de carga interno de Azure. Ambas direcciones del flujo pasan por diferentes equilibradores de carga. Por lo tanto, si necesita simetría de tráfico, las instancias de NVA deben realizar SNAT para atraer el tráfico devuelto y garantizar la simetría del tráfico. La mayoría de los firewalls requieren simetría de tráfico.

En el diagrama siguiente se muestra cómo usar el mismo diseño del equilibrador de carga para inspeccionar el tráfico entre las redes locales y Azure, o East-West tráfico, lo que implica solo un equilibrador de carga interno. También puede usar este método para enviar tráfico entre radios a través de las NVA.

En este diagrama se muestra un concentrador y dos radios. El centro contiene una subred de puerta de enlace y una subred de NVA. La subred de puerta de enlace contiene una puerta de enlace VPN o ExpressRoute. La subred de NVA contiene un equilibrador de carga interno de Azure y NVA. Cada radio contiene un servidor de aplicaciones. Spoke2 tiene una nota que lee la tabla de rutas de radio 0.0.0.0/0 a 10.0.0.36 y deshabilita la propagación de la puerta de enlace. El tráfico entrante fluye desde el entorno local a las NVA a través de la puerta de enlace vpn o ExpressRoute y, a continuación, el equilibrador de carga interno de Azure. A continuación, este tráfico fluye al servidor de aplicaciones en Spoke2. Devuelve flujos de tráfico desde este servidor de aplicaciones a las NVA a través del equilibrador de carga interno de Azure. A continuación, este tráfico fluye a un entorno local a través de la puerta de enlace vpn o ExpressRoute.

En los diagramas anteriores, spoke1 no conoce el rango de spoke2. Por lo tanto, la 0.0.0.0/0 UDR envía el tráfico destinado a spoke2 al equilibrador de carga interno de Azure de la NVA.

Para el tráfico entre redes locales y Azure, o entre máquinas virtuales de Azure, la simetría del tráfico se garantiza en NVA de NIC únicas mediante el equilibrador de carga interno de Azure. Cuando ambas direcciones de un flujo de tráfico atraviesan el mismo equilibrador de carga de Azure, el equilibrador de carga selecciona la misma instancia de NVA para ambas direcciones. Si un diseño de NVA de doble NIC tiene un equilibrador de carga interno para cada dirección de comunicación, SNAT garantiza la simetría del tráfico. El diagrama de North-South anterior proporciona un ejemplo de este diseño.

En este diseño, las NVA de doble NIC deben determinar dónde enviar respuestas a las comprobaciones de estado del equilibrador de carga. Load Balancer siempre usa la misma dirección IP que el origen de las comprobaciones de estado, que es 168.63.129.16. La NVA debe enviar estas respuestas de comprobación de estado a través de la misma interfaz en la que se recibieron. Este proceso normalmente requiere varias tablas de enrutamiento en un sistema operativo porque el enrutamiento basado en destino envía las respuestas a través de la misma NIC.

El equilibrador de carga de Azure tiene un buen tiempo de convergencia en interrupciones individuales de NVA. Puede enviar sondeos de estado cada cinco segundos, y se requieren tres sondeos erróneos para declarar una instancia de back-end como fuera de servicio. Por lo tanto, normalmente, el equilibrador de carga de Azure tarda entre 10 y 15 segundos en converger el tráfico a una instancia de NVA diferente.

Esta configuración admite configuraciones activas, activas y activas o en espera. Para las configuraciones activas o en espera, las instancias de NVA deben proporcionar un puerto TCP o UDP o un punto de conexión HTTP que responda solo a los sondeos de estado del equilibrador de carga para la instancia que se encuentra actualmente en el rol activo.

Equilibradores de carga de capa 7

Un diseño específico para dispositivos de seguridad reemplaza al equilibrador de carga público de Azure por un equilibrador de carga de nivel 7, como Azure Application Gateway, que se puede considerar una aplicación virtual de red.

En este escenario, las NVA solo requieren un equilibrador de carga interno para el tráfico desde los sistemas de carga de trabajo. A veces, los dispositivos NIC duales usan este enfoque para evitar problemas de enrutamiento con las comprobaciones de estado del equilibrador de carga de Azure. Este diseño solo admite los protocolos de nivel 7 que admite el equilibrador de carga de capa 7, que normalmente es HTTP y HTTPS.

La NVA debe controlar el tráfico entrante para los protocolos que el equilibrador de carga de capa 7 no admite. La NVA también puede controlar el tráfico de salida. Para más información, consulte Firewall y Application Gateway para redes virtuales.

Servidor de Rutas

Route Server es un servicio que permite que una aplicación virtual de red interactúe con redes definidas por software de Azure a través de BGP. Las NVA aprenden qué prefijos de dirección IP existen en las redes virtuales de Azure. También pueden insertar rutas en las tablas de rutas eficaces de las máquinas virtuales de Azure.

En este diagrama se muestra un concentrador y dos radios. El centro contiene una subred de puerta de enlace, una subred de NVA y una subred de Route Server. La subred de puerta de enlace contiene una puerta de enlace VPN o ExpressRoute. La subred de NVA contiene dos NVA. La subred Route Server contiene Route Server. Cada radio contiene un servidor de aplicaciones. Spoke2 tiene una nota que indica las rutas efectivas de spoke de 0.0.0.0/0 a 10.0.0.37 y de 0.0.0.0/0 a 10.0.0.38. El tráfico entrante fluye desde la red pública de Internet a NVA1 a través del equilibrador de carga de Azure público. A continuación, este tráfico fluye al servidor de aplicaciones en Spoke2. Devuelve flujos de tráfico desde este servidor de aplicaciones a NVA1 y, a continuación, a la red pública de Internet. La adyacencia BGP conecta NVA1, NVA2 y Route Server. NVA2 y Route Server están conectados a través de eBGP.

En el diagrama anterior, cada instancia de NVA se conecta a Route Server a través de BGP. Este diseño no requiere una tabla de rutas en las subredes de radio porque Route Server programa las rutas que anuncian las NVA. Si se configuran dos o más rutas en las máquinas virtuales de Azure, utilizan el enrutamiento multipath de costo igual para elegir una de las instancias de NVA para cada flujo de tráfico individual. Por lo tanto, si necesita simetría en el tráfico, debe incluir SNAT en este diseño.

Este método de inserción admite configuraciones tanto activas/activas como activas/en espera. En una configuración activa o activa, todas las NVA anuncian las mismas rutas a Route Server. En una configuración activa/en espera, un NVA anuncia rutas con una ruta de acceso de sistema autónomo (AS) más corta que la otra. Route Server admite un máximo de ocho adyacencias BGP. Por lo tanto, si usa un clúster de escalabilidad horizontal de NVA activos, este diseño admite un máximo de ocho instancias de NVA.

Esta configuración tiene un tiempo de convergencia rápido. Los temporizadores keepalive y holdtime de la adyacencia BGP influyen en el tiempo de convergencia. Route Server tiene temporizadores keepalive predeterminados establecidos en 60 segundos y temporizadores de tiempo de suspensión establecidos en 180 segundos. Pero las NVA pueden negociar menores temporizadores durante el establecimiento de adyacencia BGP. Establecer estos temporizadores demasiado bajos podría dar lugar a las instabilities BGP.

Este diseño se adapta a las aplicaciones virtuales de red (NVAs) que necesitan interactuar con el enrutamiento de Azure. Algunos ejemplos son SD-WAN o NVA de IPsec, que normalmente tienen una buena compatibilidad con BGP. Estas aplicaciones virtuales de red deben aprender los prefijos configurados en redes virtuales de Azure o anunciar determinadas rutas a través de emparejamientos privados de ExpressRoute. Estos tipos de dispositivos suelen ser sin estado, por lo que la simetría del tráfico no es un problema y SNAT no es necesaria.

Equilibrador de carga de puerta de enlace

Equilibrador de carga de puerta de enlace proporciona una manera de insertar NVA en la ruta de acceso de datos sin necesidad de enrutar el tráfico mediante UDR. En el caso de las máquinas virtuales que exponen sus cargas de trabajo a través de un equilibrador de carga de Azure o una dirección IP pública, puede redirigir el tráfico entrante y saliente de forma transparente a un clúster de NVA ubicados en una red virtual diferente. En el diagrama siguiente se muestra la ruta de acceso que siguen los paquetes para el tráfico entrante desde la red pública de Internet si las cargas de trabajo exponen la aplicación a través de un equilibrador de carga de Azure.

En este diagrama se muestra una red virtual de NVA y una red virtual de aplicación. La red virtual de NVA contiene Equilibrador de carga de puerta de enlace y NVA. La red virtual de la aplicación contiene un servidor web. El flujo de usuario va de Internet al servidor web a través de un equilibrador de carga de Azure estándar público. El flujo controlado por el Equilibrador de carga de puerta de enlace va del equilibrador de carga de Azure estándar público al Equilibrador de carga de puerta de enlace y, a continuación, a las NVA. Este flujo invierte las direcciones y va de las NVA al equilibrador de carga de puerta de enlace y luego al equilibrador de carga estándar público de Azure.

Este método de inyección de NVA proporciona las siguientes ventajas:

• Este método no requiere SNAT para garantizar la simetría del tráfico.

• Puede usar las mismas NVA para inspeccionar el tráfico hacia y desde diferentes redes virtuales, lo que proporciona multiinquilino desde la perspectiva de la aplicación virtual de red.

• El emparejamiento de redes virtuales no es necesario entre la red virtual de NVA y las redes virtuales de carga de trabajo, lo que simplifica la configuración.

• Las UDR no son necesarias en la red virtual de carga de trabajo, lo que también simplifica la configuración.

Puede usar la inserción de servicios a través del Equilibrador de carga de puerta de enlace para el tráfico entrante a un equilibrador de carga público de Azure, su tráfico devuelto y el tráfico saliente de Azure. East-West El tráfico entre máquinas virtuales de Azure no puede utilizar Gateway Load Balancer para la inserción de NVA.

En el clúster de NVA, los sondeos de comprobación de estado del equilibrador de carga de Azure detectan errores en instancias de NVA individuales, lo que proporciona un tiempo de convergencia rápido de 10 a 15 segundos.

Dirección IP pública dinámica y administración de UDR

El objetivo de este diseño es tener una configuración que funcione sin redundancia de NVA y que se pueda modificar si el NVA experimenta tiempo de inactividad. En el diagrama siguiente se muestra cómo una dirección IP pública de Azure se asocia a una NVA activa (NVA1 en el diagrama). Las UDR de los radios usan la dirección IP de la NVA activa (10.0.0.37) como próximo salto.

En este diagrama se muestra un concentrador y dos radios. El centro contiene una subred de puerta de enlace y una subred de NVA. La subred de puerta de enlace contiene una puerta de enlace VPN o ExpressRoute. La subred de NVA contiene dos NVA. NVA1 se etiqueta como activo y NVA2 se etiqueta como en espera. Cada radio contiene un servidor de aplicaciones. Spoke2 tiene una nota que lee la tabla de rutas de radio 0.0.0.0/0 a 10.0.0.37 y deshabilita la propagación de la puerta de enlace. El tráfico entrante fluye desde Internet a NVA1 a través de una dirección IP pública. A continuación, este tráfico fluye a Spoke2. Devuelve flujos de tráfico de Spoke2 a NVA1 y, a continuación, a Internet.

Si la NVA activa deja de estar disponible, la NVA en espera llama a la API de Azure para volver a asignar la dirección IP pública y las UDR de radio a sí misma o tomar el control de la dirección IP privada. Estas llamadas API pueden tardar varios minutos en ser efectivas. Este diseño proporciona el peor tiempo de convergencia entre las opciones de este artículo.

Este diseño solo admite configuraciones activas o en espera, lo que puede provocar problemas de escalabilidad. Si necesita aumentar el ancho de banda que admiten las NVA (aplicaciones virtuales de red), debe ampliar ambas instancias.

Este diseño no requiere SNAT para garantizar la simetría del tráfico porque solo hay una NVA activa en un momento dado.

Colaboradores

Microsoft mantiene este artículo. Los colaboradores siguientes escribieron este artículo.

Autores principales:

• Keith Mayer | Arquitecto principal de soluciones en la nube
• Telmo Sampaio | Administrador de ingeniería de servicios principales
• Jose Moreno | Ingeniero principal

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Paso siguiente

• Redes perimetrales

Recurso relacionado

• Implementación de una red híbrida segura mediante Azure Firewall