La nube está cambiando la forma en que se diseña la infraestructura, incluido el diseño de los firewalls, ya que la red no es física ni está en LAN virtuales. No todas las características de una red física están disponibles en una red virtual (VNet), lo que incluye el uso de direcciones IP flotantes o el tráfico de difusión, y eso influye en la implementación de arquitecturas de alta disponibilidad. Los equilibradores de carga de los dispositivos virtuales de red (NVA) pueden o deben implementarse de una manera determinada para lograr una arquitectura de alta disponibilidad en una red virtual. En esta guía se presenta un enfoque estructurado para el diseño de firewalls de alta disponibilidad (FW) en Azure mediante dispositivos virtuales de terceros.
Opciones para diseñar dispositivos virtuales de red disponibles
Al implementar arquitecturas de alta disponibilidad, hay varias opciones que permiten proporcionar conmutación por error:
- Tablas de rutas administradas por API de Azure: esta opción usa dos tablas de rutas, una activa y otra pasiva, para cambiar la dirección IP de la puerta de enlace activa en todos los servicios que se ejecutan en una red virtual o subred.
- IP flotante administrada por API de Azure: esta opción usa una dirección IP secundaria en los firewalls que se puede desplazar entre un firewall que esté activo y otro que esté en espera.
- Load Balancer administrado: esta opción usa Azure Load Balancer como dirección IP de la puerta de enlace de la subred, que luego reenvía el tráfico al firewall de alta disponibilidad activo. Incluso puede reenviar el tráfico activo-activo para proporcionar un equilibrio de carga real.
El problema con las dos primeras opciones es que la propia conmutación por error es lenta. El firewall debe indicar la conmutación por error, que es esencialmente una "reconfiguración" de los servicios de Azure a través de una nueva implementación. En función del tiempo que tarde en completarse la implementación, los flujos de tráfico estarán inactivos durante varios minutos. Además, no permite una configuración activo-activo en la que ambos firewalls funcionen al mismo tiempo.
Este es el motivo por el que se prefiere la tercera opción. Se minimiza el tiempo de inactividad, ya que el equilibrador de carga puede realizar la conmutación por error de forma casi instantánea en el firewall en espera (en activo-pasivo) o simplemente quitar la carga del firewall en que se ha producido el error (en activo-activo). Sin embargo, los equilibradores de carga no se pueden usar como "puertas de enlace predeterminadas", ya que afectan al flujo de tráfico y los paquetes TCP deben ser con estado.
Firewalls de dos segmentos
La siguiente imagen comienza con dos firewalls de alta disponibilidad (FW-1 y FW-2), un equilibrador de carga externo y un servidor back-end S1.
Esta arquitectura es una configuración simple que se usa para el tráfico entrante. Un paquete alcanza el equilibrador de carga, que elige el firewall de alta disponibilidad de destino de su configuración. Luego, el firewall elegido envía el tráfico al servidor back-end (web). Si FW-1 tiene SNAT habilitado, el servidor S1 verá el tráfico que procede de la dirección IP interna de FW-1, por lo que también enviará la respuesta al paquete a FW-1. En este escenario, la conmutación por error puede producirse rápidamente en FW-2. En cuanto al tráfico saliente, podemos agregar otro equilibrador de carga en el lado interno. Cuando el servidor S1 inicie el tráfico, se aplicará el mismo principio. El tráfico alcanza el equilibrador de carga interno (iLB), que elige un firewall que luego realiza la traducción de NAT para la resolución externa:
Firewalls de tres segmentos
Los problemas surgen cuando se agrega otra interfaz al firewall y es necesario deshabilitar la traducción de NAT entre las zonas internas. En este caso, consulte Subred B y Subred C:
Se equilibrará la carga del enrutamiento de L3 entre las zonas internas (Subred B y Subred C) sin NAT. Esta configuración se ve con mayor claridad en los flujos de tráfico que incluyen los equilibradores de carga en otra vista. En el diagrama siguiente se muestra la vista en la que los equilibradores de carga internos [iLB] están vinculados a una NIC específica en los firewalls de alta disponibilidad:
Con el tráfico de L3 (sin NAT), S2 verá la dirección IP de S1 como dirección de origen. Luego, S2 enviará el tráfico de retorno a Subred B (a la que pertenece la dirección IP de S1) al iLB que se encuentra en Subred C. Dado que la iLB de Subred B y la iLB de Subred C no sincronizan sus estados de sesión, en función del algoritmo de equilibrio de carga el tráfico podría acabar en FW-2. De manera predeterminada, FW-2 no tienen ningún tipo de información acerca del paquete inicial (verde), por lo que anulará la conexión.
Algunos proveedores de firewalls intentan conservar un estado de conexión entre los firewalls, pero necesitarían tener una sincronización casi instantánea actualizada en los estados de conexión. Consulte al proveedor del firewall si recomienda esta instalación.
La mejor manera de tratar este problema es eliminarlo. En el ejemplo anterior, esta solución significa la eliminación de Subred C, lo que nos lleva a las ventajas de las redes virtuales virtualizadas.
Aislamiento de hosts en una subred con grupos de seguridad de red
Cuando hay dos máquinas virtuales en una subred, se puede aplicar un grupo de seguridad de red que aísle el tráfico entre ambas. De forma predeterminada, se permite todo el conjunto de tráfico que haya dentro de una red virtual. Al agregar una regla Denegar todo regla al grupo de seguridad de red, se aíslan todas las máquinas virtuales entre sí.
Las redes virtuales usan los mismos enrutadores de back-end (virtuales)
La red virtual o las subredes usan un único sistema de enrutadores de back-end de Azure, por lo que no es preciso especificar una dirección IP de enrutador para cada subred. El destino de la ruta puede estar en cualquier lugar de la misma red virtual, o incluso fuera.
Con las redes virtualizadas, se pueden controlar las rutas de todas las subredes. Estas rutas también pueden apuntar a una única dirección IP de otra subred. En la imagen anterior, sería el iLB de Subred D, que equilibra la carga de los dos firewalls. Cuando S1 inicie el tráfico (verde), se equilibrará su carga a, por ejemplo, FW-1. A continuación, FW-1 se conectará a S2 (aún verde). S2 enviará el tráfico de respuesta a la dirección IP de S1 (ya que NAT está deshabilitado). Debido a las tablas de rutas, S2 usa la misma dirección IP de iLB que su puerta de enlace. El iLB puede coincidir con el tráfico de la sesión inicial, por lo que siempre apuntará este tráfico a FW-1. Después, FW-1 lo envía a S1, lo que establece un flujo de tráfico sincrónico.
Para que esta configuración funcione, es preciso que el firewall tenga una tabla de rutas (internamente) que apunte tanto Subred B como Subnet C a su puerta de enlace de subred predeterminada. Esa puerta de enlace de subred es la primera dirección IP disponible lógicamente en el intervalo de subredes de esa red virtual.
Impacto en servicios de proxy inverso
Al implementar un servicio de proxy inverso, lo normal es que esté detrás del firewall. En su lugar, puede ponerlo en línea con el firewall y enrutar realmente el tráfico a través del firewall. La ventaja de esta configuración es que el servicio de proxy inverso vería la dirección IP original del cliente que se conecta:
Para esta configuración, es preciso que las tablas de rutas de Subred E apunten a Subred B y Subred C a través del equilibrador de carga interno. Algunos servicios de proxy inverso tienen firewalls integrados que permiten eliminar todos los firewalls al mismo tiempo en este flujo de red. Los firewalls integrados apuntan desde el proxy inverso directamente a los servidores de Subnet B y Subred C.
En este escenario, SNAT también se necesitará en el proxy inverso para evitar que el tráfico de retorno fluya a través de los firewalls de alta disponibilidad hasta Subred A y los deniegue.
VPN/ER
Azure proporciona servicios de VPN/ER de alta disponibilidad y habilitados para BGP a través de las puertas de enlace de Azure Virtual Network. La mayoría de los arquitectos los conservan para conexiones de back-end o que no tengan acceso a Internet. Esta configuración significa que la tabla de rutas debe alojar también las subredes que hay detrás de estas conexiones. Aunque no hay una gran diferencia con la conectividad de Subred B/C, la hay en el diseño del tráfico de retorno, lo que completa la imagen:
En esta arquitectura, el tráfico que llega al firewall del alta disponibilidad, por ejemplo de Subred B a Subred X se enviaría a iLB, que a su vez lo envía a cualquier firewall. La ruta interna dentro del firewall del alta disponibilidad devolverá el tráfico a la puerta de enlace de la subred (la primera dirección IP disponible en Subred D). No es preciso enviar el tráfico directamente al propio dispositivo de puerta de enlace, ya que otra ruta de Subred D tendrá una ruta para Subred X que apunta a la puerta de enlace de la red virtual. Las redes de Azure se encargarán del enrutamiento real.
El tráfico de retorno que provenga de Subred X se reenviará al iLB de Subred D. GatewaySubnet también tendrá una ruta personalizada que apunta Subred B/C al iLB. Subred D no apunta a través de iLB. Esto se tratará como enrutamiento normal entre redes virtuales.
Aunque no esté en el dibujo, tendría sentido que Subred B/C/D/puerta de enlace también incluyan una ruta para Subred A que señale al iLB. Esta organización evita que el enrutamiento de red virtual "normal" omita los firewalls. Esto se debe a que Subred A es otra subred de la red virtual según la pila de redes de Azure. No se tratará a Subred A de forma diferente, aunque se le trate como una red perimetral/Internet, etc.
Resumen
En resumen, la forma en que trate los firewalls en las redes locales (físicas o basadas en VLAN), con muchas interfaces (virtuales o físicas) no coincide con su tratamiento en Azure. Si es necesario, puede (hasta cierto punto) tener implementaciones activo-activo y tablas de rutas limpias, aunque hay formas mejores de asegurarse de que puede minimizar el tiempo de inactividad de la conmutación por error.
Puede encontrar más información sobre el uso de equilibradores de carga como puertas de enlace para todo el tráfico en Introducción a los puertos de alta disponibilidad.
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Autor principal:
- Roelf Zomerman | Arquitecto sénior de soluciones en la nube
Pasos siguientes
Más información sobre las tecnologías de los componentes:
Recursos relacionados
Explore las arquitecturas relacionadas:
- Implementación de una red híbrida segura
- Conexión híbrida
- Extensión de una red local mediante VPN
- Elección entre el emparejamiento de red virtual y las puertas de enlace de VPN
- Solución de problemas de una conexión VPN híbrida
- Topología de red en estrella tipo hub-and-spoke en Azure
- Conexión de servidores independientes mediante el adaptador de red de Azure