linux:kea

DHCPv4|v6-Server mit DHCP ISC Kea unter Arch Linux einrichten und nutzen

Bild: Logo des DHCP ISC Kea Zum Einsatz in unserer Umgebung wird der Kea DHCP-Server kommen, der Nachfolger des ISC DHCP Servers der Ende 2022 das Ende seines Lebenszyklus erreichte und nicht weiterentwickelt wurde. Das Nachfolgeprodukt ist nun der moderne Open Source DHCPv4 & DHCPv6 Server Kea.

Im wesentlichen unterscheidet sich Kea von seinem Vorgänger unter anderem durch sein modulares Komponenten basierenden Design, welches mit sog. Hooks-Modulen leicht erweiterbar ist. Kea stellt einzelne Daemons zur Verfügung die entweder gemeinsam oder auch getrennt genutzt werden können. So enthält Kea einen Daemon für einen DHCPv4-Server, einen DHCPv6-Server und ein dynamisches Modul für DNS. Die Konfiguration des Kea-Servers erfolgt mit Hilfe einer JSON-Konfigurationsdatei. Mit Hilfe der REST-API können zur Laufzeit jederzeit während des Betriebs Änderungen des Daemons vorgenommen werden, ohne dass der Daemon neu gestartet werden muss. Optional kann beim Kea Server auch ein WEB-UI ein grafisches Dashboard genutzt werden zur Überwachung mehrerer Kea-Instanzen. Neben der Dateibasierenden Variante können die ganzen Konfigurationsoptionen auch optional in einer PostgreSQL oder Maria-mySQL-Datenbank vorgehalten werden.

In der nachfolgenden WIKI-Artikel wollen wir uns nun eingehender mit der Installation und Konfiguration unseres Kea DHCP Servers für für DHCPv4 und DHCPv6 beschäftigen. In dem Konfigurationsbeispiel wird dem Kea-Daemon die Verwaltung und Verteilung der Intranet-Adressen der Zone intra.nausch.org übertragen. Dieses Subnetz umfasst nachfolgende Adressbereiche - zum besseren Verständnis sind in der Tabelle auch exemplarische Hosts mit den entsprechenden Adressen vermerkt:

Subnetz
(ID) 		Subnetz
(Use) 		Subnetz Prefix
(global Unicast) 		Host
- 		IPv4
- 		Link-Local-Scope
(LLA) 		Unique-Local-Scope
(ULA) 		Global-Scope
(GUA)
7 Intra 2003:a:bcd:1234::/64
pml010073 10.0.10.73 fe80::e9a6::bb03:1544:b0000/64 fd00:dead:beef:0:10:0:10:073/64 2003:a:bcd:1234:10:0:10:73
pml010102 10.0.10.102 fe80::10:ff:fe10:102 fdb6:dead:beef:0:10:0:10:102/64 2003:a:bcd:1234:10:0:10:102
vml010110 10.0.10.110 fe80::10:ff:fe10:110 fdb6:dead:beef:0:10:0:10:110/64 2003:a:bcd:1234:10:0:10:110

Grundsätzliches

IPv4 - DHCPv4

Für die Zuweisung der Netzwerkkonfiguration an den Client durch unseren Server bedienen wir uns des DHCP1), DHCP ist eine Ergänzung und Erweiterung von BOOTP2). DHCP wurde im RFC 2131 definiert und bekam von der Internet Assigned Numbers Authority die beiden UDP-Ports 67 und 68 zugewiesen.

Mittels DHCP ist die automatische Einbindung eines neuen Client in unser bestehendes Netzwerk ohne grosse manuelle Konfiguration möglich. Am Client muss daher nur der automatische Bezug der IP-Adresse eingestellt sein. Beim Start des Clients am Netz kann dieser die IP-Adresse, die Netzmaske, das Gateway, DNS-Server und weitere Konfigurationsparameter vom DHCP-Server beziehen. Neben diesen klassischen Parametern zählen hierzu auch die Verwendung einer Reihe von weiteren IP-Variablen, wie z.B.: X-Display- , Time-, Swap-, NIS-Server und die Unterstützung von Vendor-Code-Identifiern zum Einsatz im Bereich PXE3) finden.

Beim Starten eines Clients frägt dieser über einen Broadcast im gesamten Netzwerk nach (s)einer IP-Adresse. Als Antwort auf seinen Broadcast erhält er die beiden wichtigsten Parameter:

  • IP-Adresse
  • Lease-Time

Darüber hinaus können optional noch weitere Parameter mit übergeben werden, wie z.B.:

  • Default-Route
  • Netzmaske
  • DNS-Server-Adressen
  • WINS-Server
  • Broadcast-Adresse
  • IP-Variablen
  • sowie noch weitere Parameter

DHCPv4-Adressvergabe - Detailbetrachtung

