Kea-DHCP-Server unter Rocky Linux 9: Reservierungen, Prüfung und Hochverfügbarkeit

EdwardMoon

Kea ist ein moderner DHCPv4-Server, der Clients automatisch IPv4-Adressen, Standardgateway, DNS und Lease-Zeiten bereitstellt. Eine frühere dhcpd-Konfiguration für CentOS 7.9 eignet sich aus zwei Gründen nicht für neue Installationen: CentOS 7 hat sein Supportende erreicht, und ISC DHCP wird seit Ende 2022 nicht mehr gepflegt.

Dieser Leitfaden richtet zunächst ein einzelnes Subnetz mit Rocky Linux 9 und den offiziellen Kea-3.0-LTS-RPMs sicher ein. Er verbindet die Prüfung tatsächlicher Schnittstellen und Adressplanung mit JSON-Syntaxprüfung, begrenzter Firewallfreigabe, Paketmitschnitt, konfliktfreien Reservierungen sowie Relay- und HA-Planung.

Warum Kea statt ISC DHCP?

ISC veröffentlichte DHCP 4.4.3-P1 als letzte Wartungsversion und empfiehlt für neue Umgebungen Kea oder einen anderen gepflegten Server. Kea bietet JSON-Konfiguration, Steuerbefehle, Statistiken, Hooks, Lease-Backends mit memfile, MySQL oder PostgreSQL sowie Hochverfügbarkeit. Die 3.0-Reihe ist ein Zweig mit Langzeitunterstützung.

Kea und der DORA-Ablauf

Liegen Client und Server nicht in derselben Broadcast-Domäne, leitet ein DHCP-Relay auf einem Layer-3-Gerät die Anfrage per Unicast weiter. Relay-Adresse, Subnetzauswahl, Rückweg vom Server und ACL-Freigaben für UDP 67 und 68 müssen zueinander passen.

Vorabprüfungen unter Rocky Linux 9

Das Beispiel verwendet die Serveradresse 192.168.100.2/24, die Schnittstelle ens192 und das Gateway 192.168.100.1. Vor dem Übernehmen tatsächliche Netzwerkkarte, VLAN, doppelte Adressen und vorhandene DHCP-Server ermitteln.

cat /etc/os-release
ip -br link
ip -br address
ip route
nmcli -t -f NAME,DEVICE,TYPE,STATE connection show --active
ss -lunp | grep -E ':(67|68)\b' || true

Adresspool auf Überschneidungen prüfen

• Dynamische Pools dürfen statische Adressen von Gateway, Servern, Druckern und Netzwerkgeräten nicht überlappen.
• Reservierte Adressen wie im Beispiel außerhalb des dynamischen Pools halten oder die Kea-Konfliktbehandlung ausdrücklich testen.
• Per Paketmitschnitt prüfen, ob im selben VLAN bereits ein DHCP-Server antwortet.
• Prüfen, ob zufällige Client-MAC-Adressen Reservierungen über hw-address beeinflussen.

Offizielle RPMs für Kea 3.0 LTS installieren

ISC stellt Pakete für die RHEL-Familie über Cloudsmith bereit. Ein entferntes Skript zunächst lokal herunterladen und Inhalt sowie TLS-Quelle prüfen, bevor es ausgeführt wird. Bei entsprechenden Lieferkettenvorgaben die Pakete in ein freigegebenes internes Repository spiegeln.

curl --fail --location --proto '=https' --tlsv1.2   https://dl.cloudsmith.io/public/isc/kea-3-0/setup.rpm.sh   --output /tmp/isc-kea-3-0-setup.rpm.sh

less /tmp/isc-kea-3-0-setup.rpm.sh
sudo bash /tmp/isc-kea-3-0-setup.rpm.sh

Nur DHCPv4-Komponenten installieren und Version dokumentieren

sudo dnf install -y isc-kea-dhcp4
rpm -q isc-kea-dhcp4 isc-kea-common
kea-dhcp4 -V
dnf repolist --enabled | grep -i kea

ISC-RPM-Abhängigkeiten können zusätzliche Repositories wie EPEL erfordern. Abhängigkeitsfehler nicht mit --skip-broken umgehen. Stattdessen anhand der ISC-Paketdokumentation freigegebene Rocky-9-Repositories und die Verfügbarkeit benötigter Pakete prüfen.

JSON-Konfiguration für Kea

Die offizielle RPM-Konfiguration liegt üblicherweise unter /etc/kea/kea-dhcp4.conf. Zuerst sichern und das folgende Beispiel mit sudoedit anpassen. Bei JSON treten häufig Fehler mit Kommentaren, Kommas oder Anführungszeichen auf. Vor dem Dienststart deshalb unbedingt den Kea-eigenen Prüfer erfolgreich ausführen.

