Todo el mundo lo despliega, nadie lo ha abierto nunca. El HALB — High Availability Load Balancing — es ese appliance que se coloca delante de las Secure Gateways, se configura en dos pantallas y se olvida. Quise saber qué había dentro y, sobre todo, responder a una pregunta que se hace todo arquitecto: ¿es una caja negra frágil o está bien blindado? Análisis estático, de solo lectura, sobre una copia de la imagen: la original nunca se montó ni se arrancó, y no se ejecutó ningún comando dentro del invitado. El veredicto, de entrada: está mucho mejor construido que un simple Linux con un HAProxy encima.
Recordatorio: para qué sirve un HALB
El HALB reparte el tráfico entre varias RAS Secure Gateways y garantiza su alta disponibilidad. Dos o más appliances, primario/secundario, comparten una IP virtual (VIP); si el primario cae, el secundario retoma la VIP. La documentación de Parallels describe el mecanismo — VRRP entre appliances, tráfico de Gateway en 80/443, passthrough SSL por defecto con offload opcional — pero se queda en la superficie. Lo que sigue es la implementación concreta.
La muñeca rusa
La primera sorpresa, y no menor: el appliance no es un simple Linux con HAProxy encima. Es una pila de tres capas, y cada una cierra una puerta.
- Un host NixOS, versión 26.05 (Yarara). Un sistema inmutable, reconstruido de forma determinista: el Nix store se monta en solo lectura (
ro,nodev,nosuid) y hay varios módulos de seguridad del kernel activos (Landlock, Yama, BPF). Un host NixOS inmutable significa que no se modifica el sistema sobre la marcha: no hay una superficie clásica donde dejar algo y hacerlo persistir. - Un motor Docker que corre sobre ese host.
- Un contenedor Debian 12 lanzado por Docker, que contiene todo el plano de datos del HALB.
Dicho de otro modo: cuando administra un HALB, habla con un agente que vive dentro de un contenedor Docker, a su vez apoyado en un NixOS que usted nunca ve. La elección es elegante: el host se mantiene mínimo e inmutable, y todo lo que se mueve queda aislado en el contenedor.
El contenedor y el modelo de persistencia
El contenedor se lanza con privilegios elevados (--privileged, --network=host, capacidades de sistema adicionales). Es necesario para un appliance de red — tiene que manejar las interfaces, el VRRP y el firewall — y es un punto que un arquitecto debe tener presente, pero es una elección deliberada y coherente con ese papel.
Sobre todo, el contenedor es efímero (--rm). No conserva nada: toda la persistencia se traslada a volúmenes Docker dedicados.
| Volumen | Contenido |
|---|---|
agentConfig | configuración del agente HALB |
keepalivedConfig | configuración Keepalived/VRRP generada |
haproxyConfig | configuración HAProxy generada |
firewallConfig | reglas de firewall |
parallelsLogs / sysLogs | registros |
Una conclusión directa y muy útil: la imagen base es un armazón vacío. Las VIP, los backends, los certificados reales no están en ella — se inyectan en estos volúmenes cuando configura su HALB Virtual Server. Por eso siempre hay tres estados:
| Estado | Significado |
|---|---|
| Entregado | presente en la plantilla de la imagen, genérico |
| Generado | producido durante la configuración, en los volúmenes |
| Confirmado en laboratorio | observado realmente en un appliance de prueba |
HALBAgent, el director de orquesta
El corazón del sistema es un binario de Parallels, 2XHALBAgent, que se ejecuta de forma continua y siempre se reinicia. No es un simple watchdog: es él quien genera las configuraciones. Lleva las plantillas de Keepalived y HAProxy y las escribe en los volúmenes a partir de los parámetros que usted introduce en la consola RAS:
- una
vrrp_instancede Keepalived completa — VIP, prioridad, intervalo de anuncio, autenticación — con un script que vigila HAProxy; - los frontends y backends de HAProxy hacia sus Gateways, con el intervalo de health-check;
- la referencia al certificado de offload, cuando activa la terminación TLS.
Es la pieza que une la consola que usted conoce con el Linux que nunca ve. Y también explica por qué no se trastea un HALB a mano: la configuración se genera, no se edita. Si modifica un archivo dentro del contenedor, el agente lo reescribe.
La verdadera HA: Keepalived + HAProxy
El modo normal es el dúo clásico Keepalived (VRRP) para la conmutación de la VIP, HAProxy para el balanceo de carga. Keepalived ejecuta periódicamente un health-check que comprueba que HAProxy está presente y que su configuración existe. Si HAProxy desaparece, la VIP puede conmutar.
Un punto interesante para entender los tiempos de recuperación: no hay healthcheck de Docker a nivel de contenedor. La supervisión se apoya en systemd, Docker y ese health-check de Keepalived. Un estado contenedor vivo pero plano de datos degradado se detecta, por tanto, de forma indirecta — una buena prueba si quiere medir sus tiempos de conmutación reales.
IPVS, el modo fantasma
El appliance también incluye ipvsadm y las funciones IPVS, pero en la base entregada las reglas están vacías y el arranque automático está desactivado. IPVS parece conservado como capacidad o por compatibilidad histórica, no como ruta activa: el balanceo por defecto es HAProxy en modo TCP.
Lo que cierra las puertas
Aquí es donde el appliance se gana su bien hecho. Más allá del host inmutable, varias decisiones apuntan en la misma dirección:
- El firewall efectivo observado en laboratorio es deny por defecto (política DROP), abriendo solo lo necesario — VRRP, los puertos de Gateway y el puerto de configuración documentado. Sin superficie abierta de par en par.
- El contenedor no persiste nada: ningún estado que se acumule, ninguna deriva de configuración.
- La configuración se genera, no es editable: menos margen para el error humano o un cambio salvaje.
- El acceso SSH es temporal, no permanente. El agente puede abrir una ventana SSH para el soporte desde la consola, pero se cierra sola al cabo de poco tiempo. Una puerta de servicio que se bloquea sola, en lugar de un SSH abierto de forma continua.
- TLS moderno del lado de HAProxy: TLS 1.2 mínimo, suites 1.3 al día (ECDHE/AES-GCM, ChaCha20), tickets desactivados. El appliance incluso lleva una configuración FIPS activable.
Ningún appliance es perfecto, y la buena higiene sigue siendo cosa suya — regenere las identidades (certificados, claves de host SSH) en cualquier clon, limite el acceso de red al puerto de configuración y trate el support bundle como un dato sensible. Pero la base, en sí, es seria.
El support bundle
Un último punto que conviene conocer: el agente puede producir un support bundle que reúne la configuración de HAProxy/Keepalived, el estado del firewall, la información de interfaces e IP, y los registros. Muy práctico para un diagnóstico — pero es la fotografía completa de su appliance, a manejar con cuidado antes de enviarla a ninguna parte.
Lo que cambia para nosotros
- El HALB es un appliance Docker inmutable, no un servidor Linux clásico. No se conecta uno para mirar: todo pasa por el agente y la consola.
- La configuración vive en volúmenes, no en la imagen. Un clon no arrastra su configuración — y acuérdese de regenerar las identidades en cualquier clon.
- La recuperación depende de Keepalived y de un health-check de proceso. Para cifras de conmutación fiables, pruebe los estados parciales, no solo apagar el primario.
- El modo por defecto es passthrough TLS L4. El offload es una elección explícita, con su propio certificado.
Método y deontología
Este análisis es estático, sin conexión y no destructivo. La imagen original no se montó en escritura ni se arrancó; todo se hizo sobre una copia de trabajo. Ningún secreto — clave, contraseña, certificado, registro en bruto, dirección IP, valor VRRP o topología real — se reproduce aquí. El objetivo es documentar la arquitectura y los mecanismos genéricos del producto, no la configuración de nadie.
Fuentes
- Componentes de la arquitectura de referencia de Parallels RAS
- Referencia de puertos HALB
- Añadir un servidor virtual HALB