Der grundsätzliche Ablauf bei der Adress-Anfrage folgt dabei folgendem Schema. Die Kommunikation zwischen dem Server (Port 67) und dem Clients (Port 68) erfolgte mittels UPD4).

  1. Schritt der DHCP-Adressanfrage - DHCPDISCOVER
    Beim Booten unseres Client-Rechners frägt dieser mit einer DHCPDISCOVER-Nachricht via Broadcast nach seiner Konfiguration. Zu diesem Zeitpunkt besitzt er noch keine eigene IP-Adresse und er kennt auch noch nicht, in welchem Netz er sich befindet. Lediglich seine MAC5)-Adresse seines Netzwerkinterfaces ist ihm bekannt. Aus diesem Grund sendet er ein Broadcastpaket mit der Quelladresse 0.0.0.0 und an die Zieladresse 255.255.255.255.
    ClientServerDHCP4_QUERY_LABELDHCPDISCOVER mit MAC 00:11:22:33:44:55

    2024-07-04 13:23:11.726 INFO  [kea-dhcp4.dhcp4/1023.138852396816064] DHCP4_QUERY_LABEL received query: [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x9788fd77
    Das Label DHCP4_QUERY_LABEL zeigt in dieser Informationsmeldung an, dass eine Abfrage empfangen wurde. Diese Meldung zeigt den Client und die Transaktionskennung an.

    ClientServerDHCP4_PACKET_RECEIVEDDHCPDISCOVER mit MAC 00:11:22:33:44:55
    2024-07-04 13:23:11.726 INFO  [kea-dhcp4.packets/1023.138852396816064] DHCP4_PACKET_RECEIVED [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x9788fd77: DHCPREQUEST (type 3) received from 0.0.0.0 to 255.255.255.255 on interface net1
    Die zweite Meldung mit dem Label DHCP4_PACKET_RECEIVED gibt einen Hinweis, dass der DHCP-Daemon den angegebenen Pakettyp auf der angegebenen Schnittstelle empfangen hat. Das erste Argument gibt die Client- und Transaktionsidentifikationsinformationen an. Das zweite und dritte Argument geben den Namen der DHCPv4-Nachricht bzw. ihren numerischen Typ an. Die übrigen Argumente geben die Quell-IPv4-Adresse, die Ziel-IPv4-Adresse und den Namen der Schnittstelle an, über die die Nachricht empfangen wurde.

    ClientServerDHCP4_INIT_REBOOTDHCPREQUEST Address10.0.10.230
    2024-07-04 13:23:11.726 INFO  [kea-dhcp4.leases/1023.138852396816064] DHCP4_INIT_REBOOT [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x9788fd77: client is in INIT-REBOOT state and requests address 10.0.10.230
    Die Dritte Meldung mit dem Label DHCP4_INIT_REBOOT besagt, dass sich der Client im Zustand INIT-REBOOT befindet und die Zuweisung einer von ihm verwendeten IPv4-Adresse anfordert. Das erste Argument enthält die Client- und Transaktionsidentifikationsinformationen. Das zweite Argument gibt die angeforderte IPv4-Adresse an, die der Client gerne haben würde.

    ClientServerDHCP4_QUERY_LABELDHCPDISCOVER mit MAC 00:11:22:33:44:55

    2024-07-04 13:23:13.726 INFO  [kea-dhcp4.dhcp4/1023.138852413601472] DHCP4_QUERY_LABEL received query: [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x14bc2494
    Das Label DHCP4_QUERY_LABEL zeigt in dieser Informationsmeldung an, dass eine Abfrage empfangen wurde. Diese Meldung zeigt den Client und die Transaktionskennung an.

    ClientServerDHCP4_PACKET_RECEIVEDDHCPDISCOVER mit MAC 00:11:22:33:44:55
    2024-07-04 13:23:13.726 INFO  [kea-dhcp4.packets/1023.138852413601472] DHCP4_PACKET_RECEIVED [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x14bc2494: DHCPDISCOVER (type 1) received from 0.0.0.0 to 255.255.255.255 on interface net1
    Das Label DHCP4_PACKET_RECEIVED zeigt in dieser Meldung an, dass der DHCP-Daemon den angegebenen Pakettyp auf der angegebenen Schnittstelle empfangen hat. Das erste Argument gibt die Client- und Transaktionsidentifikationsinformationen an. Das zweite und dritte Argument geben den Namen der DHCPv4-Nachricht bzw. ihren numerischen Typ an. Die übrigen Argumente geben die Quell-IPv4-Adresse, die Ziel-IPv4-Adresse und den Namen der Schnittstelle an, über die die Nachricht empfangen wurde.

  2. Stufe der DHCP-Adressanfrage - DHCPOFFER
    Dieses Broadcast-Pakete beantwortet nun der DHCP-Server mit einer DHCPOFFER-Nachricht. Das Antwortpaket beinhaltet bereits als Zieladresse die IP, welche der Client in Zukunft bekommen soll. Da bei der vorherigen Anfrage des Clients, dieser seine eigene MAC-Adresse mitschickte, kann nun auf diese Weise die DHCPOFFER-Nachricht ihr Ziel finden.
    ClientServerDHCP4_LEASE_OFFERDHCP4_PACKET_SENDDHCPOFFER mit Address10.0.10.231

    2024-07-04 13:23:13.726 INFO  [kea-dhcp4.leases/1023.138852413601472] DHCP4_LEASE_OFFER [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x14bc2494: lease 10.0.10.231 will be offered
    Diese Informationsmeldung zeigt an, dass der Server eine Lease gefunden hat, die er dem Client anbieten wird. Das erste Argument gibt den Client und die Transaktionskenndaten an. Das zweite Argument gibt die IPv4-Adresse an, die angeboten werden soll. 
    2024-07-04 13:23:13.727 INFO  [kea-dhcp4.packets/1023.138852413601472] DHCP4_PACKET_SEND [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x14bc2494: trying to send packet DHCPOFFER (type 2) from 10.0.10.110:67 to 10.0.10.231:68 on interface net1
    Dies ist eine INFO-Meldung, die besagt, dass der Server versucht, den angegebenen Pakettyp zu senden. Die Argumente geben die Client-Identifikationsinformationen (HW-Adresse und Client-Identifier), den Namen und den Typ der DHCP-Nachricht, die Quell-IPv4-Adresse und den Port, die Ziel-IPv4-Adresse und den Port sowie den Schnittstellennamen an.

  3. Stufe der DHCP-Adressanfrage - DHCPREQUEST
    Die angebotene Adresse wird nun vom Client nochmals explizit angefordert.
    ClientServerDHCP4_QUERY_LABELDHCP4_PACKET_RECEIVEDDHCPREQUEST

    2024-07-04 13:23:13.728 INFO  [kea-dhcp4.dhcp4/1023.138852405208768] DHCP4_QUERY_LABEL received query: [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x14bc2494
    Das Label DHCP4_QUERY_LABEL zeigt in dieser Meldung an, dass eine Abfrage empfangen wurde. Diese Meldung zeigt den Client und die Transaktionskennung an. 
    2024-07-04 13:23:13.728 INFO  [kea-dhcp4.packets/1023.138852405208768] DHCP4_PACKET_RECEIVED [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x14bc2494: DHCPREQUEST (type 3) received from 0.0.0.0 to 255.255.255.255 on interface net1
    Das Label DHCP4_PACKET_RECEIVED zeigt in dieser Meldung an, dass der DHCP-Daemon den angegebenen Pakettyp auf der angegebenen Schnittstelle empfangen hat. Das erste Argument gibt die Client- und Transaktionsidentifikationsinformationen an. Das zweite und dritte Argument geben den Namen der DHCPv4-Nachricht bzw. ihren numerischen Typ an. Die übrigen Argumente geben die Quell-IPv4-Adresse, die Ziel-IPv4-Adresse und den Namen der Schnittstelle an, über die die Nachricht empfangen wurde.

  4. Stufe der DHCP-Adressanfrage - DHCPACK
    Die dem Client angebotene und bestätigte Adresse wird nun vom DHCP-Daemon als belegt gekennzeichnet und dem Client entsprechend mit einem DHCPACK abschliessend bestätigt
    ClientServerDHCP4_LEASE_ALLOCDHCP4_PACKET_SENDDHCPREQUEST

    2024-07-04 13:23:13.728 INFO  [kea-dhcp4.leases/1023.138852405208768] DHCP4_LEASE_ALLOC [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x14bc2494: lease 10.0.10.231 has been allocated for 3600 seconds
    Diese Informationsmeldung zeigt an, dass der Server als Antwort auf die DHCPREQUEST-Nachricht des Clients erfolgreich einen Lease vergeben hat. Die Lease-Informationen werden in der nachfolgenden DHCPACK-Nachricht an den Client gesendet. Das erste Argument enthält den Client und die Transaktionsidentifikationsinformationen. Das zweite Argument enthält die zugewiesene IPv4-Adresse. Das dritte Argument ist die Gültigkeitsdauer. 
    2024-07-04 13:23:13.728 INFO  [kea-dhcp4.packets/1023.138852405208768] DHCP4_PACKET_SEND [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x14bc2494: trying to send packet DHCPACK (type 5) from 10.0.10.110:67 to 10.0.10.231:68 on interface net
    Dies ist eine INFO-Meldung, die besagt, dass der Server versucht, den angegebenen Pakettyp zu senden. Die Argumente geben die Client-Identifikationsinformationen (HW-Adresse und Client-Identifier), den Namen und den Typ der DHCP-Nachricht, die Quell-IPv4-Adresse und den Port, die Ziel-IPv4-Adresse und den Port sowie den Schnittstellennamen an.

Gesamtbetrachtung und Zusammenfassung

Der gesamte erfolgreiche Ablauf aus Sicht des DHCP-Servers entspricht zusammengefasst folgendem Diagramm.

erfolgreiche Ablauf aus Sicht des DHCP-Serverserfolgreiche Ablauf aus Sicht des DHCP-Servers  DHCP - SERVER  DHCP - SERVER  Client  Client (Port 67) DHCPDISCOVERDHCPDISCOVER mitMAC 00:04:13:23:3f:b5DHCPOFFER (Port 68)DHCPOFFER mit Angabeder IP 192.168.10.61an MAC 00:04:13:23:3f:b5(Port 67) DHCPREQUESTDHCPREQUEST mit Angabeder IP 192.168.10.61und MAC 00:04:13:23:3f:b5DHCPACK (Port 68)DHCPACK mit Angabeder IP 192.168.10.61und der MAC 00:04:13:23:3f:b5

Im journald unseres Kea-DHCPv4-Servers wird der Ablauf wie folgt festgehalten: 

2024-07-04 13:23:11.726 INFO  [kea-dhcp4.dhcp4/1023.138852396816064] DHCP4_QUERY_LABEL received query: [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x9788fd77
2024-07-04 13:23:11.726 INFO  [kea-dhcp4.packets/1023.138852396816064] DHCP4_PACKET_RECEIVED [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x9788fd77: DHCPREQUEST (type 3) received from 0.0.0.0 to 255.255.255.255 on interface net1
2024-07-04 13:23:11.726 INFO  [kea-dhcp4.leases/1023.138852396816064] DHCP4_INIT_REBOOT [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x9788fd77: client is in INIT-REBOOT state and requests address 10.0.10.230
2024-07-04 13:23:13.726 INFO  [kea-dhcp4.dhcp4/1023.138852413601472] DHCP4_QUERY_LABEL received query: [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x14bc2494
2024-07-04 13:23:13.726 INFO  [kea-dhcp4.packets/1023.138852413601472] DHCP4_PACKET_RECEIVED [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x14bc2494: DHCPDISCOVER (type 1) received from 0.0.0.0 to 255.255.255.255 on interface net1
2024-07-04 13:23:13.726 INFO  [kea-dhcp4.leases/1023.138852413601472] DHCP4_LEASE_OFFER [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x14bc2494: lease 10.0.10.231 will be offered
2024-07-04 13:23:13.727 INFO  [kea-dhcp4.packets/1023.138852413601472] DHCP4_PACKET_SEND [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x14bc2494: trying to send packet DHCPOFFER (type 2) from 10.0.10.110:67 to 10.0.10.231:68 on interface net1
2024-07-04 13:23:13.728 INFO  [kea-dhcp4.dhcp4/1023.138852405208768] DHCP4_QUERY_LABEL received query: [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x14bc2494
2024-07-04 13:23:13.728 INFO  [kea-dhcp4.packets/1023.138852405208768] DHCP4_PACKET_RECEIVED [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x14bc2494: DHCPREQUEST (type 3) received from 0.0.0.0 to 255.255.255.255 on interface net1
2024-07-04 13:23:13.728 INFO  [kea-dhcp4.leases/1023.138852405208768] DHCP4_LEASE_ALLOC [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x14bc2494: lease 10.0.10.231 has been allocated for 3600 seconds
2024-07-04 13:23:13.728 INFO  [kea-dhcp4.packets/1023.138852405208768] DHCP4_PACKET_SEND [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x14bc2494: trying to send packet DHCPACK (type 5) from 10.0.10.110:67 to 10.0.10.231:68 on interface net1

Sollte die ganze Prozedur Fehl schlagen, z.B. weil der Client herausgefunden hat, dass die IP-Adresse doppelt vergeben ist, sendet er eine DHCPDECLINE-Nachricht an der Server. Diese Meldung wird ausgegeben, wenn ein Client eine Adresse erhalten hat, aber festgestellt hat, dass sie von einem anderen Gerät verwendet wird, und dies dem Server durch Senden einer DHCPDECLINE-Meldung mitgeteilt hat. Der Server prüft, ob diese Adresse wirklich an den Client vermietet wurde, und kennzeichnet diese Adresse für eine bestimmte Zeit als unbrauchbar und die gesamte Vergabeprozedur beginnt erneut von vorne.. Diese Meldung kann auf eine Fehlkonfiguration in einem Netzwerk hinweisen, da entweder ein fehlerhafter Client oder, was wahrscheinlicher ist, ein Gerät eine Adresse verwendet, die es nicht verwenden darf.

Zusammen mit seiner IP-Adresse erhält der Client in der DHCPACK-Nachricht auch eine Lease-Time mitgeteilt, welche ihm mitteilt, wie lange die IP-Adresse für ihn reserviert ist. Im RFC Standard wurde definiert, dass der Client nach der Hälfte der Lease-Time einen erneuten DHCPREQUEST sendet. So teilt er dem Server mit, dass er weiterhin die für ihn reservierte IP-Adresse behalten möchte. Nach Erhalt dieser Nachricht sendet der DHCP-Server eine identische DHCPACK-Nachricht an den Client zurück, in der dann die aktuelle neue Lease-Time mitgeteilt wird. Die IP-Adresse ist somit verlängert und der DCHP-Refresh ist komplett. Sollte der Client es versäumen eine Verlängerung zu beantragen, muss er die Konfiguration des Netzwerkinterfaces verwerfen und der DHCP-Request startet erneut mit einer DHCPDISCOVER-Nachricht.

Beim Herunterfahren eines Client-Hosts kann dieser dem Server mit einer DHCPRELEASE-Nachricht den Server informieren, damit dieser die Adresse wieder freigeben kann. 

Oct 05 14:23:22 vml000110 kea-dhcp4[558]: INFO  [kea-dhcp4.leases.138560182671040] DHCP4_RELEASE [hwtype=1 52:54:00:41:21:12], cid=[ff:5d:e2:6c:15:00:02:00:00:ab:11:6b:87:16:0d:70:5c:ed:6d]>
Oct 05 14:23:22 vml000110 kea-dhcp4[558]: INFO  [kea-dhcp4.leases.138560182671040] DHCP4_RELEASE_EXPIRED [hwtype=1 52:54:00:41:21:12], cid=[ff:5d:e2:6c:15:00:02:00:00:ab:11:6b:87:16:0d:70:5>

Diese Informationsmeldung zeigt an, dass eine Adresse ordnungsgemäss freigegeben wurde. Es handelt sich um einen normalen Vorgang beim Herunterfahren des Clients. Das erste Argument enthält die Client- und Transaktionsidentifikationsinformationen. Das zweite Argument enthält die freigegebene IPv4-Adresse.

Der Client hat aber auch die Möglichkeit, seine zuletzt zugewiesene IP-Adresse über den Reboot hinweg zu „merken“. Dies kann z.B. dann der Fall sein, wenn die Lease-Time, noch nicht abgelaufen ist, oder dem Client eine feste IP-Adresse zugeteilt wurde. Dann entfallen die Initialisierungsschritte und der Client schickt direkt eine DHCPREQUEST-Nachricht an den DHCP-Server. Dieser bestätigt entweder die Anfrage oder sendet eine DHCPNAK-Nachricht um dem Client mitzuteilen, dass dieser seine gespeicherten Konfigurationen zu löschen, und die Anfrage komplett von vorne zu beginnen hat. 

Oct 18 14:20:27 vml000110 kea-dhcp4[16237]: INFO  [kea-dhcp4.packets.136432101570240] DHCP4_PACKET_RECEIVED [hwtype=1 00:03:c5:0e:0e:20], cid=[01:00:03:c5:0e:0e:20], tid=0x96de036a: DHCPREQUEST (type 3) received from 10.0.10.31 to 10.0.10.110 on interface net

IPv6 - DHCPv6

DHCPv6-Adressvergabe

Ein Stateful DHCPv6-Server liefert neben IPv6-Adressen auch weitere Informationen, wie z.B. wie eine DNS-Serverliste und einen Domänennamen, an einen Host aus. Hosts. Dieser Stateful DHCPv6-Server behält auch den Status jeder Zuweisung im Auge, sprich er verfolgt die Verfügbarkeit des Adresspools und löst doppelte Adresskonflikte auf. Darüber hinaus protokolliert er jede Zuweisung und behält die Ablaufzeiten im Auge. Im Gegensatz zu IPv4 stellt ein Stateful DHCPv6-Server den Hosts keine Standard-Gateway-Adressen zur Verfügung, das kann bei IPv6 nur Router, die Router Advertisement-Nachrichten sendet wie z.B. unser radvd!

Im Kapitel Router Advertisement ICMPv6-Nachrichten für Stateful DHCPv6 haben wir uns bereits eingehend mit der Definition und Konfiguration der Router Advertisement Meldungen auseinander gesetzt.

In den RA6)-Meldungen muss also drei Flags entsprechend gesetzt seingesetzt sein:

  • M-Flag:
    AdvManagedFlag = on (Adresskonfiguration via Stateful DHCPv6)
  • O-Flag:
    AdvOtherConfigFlag = on (Abrufen einer DNS-Serverliste und einen Domain-Namen von einem Stateless DHCPv6-Server, aber keine keine Adressierungsinformationen.
  • A-Flag:
    AdvAutonomous = off (Adresskonfiguration via Statful DHCPv6)

Nachfolgendes Schaubild fasst den grundlegenden Ablauf bei Stateful DHCPv6 zusammen:

erfolgreiche Ablauf aus Sicht des Clients bei der Kommunikation mit dem RADV-/DHCPv6-Serverserfolgreiche Ablauf aus Sicht des Clients bei der Kommunikation mit dem RADV-/DHCPv6-Servers  RADV - SERVER/DAEMON  RADV - SERVER/DAEMON  Client / Host  Client / Host  DHCPv6 - SERVER/DAEMON  DHCPv6 - SERVER/DAEMON (Port 547) ROUTER SOLICITATION1. Der Hosts erkundigt sich mit einerRouter Solicitation-Nachrichtennach Routern auf einerangeschlossenen Verbindung.UNSOLICATED ROUTER ADVERTISEMENTS (Port 546)2. Der Router gibt seine Anwesenheitzusammen mit verschiedenen Verbindungs-und Internet-Parametern als Antwort auf eineRouter-Solicitation-Nachricht bekannt.(Port 547) SOLICIT an alle Router/DHCPv6 Server3. Der Host fordert mit dieser NachrichtRouter Advertisements sofort undnicht erst zum nächsten geplantenZeitpunkt zu senden.SOLICITED ROUTER ADVERTISEMENTS (Port 546)4. Der Router sendet gezielt an den anfragendenHost die zugehörigen Verbindungs- und Inter-net-Parameter.REQUEST bzw. INFORMATION REQUEST Unicast (Port 547)5. Der Client sendet eine DHCPv6 SOLICIT-Nachrichtan die all-dhcpv6-servers Multicast-GruppeFF02::1:2 und sucht so nach (s)einem DHCP-Server.(Port 546) Antwort mit REQUESTED INFORMATION Unicast6. Bei DHCPv6 antwortet der Serverund teilt dem Client die ange-forderten Parameter mit.DHCPv6-ADVERTISE Unicast (Port 547)7. Bei DHCPv6 frägt der Client beim betreffendenDHCPv6-Server nach der IP-Adresse und ggf.weiteren Parametern wie DNS oder Search--Listen.(Port 546) Antwort mit REPLY INFORMATION Unicast8. Bei DHCPv6 antwortet der Serverund teilt dem Client die ange-forderten Parameter mit. 9. Der Client sendet eine DuplicateAddress Detection für die empfan-gene UA- und GUA-Adressedurch, um sicherzustellen, dassdiese auch eindeutig sind.

Im Detail sind das folgende nacheinander folgende Schritte:

  1. Der Hosts erkundigt sich mit einerRouter Solicitation-Nachrichtennach Routern auf einerangeschlossenen Verbindung, in dem er eine Router-Solicitation-Nachricht an die All-Router-Multicast-Adresse FF02::2 sendet.
  2. Der Router generiert eine gibt eine Router-Advertisement-Nachricht, bei der jeweils das M-Flag = on und das A-Flag auf off gesetzt ist. Ferner reichert er diese RA-Nachricht noch um Verbindungs-Parameter wie Default-Routen an. Diese RA-Nachrichten wird an die All-Nodes-Multicast-Gruppe FF02::1 gesendet und von allen Nachbarn auf einem lokalen Segment empfangen.
  3. Der Host fordert mit dieser NachrichtRouter Advertisements sofort und nicht erst zum nächsten geplanten Zeitpunkt zu senden.
  4. Der Router sendet gezielt an den anfragenden Host die zugehörigen Verbindungs- und Internet-Parameter. Nach dem Empfang des Route Advertisements setzt Client die Quell-IPv6-Adresse von Router FE80::1 als Standardgateway. Da das A-Flag auf off gesetzt ist, führt der Client keine Stateless Address Auto-Configuration (SLAAC) durch.
  5. Da in der RA-Nachricht das M-Flag auf on gesetzt ist, sendet der Client eine DHCPv6 SOLICIT-Nachricht an die all-dhcpv6-servers Multicast-Gruppe FF02::1:2 und sucht so nach (s)einem DHCP-Server.
  6. Nach Erhalt der Solicit-Nachricht antwortet der Server mit einer DHCPv6-ADVERTISE-Nachricht. Sie ist direkt als Unicast an die link-local-Adresse des Clients gerichtet.
  7. Der Client weiss nun, dass es einen DHCPv6-Daemon im Netzwerk gibt und sendet ein REQUEST-Paket an den DHCPv6-Daemon und bitten so um entsprechende Adressierungsinformationen.
  8. Nach dem Empfang des REQUEST-Pakets antwortet der Server mit einem DHCPv6 REPLY-Paket, welches u.a. die globale Unicast-Adresse und alle weiteren Informationen enthält.
  9. Am Ende führt der Client dann noch eine DAD7) für die empfangene LUA- und GUA-Adresse durch, um sicherzustellen, dass diese auch eindeutig sind.

Installation und Konfiguration des Kea-DHCP-Servers

Dokumentation

Eine ausführliche Onlinedokumentation des modernen Open Source DHCPv4 & DHCPv6 Server Kea findet sich auf der entsprechenden Dokumentationsseite bei Read the Docs → https://kea.readthedocs.io/en/latest/ .

Paketinstallation

Die Installation und Konfiguration des DHCP-Servers gestaltet sich relativ einfach. Bei der Installation des Kea-Paketes verwenden wir unter Arch Linux den Paketmanager pacman.

  1. Als User: 
     $ sudo pacman -S kea
  2. Als Nutzer mit Root-Rechten entsprechend: 
     # pacman -S kea

Was uns das Paket kea alles in das System unseres Arch Linux Server gebracht hat, können wir wie folgt abfragen: 

 # pacman -Qil kea

Paketinhalte

Grund-Konfiguration

Firewall/Paketfilter - firewalld

Bevor wir nun unseren Kea-DHCP-Daemon konfigurieren und starten müssen wir natürlich sicherstellen, dass auf dem betreffendem Host auch die Kommunikationsbeziehungen entsprechend erlaubt sind.

Wie auch schon früher bei CentOS ab Release 7 bzw. den nachfolgenden Relaese-Kandidaten Stream von RHEL nutzen wir auch unter Arch Linux den dynamischen firewalld Service. Ein grosser Vorteil der dynamischen Paketfilterregeln ist unter anderem, dass zur Aktivierung der neuen Firewall-Regel(n) nicht der Daemon durchgestartet werden muss und somit alle aktiven Verbindungen kurz getrennt werden. Sondern unsere Änderungen können on-the-fly aktiviert oder auch wieder deaktiviert werden.

In folgendem Konfigurationsbeispiel gehen wir von einem Host aus, der zwei Firewall-Zonen hält, einmal die Zone idmz und einmal die Zone intra. Nur in der Zone intra sollen später die beiden DHCP-Daemon kea-dhcp4 und kea-dhcp6 Anfragen von Clients entsprechend beantworten.

Damit unsere Clients Verbindungen zu dem geöffneten dhcpv4-Port 67/udp und dhcpv6-server-Port 547/udp der beiden zugehörigen Kea-Daemons aufbauen können, müssen wir für diese noch Änderungen am Paketfilter firewalld vornehmen.

Mit Hilfe des Programms firewall-cmd legen wir nun eine permanente Regel in der Zone intra an. Genug der Vorrede, mit nachfolgendem Befehl werden die Ports für den Service dhcp geöffnet. 

 # firewall-cmd --permanent --zone=intra --add-service=dhcp
success

Das Gleiche machen wir nun noch für den Service dhcpv6 

 # firewall-cmd --permanent --zone=intra --add-service=dhcpv6
success

Anschliessend können wir den Firewall-Daemon einmal neu laden und überprüfen, ob die Regeln auch entsprechend unserer Definition, gezogen haben. 

 # firewall-cmd --reload
success

Werfen wir noch kurz einen Blick in die Zone intra: 

 # firewall-cmd --zone=intra --list-services
dhcp dhcpv6

automatischer Start des Daemon

Damit die beiden Daemon kea-dhcp4 und kea-dhcp6 automatisch bei jedem Systemstart startet, kann die Einrichtung eines Start-Scriptes über folgenden Befehl erreicht werden: 

 # systemctl enable kea-dhcp4.service kea-dhcp6.service
Created symlink '/etc/systemd/system/multi-user.target.wants/kea-dhcp4.service' → '/usr/lib/systemd/system/kea-dhcp4.service'.
Created symlink '/etc/systemd/system/multi-user.target.wants/kea-dhcp6.service' → '/usr/lib/systemd/system/kea-dhcp6.service'.

Ein Überprüfung ob die beiden Dienste (Daemon) kea-dhcp4 und kea-dhcp6 wirklich bei jedem Systemstart automatisch mit gestartet wird, kann durch folgenden Befehl erreicht werden: 

 # systemctl is-enabled kea-dhcp4.service kea-dhcp6.service
enabled
enabled

Starten werden wir ddie beiden Deamon kea-dhcp4 und kea-dhcp6aber erst einmal noch nicht, da wir diesen ja noch konfigurieren müssen. Nachfolgend werden wir noch detailliert zu einzelnen Anwendungsfällen eingehen:

  1. DHCPv4 Server für statische und dynamische IPv4-Adressen
  2. Stateful DHCPv6 Server

Konfiguration

Die Konfiguration unseres DHCPv4 und DHCPv6-Servers wie auch des Controll-Agenten und ggf. des Kea DHCP DDNS Daemaons erfolgt über JSON-Konfigurationsdateien im Verzeichnis /etc/kea/.

DHCPv4 Server

Zunächst wollen wir uns eingehend mit der Konfiguration unseres DHCPv4-Daemons befassen. Die zugehörige Original-Dokumentation findet sich im Abschnitt 8.2. DHCPv4 Server Configuration.

Konfigurationsoptionen für unseren DHCPv4-Daemon

In unserer Betriebsumgebung haben wir folgende Rahmenbedingungen für unseren DHCPv4-Server:

  • Netzwerkinterface :
    Unser DHCPv4-Daemon soll auf den beiden Netzwerkinterfaces net0 (idmz) und net1 (intra) auf entsprechende Adressanfragen lauschen und entsprechend Adressen ausliefern.
  • Management API :
    Die Verwaltungs-API ermöglicht die Ausgabe spezifischer Verwaltungsbefehle, wie z. B. das Abrufen von Statistiken, die Neukonfiguration oder das Herunterfahren. Die API soll unter dem socket-type = unix der unter dem Link socket-name = /var/lib/kea/kea4-ctrl-socket erreichbar sein.
  • Leases :
    In unserer Beispielumgebung sollen die Leases unserer Clients in der Datei /var/lib/kea/dhcp4.leases vorgehalten werden. Optional wäre auch die Speicherung in einer MariaDB bzw. mySQL-Datenbank oder in einer PostgreSQL-Datenbank denkbar. Aber im ersten Schritt wollen wir uns mal mit einer Ablage in einer Datei begnügen. Die Lease-Time soll eine Stunde, also 3600 Sekunden gelten. Nach 90% der max. Lease-Time soll der Daemon sein Lease-File aufräumen LFC8) durchführt werden, also nach 3200 Sekunden lfc-interval. Dadurch werden redundante (historische) Informationen aus der Lease-Datei entfernt und die Grösse der Lease-Datei effektiv reduziert. Gibt es beim Laden des Lease-Files Fehler, soll der Server nach 100 Fehlern abbrechen und aufhören, zu versuchen die Lease-Datei zu laden.
  • Lease Reclamation :
    Bei der Lease Reclamation, also der Rückforderung von Leases, bei dem abgelaufene Leases zurückgefordert und so anderen Clients wieder zur Verfügung gestellt werden. Hier übernehmen wir die vorgegebenen Default-Wertev von reclaim-timer-wait-time mit 10, flush-reclaimed-timer-wait-time vomn 25, hold-reclaimed-time von 3600, max-reclaim-leases von 100, max-reclaim-time von 250 und unwarned-reclaim-cycles von 5.
  • Lease-Timer :
    Leases sollen eine Stunde, also valid-lifetime von 3600 Sekunden gelten. Nach 1800 Sekunden - das ist die 1/2 der valid-lifetime sollen die Clients nach einer Verlängerung der Lease fragen, also setzen wir renew-timer = 1800. Die Clients sollen zusätzlich alle erreichbaren DHCP-Server fragen, ob die Lease noch einmal verlängert werden kann und dies nach 90% der valid-lifetime, also setzen wir rebind-timer = 3200.
  • Logging :
    Da wir ein zentrales Logging und Auswertung mit Hilfe von Graylog einsetzen, lassen wir den DHCP4-Daemon kein eigenes Logfile schreiben sondern nutzen unser zentrales syslog, welches der systemd-journald.service in unser Journal schreibt. Hierzu setzen wir die nötigen Parameter wie folgt: name gleich kea-dhcp4, output auf syslog, die severity gleich INFO und den debuglevel auf 0.
  • Name-Server :
    Der interne DNS-Daemon ist unter der IP-Adresse 10.0.0.27 erreichbar.
  • Domain-Name :
    Der Name unserer Domain lautet nausch.org.
  • Domain-Search-Liste :
    Auf Domain-Search-Listen wird bewusst verzichtet, da diese ein Anachronismus aus den Anfangszeiten des DNS sind und gerne alle Arten von Sicherheits- und Konfigurationsproblemen (DNSSEC, DNS64, QName-Minimization, DNS-Leakage von internen Konfigurationsdaten) erzeugen.
  • Time-Server :
    Der interne Time-Server ist unter der IP-Adresse 10.0.0.17 erreichbar.
  • Subnetz :
    Der DHCPv4-Server ist verantwortlich für das Sub-Netz 10.0.10.0/24 der Zone intra
    • Router :
      Der Default-Router ist für dieses Subnetz unter der IP-Adresse 10.0.10.110 erreichbar.
    • Time-Server :
      Der interne Time-Server ist bei diesem Subnetz unter der IP-Adresse 10.0.10.110 erreichbar.
    • Name-Server :
      Der interne DNS-Daemon ist unter der IP-Adresse 10.0.10.110 in diesem Subnetz erreichbar.
    • Pool (dynamischer Adress-Bereich) :
      Dynamische IP-Adressen sollen aus dem Bereich von 10.0.10.230 - 10.0.10.250 vergeben werden.
    • Reservierungen :
      Einige Hosts bekommen eine feste IP-Adresse, die der DHCP-Server an Hand der übermittelten MAC-Adresse der Netzwerkschnittstelle vergeben wird.
  • Subnetz :
    Der DHCPv4-Server ist verantwortlich für das Sub-Netz 10.0.0.0/24 der Zone idmz
    • Router :
      Der Default-Router ist für dieses Subnetz unter der IP-Adresse 10.0.0.210 erreichbar.
    • Time-Server :
      Der interne Time-Server ist bei diesem Subnetz unter der IP-Adresse 10.0.0.110 erreichbar.
    • Name-Server :
      Der interne DNS-Daemon ist unter der IP-Adresse 10.0.0.110 in diesem Subnetz erreichbar.
    • Pool (dynamischer Adress-Bereich) :
      Da die IPv4-Adressen in der Zone idmz ausschließlich per Ansible statisch vergeben werden, gibt es hier keinen dynamischen Adresspool!
    • Reservierungen :
      Einige Hosts bekommen eine feste IP-Adresse, die der DHCP-Server an Hand der übermittelten MAC-Adresse der Netzwerkschnittstelle vergeben wird.

Konfigurationsdatei /etc/kea-dhcp4.conf

Bei der Installation unseres Kea-Servers wurde uns eine entsprechende Musterkonfigurations-Datei bereits mitgeliefert. 

 # less /etc/kea/kea-dhcp4.conf

/etc/kea/kea-dhcp4.conf

Bevor wir nun aber unseren Kea-DHCPv4-Daemon individuell nach unseren Bedürfnissen hin anpassen, werden wir zunächst die im Paket mitgelieferte Original-Konfigurationsdatei /etc/kea/kea-dhcp4.conf für spätere Referenzen sichern. 

 # cp -a /etc/kea/kea-dhcp4.conf /etc/kea/kea-dhcp4.conf.orig

So können wir später bei etwaigen Bedarf Vergleiche zur originalen Konfigurationsdatei mit einer neuen Version bei einem Update des KEA-Paketes anstreben, wie in diesem Beispiel hier: 

 # vimdiff /etc/kea/kea-dhcp4.conf.orig /etc/kea/kea-dhcp4.conf.pacnew

Bild: Bildschirmharcopy des Aufgrufes 'vimdiff /etc/kea/kea-dhcp4.conf.orig /etc/kea/kea-dhcp4.conf.pacnew'

Aus den oben genannten Konfigurationsparametern erstellen wir uns nun eine entsprechende Konfigurationsdatei /etc/kea/kea-dhcp4.conf für unseren Kea-DHCPv4-Daemon. 

 # vim /etc/kea/kea-dhcp4.conf
/etc/kea/kea-dhcp4.conf
// This is a basic configuration for the Kea DHCPv4 server. See section
// 8.2. DHCPv4 Server Configuration for detailed informations.
//
// This configuration file contains only DHCPv4 server's configuration.
// If configurations for other Kea services are also included in this file they
// are ignored by the DHCPv4 server.
{
 
// DHCPv4 configuration starts here. This section will be read by DHCPv4 server
// and will be ignored by other components.
"Dhcp4": {
    // See section 8.2.4 Interface Configuration for more details.
    "interfaces-config": {
        "interfaces": [ "net0", "net1" ],
        "dhcp-socket-type": "raw"
    },
 
    // See section 8.9. Management API for the DHCPv4 Server for more details.
    "control-socket": {
        "socket-type": "unix",
        "socket-name": "/var/lib/kea/kea4-ctrl-socket"
    },
 
    // See Section 8.2.2.1. Memfile - Basic Storage for Leases" for details.
    "lease-database": {
        "type": "memfile",
        "persist": true,
        "name": "/var/lib/kea/kea-leases4.csv",
        "lfc-interval": 3240,
        "max-row-errors": 100
    },
 
    // Setup reclamation of the expired leases and leases affinity.
    // See section 11. Lease Expiration for more and detailed informations.
    "expired-leases-processing": {
        "reclaim-timer-wait-time": 10,
        "flush-reclaimed-timer-wait-time": 25,
        "hold-reclaimed-time": 3600,
        "max-reclaim-leases": 100,
        "max-reclaim-time": 250,
        "unwarned-reclaim-cycles": 5
    },
 
    // Global timers specified here apply to all subnets, unless there are
    // subnet specific values defined in particular subnets. See section
    // 8.2.1. Introduction ans section 8.2.9. Sending T1 (Option 58) and T2 
    // (Option 59) for details. 
    "renew-timer": 1800,
    "rebind-timer": 3200,
    "valid-lifetime": 3600,
 
    // Many additional parameters can be specified here. Alle datails will be
    // found in following sections:
    // - 8.2.10. Standard DHCPv4 Options
    // - 8.2.11. Custom DHCPv4 Options
    // - 8.2.12. DHCPv4 Private Options 
    // - 8.2.13. DHCPv4 Vendor-Specific Options
    // - 8.2.14. Nested DHCPv4 Options (Custom Option Spaces) 
    // - 8.2.15. Unspecified Parameters for DHCPv4 Option Configuration
    // - 8.2.16. Support for Long Options
    "option-data": [
        // Domain-Name-Server:
        //{
        //    "name": "domain-name-servers",
        //    "data": "10.0.10.27"
        //},
 
        // Domain-Name:
        {
            "name": "domain-name",
            "data": "nausch.org"
        },
 
        // Time-Server:
        //{
        //    "name": "ntp-servers",
        //    "data": "10.0.0.17"
        //},
 
        // Time-Offset ( Eastern Standard Time):
        {
            "name": "time-offset",
            "data": "-18000"
        }
    ],
 
    // Finally, we list the subnets from which we will be leasing addresses.
    // See section 8.2.6. IPv4 Subnet Identifier and the following sections
    // for more details.
    "subnet4": [
        {
            // This defines the whole subnet. Kea will use this information to
            // determine where the clients are connected. This is the whole
            // subnet in your network.
 
            // Subnet identifier should be unique for each subnet.
            "id": 1,
 
            // This is mandatory parameter for each subnet.
            "subnet": "10.0.10.0/24",
 
            // Pools define the actual part of your subnet that is governed
            // by Kea.
            "pools": [ { "pool": "10.0.10.230 - 10.0.10.250" } ],
 
            // These are options that are subnet specific.
            "option-data": [
                {
                    // Router for the IPv4 subnet.
                    "name": "routers",
                    "data": "10.0.10.110"
                },
 
                { 
                    // Time-Server:
                    "name": "ntp-servers",
                    "data": "10.0.10.110"
                },
 
                {
                    // Domain-Name-Server:
                    "name": "domain-name-servers",
                    "data": "10.0.10.27"
                }
 
            ],
 
            // Kea offers host reservations mechanism. Kea supports reservations
            // by several different types of identifiers: hw-address
            // (hardware/MAC address of the client), duid (DUID inserted by the
            // client), client-id (client identifier inserted by the client) and
            // circuit-id (circuit identifier inserted by the relay agent).
            "reservations": [
 
                // This are the reservations for a specific hardware/MAC addresses.
                // MNSS (c7)
                {
                    "hw-address": "ac:1f:6b:00:d3:9a",
                    "ip-address": "10.0.10.2",
                    "hostname": "pml010002.intra.nausch.org"
                },
 
                // MNSS-IPMI (C7)
                {
                    "hw-address": "00:25:90:13:ba:a2",
                    "ip-address": "10.0.10.3",
                    "hostname": "pnc010003.intra.nausch.org"
                }              
            ],
            "reservations": [
 
                // This are the reservations for a specific hardware/MAC addresses.
                // vml000200 
                {
                    "hw-address": "52:54:00:41:20:01",
                    "ip-address": "10.0.0.200",
                    "hostname": "vml000200.dmz.nausch.org"
                },
 
                // vml000201
                {
                    "hw-address": "52:54:00:41:20:11",
                    "ip-address": "10.0.0.201",
                    "hostname": "vml000201.dmz.nausch.org"
                },
 
                // vml000202
                {
                    "hw-address": "52:54:00:41:20:21",
                    "ip-address": "10.0.0.202",
                    "hostname": "vml000202.dmz.nausch.org"
                },
 
                // vml000203
                {
                    "hw-address": "52:54:00:41:20:31",
                    "ip-address": "10.0.0.203",
                    "hostname": "vml000203.dmz.nausch.org"
                },
 
                // vml000204
                {
                    "hw-address": "52:54:00:41:20:41",
                    "ip-address": "10.0.0.204",
                    "hostname": "vml000204.dmz.nausch.org"
                }
            ]
        }
    ],
 
    // Logging configuration starts here. Kea uses different loggers to log various
    // activities. For details (e.g. names of loggers), see Chapter 18.
    "loggers": [
    {
        // This section affects kea-dhcp4, which is the base logger for DHCPv4
        // component. It tells DHCPv4 server to write all log messages (on
        // severity INFO or more) to a file.
        "name": "kea-dhcp4",
        "output_options": [
            {
                // Specifies the output file. There are several special values
                // supported:
                // - stdout (prints on standard output)
                // - stderr (prints on standard error)
                // - syslog (logs to syslog)
                // - syslog:name (logs to syslog using specified name)
                // Any other value is considered a name of the file
                "output": "syslog"
            }
        ],
        // This specifies the severity of log messages to keep. Supported values
        // are: FATAL, ERROR, WARN, INFO, DEBUG
        "severity": "INFO",
 
        // If DEBUG level is specified, this value is used. 0 is least verbose,
        // 99 is most verbose. Be cautious, Kea can generate lots and lots
        // of logs if told to do so.
        "debuglevel": 0
    }
  ]
}
}

Wollen wir die Kondfigurationsdate ohne die Kommentare sehen, grep'en wir einfach entsprechend danach. 

 # grep -Ev '(^.*//|^$)' /etc/kea/kea-dhcp4.conf

Beispielkonfigurationsdatei ohne Kommentare

Bevor wir nun unseren kea-dhcp4 starten, führen wir noch einen Konfigurationstest durch. Wir prüfen also nun die Konfigurationsdatei unseres kea-dhcp4 auf syntaktische Fehler. 

 # kea-dhcp4 -t /etc/kea/kea-dhcp4.conf
2024-07-04 17:23:55.327 INFO  [kea-dhcp4.hosts/1913.135232873002112] HOSTS_BACKENDS_REGISTERED the following host backend types are available: mysql postgresql 
2024-07-04 17:23:55.328 WARN  [kea-dhcp4.dhcpsrv/1913.135232873002112] DHCPSRV_MT_DISABLED_QUEUE_CONTROL disabling dhcp queue control when multi-threading is enabled.
2024-07-04 17:23:55.328 WARN  [kea-dhcp4.dhcp4/1913.135232873002112] DHCP4_RESERVATIONS_LOOKUP_FIRST_ENABLED Multi-threading is enabled and host reservations lookup is always performed first.
2024-07-04 17:23:55.328 INFO  [kea-dhcp4.dhcpsrv/1913.135232873002112] DHCPSRV_CFGMGR_NEW_SUBNET4 a new subnet has been added to configuration: 10.0.10.0/24 with params: t1=1800, t2=3200, valid-lifetime=3600
2024-07-04 17:23:55.330 INFO  [kea-dhcp4.dhcpsrv/1913.135232873002112] DHCPSRV_CFGMGR_NEW_SUBNET4 a new subnet has been added to configuration: 10.0.0.0/24 with params: t1=1800, t2=3200, valid-lifetime=3600
2024-07-04 17:23:55.330 INFO  [kea-dhcp4.dhcpsrv/1913.135232873002112] DHCPSRV_CFGMGR_SOCKET_TYPE_SELECT using socket type raw
2024-07-04 17:23:55.330 INFO  [kea-dhcp4.dhcpsrv/1913.135232873002112] DHCPSRV_CFGMGR_SOCKET_TYPE_SELECT using socket type raw
2024-07-04 17:23:55.331 INFO  [kea-dhcp4.dhcpsrv/1913.135232873002112] DHCPSRV_CFGMGR_ADD_IFACE listening on interface net0
2024-07-04 17:23:55.331 INFO  [kea-dhcp4.dhcpsrv/1913.135232873002112] DHCPSRV_CFGMGR_ADD_IFACE listening on interface net1

Start des kea-dhcp4

Nun können wir beruhigt und guten Mutes unseren kea-dhcp4 Daemon starten. 

 # systemctl start kea-dhcp4.service

Im Journal wir der Start entsprechend dokumentiert. 

Jul 04 17:25:35 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.commands.136533820646528] COMMAND_ACCEPTOR_START Starting to accept connections via unix domain socket bound to /var/lib/kea/kea4-ctrl-socket
Jul 04 17:25:35 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.dhcp4.136533820646528] DHCP4_CONFIG_COMPLETE DHCPv4 server has completed configuration: added IPv4 subnets: 2; DDNS: disabled
Jul 04 17:25:35 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.dhcpsrv.136533820646528] DHCPSRV_MEMFILE_DB opening memory file lease database: lfc-interval=3240 max-row-errors=100 name=/var/lib/kea/kea-leases4.csv persist=true type=memfile universe=4
Jul 04 17:25:35 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.dhcpsrv.136533820646528] DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file /var/lib/kea/kea-leases4.csv
Jul 04 17:25:35 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.dhcpsrv.136533820646528] DHCPSRV_MEMFILE_EXTRACT_EXTENDED_INFO4 extracting extended info saw 0 leases, extended info sanity checks modified 0 / updated 0 leases and 0 leases have relay or remote id
Jul 04 17:25:35 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.dhcpsrv.136533820646528] DHCPSRV_MEMFILE_LFC_SETUP setting up the Lease File Cleanup interval to 3240 sec
Jul 04 17:25:35 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.dhcpsrv.136533820646528] DHCPSRV_CFGMGR_USE_ALLOCATOR using the iterative allocator for V4 leases in subnet 10.0.10.0/24
Jul 04 17:25:35 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.dhcpsrv.136533820646528] DHCPSRV_CFGMGR_USE_ALLOCATOR using the iterative allocator for V4 leases in subnet 10.0.0.0/24
Jul 04 17:25:35 vml000110 kea-dhcp4[1955]: WARN  [kea-dhcp4.dhcp4.136533820646528] DHCP4_MULTI_THREADING_INFO enabled: yes, number of threads: 4, queue size: 64
Jul 04 17:25:35 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.dhcp4.136533820646528] DHCP4_STARTED Kea DHCPv4 server version 2.6.0 started

Bei Bedarf können wir natürlich auch den Status unseres Daemons jederzeit abfragen. 

 # systemctl status kea-dhcp4.service

● kea-dhcp4.service - ISC Kea IPv4 DHCP daemon
     Loaded: loaded (/usr/lib/systemd/system/kea-dhcp4.service; disabled; preset: disabled)
   Active:active (running) since Thu 2024-07-04 17:25:35 CEST; 1min 59s ago
 Invocation: eb623acd23f840859c8bd34084dd4e82
       Docs: man:kea-dhcp4(8)
   Main PID: 1955 (kea-dhcp4)
      Tasks: 9 (limit: 9510)
     Memory: 3M (peak: 3.7M)
        CPU: 61ms
     CGroup: /system.slice/kea-dhcp4.service
             └─1955 /usr/bin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf

Jul 04 17:25:35 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.commands.136533820646528] COMMAND_ACCEPTOR_START Starting to accept connections via unix domain socket bound to /var/lib/kea/kea4-ctrl-socket
Jul 04 17:25:35 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.dhcp4.136533820646528] DHCP4_CONFIG_COMPLETE DHCPv4 server has completed configuration: added IPv4 subnets: 2; DDNS: disabled
Jul 04 17:25:35 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.dhcpsrv.136533820646528] DHCPSRV_MEMFILE_DB opening memory file lease database: lfc-interval=3240 max-row-errors=100 name=/var/lib/kea/kea-leases4.csv >
Jul 04 17:25:35 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.dhcpsrv.136533820646528] DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file /var/lib/kea/kea-leases4.csv
Jul 04 17:25:35 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.dhcpsrv.136533820646528] DHCPSRV_MEMFILE_EXTRACT_EXTENDED_INFO4 extracting extended info saw 0 leases, extended info sanity checks modified 0 / updated>
Jul 04 17:25:35 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.dhcpsrv.136533820646528] DHCPSRV_MEMFILE_LFC_SETUP setting up the Lease File Cleanup interval to 3240 sec
Jul 04 17:25:35 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.dhcpsrv.136533820646528] DHCPSRV_CFGMGR_USE_ALLOCATOR using the iterative allocator for V4 leases in subnet 10.0.10.0/24
Jul 04 17:25:35 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.dhcpsrv.136533820646528] DHCPSRV_CFGMGR_USE_ALLOCATOR using the iterative allocator for V4 leases in subnet 10.0.0.0/24
Jul 04 17:25:35 vml000110 kea-dhcp4[1955]: WARN  [kea-dhcp4.dhcp4.136533820646528] DHCP4_MULTI_THREADING_INFO enabled: yes, number of threads: 4, queue size: 64
Jul 04 17:25:35 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.dhcp4.136533820646528] DHCP4_STARTED Kea DHCPv4 server version 2.6.0 started

Verbindet sich nun ein uns unbekannter Host und kontaktiert unseren kea-dhcp4-Daemon wird der erfolgreiche Handshake im Journal protokolliert. 

 # journalctl -fu kea-dhcp4
Jul 04 17:45:55 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.dhcp4.136533786449600] DHCP4_QUERY_LABEL received query: [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0xa7b514ea
Jul 04 17:45:55 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.packets.136533786449600] DHCP4_PACKET_RECEIVED [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0xa7b514ea: DHCPREQUEST (type 3) received from 0.0.0.0 to 255.255.255.255 on interface net1
Jul 04 17:45:55 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.leases.136533786449600] DHCP4_INIT_REBOOT [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0xa7b514ea: client is in INIT-REBOOT state and requests address 10.0.10.231
Jul 04 17:45:57 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.dhcp4.136533778056896] DHCP4_QUERY_LABEL received query: [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x4f87482f
Jul 04 17:45:57 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.packets.136533778056896] DHCP4_PACKET_RECEIVED [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x4f87482f: DHCPDISCOVER (type 1) received from 0.0.0.0 to 255.255.255.255 on interface net1
Jul 04 17:45:57 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.leases.136533778056896] DHCP4_LEASE_OFFER [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x4f87482f: lease 10.0.10.231 will be offered
Jul 04 17:45:57 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.packets.136533778056896] DHCP4_PACKET_SEND [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x4f87482f: trying to send packet DHCPOFFER (type 2) from 10.0.10.110:67 to 10.0.10.231:68 on interface net1
Jul 04 17:45:57 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.dhcp4.136533761271488] DHCP4_QUERY_LABEL received query: [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x4f87482f
Jul 04 17:45:57 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.packets.136533761271488] DHCP4_PACKET_RECEIVED [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x4f87482f: DHCPREQUEST (type 3) received from 0.0.0.0 to 255.255.255.255 on interface net1
Jul 04 17:45:57 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.leases.136533761271488] DHCP4_LEASE_ALLOC [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x4f87482f: lease 10.0.10.231 has been allocated for 3600 seconds
Jul 04 17:45:57 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.packets.136533761271488] DHCP4_PACKET_SEND [hwtype=1 00:11:22:33:44:55], cid=[01:00:11:22:33:44:55], tid=0x4f87482f: trying to send packet DHCPACK (type 5) from 10.0.10.110:67 to 10.0.10.231:68 on interface net1

Dem Client wurde also die IP-Adresse 10.0.10.231 aus unserem Pool zugewiesen, da wir dessen MAC-Adresse 00:11:22:33:44:55 nicht kennen!

Verbindet sich jedoch nun ein uns bekannter Client, dessen MAC-Adresse ac:1f:6b:00:d3:9a wir bei den Reservierungen der IP-Adresse 10.0.10.2 zugeordnet hatten, mit unserem Kea-Host, sehen wir im Journal entsprechend: 

 # journalctl -fu kea-dhcp4
Jul 04 17:55:51 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.dhcp4.136533778056896] DHCP4_QUERY_LABEL received query: [hwtype=1 ac:1f:6b:00:d3:9a], cid=[01:ac:1f:6b:00:d3:9a], tid=0xaf0fd69a
Jul 04 17:55:51 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.packets.136533778056896] DHCP4_PACKET_RECEIVED [hwtype=1 ac:1f:6b:00:d3:9a], cid=[01:ac:1f:6b:00:d3:9a], tid=0xaf0fd69a: DHCPREQUEST (type 3) received from 0.0.0.0 to 255.255.255.255 on interface net1
Jul 04 17:55:51 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.leases.136533778056896] DHCP4_INIT_REBOOT [hwtype=1 ac:1f:6b:00:d3:9a], cid=[01:ac:1f:6b:00:d3:9a], tid=0xaf0fd69a: client is in INIT-REBOOT state and requests address 10.0.10.231
Jul 04 17:55:53 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.dhcp4.136533761271488] DHCP4_QUERY_LABEL received query: [hwtype=1 ac:1f:6b:00:d3:9a], cid=[01:ac:1f:6b:00:d3:9a], tid=0x9d121859
Jul 04 17:55:53 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.packets.136533761271488] DHCP4_PACKET_RECEIVED [hwtype=1 ac:1f:6b:00:d3:9a], cid=[01:ac:1f:6b:00:d3:9a], tid=0x9d121859: DHCPDISCOVER (type 1) received from 0.0.0.0 to 255.255.255.255 on interface net1
Jul 04 17:55:53 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.leases.136533761271488] DHCP4_LEASE_OFFER [hwtype=1 ac:1f:6b:00:d3:9a], cid=[01:ac:1f:6b:00:d3:9a], tid=0x9d121859: lease 10.0.10.2 will be offered
Jul 04 17:55:53 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.packets.136533761271488] DHCP4_PACKET_SEND [hwtype=1 ac:1f:6b:00:d3:9a], cid=[01:ac:1f:6b:00:d3:9a], tid=0x9d121859: trying to send packet DHCPOFFER (type 2) from 10.0.10.110:67 to 10.0.10.2:68 on interface net1
Jul 04 17:55:53 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.dhcp4.136533769664192] DHCP4_QUERY_LABEL received query: [hwtype=1 ac:1f:6b:00:d3:9a], cid=[01:ac:1f:6b:00:d3:9a], tid=0x9d121859
Jul 04 17:55:53 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.packets.136533769664192] DHCP4_PACKET_RECEIVED [hwtype=1 ac:1f:6b:00:d3:9a], cid=[01:ac:1f:6b:00:d3:9a], tid=0x9d121859: DHCPREQUEST (type 3) received from 0.0.0.0 to 255.255.255.255 on interface net1
Jul 04 17:55:53 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.leases.136533769664192] DHCP4_LEASE_ALLOC [hwtype=1 ac:1f:6b:00:d3:9a], cid=[01:ac:1f:6b:00:d3:9a], tid=0x9d121859: lease 10.0.10.2 has been allocated for 3600 seconds
Jul 04 17:55:53 vml000110 kea-dhcp4[1955]: INFO  [kea-dhcp4.packets.136533769664192] DHCP4_PACKET_SEND [hwtype=1 ac:1f:6b:00:d3:9a], cid=[01:ac:1f:6b:00:d3:9a], tid=0x9d121859: trying to send packet DHCPACK (type 5) from 10.0.10.110:67 to 10.0.10.2:68 on interface net1

