En este artículo se muestran varias opciones para implementar un conjunto de aplicaciones virtuales de red (NVA) para disfrutar de alta disponibilidad en Azure. Una NVA se usa normalmente 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 desmilitarizada (DMZ) y la red pública de Internet.
Hay una serie de patrones de diseño en los que se usan aplicaciones virtuales de red para inspeccionar el tráfico entre distintas zonas de seguridad, por ejemplo:
- Para inspeccionar el tráfico de salida desde 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 de Azure, con el fin de evitar movimientos laterales de sistemas en peligro.
- Para filtrar el tráfico entre sistemas locales y máquinas virtuales de Azure, si se considera que pertenecen a distintos niveles de seguridad. Por ejemplo, si Azure hospeda la DMZ y las aplicaciones internas en un entorno local.
Hay muchos ejemplos de NVA, como firewalls de red, servidores proxy inversos de capa 4, puntos de conexión VPN de IPsec, 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 y muchos otros. Todos ellos se pueden insertar en un diseño de Azure con los patrones descritos en este artículo. Incluso las aplicaciones virtuales de red propios de Azure como Azure Firewall y Azure Application Gateway usan los diseños que se explican más adelante en este artículo. Comprender estas opciones es fundamental tanto desde la perspectiva del diseño como al solucionar problemas de red.
La primera pregunta que se debe responder es por qué se requiere alta disponibilidad para las 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 dejarán de funcionar. Las interrupciones programadas y no programadas pueden y, en ocasiones, eliminar instancias de NVA (como cualquier otra máquina virtual de Azure o cualquier otra nube). Las instancias se interrumpen incluso si esas NVA están configuradas con Managed Disks Premium para proporcionar un Acuerdo de Nivel de Servicio de instancia única en Azure. Por lo tanto, las aplicaciones de alta disponibilidad requerirán al menos una segunda NVA que pueda garantizar la conectividad.
Requisitos previos: en este artículo se presupone un conocimiento básico de redes de Azure, equilibradores de carga de Azure y enrutamiento del tráfico de redes virtuales (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 a tener en cuenta es si el proveedor de NVA ha validado ese diseño específico. El proveedor también debe proporcionar la configuración de NVA necesaria para integrar la NVA en Azure. Si el proveedor de NVA ofrece diferentes alternativas como opciones de diseño admitidas para una NVA, estos factores pueden influir en la decisión:
- Tiempo de convergencia: ¿cuánto tiempo se necesita en cada diseño para alejar el tráfico de una instancia de NVA con errores?
- Compatibilidad con topologías: ¿qué configuraciones de NVA admite cada opción de diseño? ¿Clústeres de NVA activos/activos, activos/en espera y de escalabilidad horizontal 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 de 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 centro y radio.
Nota:
Este artículo se centra en los diseños de centro y radio. Virtual WAN no se explica en este artículo, ya que Virtual WAN es mucho más prescriptiva en cuanto a cómo se implementan las NVs, dependiendo de si una NVA específica se admite los centros de conectividad 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
Las arquitecturas siguientes describen los recursos y la configuración que son necesarios para dotar a las aplicaciones virtuales de red de una alta disponibilidad:
| Solución | Ventajas | Consideraciones |
|---|---|---|
| Equilibrador de carga de Azure | Admite NVA activas/activas, activas/en espera y de escalabilidad horizontal. Tiempo de convergencia muy bueno | La NVA debe proporcionar un puerto para los sondeos de estado, especialmente para las implementaciones activas o en espera. Los flujos hacia y desde Internet requieren SNAT para la simetría |
| Azure Route Server | La NVA debe admitir BGP. Admite NVA activas/activas, activas/en espera y de escalabilidad horizontal. | La simetría de tráfico requiere SNAT |
| Equilibrador de carga de puerta de enlace | Simetría de tráfico garantizada sin SNAT. Las NVA se pueden compartir entre inquilinos. Tiempo de convergencia muy bueno. Admite NVA activas/activas, activas/en espera y de escalabilidad horizontal. | Admite flujos hacia y desde Internet, sin flujos horizontales de derecha a izquierda |
| Cambio de PIP/UDR | No se requiere ninguna característica especial por parte de la NVA. Garantiza el tráfico simétrico | Solo para diseños activos/pasivos. Mucho tiempo de alta convergencia: de 1 a 2 minutos |
Diseño de equilibrador de carga
Este diseño usa dos instancias de Azure Load Balancer para exponer un clúster de aplicaciones virtuales de red al resto de la red:
- Se usa un equilibrador de carga interno para redirigir el tráfico interno desde Azure y el entorno local a las NVA. Este equilibrador de carga interno se configura con reglas de puertos de alta disponibilidad, por lo que cada puerto TCP/UDP se redirige a las instancias de NVA.
- Un equilibrador de carga público expone las NVA a Internet. Como puertos de alta disponibilidad son para el tráfico entrante, cada puerto TCP/UDP debe abrirse en una regla de equilibrio de carga dedicada.
En el diagrama siguiente se describe la secuencia de saltos que seguirían los paquetes de Internet hasta un servidor de aplicaciones en una red virtual de radio:
Descargue un archivo 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 definida por el usuario para 0.0.0.0/0, donde 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 atravesará una instancia de Azure Load Balancer (ALB) diferente (el paquete de entrada a través de la instancia de ALB pública y el paquete de salida a través de la instancia de ALB interna). Como consecuencia, si se requiere simetría de tráfico, las instancias de NVA deben realizar la traducción de direcciones de red de origen (SNAT) para atraer el tráfico devuelto y evitar la asimetría del tráfico.
Este diseño también se puede usar para inspeccionar el tráfico entre Azure y las redes locales:
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 diagrama adicional. En los diagramas de ejemplo anteriores, dado que spoke1 no conoce el intervalo de spoke2, la UDR 0.0.0.0/0 enviará tráfico dirigido a spoke2 a la instancia de ALB interna de la NVA.
Para el tráfico entre redes locales y Azure o entre máquinas virtuales de Azure, la simetría de tráfico está garantizada por la instancia de Azure Load Balancer interna: cuando ambas direcciones de un flujo de tráfico atraviesan la misma instancia de Azure Load Balancer, se elegirá la misma instancia de NVA.
La instancia de Azure Load Balancer tiene un tiempo de convergencia muy bueno en caso de interrupciones individuales de NVA. Dado que los sondeos de estado se pueden enviar cada 5 segundos y se necesitan tres sondeos con errores para declarar una instancia de back-end fuera de servicio, normalmente se tarda entre 10 y 15 segundos en que la instancia Azure Load Balancer converja el tráfico en una instancia de NVA diferente.
Esta configuración admite configuraciones activas/activas y activas/en espera. Sin embargo, para las configuraciones activas/en espera, las instancias de NVA deben ofrecer un puerto TCP/UDP o un punto de conexión HTTP que no responda a los sondeos de estado de Load Balancer a menos que la instancia esté en el rol activo.
Uso de equilibradores de carga L7
Un caso concreto de este diseño es reemplazar la instancia de Load Balancer pública de Azure por un equilibrador de carga de nivel 7, como Azure Application Gateway (que se puede considerar como una NVA por sí mismo). En este caso, las aplicaciones virtuales de red solo requerirán una instancia de Load Balancer interna delante de ellos, ya que el tráfico de Application Gateway se origina desde dentro de la red virtual y la asimetría de tráfico no es un problema.
La aplicación de red debe tomar tráfico entrante para los protocolos no compatibles con el equilibrador de carga de nivel 7, además de todo el tráfico de salida. Para obtener más detalles 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 aplicación virtual de red interactúe con Azure SDN mediante Protocolo de puerta de enlace de borde (BGP). No solo las NVA aprenderán qué prefijos IP existen en las redes virtuales de Azure, sino que también podrán 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 programará las rutas anunciadas por las NVA. Si se programan dos o más rutas en las máquinas virtuales de Azure, usarán Equal Cost MultiPathing (ECMP) para elegir una de las instancias de NVA para cada flujo de tráfico. Como consecuencia, SNAT es una necesidad en este diseño si la simetría del tráfico es un requisito.
Este método de inserción admite tanto activa/activa (todas las NVA anuncian las mismas rutas a Azure Route Server), como activa/en espera (una NVA anuncia rutas con una ruta de AS más corta que la otro). Azure Route Server admite un máximo de 8 adyacencias BGP. Por lo tanto, si usa un clúster de escalabilidad horizontal de NVA activas, este diseño admitirá un máximo de 8 instancias de NVA.
El tiempo de convergencia es bastante rápido en esta configuración y se verá afectado 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 temporizadores inferiores durante el establecimiento de la adyacencia BGP. Si estos temporizadores son demasiado bajos, se podrían producir capacidades BGP.
Este diseño es la opción más común para las NVA que necesitan interactuar con el enrutamiento de Azure, por ejemplo, las NVA de terminación VPN que necesitan conocer los prefijos configurados en las redes virtuales de Azure o anunciar determinadas rutas a través de emparejamientos privados de ExpressRoute.
Equilibrador de carga de puerta de enlace
Azure Gateway Load Balancer es una nueva manera de insertar NVA en la ruta de acceso de datos sin necesidad de dirigir el tráfico con rutas definidas por el usuario. Para las máquinas virtuales que exponen sus cargas de trabajo a través de un Azure Load Balancer o una dirección IP pública, el tráfico entrante y saliente puede ser redirigido de forma transparente a un clúster de NVA ubicado 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 una instancia de Azure Load Balancer:
Una de las principales ventajas de este método de inserció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 NVA pueden ser utilizados para inspeccionar el tráfico hacia/desde diferentes redes virtuales, logrando así el modelo multiinquilino desde la perspectiva de las NVA. 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 requiere ninguna ruta definida por el usuario en la red virtual de carga de trabajo, lo que simplifica considerablemente la configuración.
La inserción de servicios con el equilibrador de carga de la puerta de enlace se puede usar para los flujos entrantes que alcanzan una instancia pública de Azure Load Balancer (y su tráfico de retorno), así como para los flujos salientes que se originan en Azure. El tráfico horizontal de derecha a izquierda entre máquinas virtuales de Azure no puede aprovechar el equilibrador de carga de la puerta de enlace para la inserción de NVA.
En el clúster de NVA, los sondeos de estado de Azure Load Balancer se usarán para detectar errores de instancias de NVA, con lo que se consigue un tiempo de convergencia muy rápido (de 10 a 15 segundos).
Cambio de PIP-UDR
La idea detrás de este diseño es tener la configuración necesaria sin redundancia de NVA y modificarla en caso de que la aplicación 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 definidas por usuario en los radios tienen la dirección IP de la NVA activa como próximo salto (10.0.0.37).
Si la NVA activa no está disponible, la NVA en espera llamaría a la API de Azure para reasignar la dirección IP pública y las rutas definidas por el usuario del diseño de radio a sí mismo (o mover la dirección IP privada también). Estas llamadas API pueden tardar unos minutos en ser eficaces, 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/en espera, lo que puede provocar problemas de escalabilidad: si necesita aumentar el ancho de banda admitido por las aplicaciones virtuales de red, la única opción con este diseño es escalar verticalmente ambas instancias.
Una ventaja de este diseño es que no se requiere ninguna 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 en el tiempo.
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Creadores de entidad de seguridad:
- Keith Mayer | Arquitecto principal de soluciones en la nube
- Telmo Sampaio | Director de administración de ingeniería de servicios
Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.
Pasos siguientes
- Aprenda a implementar una red híbrida segura mediante Azure Firewall.
- Redes perimetrales: Cloud Adoption Framework
- Red perimetral en la nube: Cloud Adoption Framework