sudo cp -a /etc/kea/kea-dhcp4.conf   /etc/kea/kea-dhcp4.conf.before-$(date +%F-%H%M%S)
sudoedit /etc/kea/kea-dhcp4.conf

{
  "Dhcp4": {
    "interfaces-config": {
      "interfaces": [ "ens192" ]
    },
    "lease-database": {
      "type": "memfile",
      "persist": true,
      "name": "/var/lib/kea/kea-leases4.csv",
      "lfc-interval": 3600
    },
    "valid-lifetime": 3600,
    "renew-timer": 900,
    "rebind-timer": 1800,
    "subnet4": [
      {
        "id": 100,
        "subnet": "192.168.100.0/24",
        "pools": [
          { "pool": "192.168.100.100 - 192.168.100.200" }
        ],
        "option-data": [
          { "name": "routers", "data": "192.168.100.1" },
          { "name": "domain-name-servers", "data": "192.168.100.53" },
          { "name": "domain-name", "data": "example.internal" }
        ],
        "reservations": [
          {
            "hw-address": "00:11:22:33:44:55",
            "ip-address": "192.168.100.50",
            "hostname": "printer1"
          }
        ]
      }
    ],
    "loggers": [
      {
        "name": "kea-dhcp4",
        "output-options": [ { "output": "syslog" } ],
        "severity": "INFO"
      }
    ]
  }
}

Anzupassende Beispielwerte

Syntax prüfen und Dienst starten

sudo kea-dhcp4 -t /etc/kea/kea-dhcp4.conf
sudo systemctl enable --now kea-dhcp4
sudo systemctl status kea-dhcp4 --no-pager
sudo journalctl -u kea-dhcp4 -b --no-pager | tail -n 100

Firewall und begrenzte Erreichbarkeit

DHCPv4-Server verwenden UDP 67, Clients UDP 68. Bei direkt angeschlossenen VLANs den DHCP-Dienst in der firewalld-Zone der Dienstschnittstelle erlauben. In Relay-Umgebungen auch Relay, ACLs und Routing auf die notwendigen Pfade beschränken.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=internal --add-service=dhcp --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --zone=internal --list-services
sudo ss -lunp | grep ':67'

Zuerst prüfen, ob die Beispielzone internal tatsächlich zur Dienstschnittstelle gehört. Ports nicht pauschal in allen Zonen öffnen. Auf Netzwerkgeräten nur die Pfade zu Relays und legitimen Servern als vertrauenswürdige DHCP-Snooping-Ports festlegen.

Pakete und Leases diagnostizieren

DORA-Pakete live beobachten

sudo tcpdump -ni ens192 -vvv   '(udp port 67 or udp port 68)'

Dienstlogs und Lease-Dateien prüfen

sudo journalctl -u kea-dhcp4 -f
sudo ls -lh /var/lib/kea/
sudo tail -n 20 /var/lib/kea/kea-leases4.csv

DHCP-Relay und mehrere Subnetze

Der DHCP-Server muss nicht direkt mit jedem VLAN verbunden sein. Leitet ein Router oder Layer-3-Switch Anfragen als Relay weiter, wählt Kea das Subnetz anhand der übermittelten Linkinformationen. Für jedes Subnetz eine eindeutige id verwenden und Antwortweg sowie Relay-Zugriffs-ACL prüfen. Herstellerspezifische Relay-Befehle der offiziellen Gerätedokumentation entnehmen.

ip route get <RELAY_IP>
sudo tcpdump -ni any -vvv   'host <RELAY_IP> and (udp port 67 or udp port 68)'
sudo journalctl -u kea-dhcp4 --since '-10 min'

Reservierungen planen

Eine Reservierung ist keine manuell konfigurierte feste IP-Adresse, sondern eine Serverregel, die einem wiedererkannten Clientbezeichner eine bestimmte Lease zuweist. MAC-Adressen verwalteter Drucker und Server können stabil sein; Mobilgeräte verwenden dagegen möglicherweise private MAC-Adressen pro SSID. Bei der Auswahl hw-address-, client-id- und flex-id-Richtlinien berücksichtigen.

• Konfliktvermeidung bei Überschneidungen zwischen Reservierungen und dynamischem Pool testen.
• MAC-Adresse, Eigentümer und Verwendungszweck aus der Anlagenverwaltung mit dem Änderungsverlauf der Reservierung verknüpfen.
• Für den Gerätetausch ein Freigabeverfahren zum Bereinigen bisheriger Bezeichner und Leases festlegen.
• Bei vielen Reservierungen unterstützte Host-Backends und Änderungs-APIs statt manueller JSON-Bearbeitung prüfen.

Von ISC DHCP auf Kea migrieren