Der Host hat also seine vordefinierte feste IPv4-Adresse 10.0.10.2 vom kea-dhcp4-Damon erfolgreich zugewiesen bekommen!

Stateful DHCPv6 Server

Ein Stateful DHCPv6-Server liefert neben IPv6-Adressen auch weitere Informationen, wie z.B. wie eine DNS-Serverliste und einen Domänennamen, an einen Host aus. Hosts. Dieser Stateful DHCPv6-Server behält auch den Status jeder Zuweisung im Auge, sprich er verfolgt die Verfügbarkeit des Adresspools und löst doppelte Adresskonflikte auf. Darüber hinaus protokolliert er jede Zuweisung und behält die Ablaufzeiten im Auge. Im Gegensatz zu IPv4 stellt ein Stateful DHCPv6-Server den Hosts keine Standard-Gateway-Adressen zur Verfügung, das kann bei IPv6 nur Router, die Router Advertisement-Nachrichten sendet wie z.B. unser radvd!

Nun wollen wir uns eingehender mit der Konfiguration unseres DHCPv6-Daemons befassen. Die zugehörige Original-Dokumentation findet sich im Abschnitt 9.2. DHCPv6 Server Configuration.

Konfigurationsoptionen für unseren DHCPv6-Daemon

In unserer Betriebsumgebung haben wir folgende Rahmenbedingungen für unseren DHCPv6-Server:

  • Netzwerkinterface :
    Unser DHCPv4-Daemon soll „nur“ auf dem Netzwerkinterface net1 (intra) auf entsprechende Adressanfragen lauschen und entsprechend Adressen ausliefern.
  • Management API :
    Die Verwaltungs-API ermöglicht die Ausgabe spezifischer Verwaltungsbefehle, wie z. B. das Abrufen von Statistiken, die Neukonfiguration oder das Herunterfahren. Die API soll unter dem socket-type = unix der unter dem Link socket-name = /var/lib/kea/kea6-ctrl-socket erreichbar sein.
  • Leases :
    In unserer Beispielumgebung sollen die Leases unserer Clients in der Datei /var/lib/kea/dhcp6.leases vorgehalten werden. Optional wäre auch die Speicherung in einer MariaDB bzw. mySQL-Datenbank oder in einer PostgreSQL-Datenbank denkbar. Aber im ersten Schritt wollen wir uns mal mit einer Ablage in einer Datei begnügen. Die Lease-Time soll eine Stunde, also 3600 Sekunden gelten. Nach 90% der max. Lease-Time soll der Daemon sein Lease-File aufräumen LFC9) durchführt werden, also nach 3200 Sekunden lfc-interval. Dadurch werden redundante (historische) Informationen aus der Lease-Datei entfernt und die Grösse der Lease-Datei effektiv reduziert. Gibt es beim Laden des Lease-Files Fehler, soll der Server nach 100 Fehlern abbrechen und aufhören, zu versuchen die Lease-Datei zu laden.
  • Lease Reclamation :
    Bei der Lease Reclamation, also der Rückforderung von Leases, bei dem abgelaufene Leases zurückgefordert und so anderen Clients wieder zur Verfügung gestellt werden. Hier übernehmen wir die vorgegebenen Default-Wertev von reclaim-timer-wait-time mit 10, flush-reclaimed-timer-wait-time vomn 25, hold-reclaimed-time von 3600, max-reclaim-leases von 100, max-reclaim-time von 250 und unwarned-reclaim-cycles von 5.
  • Lease-Timer :
    Leases sollen eine Stunde, also valid-lifetime von 3600 Sekunden gelten. Nach 1800 Sekunden - das ist die 1/2 der valid-lifetime sollen die Clients nach einer Verlängerung der Lease fragen, also setzen wir renew-timer = 1800. Die Clients sollen zusätzlich alle erreichbaren DHCP-Server fragen, ob die Lease noch einmal verlängert werden kann und dies nach 90% der valid-lifetime, also setzen wir rebind-timer = 3200.
  • Logging :
    Da wir ein zentrales Logging und Auswertung mit Hilfe von Graylog einsetzen, lassen wir den DHCP4-Daemon kein eigenes Logfile schreiben sondern nutzen unser zentrales syslog, welches der systemd-journald.service in unser Journal schreibt. Hierzu setzen wir die nötigen Parameter wie folgt: name gleich kea-dhcp4, output auf syslog, die severity gleich INFO und den debuglevel auf 0.
  • Name-Server :
    Der interne DNS-Daemon ist unter der IP-Adresse fd00::07:10:0:10.110 erreichbar.
  • Domain-Name :
    Der Name unserer Domain lautet nausch.org.
  • Domain-Search-Liste :
    Auf Domain-Search-Listen wird bewusst verzichtet, da diese ein Anachronismus aus den Anfangszeiten des DNS sind und gerne alle Arten von Sicherheits- und Konfigurationsproblemen (DNSSEC, DNS64, QName-Minimization, DNS-Leakage von internen Konfigurationsdaten) erzeugen.
  • Time-Server :
    Der interne Time-Server ist unter der IP-Adresse fd00::07:10:0:10.110 erreichbar.
  • Subnetz :
    Der DHCPv6-Server ist verantwortlich für das Sub-Netz fd00:0:0:7::/64 der Zone intra
    • Time-Server :
      Der interne Time-Server ist bei diesem Subnetz unter der IP-Adresse fd00::07:10:0:10.110 erreichbar.
    • Name-Server :
      Der interne DNS-Daemon ist unter der IP-Adresse fd00::07:10:0:10.110 in diesem Subnetz erreichbar.
    • Pool (dynamischer Adress-Bereich) :
      Dynamische IP-Adressen sollen aus dem Bereich von fd00:0:0:7:10:0:10:300/120 vergeben werden.
    • Reservierungen :
      Einige Hosts bekommen eine feste IP-Adresse, die der DHCP-Server an Hand der übermittelten DUID des Clients und seiner Netzwerkschnittstelle vergeben wird.

