OPNsense KEA HA

Kea DHCP im HA-Cluster

• Dieser Artikel setzt einen funktionierenden CARP-Cluster nach OPNsense HA Umsetzung voraus
• Ziel: ein DHCP-Dienst, der einen Ausfall des Masters übersteht, ohne dass Clients ihre Adresse verlieren

Warum nicht über das normale HA?

• Das OPNsense-HA besteht aus drei Mechanismen: CARP für die virtuellen IPs, pfsync für die Firewall-States und XMLRPC für die Konfiguration
• XMLRPC überträgt ausschließlich Konfiguration, keine Betriebsdaten
• Vergebene Adressen (Leases) sind Betriebsdaten – für sie gibt es im OPNsense-HA kein Gegenstück zu pfsync
• CARP meldet einem Knoten auch nicht, dass er die Rolle übernommen hat; das passiert im Kernel auf Interface-Ebene, die Dienste darüber merken davon nichts
• Deshalb bringt Kea eine eigene HA-Logik mit: eigener Kanal über HTTP, eigene Rollen, eigener Heartbeat
• dnsmasq hat das nicht. Dort bleibt nur, den DHCP-Dienst auf einen Knoten zu beschränken oder die Pools aufzuteilen

Betriebsmodell

• Kea arbeitet im Modus Hot-Standby: der Primary vergibt die Adressen, der Standby wartet und hält die Lease-Daten mit
• Fällt der Primary aus, übernimmt der Standby und vergibt aus demselben Pool weiter
• Kommt der Primary zurück, übernimmt er wieder

Vorbereitung

• dnsmasq als DHCP-Server abschalten – sonst antworten zwei Server im selben Segment
  • Services => Dnsmasq DNS & DHCP => General: DHCP-Ranges entfernen
• Beide Knoten müssen dieselbe OPNsense-Version haben
• Die HA-Kommunikation läuft über das SYN-Netz (100.64.64.0/30), dort erlaubt die vorhandene Allow-Regel bereits allen Verkehr

Ports

Port	Verwendung
8000	Control Agent (lokale Steuerung des Dienstes)
8001	Peer-Kommunikation zwischen den Knoten

• Die beiden Ports müssen unterschiedlich sein. Wird für die Peers derselbe Port wie für den Control Agent eingetragen, startet Kea zwar, findet den Partner aber nicht.

Control Agent (beide Firewalls)

• Services => Kea DHCP => Control Agent

Parameter	Wert
Enabled	aktiviert
Port	8000

• Anschließend Apply

DHCPv4 (Master Firewall)

• Services => Kea DHCP => KEA DHCPv4
• Sämtliche Konfiguration erfolgt auf dem Master und wird später zum Backup übertragen

Parameter	Wert
Enabled	aktiviert
Interfaces	LAN

Subnetz

Parameter	Wert
Subnet	192.168.1.0/24
Pools	192.168.1.100 - 192.168.1.150
Option: routers	192.168.1.3
Option: domain-name-servers	192.168.1.3

Achtung

• Als Router und DNS muss die LAN-VIP 192.168.1.3 verteilt werden, nicht die 192.168.1.1
• Wird die echte Adresse des Masters verteilt, ist der Client beim Ausfall des Masters offline – obwohl der DHCP-Dienst hochverfügbar ist

High Availability (Master Firewall)

• Services => Kea DHCP => Settings => High Availability

Parameter	Wert
Enabled	aktiviert
This server name	opns-ha1
Role	primary

Peers

• Im Reiter Peers werden beide Knoten eingetragen, auch der eigene

Name	Role	URL
opns-ha1	primary	http://100.64.64.1:8001/
opns-ha2	standby	http://100.64.64.2:8001/

• Die Namen müssen exakt dem entsprechen, was auf dem jeweiligen Knoten unter This server name steht

Konfiguration übertragen

• System => High Availability => Settings: den Dienst Kea DHCP zusätzlich in die Services-Liste aufnehmen und speichern
• System => High Availability => Status => Synchronize and reconfigure all

High Availability (Backup Firewall)

• Nach dem Sync liegt die Konfiguration auf dem Backup, die Rolle muss dort aber von Hand gesetzt werden
• Services => Kea DHCP => Settings => High Availability

Parameter	Wert
This server name	opns-ha2
Role	standby

Funktionstest

• Auf dem Client eine Adresse anfordern:

ipconfig /release
ipconfig /renew
ipconfig /all

• Gateway und DNS müssen 192.168.1.3 sein
• Master in den Wartungsmodus versetzen: Interfaces => Virtual IPs => Status => Enter Persistent CARP Maintenance Mode
• Erneut release und renew auf dem Client – die Adresse muss weiterhin vergeben werden, jetzt vom Backup
• Zweiter Test: Master hart ausschalten und dasselbe prüfen

Debugging

Lauschen die Dienste?

• Auf beiden Knoten:

sockstat -4 -l | grep 800

• Erwartet werden Einträge für 8000 und 8001

Erreicht der Master den Partner?

curl http://100.64.64.2:8001/

Log

tail -f /var/log/kea/latest.log

Beobachtung	Ursache
Kea startet, HA bleibt im Zustand "communication-recovery"	Peer nicht erreichbar – Port, IP oder Regel auf dem SYN-Interface prüfen
Partner wird nicht erkannt, obwohl erreichbar	Name im Peer-Eintrag stimmt nicht mit "This server name" überein
Beide Knoten vergeben Adressen	dnsmasq läuft noch als DHCP-Server
Client bekommt 192.168.1.1 als Gateway	Option "routers" zeigt nicht auf die VIP