Thomas.will: Die Seite wurde neu angelegt: „= Kea DHCP im HA-Cluster = * Dieser Artikel setzt einen funktionierenden CARP-Cluster nach OPNsense HA Umsetzung voraus * Ziel: ein DHCP-Dienst, der einen…“

2026-09-03T18:00:32Z

Die Seite wurde neu angelegt: „= Kea DHCP im HA-Cluster = * Dieser Artikel setzt einen funktionierenden CARP-Cluster nach OPNsense HA Umsetzung voraus * Ziel: ein DHCP-Dienst, der einen…“

Neue Seite

= 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 ==
{| class="wikitable"
! 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
{| class="wikitable"
! 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
{| class="wikitable"
! Parameter !! Wert
|-
| Enabled || aktiviert
|-
| Interfaces || LAN
|}

== Subnetz ==
{| class="wikitable"
! 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
{| class="wikitable"
! Parameter !! Wert
|-
| Enabled || aktiviert
|-
| This server name || opns-ha1
|-
| Role || primary
|}

== Peers ==
* Im Reiter '''Peers''' werden '''beide''' Knoten eingetragen, auch der eigene
{| class="wikitable"
! 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
{| class="wikitable"
! 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

{| class="wikitable"
! 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
|}

OPNsense KEA HA - Versionsgeschichte

Thomas.will: Die Seite wurde neu angelegt: „= Kea DHCP im HA-Cluster = * Dieser Artikel setzt einen funktionierenden CARP-Cluster nach OPNsense HA Umsetzung voraus * Ziel: ein DHCP-Dienst, der einen…“