Konfigurationsdatei /etc/kea-dhcp6.conf

Bei der Installation unseres Kea-Servers wurde uns eine entsprechende Musterkonfigurations-Datei bereits mitgeliefert. 

 # less /etc/kea/kea-dhcp6.conf

/etc/kea/kea-dhcp6.conf

Bevor wir nun aber unseren Kea-DHCPv6-Daemon individuell nach unseren Bedürfnissen hin anpassen, werden wir zunächst die im Paket mitgelieferte Original-Konfigurationsdatei /etc/kea/kea-dhcp6.conf für spätere Referenzen sichern. 

 # cp -a /etc/kea/kea-dhcp6.conf /etc/kea/kea-dhcp6.conf.orig

So können wir später bei etwaigen Bedarf Vergleiche zur originalen Konfigurationsdatei mit einer neuen Version bei einem Update des KEA-Paketes anstreben, wie in diesem Beispiel hier: 

 # vimdiff /etc/kea/kea-dhcp6.conf.orig /etc/kea/kea-dhcp6.conf.pacnew

Bild: Bildschirmharcopy des Aufgrufes 'vimdiff /etc/kea/kea-dhcp6.conf.orig /etc/kea/kea-dhcp6.conf.pacnew'

Aus den oben genannten Konfigurationsparametern erstellen wir uns nun eine entsprechende Konfigurationsdatei /etc/kea/kea-dhcp6.conf für unseren Kea-DHCPv4-Daemon. 

 # vim /etc/kea/kea-dhcp6.conf
