(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
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
|
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
- 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?
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
|