En este artículo se explican las opciones más comunes para implementar un conjunto de aplicaciones virtuales de red (NVA) para lograr una alta disponibilidad en Azure. Normalmente, una aplicación virtual de red se usa para controlar el flujo de tráfico entre segmentos de red clasificados con distintos niveles de seguridad, por ejemplo, entre una red virtual de zona de De-Militarized (DMZ) y la red virtual pública de Internet, o para conectar ubicaciones externas a Azure, como dispositivos VPN o SDWAN (Software-Defined WAN).
Hay muchos patrones de diseño en los que se usan NVA para inspeccionar el tráfico entre diferentes zonas de seguridad, por ejemplo:
- 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 los sistemas locales y las máquinas virtuales de Azure, si se consideran que pertenecen a distintos niveles de seguridad. (Por ejemplo, si Azure hospeda la red perimetral y el entorno local, las aplicaciones internas).
- Para finalizar túneles VPN o SDWAN desde ubicaciones externas, como redes locales u otras nubes públicas.
Hay muchos ejemplos de NVA, incluidos los siguientes, entre otros:
- Firewalls de red
- Servidores proxy inversos de capa 4
- Puntos de conexión vpn de IPsec
- Dispositivos SDWAN
- Servidores proxy inversos basados en web con 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
Todas estas aplicaciones virtuales de red se pueden insertar en un diseño de Azure con los patrones descritos en este artículo. Incluso las aplicaciones virtuales de red de azure de primera entidad, como azure Firewall y Azure Application Gateway usar los diseños que se explican más adelante en este artículo. Comprender estas opciones es fundamental desde una perspectiva de diseño y al solucionar problemas de red.
La primera pregunta que se debe responder es por qué se requiere alta disponibilidad para aplicaciones virtuales de red. El motivo es que estos dispositivos controlan la comunicación entre segmentos de red. Si no están disponibles, el tráfico de red no puede fluir y las aplicaciones dejan de funcionar. Las interrupciones programadas y no programadas provocarán ocasionalmente instancias de NVA (como cualquier otra máquina virtual de Azure o cualquier otra nube). Las instancias se desactivan incluso si esas aplicaciones virtuales de red están configuradas con Discos administrados Premium para proporcionar un Acuerdo de Nivel de Servicio de instancia única en Azure. Por lo tanto, las aplicaciones de alta disponibilidad requieren al menos una segunda aplicación virtual de red que pueda garantizar la conectividad.
Requisitos previos: En este artículo se da por supuesto un conocimiento básico de las redes de Azure, azure Load Balancersy de enrutamiento de tráfico de red virtual (UDR).
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 que se debe tener en cuenta es si el proveedor de NVA ha examinado y validado ese diseño específico. El proveedor también debe proporcionar la configuración de NVA necesaria necesaria para integrar la aplicación virtual de red en Azure. Si el proveedor de NVA ofrece diferentes alternativas como opciones de diseño admitidas para una aplicación virtual de red, estos factores pueden influir en la decisión:
- Tiempo de convergencia: ¿cuánto tiempo tarda cada diseño en alejar el tráfico de una instancia de NVA con error?
- Compatibilidad con topologías: ¿qué configuraciones de NVA admite cada opción de diseño? ¿Clústeres de NVA de escalado horizontal activo/activo, activo/activo/en espera con redundancia n+1?
- Simetría de tráfico: ¿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 se aplica la simetría del tráfico por otros medios?
En las secciones siguientes del documento se describen las arquitecturas más comunes que se usan para integrar NVA en una red de concentrador y radio.
Nota:
Este artículo se centra en los diseños de Hub & Spoke. no se trata el de Virtual WAN, ya que Virtual WAN es mucho más prescriptivo sobre cómo se implementan las NVA, en función de si se admite una NVA específica en los centros de Virtual WAN. Consulte Aplicaciones virtuales de red en el centro de conectividad de Virtual WAN para obtener más información.
Introducción a las arquitecturas de alta disponibilidad
En las arquitecturas siguientes se describen los recursos y la configuración necesarios para las aplicaciones virtuales de red de alta disponibilidad:
| Solución | Ventajas | Consideraciones |
|---|---|---|
| Equilibrador de carga de Azure | Admite NVA activas o activas, activas o en espera y 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 aplicación virtual de red debe admitir BGP. Admite NVA activas o activas, activas o en espera y escalabilidad horizontal. | La simetría del tráfico también requiere SNAT |
| Equilibrador de carga de puerta de enlace | Simetría de tráfico garantizada sin SNAT. Las aplicaciones virtuales de red se pueden compartir entre inquilinos. Buen tiempo de convergencia. Admite NVA activas o activas, activas o en espera y escalabilidad horizontal. | Admite flujos hacia o desde Internet, sin flujos de East-West |
| cambio de PIP/UDR | Ninguna característica especial requerida por la aplicación virtual de red. Garantiza el tráfico simétrico | Solo para diseños activos/pasivos. Tiempo de convergencia alto de 1 a 2 minutos |
Diseño de Load Balancer
Este diseño usa dos equilibradores de carga de Azure para exponer un clúster de NVA al resto de la red. El enfoque se usa con frecuencia para NVA con estado y sin estado:
- Una instancia interna de Load Balancer se usa para redirigir el tráfico interno desde Azure y el entorno local a las aplicaciones virtuales de red. Este equilibrador de carga interno se configura con reglas de puertos de alta disponibilidad, de modo que cada puerto TCP/UDP se redirija a las instancias de NVA.
- Un equilibrador de carga público expone las NVA a Internet. Dado que los puertos de alta disponibilidad son para el tráfico entrante, cada puerto TCP/UDP individual debe abrirse en una regla de equilibrio de carga dedicada.
En el diagrama siguiente se describe la secuencia de saltos que los paquetes de Internet a un servidor de aplicaciones de una red virtual radial seguirían el recorrido de una NVA de firewall para controlar el tráfico hacia o desde la red pública de Internet (también denominada tráfico norte/sur):
Descargar un archivo de Visio de esta arquitectura.
El mecanismo para enviar tráfico desde radios a la red pública de Internet a través de las NVA es una ruta de User-Defined para 0.0.0.0/0 con el próximo salto 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 una instancia diferente de Azure Load Balancer. Esto ocurre incluso si la NVA del firewall tiene una sola NIC para las redes públicas e internas, ya que el paquete de entrada pasa por el ALB público y el paquete de salida pasa por el ALB interno. Dado que ambas direcciones del flujo pasan por diferentes equilibradores de carga, si se requiere simetría de tráfico, como suele ser el caso en la mayoría de los firewalls, la traducción de direcciones de red de origen (SNAT) debe realizarse por las instancias de NVA para atraer el tráfico devuelto y evitar la asimetría del tráfico.
También se puede usar el mismo diseño con equilibradores de carga para inspeccionar el tráfico entre Azure y las redes locales (Este/Oeste), donde solo interviene un equilibrador de carga interno:
El mecanismo para enviar tráfico entre radios a través de las NVA es exactamente el mismo, por lo que no se proporciona ningún otro diagrama. En los diagramas de ejemplo anteriores, dado que spoke1 no conoce el intervalo de spoke2, el 0.0.0.0/0 UDR envía el tráfico dirigido a spoke2 al equilibrador de carga interno de Azure Load Balancer de la NVA.
En el caso del 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 una sola NIC por parte del equilibrador de carga interno de Azure: cuando ambas direcciones de un flujo de tráfico atraviesan la misma instancia de Azure Load Balancer, el equilibrador de carga elegirá la misma instancia de NVA. En el caso de NVA de doble NIC, donde hay un equilibrador de carga interno para cada sentido de la comunicación, la simetría del tráfico debe proporcionarse a través de SNAT como en el ejemplo norte/sur anterior.
Otro desafío que enfrentan las NVA de doble NIC en este diseño es donde enviar las respuestas a las comprobaciones de estado del equilibrador de carga. Azure Load Balancer siempre usa la misma dirección IP que el origen de las comprobaciones de estado (168.63.129.16). La aplicación virtual de red debe poder enviar la respuesta al origen de la comprobación de estado de esta dirección IP en la misma interfaz que se recibieron. Normalmente, esto requiere varias tablas de enrutamiento en un sistema operativo, ya que el enrutamiento basado en destino enviaría la respuesta a las comprobaciones de estado siempre a través de la misma NIC.
Azure Load Balancer tiene un buen tiempo de convergencia en interrupciones individuales de NVA. Dado que los sondeos de estado de se pueden enviar cada 5 segundos y tarda 3 sondeos erróneos en declarar una instancia de back-end fuera del servicio, normalmente 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. En el caso de las configuraciones activas o en espera, las instancias de NVA deben ofrecer un puerto TCP/UDP o un punto de conexión HTTP que solo responda a los sondeos de estado de Load Balancer para la instancia que se encuentra en el rol activo.
Uso de equilibradores de carga L7
Un caso concreto de este diseño para dispositivos de seguridad consiste en reemplazar el equilibrador de carga público de Azure por un equilibrador de carga de capa 7, como la de Azure Application Gateway (que se puede considerar como una aplicación virtual de red por sí misma). En este caso, las NVA solo requieren un equilibrador de carga interno para el tráfico procedente de los sistemas de carga de trabajo. A veces, los dispositivos NIC duales usan este mecanismo para evitar el problema de enrutamiento con las comprobaciones de estado de Azure Load Balancer descritas en la sección anterior. Una restricción de este diseño es que solo admite los protocolos de nivel 7 admitidos por el equilibrador de carga de capa 7, normalmente HTTP(S).
La aplicación virtual de red debe tomar tráfico entrante para los protocolos no compatibles con el equilibrador de carga de nivel 7, además de potencialmente todo el tráfico de salida. Para más información sobre esta configuración al usar Azure Firewall como NVA y Azure Application Gateway como proxy inverso web de capa 7, consulte Firewall y Application Gateway para redes virtuales.
Azure Route Server
Azure Route Server es un servicio que permite que una NVA interactúe con Azure SDN a través del Protocolo de puerta de enlace de borde (BGP). No solo los NVA aprenden qué prefijos IP existen en las redes virtuales de Azure, pero pueden insertar rutas en las tablas de rutas eficaces de las máquinas virtuales de Azure.
En el diagrama anterior, cada instancia de NVA se empareja a través de BGP con Azure Route Server. No se requiere ninguna tabla de rutas en las subredes de radio, ya que Azure Route Server programa las rutas anunciadas por las NVA. Si se programan dos o más rutas en las máquinas virtuales de Azure, usan Equal Cost MultiPathing (ECMP) para elegir una de las instancias de NVA para cada flujo de tráfico. Como consecuencia, SNAT es un elemento necesario en este diseño si la simetría del tráfico es un requisito.
Este método de inserción admite tanto activa como activa (todas las NVA anuncian las mismas rutas a Azure Route Server) y activa/en espera (una NVA anuncia rutas con una ruta as más corta que la otra). Azure Route Server admite un máximo de 8 adyacencias BGP. Por lo tanto, si se usa un clúster de escalabilidad horizontal de NVA activas, este diseño admite un máximo de 8 instancias de NVA.
El tiempo de convergencia es rápido en esta configuración y está influenciado por los temporizadores keepalive y holdtime de la adyacencia BGP. Aunque Azure Route Server tiene temporizadores keepalive y holdtime predeterminados (60 segundos y 180 segundos respectivamente), las NVA pueden negociar los temporizadores más bajos durante el establecimiento de adyacencia de BGP. Establecer estos temporizadores demasiado bajos podría dar lugar a las instabilities BGP.
Este diseño es la opción más común para las aplicaciones virtuales de red que necesitan interactuar con el enrutamiento de Azure, por ejemplo, NVA sdWAN o IPsec que suelen tener una buena compatibilidad con BGP y necesitan aprender los prefijos configurados en redes virtuales de Azure o anunciar determinadas rutas a través de emparejamientos privados de ExpressRoute. Este tipo de dispositivos suele ser sin estado, por lo que la simetría del tráfico no es un problema y, por tanto, no se requiere SNAT.
Equilibrador de carga de puerta de enlace
azure Gateway Load Balancer es una nueva forma de insertar NVA en la ruta de acceso de datos sin necesidad de dirigir el tráfico con rutas de User-Defined. En el caso de las máquinas virtuales que exponen sus cargas de trabajo a través de una instancia de Azure Load Balancer o una dirección IP pública, el tráfico entrante y saliente se puede redirigir de forma transparente a un clúster de NVA ubicados en una red virtual diferente. En el diagrama siguiente se describe la ruta de acceso que siguen los paquetes para el tráfico entrante desde la red pública de Internet en caso de que las cargas de trabajo expongan la aplicación a través de azure Load Balancer:
Una de las principales ventajas de este método de inyección de NVA es que la traducción de direcciones de red de origen (SNAT) no es necesaria para garantizar la simetría del tráfico. Otra ventaja de esta opción de diseño es que las mismas aplicaciones virtuales de red se pueden usar para inspeccionar el tráfico hacia y desde diferentes redes virtuales, logrando así multiinquilino desde la perspectiva de la aplicación virtual de red. No se requiere ningún emparejamiento de red virtual entre la red virtual de NVA y las redes virtuales de carga de trabajo, y no se requieren rutas User-Defined en la red virtual de carga de trabajo, lo que simplifica drásticamente la configuración.
La inserción de servicios con El equilibrador de carga de puerta de enlace se puede usar para los flujos de entrada que alcanzan un equilibrador de carga público de Azure (y su tráfico devuelto) y para los flujos de salida que se originan en Azure. East-West tráfico entre máquinas virtuales de Azure no puede aprovechar Gateway Load Balancer para la inserción de NVA.
En el clúster de NVA, los sondeos de comprobación de estado de Azure Load Balancer se usan para detectar errores individuales de instancia de NVA, lo que permite lograr un tiempo de convergencia rápido (de 10 a 15 segundos).
Cambio de PIP-UDR
La idea de este diseño es tener la configuración necesaria sin redundancia de NVA y modificarla en caso de que la aplicación virtual de red sufra un tiempo de inactividad. En el diagrama siguiente se muestra cómo se asocia una dirección IP pública de Azure a la NVA activa (NVA1) y las rutas de User-Defined en los radios tienen la dirección IP de la NVA activa como próximo salto (10.0.0.37).
Si la aplicación virtual de red activa no está disponible, la aplicación virtual de red en espera llamaría a la API de Azure para volver a asignar la dirección IP pública y el radio User-Defined Rutas a sí misma (o también movería la dirección IP privada). Estas llamadas API pueden tardar unos minutos en ser efectivas, por lo que este diseño ofrece el peor tiempo de convergencia de todas las opciones de este documento.
Otra limitación de este diseño es que solo se admiten configuraciones activas o en espera, lo que puede provocar problemas de escalabilidad: si necesita aumentar el ancho de banda admitido por las NVA, la única opción con este diseño es escalar verticalmente ambas instancias.
Una ventaja de este diseño es que no se requiere traducción de direcciones de red de origen (SNAT) para garantizar la simetría del tráfico, ya que solo hay una NVA activa en un momento dado.
Colaboradores
Microsoft mantiene este artículo. Originalmente fue escrito por los siguientes colaboradores.
Autores principales:
- Keith Mayer | Arquitecto principal de soluciones en la nube
- Telmo Sampaio | Director de administración de ingeniería de servicios
- Jose Moreno | Ingeniero principal
Para ver perfiles de LinkedIn no públicos, inicie sesión en LinkedIn.
Pasos siguientes
- Aprenda a implementar una red híbrida segura mediante Azure Firewall.
- redes perimetrales de : de Cloud Adoption Framework
- Cloud DMZ- Cloud Adoption Framework