/etc/kea/kea-dhcp6.conf
// This is our basic configuration for the Kea DHCPv6 server. See section
// 9.2 DHCPv6 Server Configuration for detailed informations. the direct link
// for the stable version is https://kea.readthedocs.io/).
//
// This configuration file contains only DHCPv6 server's configuration.
// If configurations for other Kea services are also included in this file they
// are ignored by the DHCPv6 server.
//
// DHCPv6 configuration starts here. This section will be read by DHCPv6 server
// and will be ignored by other components.
{
  "Dhcp6": {
    // See section 9.2.4 Interface Configuration for more details:
    "interfaces-config": {
      "interfaces": [ "eth1" ]
    },
 
    // Kea supports control channel, which is a way to receive management
    // commands while the server is running. For detailed description,
    // see Sections 9.14.
    "control-socket": {
      "socket-type": "unix",
      "socket-name": "/var/lib/kea/kea6-ctrl-socket"
    },
    // Use Memfile lease database backend to store leases in a CSV file.
    //  See Section 9.2.2.1 Memfile - Basic Storage for Leases
    "lease-database": {
      "type": "memfile",
      "persist": true,
      "name": "/var/lib/kea/kea-leases6.csv",
      "lfc-interval": 3200,
      "max-row-errors": 100
    },
 
    // Setup reclamation of the expired leases and leases affinity.
    // See section 11. Lease Expiration for more and detailed informations.                                          
    "expired-leases-processing": {
      "reclaim-timer-wait-time": 10,
      "flush-reclaimed-timer-wait-time": 25,
      "hold-reclaimed-time": 3600,
      "max-reclaim-leases": 100,
      "max-reclaim-time": 250,
      "unwarned-reclaim-cycles": 5
    },
 
    // Global timers specified here apply to all subnets, unless there are
    // subnet specific values defined in particular subnets. See section
    // 9.2.1. Introduction.
    "valid-lifetime": 3600,
    "renew-timer": 1800,
    "rebind-timer": 3200,
    "preferred-lifetime": 3000,
 
    // Many additional parameters can be specified here. Alle datails will be
    // found in following sections:
    // - 9.2.11. Standard DHCPv6 Options
    // - 9.2.14. Custom DHCPv4 Options
    // - 9.2.15. DHCPv6 Vendor-Specific Options                                                                      
    // - 9.2.16. Nested DHCPv6 Options (Custom Option Spaces)                                                        
    // - 9.2.17. Unspecified Parameters for DHCPv6 Option Configuration
    //
    // For a complete list of options currently supported by Kea, see
    // Section 9.2.11 "Standard DHCPv6 Options". Kea also supports
    // vendor options (see Section 7.2.10) and allows users to define their
    // own custom options (see Section 7.2.9).
    "option-data": [
      // Domain-Name-Server:
      {
        "name": "dns-servers",
        "data": "fd00:0:0:7:10:0:10:110"
      },
 
      // Domain-Search-Liste:
      {
        "name": "domain-search",
        "data": "nausch.org"
      }
    ],
 
    // Finally, we list the subnets from which we will be leasing addresses.
    // See section 9.2.5 IPv6 Subnet Identifier and the following sections
    // for more details.
    "subnet6": [
      {
        "interface": "eth1",
 
        // This defines the whole subnet. Kea will use this information to
        // determine where the clients are connected. This is the whole
        // subnet in your network.
 
        // Subnet identifier should be unique for each subnet.
        // Subnet identifier for zone intra
        "id": 62,
 
        // This is mandatory parameter for each subnet.                                                              
        "subnet": "fd00:0:0:7::/64",
 
        // Pools define the actual part of your subnet that is governed
        // by Kea.
        "pools": [ { "pool": "fd00:0:0:7:10:0:10:300/120" } ],
 
        "option-data": [
          // You can specify additional options here that are subnet
          // specific. Also, you can override global options here.
          {
            "name": "dns-servers",
            "data": "fd00:0:0:7:10:0:10:110"
          },                                                                                                
          {
            "name": "sntp-servers",
            "data": "fd00:0:0:7:10:0:10:110"
          }                                                                                                
 
        ],
 
        // Host reservations can be defined for each subnet.
        // Note that reservations are subnet-specific in Kea. This is
        // different than ISC DHCP. Keep that in mind when migrating
        // your configurations.
        "reservations": [
 
          // This are the reservations for specific DUID matchings.
          // "MNSS (C7)"
          {
            "duid": "00:03:00:01:ac:1f:6b:00:d3:9b",
            "ip-addresses": [ "fd00:0:0:7:10:0:10:2" ],
            "hostname": "pml010002.intra.nausch.org"
          },
 
          // "WLAN Router Trendnet TEW-826DAP"
          {
            "duid": "00:03:00:01:d8:eb:97:33:48:62",
            "ip-addresses": [ "fd00:0:0:7:10:0:10:3" ],
            "hostname": "pnc010003.intra.nausch.org"
          },
 
          // "Netzwerkswitch TP-Link T1600G-52PS (UG)"
          {
            "duid": "00:03:00:01:64:66:b3:c9:98:7c",
            "ip-addresses": [ "fd00:0:0:7:10:0:10:6" ],
            "hostname": "pnc010006.intra.nausch.org"
          },
 
          // "Netzwerkswitch Netgear GS308E (DG)"
          {
            "duid": "00:03:00:01:6c:cd:d6:b8:52:be",
            "ip-addresses": [ "fd00:0:0:7:10:0:10:7" ],
            "hostname": "pnc010007.intra.nausch.org"
          },
 
          // "TecVDR (19 Zoll Tischgerät)"
          {
            "duid": "00:03:00:01:00:0b:6a:32:32:95",
            "ip-addresses": [ "fd00:0:0:7:10:0:10:100" ],
            "hostname": "pml010100.intra.nausch.org"
          },
 
          // "MNSS (ArchLinux)"
          {
            "duid": "00:02:00:00:ab:11:3e:4a:0e:2c:c1:5b:e2:64",
            "ip-addresses": [ "fd00:0:0:7:10:0:10:102" ],
            "hostname": "pml010102.intra.nausch.org"
          },
 
          // "ArchLinux FWC"
          {
            "duid": "00:03:00:01:52:54:00:41:11:02",
            "ip-addresses": [ "fd00::7:10:0:10:110" ],
            "hostname": "vml010110.intra.nausch.org"
          }
        ]
      }
    ],
 
    // Logging configuration starts here. Kea uses different loggers to log various
    //# activities. For details (e.g. names of loggers), see Chapter 19.
    "loggers": [
      {
        // This specifies the logging for kea-dhcp6 logger, i.e. all logs
        // generated by Kea DHCPv6 server.
        "name": "kea-dhcp6",
        "output_options": [
          {
            // Specifies the output file. There are several special values
            // supported:
            // - stdout (prints on standard output)
            // - stderr (prints on standard error)
            // - syslog (logs to syslog)
            // - syslog:name (logs to syslog using specified name)
            // Any other value is considered a name of the file
            "output": "syslog"                                                                             
          }
        ],
 
        // This specifies the severity of log messages to keep. Supported values
        // are: FATAL, ERROR, WARN, INFO, DEBUG
        "severity": "INFO",
 
        // If DEBUG level is specified, this value is used. 0 is least verbose,
        // 99 is most verbose. Be cautious, Kea can generate lots and lots
        // of logs if told to do so.
        "debuglevel": 0
      }
    ]
  }
}

