Iedereen zet hem in, niemand heeft hem ooit opengemaakt. De HALB — High Availability Load Balancing — is die appliance die je voor de Secure Gateways plaatst, in twee schermen configureert en vervolgens vergeet. Ik wilde weten wat erin zit, en vooral een vraag beantwoorden die elke architect zich stelt: een broze blackbox, of goed op slot? Statische, alleen-lezen analyse op een kopie van de image: het origineel is nooit aangekoppeld of opgestart, en er is geen enkel commando in de gast uitgevoerd. Het oordeel meteen: aanzienlijk beter gebouwd dan een simpele Linux met HAProxy erop.
Even opfrissen: waarvoor dient een HALB
De HALB verdeelt het verkeer over meerdere RAS Secure Gateways en zorgt voor hun hoge beschikbaarheid. Twee of meer appliances, primair/secundair, delen een virtueel IP (VIP); valt de primaire uit, dan neemt de secundaire de VIP over. De Parallels-documentatie beschrijft het mechanisme — VRRP tussen de appliances, Gateway-verkeer op 80/443, standaard SSL-passthrough met optionele offload — maar blijft aan de oppervlakte. Wat volgt, is de concrete uitwerking.
De matroesjka
De eerste verrassing, en niet de minste: de appliance is geen simpele Linux met HAProxy erop. Het is een stapel van drie lagen, en elke laag sluit een deur.
- Een NixOS-host, versie 26.05 (Yarara). Een onveranderlijk systeem, deterministisch herbouwd: de Nix-store wordt alleen-lezen aangekoppeld (
ro,nodev,nosuid), en er zijn meerdere kernelbeveiligingsmodules actief (Landlock, Yama, BPF). Een onveranderlijke NixOS-host betekent dat je het systeem niet ter plekke wijzigt: er is geen klassiek oppervlak waarop je iets kunt neerzetten en laten blijven staan. - Een Docker-engine die op die host draait.
- Een Debian 12-container, door Docker gestart, die het volledige HALB-dataplane bevat.
Met andere woorden: wanneer je een HALB beheert, praat je met een agent die in een Docker-container leeft, die op zijn beurt op een NixOS staat die je nooit ziet. De keuze is elegant: de host blijft minimaal en onveranderlijk, en alles wat beweegt zit geïsoleerd in de container.
De container en het persistentiemodel
De container draait met verhoogde rechten (--privileged, --network=host, extra systeem-capabilities). Dat is nodig voor een netwerkappliance — hij moet de interfaces, VRRP en de firewall aansturen — en een punt dat een architect in het oog moet houden, maar het is een bewuste en voor die rol logische keuze.
Belangrijker nog: de container is vluchtig (--rm). Hij bewaart niets: alle persistentie wordt naar specifieke Docker-volumes verplaatst.
| Volume | Inhoud |
|---|---|
agentConfig | configuratie van de HALB-agent |
keepalivedConfig | gegenereerde Keepalived/VRRP-configuratie |
haproxyConfig | gegenereerde HAProxy-configuratie |
firewallConfig | firewallregels |
parallelsLogs / sysLogs | logs |
Een directe en zeer nuttige conclusie: de basis-image is een lege huls. De VIP’s, de backends, de echte certificaten staan er niet in — ze worden in deze volumes geïnjecteerd wanneer je je HALB Virtual Server configureert. Er zijn dus altijd drie toestanden:
| Toestand | Betekenis |
|---|---|
| Geleverd | aanwezig in de image-template, generiek |
| Gegenereerd | geproduceerd tijdens de configuratie, in de volumes |
| Bevestigd in het lab | daadwerkelijk waargenomen op een test-appliance |
HALBAgent, de dirigent
Het hart van het systeem is een Parallels-binary, 2XHALBAgent, die continu draait en zich altijd herstart. Het is geen gewone watchdog: het is degene die de configuraties genereert. Hij draagt de Keepalived- en HAProxy-templates en schrijft ze naar de volumes op basis van de parameters die je in de RAS-console invoert:
- een volledige Keepalived-
vrrp_instance— VIP, prioriteit, advertentie-interval, authenticatie — met een script dat HAProxy bewaakt; - de HAProxy-frontends en -backends naar je Gateways, met het health-check-interval;
- de verwijzing naar het offload-certificaat, wanneer je TLS-terminatie inschakelt.
Dit is het onderdeel dat de console die je kent verbindt met de Linux die je nooit ziet. En het verklaart ook waarom je niet met de hand aan een HALB sleutelt: de configuratie wordt gegenereerd, niet bewerkt. Wijzig je een bestand in de container, dan overschrijft de agent het.
Echte HA: Keepalived + HAProxy
De normale modus is het klassieke duo Keepalived (VRRP) voor de VIP-failover, HAProxy voor de load balancing. Keepalived voert periodiek een health-check uit die controleert of HAProxy aanwezig is en of zijn configuratie bestaat. Verdwijnt HAProxy, dan kan de VIP omschakelen.
Een interessant punt om de hersteltijden te begrijpen: er is geen Docker-healthcheck op containerniveau. De bewaking steunt op systemd, Docker en die Keepalived-health-check. Een toestand container leeft maar dataplane verslechterd wordt dus indirect gedetecteerd — een goede test als je je echte failovertijden wilt meten.
IPVS, de spookmodus
De appliance bevat ook ipvsadm en de IPVS-functies, maar in de geleverde basis zijn de regels leeg en is de automatische start uitgeschakeld. IPVS lijkt bewaard als mogelijkheid of uit historische compatibiliteit, niet als actief pad: de standaard load balancing is HAProxy in TCP-modus.
Wat de deuren sluit
Hier verdient de appliance haar goed gebouwd. Naast de onveranderlijke host wijzen meerdere keuzes dezelfde kant op:
- De effectieve firewall die in het lab is waargenomen staat standaard op deny (DROP-beleid) en opent alleen wat nodig is — VRRP, de Gateway-poorten en de gedocumenteerde configuratiepoort. Geen gapend oppervlak.
- De container bewaart niets: geen toestand die zich opstapelt, geen configuratiedrift.
- De configuratie wordt gegenereerd, niet bewerkt: minder ruimte voor menselijke fouten of een eigenmachtige wijziging.
- SSH-toegang is tijdelijk, niet permanent. De agent kan via de console een SSH-venster voor de support openen, maar dat sluit vanzelf na korte tijd. Een servicedeur die zichzelf vergrendelt, in plaats van een continu openstaande SSH.
- Modern TLS aan de HAProxy-kant: minimaal TLS 1.2, actuele 1.3-suites (ECDHE/AES-GCM, ChaCha20), tickets uitgeschakeld. De appliance draagt zelfs een inschakelbare FIPS-configuratie.
Geen enkele appliance is perfect, en goede hygiëne blijft jouw taak — regenereer de identiteiten (certificaten, SSH-hostsleutels) op elke kloon, beperk de netwerktoegang tot de configuratiepoort en behandel de support bundle als gevoelige data. Maar het fundament zelf is serieus.
De support bundle
Een laatste punt om te weten: de agent kan een support bundle produceren die de HAProxy-/Keepalived-configuratie, de firewallstatus, interface- en IP-informatie en logs bundelt. Erg handig voor een diagnose — maar het is de volledige momentopname van je appliance, voorzichtig mee omgaan voordat je het ergens heen stuurt.
Wat het voor ons verandert
- De HALB is een onveranderlijke Docker-appliance, geen klassieke Linux-server. Je logt niet in om even te kijken: alles gaat via de agent en de console.
- De configuratie leeft in volumes, niet in de image. Een kloon neemt je configuratie niet over — en denk eraan de identiteiten op elke kloon te regenereren.
- Het herstel hangt af van Keepalived en een proces-health-check. Voor betrouwbare failovercijfers test je de deeltoestanden, niet alleen het uitzetten van de primaire.
- De standaardmodus is L4 TLS-passthrough. Offload is een expliciete keuze, met een eigen certificaat.
Methode en deontologie
Deze analyse is statisch, offline en niet-destructief. De originele image is niet schrijfbaar aangekoppeld, noch opgestart; alles gebeurde op een werkkopie. Geen enkel geheim — sleutel, wachtwoord, certificaat, ruwe log, IP-adres, VRRP-waarde of echte topologie — wordt hier weergegeven. Het doel is de architectuur en de generieke mechanismen van het product te documenteren, niet de configuratie van wie dan ook.
Bronnen
- Componenten van de Parallels RAS-referentiearchitectuur
- HALB-poortreferentie
- Een HALB Virtual Server toevoegen
