XPLN/Lernbereiche

F11 · Kea 3.0.2 · VM-Labor

Linux und Kea praktisch einrichten

Kapitel in dieser Lernstufe

Das lernst du

  • Eine nachvollziehbare Kea-DHCPv4-Konfiguration schreiben und validieren.
  • Konfigurationsdatei, Dienst und Lease-Speicher unterscheiden.

Voraussetzungen: G06 · Subnetz, Scope und PoolF07 · Reservierungen und ClientidentitätF09 · DHCP-Relay und giaddrF10 · Windows Server praktisch einrichten

Kea verwendet eine deklarative Konfiguration. Dieses Lehrprofil ist auf Kea 3.0.2 festgelegt; Dienstnamen, Dateipfade und Paketversionen hängen von der Linux-Distribution ab. P22 und P23 enthalten die isolierten Laborabläufe.

Datei, laufender Dienst und Lease sind verschiedene Zustände

Konfiguration ist noch kein Laufzeitnachweiskea-dhcp4.conf{subnet4192.168.10.0/24pools.100 – .199option-data}1Dateiprüfen2Dienst lädtKonfiguration3Antwort +Client prüfenLease-Daten separat sichern; sie stehen nicht in dieser Datei.
Grafik vergrößern
Konfiguration ist noch kein Laufzeitnachweiskea-dhcp4.conf{subnet4192.168.10.0/24pools.100 – .199option-data}1Dateiprüfen2Dienst lädtKonfiguration3Antwort +Client prüfenLease-Daten separat sichern; sie stehen nicht in dieser Datei.
Das Kea-Lehrprofil trennt Konfigurationsdaten auf der linken Seite von ihrem Laufzeitnachweis rechts. subnet4 beschreibt das Clientnetz, pools die dynamische Menge, option-data die Parameter. Ein erfolgreicher Konfigurationstest ist noch kein Beleg für eine geladene Konfiguration oder eine erfolgreiche Vergabe. Erst Paketantwort und Clientwerte schließen die Prüfkette; die Lease-Datenbank ist ein eigener Bestand.

Eine kleine vollständige Konfiguration

interfaces-config bestimmt die verwendeten Interfaces. subnet4 beschreibt die Clientnetze, pools die dynamischen Mengen. option-data enthält Parameter. Eine Reservierung kann etwa über hw-address definiert sein; host-reservation-identifiers macht die hier verwendete Suche ausdrücklich.

Das Beispiel ist für einen direkt angeschlossenen Testclient in 192.168.10.0/24 gedacht. Der Server selbst hat .10 außerhalb des Pools. enp1s0 ist vor Anwendung durch den tatsächlichen Labornamen zu ersetzen. Ein entferntes Netz benötigt zusätzlich eine korrekte Relayarchitektur.

Kea 3.0.2 · JSON
{
  "Dhcp4": {
    "interfaces-config": { "interfaces": ["enp1s0"] },
    "valid-lifetime": 28800,
    "renew-timer": 14400,
    "rebind-timer": 25200,
    "lease-database": { "type": "memfile", "persist": true },
    "host-reservation-identifiers": ["hw-address"],
    "subnet4": [{
      "id": 10, "subnet": "192.168.10.0/24",
      "pools": [{"pool": "192.168.10.100 - 192.168.10.199"}],
      "option-data": [
        {"name": "routers", "data": "192.168.10.1"},
        {"name": "domain-name-servers", "data": "192.168.20.10"},
        {"name": "domain-name", "data": "nordlicht.test"}
      ],
      "reservations": [{"hw-address":"02:00:00:00:10:50", "ip-address":"192.168.10.150"}]
    }]
  }
}

Prüfen, anwenden, beobachten

kea-dhcp4 -t prüft eine Konfigurationsdatei, ist aber kein End-to-End-Test für Interfaces, Firewall und Clientverkehr. Mit kea-dhcp4 -V die tatsächliche Version bzw. Buildkonfiguration aufnehmen. Die laufende Dienstdefinition verrät verwendeten Pfad und Benutzer.