Wollen wir die Kondfigurationsdate ohne die Kommentare sehen, grep'en wir einfach entsprechend danach. 

 # grep -Ev '(^.*//|^$)' /etc/kea/kea-dhcp6.conf

Beispielkonfigurationsdatei ohne Kommentare

Bevor wir nun unseren kea-dhcp6-Daemon starten, führen wir noch einen Konfigurationstest durch. Wir prüfen also nun die Konfigurationsdatei unseres kea-dhcp6 auf syntaktische Fehler. 

 # kea-dhcp6 -t /etc/kea/kea-dhcp6.conf
2024-10-19 11:42:46.735 INFO  [kea-dhcp6.hosts/13028.126477756442496] HOSTS_BACKENDS_REGISTERED the following host backend types are available: mysql postgresql 
2024-10-19 11:42:46.736 WARN  [kea-dhcp6.dhcpsrv/13028.126477756442496] DHCPSRV_MT_DISABLED_QUEUE_CONTROL disabling dhcp queue control when multi-threading is enabled.
2024-10-19 11:42:46.736 WARN  [kea-dhcp6.dhcp6/13028.126477756442496] DHCP6_RESERVATIONS_LOOKUP_FIRST_ENABLED Multi-threading is enabled and host reservations lookup is always performed first.
2024-10-19 11:42:46.736 INFO  [kea-dhcp6.dhcpsrv/13028.126477756442496] DHCPSRV_CFGMGR_NEW_SUBNET6 a new subnet has been added to configuration: fd00:0:0:7::/64 with params: t1=1800, t2=3200, preferred-lifetime=3000, valid-lifetime=3600, rapid-commit is false
2024-10-19 11:42:46.738 INFO  [kea-dhcp6.dhcpsrv/13028.126477756442496] DHCPSRV_CFGMGR_SOCKET_TYPE_SELECT using socket type raw
2024-10-19 11:42:46.738 INFO  [kea-dhcp6.dhcpsrv/13028.126477756442496] DHCPSRV_CFGMGR_ADD_IFACE listening on interface eth1

Start des kea-dhcp6

Nun können wir beruhigt und guten Mutes unseren kea-dhcp6 Daemon starten. 

 # systemctl start kea-dhcp6.service

Im Journal wir der Start entsprechend dokumentiert. 