Der Kea Migration Assistant von ISC kann dhcpd.conf teilweise umwandeln. Das Ergebnis ist jedoch nicht automatisch produktionsfertig. Bedingungen, DDNS, Failover, Klassen, Lease-Verarbeitung und nicht unterstützte Optionen müssen manuell geprüft werden. Das Umschaltfenster so planen, dass alter und neuer Server nicht gleichzeitig denselben Pool maßgeblich bedienen.

1. Bisherige Konfiguration, Leases, DNS-Anbindung, Relays, Optionen und Reservierungen sichern und erfassen.
2. KeaMA-Warnungen und nicht umgewandelte Syntax prüfen und eine minimale JSON-Konfiguration erstellen.
3. In einem isolierten VLAN DORA, Reservierungen, Erneuerung, DNS, PXE und langfristiges Lease-Verhalten testen.
4. Lease-Zeiten mit ausreichender Übergangsfrist schrittweise verkürzen oder eine andere Kollisionsvermeidung für den Wechsel festlegen.
5. Im Änderungsfenster alte Antworten stoppen, Kea starten und Pakete, Logs sowie doppelte Adressen beobachten.
6. Rückkehrbedingungen und Reaktivierung des bisherigen Servers vorab dokumentieren.

Hochverfügbarkeit planen

Die obige JSON-Datei konfiguriert einen einzelnen DHCP-Server und aktiviert keine HA. Für eine tatsächliche HA-Bereitstellung werden das passende HA-Hook-Paket, Partnereinstellungen unter hooks-libraries, ein HTTP-/HTTPS-Steuerkanal und Relay-Weiterleitung an beide Server benötigt. Die folgenden Punkte sind Entwurfs- und Prüfkriterien, keine vollständige HA-Konfiguration. Die Beispiele derselben Version aus dem ISC HA Quickstart als Ausgangspunkt verwenden und beide Knotenkonfigurationen gemeinsam prüfen.

Der Kea-HA-Hook verwaltet Partnerzustände und Lease-Updates etwa im Hot-Standby- oder Lastverteilungsbetrieb. Identische JSON-Dateien auf zwei Servern ergeben allein noch keine HA. Heartbeats, Zustandswechsel, Lease-Synchronisierung, Antwortstrategie bei Split Brain, Relay-Ziele, Hook-Kompatibilität und Ausfallszenarien gemeinsam planen.

• Zeitsynchronisierung, Versionen, Hooks und Subnetzeinstellungen beider Server abstimmen.
• HA-Kommunikationsports nur im Verwaltungsnetz freigeben und TLS- sowie Authentifizierungsunterstützung prüfen.
• Primary-Stopp, HA-Linkunterbrechung, Relay-Pfadausfall und Lease-Backend-Ausfall getrennt testen.
• Clientauswirkungen während des Wechsels nach partner-down mit tatsächlichen Endgeräten und perfdhcp messen.
• HA repliziert auch falsche Optionen, Löschungen und Bedienfehler. Konfigurationsversionierung und unabhängige Sicherungen bleiben erforderlich.

Checkliste für den Betrieb

• Supportende von CentOS 7 und ISC DHCP berücksichtigt und unterstütztes Betriebssystem sowie Kea-Zweig gewählt.
• Tatsächliche Schnittstelle, Subnetz, Pool, Gateway, DNS, Relay und vorhandene DHCP-Antworten geprüft.
• Nach JSON-Prüfung Dienst gestartet und DISCOVER, OFFER, REQUEST sowie ACK aufgezeichnet.
• Firewall nur für Dienst-VLAN oder Relay-Pfad im erforderlichen Umfang freigegeben.
• Reservierungen, Bezeichner, zufällige MAC-Adressen und Alarme für Poolerschöpfung werden verwaltet.
• Konfiguration, Lease-Backend, Hooks und Paketversionen gesichert und Wiederherstellung getestet.
• Bei HA neben Serverstopp auch Netzpartitionen und fehlgeschlagene Lease-Synchronisierung geprüft.

Offizielle Dokumentation und weiterführende Anleitungen

• ISC: Wartungsende von ISC DHCP
• Offizielle Administrationsdokumentation für Kea 3.0 LTS
• Offizielle ISC-Kea-Pakete und Dienstnamen
• Cloudsmith-Repository für Kea 3.0 einrichten
• Von ISC DHCP auf Kea migrieren
• Offizieller Kea HA Quickstart
• Linux: Speicher- und Inode-Störungen diagnostizieren

Zusammenfassung

Für neue Umgebungen unterstützte Kea- und Betriebssystemversionen wählen und anhand der Adressplanung sowie tatsächlicher Pakete prüfen. Entscheidend sind die Vermeidung konkurrierender DHCP-Server, Pool- und Reservierungsverwaltung, Relay-Pfade, begrenzte Firewallfreigaben, Wiederherstellung von Leases und Konfiguration sowie HA-Tests einschließlich Netzpartitionen.