memfile hält Leaseinformationen im Speicher und kann sie bei persist=true in Dateien sichern. Das Verzeichnis und seine Rechte müssen zum Dienstbenutzer passen. Eine gesicherte JSON-Datei enthält nicht automatisch die aktuellen Leases. Ein Neustart mit verlorener Lease-Datenbank kann doppelte Vergaben begünstigen.

Linux-Shell · nur Labor-VM
kea-dhcp4 -V
sudo kea-dhcp4 -t /etc/kea/kea-dhcp4.conf
# Unit zuerst auf dem Laborsystem ermitteln:
systemctl list-unit-files '*kea*'
# Beispiel bei Debian-Paketierung:
sudo systemctl restart kea-dhcp4-server
sudo journalctl -u kea-dhcp4-server --since '5 minutes ago'

Subnetz-ID, Pools und Optionen auseinanderhalten

In Kea beschreibt ein subnet4-Eintrag ein verwaltetes IPv4-Subnetz. Seine administrative ID ist keine VLAN-Nummer, die der Client überträgt. Innerhalb dieses Subnetzes beschreiben Pools die dynamisch nutzbaren Mengen; option-data enthält Parameter für Clients. Die Zuordnung einer Anfrage zum richtigen Subnetz muss zuerst funktionieren, bevor eine passende Adresse aus einem Pool gewählt werden kann.

Ein Lückenbereich lässt sich im einfachen Lehrprofil durch zwei getrennte Pools ausdrücken. Für .100–.199 mit ausgesparten .120–.129 sind das .100–.119 und .130–.199. Die Größen sind 20 und 70, zusammen 90. Das ist eine konkrete Konfigurationsentscheidung für dieses Kea-Beispiel und keine Behauptung, jedes Produkt verwalte Ausschlüsse in derselben Form.

Syntaktisch gültig ist noch nicht betriebsbereit

Ein erfolgreicher Konfigurationstest erkennt unterstützte Syntax und bestimmte inhaltliche Fehler. Er beweist nicht, dass der Dienst die vorgesehenen Schnittstellen öffnen kann, der Lease-Speicher beschreibbar ist oder die Relaypakete eintreffen. Nach dem Laden der Konfiguration müssen daher Laufzeitprotokoll und ein tatsächlicher Bezug hinzukommen. Die Prüfschritte werden in der Kea-Laboranleitung mit Versionsbezug getrennt durchgeführt.

Für einen belastbaren Änderungsablauf sicherst du zuerst die vorige Konfiguration, prüfst die neue Datei und beobachtest danach Dienstzustand, Paketantwort und Clientwerte. Bei einem Fehler muss die Rücknahme auch den wirklich geladenen Zustand wiederherstellen. Eine korrigierte Datei auf der Festplatte allein belegt nicht, dass der laufende Prozess sie bereits verwendet. Lease-Daten und Konfigurationsdatei bleiben außerdem verschiedene Bestände.

DURCHGEARBEITETES BEISPIEL

Ausschluss .120–.129 ausdrücken

  1. Ein einzelner Pool .100–.199 würde den gesamten Bereich enthalten.
  2. Statt einer erfundenen Windows-Exclusion-Eigenschaft zwei Pools anlegen: .100–.119 und .130–.199.
  3. Die Gesamtzahl ist 20+70=90. Eine Reservierung .150 vermindert die frei dynamische Menge für andere Clients um eins.
  4. Datei prüfen, Dienstdefinition und Logs kontrollieren, mehrere echte Testclients versorgen. Lease-Datei und Paketoptionen gegen die Planung vergleichen.

Ergebnis: Gültiges JSON allein genügt nicht. Kea-Semantik, Betriebsrechte und echte Vergabe sind getrennte Prüfungen.

Typische Fehler

  • Scope-Cmdlets sind keine Kea-Konfigurationsschlüssel.
  • -t prüft keine echte Clientkommunikation.
  • Ein anderer Paketdienstname ist kein Beweis, dass die dokumentierte Konfiguration falsch ist.

Praktisch anwenden

Offizielle Quellen

Versionsbezüge geprüft am 14. Oktober 2026. Produktkonfigurationen werden im jeweiligen isolierten Labor validiert.