Oct 19 11:49:48 vml000110 systemd[1]: Started ISC Kea IPv6 DHCP daemon.
Oct 19 11:49:49 vml000110 kea-dhcp6[13092]: 2024-10-19 11:49:49.027 INFO  [kea-dhcp6.dhcp6/13092.138845348149120] DHCP6_STARTING Kea DHCPv6 server version 2.6.1 (stable) starting
Oct 19 11:49:49 vml000110 kea-dhcp6[13092]: 2024-10-19 11:49:49.030 INFO  [kea-dhcp6.commands/13092.138845348149120] COMMAND_RECEIVED Received command 'config-set'
Oct 19 11:49:49 vml000110 kea-dhcp6[13092]: INFO  [kea-dhcp6.hosts.138845348149120] HOSTS_BACKENDS_REGISTERED the following host backend types are available: mysql postgresql
Oct 19 11:49:49 vml000110 kea-dhcp6[13092]: WARN  [kea-dhcp6.dhcpsrv.138845348149120] DHCPSRV_MT_DISABLED_QUEUE_CONTROL disabling dhcp queue control when multi-threading is enabled.
Oct 19 11:49:49 vml000110 kea-dhcp6[13092]: WARN  [kea-dhcp6.dhcp6.138845348149120] DHCP6_RESERVATIONS_LOOKUP_FIRST_ENABLED Multi-threading is enabled and host reservations lookup is always performed first.
Oct 19 11:49:49 vml000110 kea-dhcp6[13092]: INFO  [kea-dhcp6.dhcpsrv.138845348149120] DHCPSRV_CFGMGR_NEW_SUBNET6 a new subnet has been added to configuration: fd00:0:0:7::/64 with params: t1=1800, t2=3200, preferred-lifetime=3000, valid-lifetime=3600, rapid-commit is false
Oct 19 11:49:49 vml000110 kea-dhcp6[13092]: INFO  [kea-dhcp6.dhcpsrv.138845348149120] DHCPSRV_CFGMGR_SOCKET_TYPE_SELECT using socket type raw
Oct 19 11:49:49 vml000110 kea-dhcp6[13092]: INFO  [kea-dhcp6.dhcpsrv.138845348149120] DHCPSRV_CFGMGR_ADD_IFACE listening on interface eth1
Oct 19 11:49:49 vml000110 kea-dhcp6[13092]: INFO  [kea-dhcp6.commands.138845348149120] COMMAND_ACCEPTOR_START Starting to accept connections via unix domain socket bound to /var/lib/kea/kea6-ctrl-socket
Oct 19 11:49:49 vml000110 kea-dhcp6[13092]: INFO  [kea-dhcp6.dhcp6.138845348149120] DHCP6_CONFIG_COMPLETE DHCPv6 server has completed configuration: added IPv6 subnets: 1; DDNS: disabled
Oct 19 11:49:49 vml000110 kea-dhcp6[13092]: INFO  [kea-dhcp6.dhcpsrv.138845348149120] DHCPSRV_MEMFILE_DB opening memory file lease database: lfc-interval=3200 max-row-errors=100 name=/var/lib/kea/kea-leases6.csv persist=true type=memfile universe=6
Oct 19 11:49:49 vml000110 kea-dhcp6[13092]: INFO  [kea-dhcp6.dhcpsrv.138845348149120] DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file /var/lib/kea/kea-leases6.csv.2
Oct 19 11:49:49 vml000110 kea-dhcp6[13092]: INFO  [kea-dhcp6.dhcpsrv.138845348149120] DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file /var/lib/kea/kea-leases6.csv
Oct 19 11:49:49 vml000110 kea-dhcp6[13092]: INFO  [kea-dhcp6.dhcpsrv.138845348149120] DHCPSRV_MEMFILE_BUILD_EXTENDED_INFO_TABLES6 building extended info tables saw 13 leases, extended info sanity checks modified 0 leases and 0 leases were entered into tables
Oct 19 11:49:49 vml000110 kea-dhcp6[13092]: INFO  [kea-dhcp6.dhcpsrv.138845348149120] DHCPSRV_MEMFILE_LFC_SETUP setting up the Lease File Cleanup interval to 3200 sec
Oct 19 11:49:49 vml000110 kea-dhcp6[13092]: INFO  [kea-dhcp6.dhcp6.138845348149120] DHCP6_USING_SERVERID server is using server-id 00:01:00:01:2d:c7:a3:0e:52:54:00:41:11:01 and stores in the file /var/lib/kea/kea-dhcp6-serverid
Oct 19 11:49:49 vml000110 kea-dhcp6[13092]: INFO  [kea-dhcp6.dhcpsrv.138845348149120] DHCPSRV_CFGMGR_USE_ALLOCATOR using the iterative allocator for IA_NA leases in subnet fd00:0:0:7::/64
Oct 19 11:49:49 vml000110 kea-dhcp6[13092]: INFO  [kea-dhcp6.dhcpsrv.138845348149120] DHCPSRV_CFGMGR_USE_ALLOCATOR using the iterative allocator for IA_TA leases in subnet fd00:0:0:7::/64
Oct 19 11:49:49 vml000110 kea-dhcp6[13092]: INFO  [kea-dhcp6.dhcpsrv.138845348149120] DHCPSRV_CFGMGR_USE_ALLOCATOR using the iterative allocator for IA_PD leases in subnet fd00:0:0:7::/64
Oct 19 11:49:49 vml000110 kea-dhcp6[13092]: WARN  [kea-dhcp6.dhcp6.138845348149120] DHCP6_MULTI_THREADING_INFO enabled: yes, number of threads: 4, queue size: 64
Oct 19 11:49:49 vml000110 kea-dhcp6[13092]: INFO  [kea-dhcp6.dhcp6.138845348149120] DHCP6_STARTED Kea DHCPv6 server version 2.6.1 started

Bei Bedarf können wir natürlich auch den Status unseres Daemons jederzeit abfragen. 

 # systemctl status kea-dhcp6.service

● kea-dhcp6.service - ISC Kea IPv6 DHCP daemon
     Loaded: loaded (/usr/lib/systemd/system/kea-dhcp6.service; enabled; preset: disabled)
   Active:active (running) since Sat 2024-10-19 11:49:48 CEST; 3min 16s ago
 Invocation: 0d82ea986a164eea91930cafef01d523
       Docs: man:kea-dhcp6(8)
   Main PID: 13092 (kea-dhcp6)
      Tasks: 9 (limit: 9510)
     Memory: 3M (peak: 3.5M)
        CPU: 66ms
     CGroup: /system.slice/kea-dhcp6.service
             └─13092 /usr/bin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf

Oct 19 11:49:49 vml000110 kea-dhcp6[13092]: WARN  [kea-dhcp4.dhcp4.136533820646528] DHCP4_MULTI_THREADING_INFO enabled: yes, number of threads: 4, queue size: 64
Oct 19 11:49:49 vml000110 kea-dhcp6[13092]: INFO  [kea-dhcp6.dhcp6.138845348149120] DHCP6_STARTED Kea DHCPv6 server version 2.6.1 started
Oct 19 11:50:00 vml000110 kea-dhcp6[13092]: INFO  [kea-dhcp6.dhcp6.138845313959616] DHCP6_QUERY_LABEL received query: duid=[00:01:00:01:29:0f:e9:34:b8:27:eb:b2:56:1f], [no hwaddr info], tid=0x3e3337
Oct 19 11:50:00 vml000110 kea-dhcp6[13092]: INFO  [kea-dhcp6.packets.138845313959616] DHCP6_PACKET_RECEIVED duid=[00:01:00:01:29:0f:e9:34:b8:27:eb:b2:56:1f], [no hwaddr info], tid=0x3e3337: RENEW (type 5) received from fe80::a112:c604:f325:26dc to ff02::1:2 on interface eth1
Oct 19 11:50:00 vml000110 kea-dhcp6[13092]: INFO  [kea-dhcp6.leases.138845313959616] DHCP6_LEASE_RENEW duid=[00:01:00:01:29:0f:e9:34:b8:27:eb:b2:56:1f], [no hwaddr info], tid=0x3e3337: lease for address fd00::7:10:0:10:36 and iaid=3957113288 has been allocated
Oct 19 11:50:00 vml000110 kea-dhcp6[13092]: INFO  [kea-dhcp6.packets.138845313959616] DHCP6_PACKET_SEND duid=[00:01:00:01:29:0f:e9:34:b8:27:eb:b2:56:1f], [no hwaddr info], tid=0x3e3337: trying to send packet REPLY (type 7) from [ff02::1:2]:547 to [fe80::a112:c604:f325:26dc]:546 on interface eth1
Oct 19 11:51:52 vml000110 kea-dhcp6[13092]: INFO  [kea-dhcp6.dhcp6.138845305566912] DHCP6_QUERY_LABEL received query: duid=[00:03:00:01:1c:ed:6f:bb:f3:9f], [no hwaddr info], tid=0xd5b5b1
Oct 19 11:51:52 vml000110 kea-dhcp6[13092]: INFO  [kea-dhcp6.packets.138845305566912] DHCP6_PACKET_RECEIVED duid=[00:03:00:01:1c:ed:6f:bb:f3:9f], [no hwaddr info], tid=0xd5b5b1: RENEW (type 5) received from fe80::1eed:6fff:febb:f39f to ff02::1:2 on interface eth1
Oct 19 11:51:52 vml000110 kea-dhcp6[13092]: INFO  [kea-dhcp6.leases.138845305566912] DHCP6_LEASE_RENEW duid=[00:03:00:01:1c:ed:6f:bb:f3:9f], [no hwaddr info], tid=0xd5b5b1: lease for address fd00::7:10:0:10:5 and iaid=1874588575 has been allocated
Oct 19 11:51:52 vml000110 kea-dhcp6[13092]: INFO  [kea-dhcp6.packets.138845305566912] DHCP6_PACKET_SEND duid=[00:03:00:01:1c:ed:6f:bb:f3:9f], [no hwaddr info], tid=0xd5b5b1: trying to send packet REPLY (type 7) from [ff02::1:2]:547 to [fe80::1eed:6fff:febb:f39f]:546 on interface eth1

Verbindet sich nun ein uns unbekannter Host und kontaktiert unseren kea-dhcp6-Daemon wird der erfolgreiche Handshake im Journal protokolliert. 

 # journalctl -fu kea-dhcp6
Oct 19 12:10:53 vml000110 kea-dhcp6[13178]: INFO  [kea-dhcp6.dhcp6.136335342069440] DHCP6_QUERY_LABEL received query: duid=[00:01:00:01:2e:46:d3:f8:f4:a8:0d:20:b1:37], [no hwaddr info], tid=0x86bd1b
Oct 19 12:10:53 vml000110 kea-dhcp6[13178]: INFO  [kea-dhcp6.packets.136335342069440] DHCP6_PACKET_RECEIVED duid=[00:01:00:01:2e:46:d3:f8:f4:a8:0d:20:b1:37], [no hwaddr info], tid=0x86bd1b: RENEW (type 5) received from fe80::9ae3:7d16:5806:aff0 to ff02::1:2 on interface eth1
Oct 19 12:10:53 vml000110 kea-dhcp6[13178]: INFO  [kea-dhcp6.leases.136335342069440] DHCP6_LEASE_RENEW duid=[00:01:00:01:2e:46:d3:f8:f4:a8:0d:20:b1:37], [no hwaddr info], tid=0x86bd1b: lease for address fd00::7:10:0:10:304 and iaid=170694673 has been allocated
Oct 19 12:10:53 vml000110 kea-dhcp6[13178]: INFO  [kea-dhcp6.packets.136335342069440] DHCP6_PACKET_SEND duid=[00:01:00:01:2e:46:d3:f8:f4:a8:0d:20:b1:37], [no hwaddr info], tid=0x86bd1b: trying to send packet REPLY (type 7) from [ff02::1:2]:547 to [fe80::9ae3:7d16:5806:aff0]:546 on interface eth1

Dem Client wurde also die IP-Adresse fd00::7:10:0:10:304 aus unserem definierten Pool zugewiesen, da wir dessen DUID 00:01:00:01:2e:46:d3:f8:f4:a8:0d:20:b1:37 nicht kennen!

Verbindet sich jedoch nun ein uns bekannter Client, dessen DUID 00:03:00:01:d8:eb:97:33:48:62 wir bei den Reservierungen der IP-Adresse fd00::7:10:0:10:3 zugeordnet hatten, mit unserem Kea-Host, sehen wir im Journal entsprechend: 

 # journalctl -fu kea-dhcp4
Oct 19 12:11:14 vml000110 kea-dhcp6[13178]: INFO  [kea-dhcp6.dhcp6.136335333676736] DHCP6_QUERY_LABEL received query: duid=[00:03:00:01:d8:eb:97:33:48:62], [no hwaddr info], tid=0xcec735
Oct 19 12:11:14 vml000110 kea-dhcp6[13178]: INFO  [kea-dhcp6.packets.136335333676736] DHCP6_PACKET_RECEIVED duid=[00:03:00:01:d8:eb:97:33:48:62], [no hwaddr info], tid=0xcec735: RENEW (type 5) received from fe80::2e3a:fdff:fe2e:bd0b to ff02::1:2 on interface eth1
Oct 19 12:11:14 vml000110 kea-dhcp6[13178]: INFO  [kea-dhcp6.alloc-engine.136335333676736] ALLOC_ENGINE_V6_HR_ADDR_GRANTED reserved address fd00::7:10:0:10:3 was assigned to client duid=[00:03:00:01:d8:eb:97:33:48:62], [no hwaddr info], tid=0xcec735
Oct 19 12:11:14 vml000110 kea-dhcp6[13178]: INFO  [kea-dhcp6.leases.136335333676736] DHCP6_LEASE_RENEW duid=[00:03:00:01:d8:eb:97:33:48:62], [no hwaddr info], tid=0xcec735: lease for address fd00::7:10:0:10:4 and iaid=4247698699 has been allocated
Oct 19 12:11:14 vml000110 kea-dhcp6[13178]: INFO  [kea-dhcp6.packets.136335333676736] DHCP6_PACKET_SEND duid=[00:03:00:01:d8:eb:97:33:48:62], [no hwaddr info], tid=0xcec735: trying to send packet REPLY (type 7) from [ff02::1:2]:547 to [fe80::2e3a:fdff:fe2e:bd0b]:546 on interface eth1

