Tout le monde en déploie, personne ne l’a jamais ouverte. Le HALB — High Availability Load Balancing — est cette appliance qu’on pose devant les Secure Gateways, qu’on configure en deux écrans, et qu’on oublie. J’ai eu envie de savoir ce qu’il y avait dedans, et surtout de répondre à une question que tout architecte se pose : est-ce une boîte noire fragile, ou est-ce bien verrouillé ? Analyse statique, en lecture seule, sur une copie de l’image : l’originale n’a jamais été montée ni démarrée, aucune commande n’a été exécutée dans l’invité. Verdict d’entrée de jeu : c’est nettement mieux fichu qu’un simple Linux avec un HAProxy posé dessus.
Rappel : à quoi sert un HALB
Le HALB répartit le trafic sur plusieurs RAS Secure Gateways et assure leur haute disponibilité. Deux appliances ou plus, en primaire/secondaire, partagent une IP virtuelle (VIP) ; si la primaire tombe, la secondaire reprend la VIP. La documentation Parallels décrit le mécanisme — VRRP entre appliances, trafic Gateway en 80/443, passthrough SSL par défaut avec offload optionnel — mais s’arrête à la surface. Ce qui suit, c’est la réalisation concrète.
La poupée russe
Première surprise, et pas la moindre : l’appliance n’est pas un simple Linux avec HAProxy dessus. C’est un empilement en trois couches, et chacune ferme une porte.
- Un hôte NixOS, en version 26.05 (Yarara). Système immuable, reconstruit de façon déterministe : le Nix store est monté en lecture seule (
ro,nodev,nosuid), et plusieurs modules de sécurité noyau sont activés (Landlock, Yama, BPF). Un hôte NixOS immuable, ça veut dire qu’on ne « modifie » pas le système en place : il n’y a pas de surface classique où déposer et faire persister quelque chose. - Un moteur Docker qui tourne sur cet hôte.
- Un conteneur Debian 12 lancé par Docker, qui contient tout le plan de données HALB.
Autrement dit, quand vous pilotez un HALB, vous parlez à un agent qui vit dans un conteneur Docker, lui-même posé sur un NixOS que vous ne voyez jamais. Le choix est élégant : l’hôte reste minimal et immuable, et tout ce qui bouge est isolé dans le conteneur.
Le conteneur et le modèle de persistance
Le conteneur est lancé avec des privilèges élevés (--privileged, --network=host, capacités système supplémentaires). C’est nécessaire pour une appliance réseau — il faut manipuler les interfaces, le VRRP et le pare-feu — et c’est un point qu’un architecte doit avoir en tête, mais c’est un choix assumé et cohérent pour ce rôle.
Surtout, le conteneur est éphémère (--rm). Il ne garde rien : toute la persistance est déportée dans des volumes Docker dédiés.
| Volume | Contenu |
|---|---|
agentConfig | configuration de l’agent HALB |
keepalivedConfig | configuration Keepalived/VRRP générée |
haproxyConfig | configuration HAProxy générée |
firewallConfig | règles de pare-feu |
parallelsLogs / sysLogs | journaux |
Conséquence directe et très utile à retenir : l’image de base est un socle vide. Les VIP, les backends, les certificats réels n’y sont pas — ils sont injectés dans ces volumes au moment où vous configurez votre HALB Virtual Server. On distingue donc toujours trois états :
| État | Signification |
|---|---|
| Livré | présent dans le template de l’image, générique |
| Généré | produit lors de la configuration, dans les volumes |
| Confirmé en lab | observé réellement sur une appliance de test |
HALBAgent, le chef d’orchestre
Le cœur du système est un binaire Parallels, 2XHALBAgent, qui tourne en permanence et redémarre toujours. Ce n’est pas un simple watchdog : c’est lui qui génère les configurations. Il embarque les templates de Keepalived et de HAProxy et les écrit dans les volumes à partir des paramètres que vous saisissez dans la console RAS :
- un
vrrp_instanceKeepalived complet — VIP, priorité, intervalle d’annonce, authentification — avec un script qui surveille HAProxy ; - les frontends et backends HAProxy vers vos Gateways, avec l’intervalle de health-check ;
- la référence au certificat d’offload, quand vous activez la terminaison TLS.
C’est la pièce qui relie la console que vous connaissez au Linux que vous ne voyez pas. Et c’est aussi ce qui explique pourquoi on ne « bidouille » pas un HALB à la main : la config est générée, pas éditée. Si vous modifiez un fichier dans le conteneur, l’agent le réécrit.
La vraie HA : Keepalived + HAProxy
Le mode normal, c’est le duo classique Keepalived (VRRP) pour la bascule de VIP, HAProxy pour le load-balancing. Keepalived exécute périodiquement un health-check qui vérifie que HAProxy est bien présent et que sa configuration existe. Si HAProxy disparaît, la VIP peut basculer.
Point intéressant pour comprendre les délais de reprise : il n’y a pas de healthcheck Docker au niveau du conteneur. La supervision repose sur systemd, Docker et ce health-check Keepalived. Un état « conteneur vivant mais plan de données dégradé » se détecte donc indirectement — un bon sujet de test si vous voulez mesurer vos temps de bascule réels.
IPVS, le mode fantôme
L’appliance embarque aussi ipvsadm et les fonctions IPVS, mais dans le socle livré les règles sont vides et le démarrage automatique est désactivé. IPVS semble conservé comme capacité ou compatibilité historique, pas comme chemin actif : le load-balancing par défaut, c’est HAProxy en mode TCP.
Ce qui ferme les portes
C’est là que l’appliance mérite son « bien fait ». Au-delà de l’hôte immuable, plusieurs choix vont dans le même sens :
- Le pare-feu effectif observé en lab est en deny par défaut (politique DROP), n’ouvrant que ce qui est nécessaire — VRRP, les ports Gateway et le port de configuration documenté. Pas de surface béante.
- Le conteneur ne persiste rien : pas d’état qui s’accumule, pas de dérive de configuration.
- La configuration est générée, pas éditable : moins de place pour l’erreur humaine ou une modification sauvage.
- L’accès SSH est temporaire, pas permanent. L’agent peut ouvrir une fenêtre SSH pour le support via la console, mais elle se referme d’elle-même au bout d’un délai court. Une porte de service qui se verrouille toute seule, plutôt qu’un SSH ouvert en continu.
- TLS moderne côté HAProxy : TLS 1.2 minimum, suites 1.3 à jour (ECDHE/AES-GCM, ChaCha20), tickets désactivés. L’appliance porte même une configuration FIPS activable.
Aucune appliance n’est parfaite, et la bonne hygiène reste de votre côté — régénérez les identités (certificats, clés d’hôte SSH) sur tout clone, limitez l’accès réseau au port de configuration, et traitez le support bundle comme une donnée sensible. Mais le socle, lui, est sérieux.
Le support bundle
Dernier point à connaître : l’agent sait produire un support bundle regroupant configuration HAProxy/Keepalived, état du pare-feu, informations d’interfaces et d’IP, et journaux. Très pratique pour un diagnostic — mais c’est la photographie complète de votre appliance, à manier avec précaution avant de l’envoyer où que ce soit.
Ce que ça change pour nous
- Le HALB est une appliance Docker immuable, pas un serveur Linux classique. On ne s’y connecte pas pour « regarder » : tout passe par l’agent et la console.
- La config vit dans des volumes, pas dans l’image. Un clone ne reconduit pas votre configuration — et pensez à régénérer les identités sur tout clone.
- La reprise dépend de Keepalived et d’un health-check de processus. Pour des chiffres de bascule fiables, testez les états partiels, pas seulement « j’éteins la primaire ».
- Le mode par défaut est du passthrough TLS L4. L’offload est un choix explicite, avec son propre certificat.
Méthode et déontologie
Cette analyse est statique, hors ligne et non destructive. L’image originale n’a été ni montée en écriture ni démarrée ; tout a été fait sur une copie de travail. Aucun secret — clé, mot de passe, certificat, journal brut, adresse IP, valeur VRRP ou topologie réelle — n’est reproduit ici. L’objectif est de documenter l’architecture et les mécanismes génériques du produit, pas la configuration de qui que ce soit.
Sources
- Composants de l’architecture de référence Parallels RAS
- Référence des ports HALB
- Configurer un HALB Virtual Server
