Jeder setzt sie ein, niemand hat sie je geöffnet. Der HALB — High Availability Load Balancing — ist jene Appliance, die man vor die Secure Gateways stellt, in zwei Masken konfiguriert und dann vergisst. Ich wollte wissen, was drinsteckt, und vor allem eine Frage beantworten, die sich jeder Architekt stellt: eine fragile Blackbox oder solide abgeriegelt? Statische, rein lesende Analyse auf einer Kopie des Images: das Original wurde nie eingehängt oder gestartet, und im Gast wurde kein einziger Befehl ausgeführt. Das Fazit vorweg: deutlich besser gebaut als ein simples Linux mit aufgesetztem HAProxy.
Zur Erinnerung: wofür ein HALB da ist
Der HALB verteilt den Datenverkehr auf mehrere RAS Secure Gateways und stellt deren Hochverfügbarkeit sicher. Zwei oder mehr Appliances, primär/sekundär, teilen sich eine virtuelle IP (VIP); fällt die primäre aus, übernimmt die sekundäre die VIP. Die Parallels-Dokumentation beschreibt den Mechanismus — VRRP zwischen den Appliances, Gateway-Verkehr auf 80/443, SSL-Passthrough standardmäßig mit optionalem Offload — bleibt aber an der Oberfläche. Was folgt, ist die konkrete Umsetzung.
Die Matrjoschka
Die erste Überraschung, und keine kleine: die Appliance ist kein simples Linux mit HAProxy obendrauf. Es ist ein Stapel aus drei Schichten, und jede schließt eine Tür.
- Ein NixOS-Host, Version 26.05 (Yarara). Ein unveränderliches System, deterministisch neu gebaut: der Nix-Store ist schreibgeschützt eingehängt (
ro,nodev,nosuid), und mehrere Kernel-Sicherheitsmodule sind aktiv (Landlock, Yama, BPF). Ein unveränderlicher NixOS-Host bedeutet, dass man das System nicht an Ort und Stelle verändert: es gibt keine klassische Fläche, auf der man etwas ablegen und dauerhaft machen könnte. - Eine Docker-Engine, die auf diesem Host läuft.
- Ein Debian-12-Container, von Docker gestartet, der die gesamte HALB-Datenebene enthält.
Anders gesagt: wenn Sie einen HALB verwalten, sprechen Sie mit einem Agenten, der in einem Docker-Container lebt, der wiederum auf einem NixOS sitzt, das Sie nie sehen. Die Wahl ist elegant: der Host bleibt minimal und unveränderlich, und alles Bewegliche ist im Container isoliert.
Der Container und das Persistenzmodell
Der Container läuft mit erhöhten Rechten (--privileged, --network=host, zusätzliche System-Capabilities). Das ist für eine Netzwerk-Appliance nötig — sie muss Schnittstellen, VRRP und die Firewall steuern — und ein Punkt, den ein Architekt im Blick haben sollte, aber eine bewusste und für diese Rolle stimmige Entscheidung.
Vor allem ist der Container flüchtig (--rm). Er behält nichts: die gesamte Persistenz wird in dedizierte Docker-Volumes ausgelagert.
| Volume | Inhalt |
|---|---|
agentConfig | Konfiguration des HALB-Agenten |
keepalivedConfig | generierte Keepalived/VRRP-Konfiguration |
haproxyConfig | generierte HAProxy-Konfiguration |
firewallConfig | Firewall-Regeln |
parallelsLogs / sysLogs | Logs |
Eine direkte und sehr nützliche Erkenntnis: das Basis-Image ist eine leere Hülle. Die VIPs, die Backends, die echten Zertifikate stehen nicht darin — sie werden in diese Volumes injiziert, wenn Sie Ihren HALB Virtual Server konfigurieren. Es gibt also stets drei Zustände:
| Zustand | Bedeutung |
|---|---|
| Ausgeliefert | im Image-Template vorhanden, generisch |
| Generiert | bei der Konfiguration erzeugt, in den Volumes |
| Im Labor bestätigt | tatsächlich auf einer Test-Appliance beobachtet |
HALBAgent, der Dirigent
Das Herz des Systems ist ein Parallels-Binary, 2XHALBAgent, das dauerhaft läuft und sich immer neu startet. Es ist kein bloßer Watchdog: es ist das, was die Konfigurationen erzeugt. Es trägt die Keepalived- und HAProxy-Templates und schreibt sie aus den in der RAS-Konsole eingegebenen Parametern in die Volumes:
- eine vollständige Keepalived-
vrrp_instance— VIP, Priorität, Ankündigungsintervall, Authentifizierung — mit einem Skript, das HAProxy überwacht; - die HAProxy-Frontends und -Backends zu Ihren Gateways, mit dem Health-Check-Intervall;
- den Verweis auf das Offload-Zertifikat, wenn Sie die TLS-Terminierung aktivieren.
Das ist das Stück, das die Konsole, die Sie kennen, mit dem Linux verbindet, das Sie nie sehen. Und es erklärt auch, warum man an einem HALB nicht von Hand herumbastelt: die Konfiguration wird generiert, nicht bearbeitet. Ändern Sie eine Datei im Container, überschreibt der Agent sie.
Echte HA: Keepalived + HAProxy
Der Normalbetrieb ist das klassische Duo Keepalived (VRRP) für das VIP-Failover, HAProxy für das Load Balancing. Keepalived führt regelmäßig einen Health-Check aus, der prüft, ob HAProxy vorhanden ist und seine Konfiguration existiert. Verschwindet HAProxy, kann die VIP umschwenken.
Interessant für das Verständnis der Wiederherstellungszeiten: es gibt keinen Docker-Healthcheck auf Container-Ebene. Die Überwachung stützt sich auf systemd, Docker und diesen Keepalived-Health-Check. Ein Zustand Container lebt, aber Datenebene degradiert wird daher indirekt erkannt — ein guter Test, wenn Sie Ihre echten Failover-Zeiten messen wollen.
IPVS, der Geistermodus
Die Appliance bringt auch ipvsadm und die IPVS-Funktionen mit, aber im ausgelieferten Sockel sind die Regeln leer und der automatische Start ist deaktiviert. IPVS wirkt als Fähigkeit oder aus historischer Kompatibilität erhalten, nicht als aktiver Pfad: das Standard-Load-Balancing ist HAProxy im TCP-Modus.
Was die Türen schließt
Hier verdient sich die Appliance ihr gut gebaut. Über den unveränderlichen Host hinaus weisen mehrere Entscheidungen in dieselbe Richtung:
- Die im Labor beobachtete effektive Firewall ist standardmäßig deny (DROP-Policy) und öffnet nur das Nötige — VRRP, die Gateway-Ports und den dokumentierten Konfigurationsport. Keine klaffende Fläche.
- Der Container persistiert nichts: kein Zustand, der sich ansammelt, keine Konfigurationsdrift.
- Die Konfiguration wird generiert, nicht bearbeitet: weniger Raum für menschliche Fehler oder eine eigenmächtige Änderung.
- Der SSH-Zugang ist temporär, nicht dauerhaft. Der Agent kann über die Konsole ein SSH-Fenster für den Support öffnen, das sich nach kurzer Zeit von selbst schließt. Eine Servicetür, die sich selbst verriegelt, statt eines ständig offenen SSH.
- Modernes TLS auf HAProxy-Seite: mindestens TLS 1.2, aktuelle 1.3-Suiten (ECDHE/AES-GCM, ChaCha20), Tickets deaktiviert. Die Appliance trägt sogar eine aktivierbare FIPS-Konfiguration.
Keine Appliance ist perfekt, und gute Hygiene bleibt Ihre Sache — erneuern Sie die Identitäten (Zertifikate, SSH-Host-Keys) bei jedem Klon, beschränken Sie den Netzwerkzugang auf den Konfigurationsport und behandeln Sie das Support-Bundle als sensible Daten. Aber der Unterbau ist seriös.
Das Support-Bundle
Noch ein Punkt, den man kennen sollte: der Agent kann ein Support-Bundle erzeugen, das die HAProxy-/Keepalived-Konfiguration, den Firewall-Zustand, Schnittstellen- und IP-Informationen sowie Logs zusammenfasst. Sehr praktisch für die Diagnose — aber es ist die vollständige Momentaufnahme Ihrer Appliance, mit Vorsicht zu behandeln, bevor Sie es irgendwohin schicken.
Was sich für uns ändert
- Der HALB ist eine unveränderliche Docker-Appliance, kein klassischer Linux-Server. Man loggt sich nicht ein, um nachzusehen: alles läuft über den Agenten und die Konsole.
- Die Konfiguration lebt in Volumes, nicht im Image. Ein Klon übernimmt Ihre Konfiguration nicht — und denken Sie daran, die Identitäten bei jedem Klon zu erneuern.
- Die Wiederherstellung hängt von Keepalived und einem Prozess-Health-Check ab. Für verlässliche Failover-Zahlen testen Sie die Teilzustände, nicht nur das Ausschalten der Primären.
- Der Standardmodus ist L4-TLS-Passthrough. Offload ist eine bewusste Wahl, mit eigenem Zertifikat.
Methode und Ethik
Diese Analyse ist statisch, offline und zerstörungsfrei. Das Original-Image wurde weder schreibend eingehängt noch gestartet; alles geschah auf einer Arbeitskopie. Kein Geheimnis — Schlüssel, Passwort, Zertifikat, Rohlog, IP-Adresse, VRRP-Wert oder echte Topologie — wird hier wiedergegeben. Ziel ist es, die Architektur und die generischen Mechanismen des Produkts zu dokumentieren, nicht die Konfiguration von irgendjemandem.
Quellen
- Komponenten der Parallels-RAS-Referenzarchitektur
- HALB-Portreferenz
- Einen HALB Virtual Server hinzufügen