Der Host hat also seine vordefinierte feste IPv6-Adresse fd00::7:10:0:10:3 vom kea-dhcp4-Damon erfolgreich zugewiesen bekommen!

Orchestrierung - Installation und Konfiguration der beiden Kea-Daemon mit Hilfe von Ansible

Aufgabenstellung

Natürlich wird man im Jahr 2024 nicht mehr ernsthaft, manuell Server aufsetzen und betreiben wollen. Vielmehr wird man auf ein Orchestrierungswerkzeug wie z.B. Ansible zurückgreifen. Setzen wir einen neue virtuellen Server unter Arch Linux neu auf, oder wollen wir bei einem bestehenden Host die Konfiguration aktualisieren, verwenden wir wie zuvor schon angeschnitten Ansible als Orchestrierungswerkzeug. So ist sichergestellt dass zum einen all unsere Hosts entsprechend gleich aufgebaut, konfiguriert und betrieben werden, es also keine Bastel-/Frickellösung geben wird.

Wir werden uns nun nachfolgend die Server-Installation und -konfiguration genauer betrachten.

Lösung

Der ungeduldigen Leser kann auch direkt zur Tat schreiten und das manuelle Anlegen der Inventory-Hülle, des Playbooks und der zugehörigen Rolle überspringen und diese Aufgaben mit folgendem Befehl sozusagen auf einem Rutsch erledigen: 

 $ mkdir -p ~/devel/ansible ; wget https://gitlab.nausch.org/django/example_kea/-/archive/main/example_kea-main.tar.gz \
         -O - | tar -xz --strip-components=1 -C ~/devel/ansible

Nach Anpassung der Daten im Inventory kann man anschliessend direkt zur Ausführung schreiten.

Vorbereitung - (Server-)Daten im Inventory

Bei unserem Konfigurationsbeispiel hier gehen wir von folgenden Host-Parametern aus:

  • zone: intra
  • hostname: vml010110

Die Konfigurationsdatei unseres inventory in unsere, Ansible-Verzeichnis beinhaltet demnach unter anderem: 

 $ vim inventories/production/hosts

inventories/production/hosts

Die beiden Beispiel-Hosts aus der Gruppe|Zone intra in diesem Inventory symbolisieren folgende unterschiedlichen Knoten.

  • Der Host pnc010007 steht exeplarisch für einen Client im Intranet. In dessen Inventory-File inventories/production/host_vars/pnc010007 sind die ihn beschreibenden Datein enthalten.
  • Der Host vml010110 ist in diesem Beispiel unser Server, der die Verbindung zwischen der Zone intra und der Aussenwelt herstellt. Auf diesem Konten läuft bereits ein Chrony Timeserver| wie auch eine Firewall auf Basis von firewalld der eine Zonendefinition intra besitzt, die die Regeln für diese Zone beinhalten. Sowohl Timeserver wie auch Firewall werden in diesem Beispiel hier nur erwähnt, da in dem Playbook bzw.genauer gesagt im Inventory darauf referenziert wird.

Wir legen uns also nun die Hostdefinitionsdatei für unseren Switch im SOHO an. 

 $ vim inventories/production/host_vars/pnc010007

inventories/production/host_vars/pnc010007

Als nächstes legen wir die Datei für den KVM-Host, auf dem unser Kea-Daemon laufen soll an und definieren darin die zugehörigen Eigenschaften. 

$ vim inventories/production/host_vars/vml010110/kvm_vhost

inventories/production/host_vars/vml010110/kvm_vhost

Die für die beiden kea-Daemon relevanten Konfigurationsparameter legen wir in der Inventrory-Datei inventories/production/host_vars/vml010110/kea ab. 

 $ vim inventories/production/host_vars/vml010110/kea

inventories/production/host_vars/vml010110/kea

Unser Beispiels-Inventory hat also nunmehr folgenden Aufbau: 

inventories/production/
├── hosts
└── host_vars
    ├── pnc010007
    └── vml010110
        ├── kea
        └── kvm_vhost

3 directories, 4 files

Playbook

Unser Playbook zum Installieren und Konfigurieren der beiden Kea-Daemon kea-dhcp4 und kea-dhcp6, ist wie imer schlank, unscheinbar und unspektakulär, beinhaltet aber Hinweise zur Aufgabe und wie es aufzurufen ist. 

 $ vim playbooks/kea_dhcp.yml

playbooks/kea_dhcp.yml

Rolle

Für die Konfiguration der kea-Daemon verwenden wir eine eigene Rolle kea_dhcp, die wir bei unserem zuvor angelegten Playbooks später einfach mit aufrufen werden. hierzu kopieren wir uns zunächst die Mustervorlage common. 

 $ cp -avr roles/common/ roles/kea_dhcp

Ausgabe von cp -avr roles/common/ roles/kea_dhcp

Bei Bedarf können wir uns die Struktur die somit angelegt wurde mit nachfolgendem Befehl anzeigen lassen. 

 $ tree roles/kea_dhcp/

Ausgabe von tree roles/kea_dhcp/

Wie wir sehen ist die Rolle durchaus überschaubar, im Task main.yaml verweisen wir lediglich auf die eigentlichen Tasks vorbereitung, dhcp4, dhcp6 und firewalld 

 $ vim roles/kea_dhcp/tasks/main.yml

roles/kea_dhcp/tasks/main.yml

Die Installation des Kea DHCP-Servers wird in der ersten Task-Gruppe mit dem tag vorbereitung vorgenommen. 

 $ vim roles/kea_dhcp/tasks/vorbereitung.yml

roles/kea_dhcp/tasks/vorbereitung.yml

Für die Konfiguration des Kea-DHCP4-Daemon werden die nötigen Schritte in der Task-Gruppe mit dem tag dhcp4 definiert. 

 $ vim roles/kea_dhcp/tasks/dhcp4.yml

roles/kea_dhcp/tasks/dhcp4.yml

Der Kea-DHCP4-Daemon wird mit Hilfe der Task-Gruppe mit dem tag dhcp6 konfiguriert. 

 $ vim roles/kea_dhcp/tasks/dhcp6.yml

roles/kea_dhcp/tasks/dhcp6.yml

Nun brauchen wir noch eine Beschreibung der Aufgaben für die Konfiguration der firewalld-Regeln für beide Kea Daemons. 

 $ vim roles/kea_dhcp/tasks/firewalld.yml

roles/kea_dhcp/tasks/firewalld.yml

Sollte bei der Abarbeitung des Playbook eine oder beide Konfigurationsdateien kea-dhcp4.conf und kea-dhcp6.conf verändert werden, ist natürlich hierbei ein Restart der betreffenden Kea-Daemon notwenig. Hierzu verwenden wir die Ansible Playbook Handlers. Diese Handler werden in den beiden Tasks zur Erstellung der Kea-Konfigurationsdateien mit Hilfe eines handler-Calls aufgerufen, sofern sich die Datei verändert hat.

Zu guter Letzt brauchen wir noch eine Konfiguration der Aufgaben die bei einem notify abgearbeitet werden sollen. 

 $ vim roles/kea_dhcp/handlers/main.yml

roles/kea_dhcp/handlers/main.yml

Für die Erstellung der jeweiligen Konfigurationsdateien /etc/kea/kea-dhcp4.conf und /etc/kea/kea-dhcp6.conf brauchen wir nun noch jeweils ein Jinja2 Templates. Mit Hilfe dieser beiden Templates und der darin enthaltenen Schleifendefinitionen werden dann mit Hilfe der Daten aus dem Inventory die zuvor genannten Konfigurationsdateien erzeugt. 

 $ vim roles/kea_dhcp/templates/dhcp4.j2

roles/kea_dhcp/templates/dhcp4.j2 

 $ vim roles/kea_dhcp/templates/dhcp6.j2

roles/kea_dhcp/templates/dhcp6.j2

Ausführung - Playbooklauf

Die orchestrierte Variante der Installation und Konfiguration unserer kea-Daemon gestaltet sich ab sofort sehr einfach, brauchen wir doch lediglich die Konfigurationswerte im Inventory zu hinterlegen und zu pflegen und letztendlich das Playbook entsprechend aufzurufen, wenn z.B. ein Client im Intranet hinzugefügt, entfernt oder ausgetauscht wird: 

 $ ansible-playbook playbooks/kea_dhcp.yml

[16:43:13] Gathering Facts
↳  vml010110 | SUCCESS | 2.19s
[16:43:15] kea-dhcp : Installation des Kea DHCP-Servers.
↳  vml010110 | SUCCESS | 7ms
[16:43:15]     ↳ vorbereitung: Vorhandenes System aktualisieren.
↳  vml010110 | CHANGED | 2.45s
[16:43:17]     ↳ vorbereitung: Installation der benötigten kea Pakete.
↳  vml010110 | SUCCESS | 1.63s
[16:43:19] kea-dhcp : Konfiguration des Kea DHCP4-Servers.
↳  vml010110 | SUCCESS | 12ms
[16:43:19]     ↳ dhcp4: Checken ob es bereits eine Backupdatei der kea-dhcp4.conf gibt.
↳  vml010110 | SUCCESS | 609ms
[16:43:19]     ↳ dhcp4: Backupdatei der Konfigurationsdatei kea-dhcp4.conf erstellen.
vml010110 | SKIPPED | 9ms
[16:43:20]     ↳ dhcp4: Individuelle Konfigurationsdatei kea-dhcp4.conf erzeugen und kopieren.
↳  vml010110 | SUCCESS | 1.19s
[16:43:21]     ↳ dhcp4: Sicherstellen, dass der kea-dhcp4 Daemon reboot(-fest) startet.
↳  vml010110 | SUCCESS | 918ms
[16:43:22] kea-dhcp : Konfiguration des Kea DHCP6-Servers.
↳  vml010110 | SUCCESS | 10ms
[16:43:22]     ↳ dhcp6: Checken ob es bereits eine Backupdatei der kea-dhcp6.conf gibt.
↳  vml010110 | SUCCESS | 524ms
[16:43:22]     ↳ dhcp6: Backupdatei der Konfigurationsdatei kea-dhcp6.conf erstellen.
vml010110 | SKIPPED | 14ms
[16:43:22]     ↳ dhcp6: Individuelle Konfigurationsdatei kea-dhcp6.conf erzeugen und kopieren.
↳  vml010110 | CHANGED | 1.31s
[16:43:24]     ↳ dhcp6: Sicherstellen, dass der kea-dhcp4 Daemon reboot(-fest) startet.
↳  vml010110 | SUCCESS | 826ms
[16:43:24] kea-dhcp : Konfiguration der firewalld-Regeln für beide Kea Daemons.
↳  vml010110 | SUCCESS | 27ms
[16:43:24]     ↳ firewalld: Konfiguration der firewalld Regeln in Zone_1 für die Kea-Daemon.
↳  vml010110 | SUCCESS | 5.09s
[16:43:30]     ↳ firewalld: Konfiguration der firewalld Regeln in Zone_2 für die Kea-Daemon./font>
↳  vml010110 | SUCCESS | 5.12s
[16:43:35]     ↳ firewalld: Zum Schluss den aktuellen permanenten Regelsatz final neu laden.
↳  vml010110 | CHANGED | 918ms
triggering handler | kea-dhcp : Restart dhcp6
↳  vml010110 | CHANGED | 1.76s
[16:43:36] system
-- Play recap --
vml010110                  : ok=17   changed=4    unreachable=0    failed=0    skipped=2    rescued=0    ignored=0

Ergebniskontrolle

Ob die Konfigrationsdateien valide erstellt und auch von den Kea-Daemons erfolgreich geladen worden sind, kontrollieren wir zum Beispiel auf dem Zielhost mit einem Blick in die betreffenden Konfigurationsdateien, mit Hilfe der Option -t beim jeweiligen kea-binarys, oder mit Hilfe der status-Abfrage des betreffenden Kea-Daemons.

  • kea-dhcp4 
     # bat /etc/kea/kea-dhcp4.conf
     # kea-dhcp4 -t /etc/kea/kea-dhcp4.conf
     # systemctl status kea-dhcp4
  • kea-dhcp6 
     # bat /etc/kea/kea-dhcp6.conf
     # kea-dhcp6 -t /etc/kea/kea-dhcp6.conf
     # systemctl status kea-dhcp6

Links

1)
Dynamic Host Configuration Protocol
2)
Bootstrap Protocol
3)
Preboot eXecution Environment
4)
Unreliable Datagram Protocol
5)
Media Access Control
6)
Router Advertisement
7)
Duplicate Address Detection
8) , 9)
Lease File Cleanup
Diese Website verwendet Cookies. Durch die Nutzung der Website stimmen Sie dem Speichern von Cookies auf Ihrem Computer zu. Außerdem bestätigen Sie, dass Sie unsere Datenschutzbestimmungen gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information
  • linux/kea.txt
  • Zuletzt geändert: 20.10.2024 13:47.
  • von django