DHCPv4|v6-Server mit DHCP ISC Kea unter Arch Linux einrichten und nutzen
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).
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.
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.
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.
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.
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.
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.
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.
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.
Stufe der DHCP-Adressanfrage - DHCPREQUEST
Die angebotene Adresse wird nun vom Client nochmals explizit angefordert.
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.
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
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.
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!
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:
Im Detail sind das folgende nacheinander folgende Schritte:
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.
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.
Der Host fordert mit dieser NachrichtRouter Advertisements sofort und nicht erst zum nächsten geplanten Zeitpunkt zu senden.
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.
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.
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.
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.
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.
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
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.
Als User:
$ sudo pacman -S kea
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:
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.
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:
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:
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:
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.
// This is a basic configuration for the Kea DHCPv4 server. Subnet declarations// are mostly commented out and no interfaces are listed. Therefore, the servers// will not listen or respond to any queries.// The basic configuration must be extended to specify interfaces on which// the servers should listen. There are a number of example options defined.// These probably don't make any sense in your network. Make sure you at least// update the following, before running this example in your network:// - change the network interface names// - change the subnets to match your actual network// - change the option values to match your network//// This is just a very basic configuration. Kea comes with large suite (over 30)// of configuration examples and extensive Kea User's Guide. Please refer to// those materials to get better understanding of what this software is able to// do. Comments in this configuration file sometimes refer to sections for more// details. These are section numbers in Kea User's Guide. The version matching// your software should come with your Kea package, but it is also available// in ISC's Knowledgebase (https://kea.readthedocs.io; the direct link for// the stable version is https://kea.readthedocs.io/).//// 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":{// Add names of your network interfaces to listen on."interfaces-config":{// See section 8.2.4 for more details. You probably want to add just// interface name (e.g. "eth0" or specific IPv4 address on that// interface name (e.g. "eth0/192.0.2.1")."interfaces":[]// Kea DHCPv4 server by default listens using raw sockets. This ensures// all packets, including those sent by directly connected clients// that don't have IPv4 address yet, are received. However, if your// traffic is always relayed, it is often better to use regular// UDP sockets. If you want to do that, uncomment this line:// "dhcp-socket-type": "udp"},
// Kea supports control channel, which is a way to receive management// commands while the server is running. This is a Unix domain socket that// receives commands formatted in JSON, e.g. config-set (which sets new// configuration), config-reload (which tells Kea to reload its// configuration from file), statistic-get (to retrieve statistics) and many// more. For detailed description, see Sections 8.8, 16 and 15."control-socket":{"socket-type":"unix",
"socket-name":"/tmp/kea4-ctrl-socket"},
// Use Memfile lease database backend to store leases in a CSV file.// Depending on how Kea was compiled, it may also support SQL databases// (MySQL and/or PostgreSQL). Those database backends require more// parameters, like name, host and possibly user and password.// There are dedicated examples for each backend. See Section 7.2.2 "Lease// Storage" for details."lease-database":{// Memfile is the simplest and easiest backend to use. It's an in-memory// C++ database that stores its state in CSV file."type":"memfile",
"lfc-interval":3600},
// Kea allows storing host reservations in a database. If your network is// small or you have few reservations, it's probably easier to keep them// in the configuration file. If your network is large, it's usually better// to use database for it. To enable it, uncomment the following:// "hosts-database": {// "type": "mysql",// "name": "kea",// "user": "kea",// "password": "kea",// "host": "localhost",// "port": 3306// },// See Section 7.2.3 "Hosts storage" for details.// Setup reclamation of the expired leases and leases affinity.// Expired leases will be reclaimed every 10 seconds. Every 25// seconds reclaimed leases, which have expired more than 3600// seconds ago, will be removed. The limits for leases reclamation// are 100 leases or 250 ms for a single cycle. A warning message// will be logged if there are still expired leases in the// database after 5 consecutive reclamation cycles.// If both "flush-reclaimed-timer-wait-time" and "hold-reclaimed-time" are// not 0, when the client sends a release message the lease is expired// instead of being deleted from the lease storage."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."renew-timer":900,
"rebind-timer":1800,
"valid-lifetime":3600,
// Many additional parameters can be specified here:// - option definitions (if you want to define vendor options, your own// custom options or perhaps handle standard options// that Kea does not support out of the box yet)// - client classes// - hooks// - ddns information (how the DHCPv4 component can reach a DDNS daemon)//// Some of them have examples below, but there are other parameters.// Consult Kea User's Guide to find out about them.// These are global options. They are going to be sent when a client// requests them, unless overwritten with values in more specific scopes.// The scope hierarchy is:// - global (most generic, can be overwritten by class, subnet or host)// - class (can be overwritten by subnet or host)// - subnet (can be overwritten by host)// - host (most specific, overwrites any other scopes)//// Not all of those options make sense. Please configure only those that// are actually useful in your network.//// For a complete list of options currently supported by Kea, see// Section 7.2.8 "Standard DHCPv4 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":[// When specifying options, you typically need to specify// one of (name or code) and data. The full option specification// covers name, code, space, csv-format and data.// space defaults to "dhcp4" which is usually correct, unless you// use encapsulate options. csv-format defaults to "true", so// this is also correct, unless you want to specify the whole// option value as long hex string. For example, to specify// domain-name-servers you could do this:// {// "name": "domain-name-servers",// "code": 6,// "csv-format": "true",// "space": "dhcp4",// "data": "192.0.2.1, 192.0.2.2"// }// but it's a lot of writing, so it's easier to do this instead:{"name":"domain-name-servers",
"data":"192.0.2.1, 192.0.2.2"},
// Typically people prefer to refer to options by their names, so they// don't need to remember the code names. However, some people like// to use numerical values. For example, option "domain-name" uses// option code 15, so you can reference to it either by// "name": "domain-name" or "code": 15.{"code":15,
"data":"example.org"},
// Domain search is also a popular option. It tells the client to// attempt to resolve names within those specified domains. For// example, name "foo" would be attempted to be resolved as// foo.mydomain.example.com and if it fails, then as foo.example.com{"name":"domain-search",
"data":"mydomain.example.com, example.com"},
// String options that have a comma in their values need to have// it escaped (i.e. each comma is preceded by two backslashes).// That's because commas are reserved for separating fields in// compound options. At the same time, we need to be conformant// with JSON spec, that does not allow "\,". Therefore the// slightly uncommon double backslashes notation is needed.// Legal JSON escapes are \ followed by "\/bfnrt character// or \u followed by 4 hexadecimal numbers (currently Kea// supports only \u0000 to \u00ff code points).// CSV processing translates '\\' into '\' and '\,' into ','// only so for instance '\x' is translated into '\x'. But// as it works on a JSON string value each of these '\'// characters must be doubled on JSON input.{"name":"boot-file-name",
"data":"EST5EDT4\\,M3.2.0/02:00\\,M11.1.0/02:00"},
// Options that take integer values can either be specified in// dec or hex format. Hex format could be either plain (e.g. abcd)// or prefixed with 0x (e.g. 0xabcd).{"name":"default-ip-ttl",
"data":"0xf0"}// Note that Kea provides some of the options on its own. In particular,// it sends IP Address lease type (code 51, based on valid-lifetime// parameter, Subnet mask (code 1, based on subnet definition), Renewal// time (code 58, based on renew-timer parameter), Rebind time (code 59,// based on rebind-timer parameter).],
// Other global parameters that can be defined here are option definitions// (this is useful if you want to use vendor options, your own custom// options or perhaps handle options that Kea does not handle out of the box// yet).// You can also define classes. If classes are defined, incoming packets// may be assigned to specific classes. A client class can represent any// group of devices that share some common characteristic, e.g. Windows// devices, iphones, broken printers that require special options, etc.// Based on the class information, you can then allow or reject clients// to use certain subnets, add special options for them or change values// of some fixed fields."client-classes":[{// This specifies a name of this class. It's useful if you need to// reference this class."name":"voip",
// This is a test. It is an expression that is being evaluated on// each incoming packet. It is supposed to evaluate to either// true or false. If it's true, the packet is added to specified// class. See Section 12 for a list of available expressions. There// are several dozens. Section 8.2.14 for more details for DHCPv4// classification and Section 9.2.19 for DHCPv6."test":"substring(option[60].hex,0,6) == 'Aastra'",
// If a client belongs to this class, you can define extra behavior.// For example, certain fields in DHCPv4 packet will be set to// certain values."next-server":"192.0.2.254",
"server-hostname":"hal9000",
"boot-file-name":"/dev/null"// You can also define option values here if you want devices from// this class to receive special options.}],
// Another thing possible here are hooks. Kea supports a powerful mechanism// that allows loading external libraries that can extract information and// even influence how the server processes packets. Those libraries include// additional forensic logging capabilities, ability to reserve hosts in// more flexible ways, and even add extra commands. For a list of available// hook libraries, see https://gitlab.isc.org/isc-projects/kea/wikis/Hooks-available.// "hooks-libraries": [// {// // Forensic Logging library generates forensic type of audit trail// // of all devices serviced by Kea, including their identifiers// // (like MAC address), their location in the network, times// // when they were active etc.// "library": "/usr/lib/kea/hooks/libdhcp_legal_log.so",// "parameters": {// "path": "/var/lib/kea",// "base-name": "kea-forensic4"// }// },// {// // Flexible identifier (flex-id). Kea software provides a way to// // handle host reservations that include addresses, prefixes,// // options, client classes and other features. The reservation can// // be based on hardware address, DUID, circuit-id or client-id in// // DHCPv4 and using hardware address or DUID in DHCPv6. However,// // there are sometimes scenario where the reservation is more// // complex, e.g. uses other options that mentioned above, uses part// // of specific options or perhaps even a combination of several// // options and fields to uniquely identify a client. Those scenarios// // are addressed by the Flexible Identifiers hook application.// "library": "/usr/lib/kea/hooks/libdhcp_flex_id.so",// "parameters": {// "identifier-expression": "relay4[2].hex"// }// }// ],// Below an example of a simple IPv4 subnet declaration. Uncomment to enable// it. This is a list, denoted with [ ], of structures, each denoted with// { }. Each structure describes a single subnet and may have several// parameters. One of those parameters is "pools" that is also a list of// structures."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":"192.0.2.0/24",
// Pools define the actual part of your subnet that is governed// by Kea. Technically this is optional parameter, but it's// almost always needed for DHCP to do its job. If you omit it,// clients won't be able to get addresses, unless there are// host reservations defined for them."pools":[{"pool":"192.0.2.1 - 192.0.2.200"}],
// These are options that are subnet specific. In most cases,// you need to define at least routers option, as without this// option your clients will not be able to reach their default// gateway and will not have Internet connectivity."option-data":[{// For each IPv4 subnet you most likely need to specify at// least one router."name":"routers",
"data":"192.0.2.1"}],
// 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).//// Kea also support flexible identifier (flex-id), which lets you// specify an expression that is evaluated for each incoming packet.// Resulting value is then used for as an identifier.//// Note that reservations are subnet-specific in Kea. This is// different than ISC DHCP. Keep that in mind when migrating// your configurations."reservations":[// This is a reservation for a specific hardware/MAC address.// It's a rather simple reservation: just an address and nothing// else.{"hw-address":"1a:1b:1c:1d:1e:1f",
"ip-address":"192.0.2.201"},
// This is a reservation for a specific client-id. It also shows// the this client will get a reserved hostname. A hostname can// be defined for any identifier type, not just client-id.{"client-id":"01:11:22:33:44:55:66",
"ip-address":"192.0.2.202",
"hostname":"special-snowflake"},
// The third reservation is based on DUID. This reservation defines// a special option values for this particular client. If the// domain-name-servers option would have been defined on a global,// subnet or class level, the host specific values take preference.{"duid":"01:02:03:04:05",
"ip-address":"192.0.2.203",
"option-data":[{"name":"domain-name-servers",
"data":"10.1.1.202, 10.1.1.203"}]},
// The fourth reservation is based on circuit-id. This is an option// inserted by the relay agent that forwards the packet from client// to the server. In this example the host is also assigned vendor// specific options.//// When using reservations, it is useful to configure// reservations-global, reservations-in-subnet,// reservations-out-of-pool (subnet specific parameters)// and host-reservation-identifiers (global parameter).{"client-id":"01:12:23:34:45:56:67",
"ip-address":"192.0.2.204",
"option-data":[{"name":"vivso-suboptions",
"data":"4491"},
{"name":"tftp-servers",
"space":"vendor-4491",
"data":"10.1.1.202, 10.1.1.203"}]},
// This reservation is for a client that needs specific DHCPv4// fields to be set. Three supported fields are next-server,// server-hostname and boot-file-name{"client-id":"01:0a:0b:0c:0d:0e:0f",
"ip-address":"192.0.2.205",
"next-server":"192.0.2.1",
"server-hostname":"hal9000",
"boot-file-name":"/dev/null"},
// This reservation is using flexible identifier. Instead of// relying on specific field, sysadmin can define an expression// similar to what is used for client classification,// e.g. substring(relay[0].option[17],0,6). Then, based on the// value of that expression for incoming packet, the reservation// is matched. Expression can be specified either as hex or// plain text using single quotes.//// Note: flexible identifier requires flex_id hook library to be// loaded to work.{"flex-id":"'s0mEVaLue'",
"ip-address":"192.0.2.206"}// You can add more reservations here.]// You can add more subnets there.}],
// There are many, many more parameters that DHCPv4 server is able to use.// They were not added here to not overwhelm people with too much// information at once.// 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":"/var/log/kea-dhcp4.log"// Shorter log pattern suitable for use with systemd,// avoids redundant information// "pattern": "%-5p %m\n",// This governs whether the log output is flushed to disk after// every write.// "flush": false,// This specifies the maximum size of the file before it is// rotated.// "maxsize": 1048576,// This specifies the maximum number of rotated files to keep.// "maxver": 8}],
// 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}]}}
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:
Aus den oben genannten Konfigurationsparametern erstellen wir uns nun eine entsprechende Konfigurationsdatei /etc/kea/kea-dhcp4.conf für unseren Kea-DHCPv4-Daemon.
// 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.
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-Adresse10.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.
// This is a basic configuration for the Kea DHCPv6 server. Subnet declarations// are mostly commented out and no interfaces are listed. Therefore, the servers// will not listen or respond to any queries.// The basic configuration must be extended to specify interfaces on which// the servers should listen. There are a number of example options defined.// These probably don't make any sense in your network. Make sure you at least// update the following, before running this example in your network:// - change the network interface names// - change the subnets to match your actual network// - change the option values to match your network//// This is just a very basic configuration. Kea comes with large suite (over 30)// of configuration examples and extensive Kea User's Guide. Please refer to// those materials to get better understanding of what this software is able to// do. Comments in this configuration file sometimes refer to sections for more// details. These are section numbers in Kea User's Guide. The version matching// your software should come with your Kea package, but it is also available// in ISC's Knowledgebase (https://kea.readthedocs.io; 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":{// Add names of your network interfaces to listen on."interfaces-config":{// You typically want to put specific interface names here, e.g. eth0// but you can also specify unicast addresses (e.g. eth0/2001:db8::1) if// you want your server to handle unicast traffic in addition to// multicast. (DHCPv6 is a multicast based protocol)."interfaces":[]},
// Kea supports control channel, which is a way to receive management commands// while the server is running. This is a Unix domain socket that receives// commands formatted in JSON, e.g. config-set (which sets new configuration),// config-reload (which tells Kea to reload its configuration from file),// statistic-get (to retrieve statistics) and many more. For detailed// description, see Sections 9.12, 16 and 15."control-socket":{"socket-type":"unix",
"socket-name":"/tmp/kea6-ctrl-socket"},
// Use Memfile lease database backend to store leases in a CSV file.// Depending on how Kea was compiled, it may also support SQL databases// (MySQL and/or PostgreSQL). Those database backends require more// parameters, like name, host and possibly user and password.// There are dedicated examples for each backend. See Section 8.2.2 "Lease// Storage" for details."lease-database":{// Memfile is the simplest and easiest backend to use. It's an in-memory// C++ database that stores its state in CSV file."type":"memfile",
"lfc-interval":3600},
// Kea allows storing host reservations in a database. If your network is// small or you have few reservations, it's probably easier to keep them// in the configuration file. If your network is large, it's usually better// to use database for it. To enable it, uncomment the following:// "hosts-database": {// "type": "mysql",// "name": "kea",// "user": "kea",// "password": "kea",// "host": "localhost",// "port": 3306// },// See Section 8.2.3 "Hosts storage" for details.// Setup reclamation of the expired leases and leases affinity.// Expired leases will be reclaimed every 10 seconds. Every 25// seconds reclaimed leases, which have expired more than 3600// seconds ago, will be removed. The limits for leases reclamation// are 100 leases or 250 ms for a single cycle. A warning message// will be logged if there are still expired leases in the// database after 5 consecutive reclamation cycles.// If both "flush-reclaimed-timer-wait-time" and "hold-reclaimed-time" are// not 0, when the client sends a release message the lease is expired// instead of being deleted from the lease storage."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},
// These parameters govern global timers. Addresses will be assigned with// preferred and valid lifetimes being 3000 and 4000, respectively. Client// is told to start renewing after 1000 seconds. If the server does not// respond after 2000 seconds since the lease was granted, a client is// supposed to start REBIND procedure (emergency renewal that allows// switching to a different server)."renew-timer":1000,
"rebind-timer":2000,
"preferred-lifetime":3000,
"valid-lifetime":4000,
// These are global options. They are going to be sent when a client requests// them, unless overwritten with values in more specific scopes. The scope// hierarchy is:// - global// - subnet// - class// - host//// Not all of those options make sense. Please configure only those that// are actually useful in your network.//// For a complete list of options currently supported by Kea, see// Section 8.2.9 "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":[// When specifying options, you typically need to specify// one of (name or code) and data. The full option specification// covers name, code, space, csv-format and data.// space defaults to "dhcp6" which is usually correct, unless you// use encapsulate options. csv-format defaults to "true", so// this is also correct, unless you want to specify the whole// option value as long hex string. For example, to specify// domain-name-servers you could do this:// {// "name": "dns-servers",// "code": 23,// "csv-format": "true",// "space": "dhcp6",// "data": "2001:db8:2::45, 2001:db8:2::100"// }// but it's a lot of writing, so it's easier to do this instead:{"name":"dns-servers",
"data":"2001:db8:2::45, 2001:db8:2::100"},
// Typically people prefer to refer to options by their names, so they// don't need to remember the code names. However, some people like// to use numerical values. For example, DHCPv6 can optionally use// server unicast communication, if extra option is present. Option// "unicast" uses option code 12, so you can reference to it either// by "name": "unicast" or "code": 12. If you enable this option,// you really should also tell the server to listen on that address// (see interfaces-config/interfaces list above).{"code":12,
"data":"2001:db8::1"},
// String options that have a comma in their values need to have// it escaped (i.e. each comma is preceded by two backslashes).// That's because commas are reserved for separating fields in// compound options. At the same time, we need to be conformant// with JSON spec, that does not allow "\,". Therefore the// slightly uncommon double backslashes notation is needed.// Legal JSON escapes are \ followed by "\/bfnrt character// or \u followed by 4 hexadecimal numbers (currently Kea// supports only \u0000 to \u00ff code points).// CSV processing translates '\\' into '\' and '\,' into ','// only so for instance '\x' is translated into '\x'. But// as it works on a JSON string value each of these '\'// characters must be doubled on JSON input.{"name":"new-posix-timezone",
"data":"EST5EDT4\\,M3.2.0/02:00\\,M11.1.0/02:00"},
// Options that take integer values can either be specified in// dec or hex format. Hex format could be either plain (e.g. abcd)// or prefixed with 0x (e.g. 0xabcd).{"name":"preference",
"data":"0xf0"},
// A few options are encoded in (length, string) tuples// which can be defined using only strings as the CSV// processing computes lengths.{"name":"bootfile-param",
"data":"root=/dev/sda2, quiet, splash"}],
// Another thing possible here are hooks. Kea supports a powerful mechanism// that allows loading external libraries that can extract information and// even influence how the server processes packets. Those libraries include// additional forensic logging capabilities, ability to reserve hosts in// more flexible ways, and even add extra commands. For a list of available// hook libraries, see https://gitlab.isc.org/isc-projects/kea/wikis/Hooks-available.// "hooks-libraries": [// {// // Forensic Logging library generates forensic type of audit trail// // of all devices serviced by Kea, including their identifiers// // (like MAC address), their location in the network, times// // when they were active etc.// "library": "/usr/lib/kea/hooks/libdhcp_legal_log.so",// "parameters": {// "path": "/var/lib/kea",// "base-name": "kea-forensic6"// }// },// {// // Flexible identifier (flex-id). Kea software provides a way to// // handle host reservations that include addresses, prefixes,// // options, client classes and other features. The reservation can// // be based on hardware address, DUID, circuit-id or client-id in// // DHCPv4 and using hardware address or DUID in DHCPv6. However,// // there are sometimes scenario where the reservation is more// // complex, e.g. uses other options that mentioned above, uses part// // of specific options or perhaps even a combination of several// // options and fields to uniquely identify a client. Those scenarios// // are addressed by the Flexible Identifiers hook application.// "library": "/usr/lib/kea/hooks/libdhcp_flex_id.so",// "parameters": {// "identifier-expression": "relay6[0].option[37].hex"// }// }// ],// Below an example of a simple IPv6 subnet declaration. Uncomment to enable// it. This is a list, denoted with [ ], of structures, each denoted with// { }. Each structure describes a single subnet and may have several// parameters. One of those parameters is "pools" that is also a list of// structures."subnet6":[{// 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":"2001:db8:1::/64",
// Pools define the actual part of your subnet that is governed// by Kea. Technically this is optional parameter, but it's// almost always needed for DHCP to do its job. If you omit it,// clients won't be able to get addresses, unless there are// host reservations defined for them."pools":[{"pool":"2001:db8:1::/80"}],
// Kea supports prefix delegation (PD). This mechanism delegates// whole prefixes, instead of single addresses. You need to specify// a prefix and then size of the delegated prefixes that it will// be split into. This example below tells Kea to use// 2001:db8:1::/56 prefix as pool and split it into /64 prefixes.// This will give you 256 (2^(64-56)) prefixes."pd-pools":[{"prefix":"2001:db8:8::",
"prefix-len":56,
"delegated-len":64// Kea also supports excluded prefixes. This advanced option// is explained in Section 9.2.9. Please make sure your// excluded prefix matches the pool it is defined in.// "excluded-prefix": "2001:db8:8:0:80::",// "excluded-prefix-len": 72}],
"option-data":[// You can specify additional options here that are subnet// specific. Also, you can override global options here.{"name":"dns-servers",
"data":"2001:db8:2::dead:beef, 2001:db8:2::cafe:babe"}],
// 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 is a simple host reservation. The host with DUID matching// the specified value will get an address of 2001:db8:1::100.{"duid":"01:02:03:04:05:0A:0B:0C:0D:0E",
"ip-addresses":["2001:db8:1::100"]},
// This is similar to the previous one, but this time the// reservation is done based on hardware/MAC address. The server// will do its best to extract the hardware/MAC address from// received packets (see 'mac-sources' directive for// details). This particular reservation also specifies two// extra options to be available for this client. If there are// options with the same code specified in a global, subnet or// class scope, the values defined at host level take// precedence.{"hw-address":"00:01:02:03:04:05",
"ip-addresses":["2001:db8:1::101"],
"option-data":[{"name":"dns-servers",
"data":"3000:1::234"},
{"name":"nis-servers",
"data":"3000:1::234"}],
// This client will be automatically added to certain// classes."client-classes":["special_snowflake", "office"]},
// This is a bit more advanced reservation. The client with the// specified DUID will get a reserved address, a reserved prefix// and a hostname. This reservation is for an address that it// not within the dynamic pool. Finally, this reservation// features vendor specific options for CableLabs, which happen// to use enterprise-id 4491. Those particular values will be// returned only to the client that has a DUID matching this// reservation.{"duid":"01:02:03:04:05:06:07:08:09:0A",
"ip-addresses":["2001:db8:1:0:cafe::1"],
"prefixes":["2001:db8:2:abcd::/64"],
"hostname":"foo.example.com",
"option-data":[{"name":"vendor-opts",
"data":"4491"},
{"name":"tftp-servers",
"space":"vendor-4491",
"data":"3000:1::234"}]},
// This reservation is using flexible identifier. Instead of// relying on specific field, sysadmin can define an expression// similar to what is used for client classification,// e.g. substring(relay[0].option[17],0,6). Then, based on the// value of that expression for incoming packet, the reservation// is matched. Expression can be specified either as hex or// plain text using single quotes.// Note: flexible identifier requires flex_id hook library to be// loaded to work.{"flex-id":"'somevalue'",
"ip-addresses":["2001:db8:1:0:cafe::2"]}]}// More subnets can be defined here.// {// "subnet": "2001:db8:2::/64",// "pools": [ { "pool": "2001:db8:2::/80" } ]// },// {// "subnet": "2001:db8:3::/64",// "pools": [ { "pool": "2001:db8:3::/80" } ]// },// {// "subnet": "2001:db8:4::/64",// "pools": [ { "pool": "2001:db8:4::/80" } ]// }],
// Client-classes can be defined here. See "client-classes" in Dhcp4 for// an example.// DDNS information (how the DHCPv6 component can reach a DDNS daemon)// Logging configuration starts here. Kea uses different loggers to log various// activities. For details (e.g. names of loggers), see Chapter 18."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":"/var/log/kea-dhcp6.log"// Shorter log pattern suitable for use with systemd,// avoids redundant information// "pattern": "%-5p %m\n",// This governs whether the log output is flushed to disk after// every write.// "flush": false,// This specifies the maximum size of the file before it is// rotated.// "maxsize": 1048576,// This specifies the maximum number of rotated files to keep.// "maxver": 8}],
// 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}]}}
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:
Aus den oben genannten Konfigurationsparametern erstellen wir uns nun eine entsprechende Konfigurationsdatei /etc/kea/kea-dhcp6.conf für unseren Kea-DHCPv4-Daemon.
// 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.
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-Adressefd00::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:
# Inventory Datei für die System-Umgebung im SOHO## Hinweise:# - Kommentare beginnen mit einem '#'-Zeichen# - leere Zeilen werden ignoriert# - Host- und Gruppendefinitionen werden mit [] abgegrenzt# - Hosts können über ihren Hostnamen, FQN oder ihrer IP-Adresse definiert# - übergeordnete Gruppen werden durch [:children] abgegrenzt## Host-Definitionen# Hosts ohne Gruppenzuordnung
localhost
[edmz]
vml000210
[idmz]
vml000110
[intra]
pnc010007
vml010110
# Host-Gruppen-Definitionen # (zu welcher Gruppe gehören Untergruppen bzw. Hosts)[linux:children]
intra
edmz
idmz
Die beiden Beispiel-Hosts aus der Gruppe|Zone intra in diesem Inventory symbolisieren folgende unterschiedlichen Knoten.
Der Host pnc010007 steht exemplarisch für einen Client im Intranet. In dessen Inventory-File inventories/production/host_vars/pnc010007 sind die ihn beschreibenden Dateien 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.
Unser Playbook zum Installieren und Konfigurieren der beiden Kea-Daemon kea-dhcp4 und kea-dhcp6, ist wie immer schlank, unscheinbar und unspektakulär, beinhaltet aber Hinweise zur Aufgabe und wie es aufzurufen ist.
---# Ansible Playbook zum Installieren und Konfigiurieren deines IPv4-DHCP-Servers auf Basis Kea.## Aufruf via:# $ ansible-playbook playbooks/kea-dhcp.yml
- name: "Playbookname: kea_dhcp.yml"# Name des Playbooks
hosts: vml010110 # Host bzw. Hostgruppen für die das Playbook gelten soll
roles:
- role: kea_dhcp # Kea-DHCP4|6 Daemon einrichten...
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.
Wie wir sehen ist die Rolle durchaus überschaubar, im Task main.yaml verweisen wir lediglich auf die eigentlichen Tasks vorbereitung, dhcp4, dhcp6 und firewalld
---
- name: "Konfiguration der firewalld Regeln in Zone_2 für die Kea-Daemon."
ansible.posix.firewalld:
zone: '{{ guest_zone_2 }}'
service: '{{ item.service }}'
immediate: true
permanent: true
state: enabled
with_items: '{{ guest_fw_services }}'
- name: "Zum Schluss den aktuellen permanenten Regelsatz final neu laden."
ansible.builtin.service:
name: firewalld
state: reloaded
...
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 notwendig. 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.
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.
//
// *** Ansible managed configuration file, do not modify manually! ***
//
// This is a basic configuration for the Kea DHCPv4 server. See section
// 8.2. DHCPv4 Server Configuration for detailed informations; the direct link
// for the stable version is https://kea.readthedocs.io/en/latest/.
//
// 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": [ "{{ guest_nic_2 }}" ],
"dhcp-socket-type": "{{ dhcp4_interface_socket_type }}"
},
// See section 8.9. Management API for the DHCPv4 Server for more details.
"control-socket": {
"socket-type": "{{ dhcp4_mgmt_socket_type }}",
"socket-name": "{{ dhcp4_mgmt_socket_name }}"
},
// See Section 8.2.2.1. Memfile - Basic Storage for Leases for details.
"lease-database": {
"type": "{{ dhcp4_lease_db_type }}",
"persist": {{ dhcp4_lease_db_persists }},
"name": "{{ dhcp4_lease_db_name }}",
"lfc-interval": {{ dhcp4_lease_lfc_interval }},
"max-row-errors": {{ dhcp4_lease_max_errors }}
},
// 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": {{ dhcp4_reclaim_timer_wait_time }},
"flush-reclaimed-timer-wait-time": {{ dhcp4_flush_reclaimed_timer_wait_time }},
"hold-reclaimed-time": {{ dhcp4_hold_reclaimed_time }},
"max-reclaim-leases": {{ dhcp4_max_reclaim_leases }},
"max-reclaim-time": {{ dhcp4_max_reclaim_time }},
"unwarned-reclaim-cycles": {{ dhcp4_unwarned_reclaim_cycles }}
},
// 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": {{ dhcp4_renew_timer }},
"rebind-timer": {{ dhcp4_rebind_timer }},
"valid-lifetime": {{ dhcp4_valid_lifetime }},
// 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": "{{ dhcp4_dns }}"
},
// Domain-Name:
{
"name": "domain-name",
"data": "{{ dhcp4_domain }}"
},
// Time-Server:
{
"name": "ntp-servers",
"data": "{{ dhcp4_timeserver }}"
},
// Time-Offset ( Eastern Standard Time):
{
"name": "time-offset",
"data": "{{ dhcp4_timeoffset }}"
}
],
// 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.
// Subnet identifier for zone {{ guest_zone_1 }}
"id": {{ dhcp4_subnetid_1 }},
// This is mandatory parameter for each subnet.
"subnet": "{{ dhcp4_subnet_1 }}",
// Pools define the actual part of your subnet that is governed
// by Kea.
"pools": [ { "pool": "{{ dhcp4_pool_1 }}" } ],
// These are options that are subnet specific.
"option-data": [
{
// Router for the IPv4 subnet.
"name": "routers",
"data": "{{ guest_ip4_2 }}"
},
{
// Time-Server:
"name": "ntp-servers",
"data": "{{ dhcp4_timeserver }}"
},
{
// Domain-Name-Server:
"name": "domain-name-servers",
"data": "{{ dhcp4_dns }}"
}
],
// 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.
{% for host in groups['intra'] %}
// "{{ hostvars[host]['host_beschreibung'] }}"
{
"hw-address": "{{ hostvars[host]['host_mac'] }}",
"ip-address": "{{ hostvars[host]['host_ipv4'] }}",
"hostname": "{{ host }}.{{ guest_zone_2 }}.{{ guest_domain }}"
},
{% endfor %}
// Dummy entry - example definition
{
"hw-address": "00:00:00:00:00:00",
"ip-address": "10.0.10.254",
"hostname": "dummy.{{ guest_zone_2 }}.{{ guest_domain }}"
}
]
}
],
// See Section 19.1. Logging Configuration for details.
// 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": "{{ dhcp4_logger_name }}",
"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": "{{ dhcp4_logger_output }}"
}
],
// This specifies the severity of log messages to keep. Supported values
// are: FATAL, ERROR, WARN, INFO, DEBUG
"severity": "{{ dhcp4_logger_severity }}",
// 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": {{ dhcp4_logger_debug_level }}
}
]
}
}
//
// *** Ansible managed configuration file, do not modify manually! ***
//
// 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": [ "{{ guest_nic_2 }}" ]
},
// 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": "{{ dhcp6_mgmt_socket_type }}",
"socket-name": "{{ dhcp6_mgmt_socket_name }}"
},
// 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": "{{ dhcp6_lease_db_type }}",
"persist": {{ dhcp6_lease_db_persists }},
"name": "/var/lib/kea/kea-leases6.csv",
"lfc-interval": {{ dhcp6_lease_lfc_interval }},
"max-row-errors": {{ dhcp6_lease_max_errors }}
},
// 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": {{ dhcp6_reclaim_timer_wait_time }},
"flush-reclaimed-timer-wait-time": {{ dhcp6_flush_reclaimed_timer_wait_time }},
"hold-reclaimed-time": {{ dhcp6_hold_reclaimed_time }},
"max-reclaim-leases": {{ dhcp6_max_reclaim_leases }},
"max-reclaim-time": {{ dhcp6_max_reclaim_time }},
"unwarned-reclaim-cycles": {{ dhcp6_unwarned_reclaim_cycles }}
},
// 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": {{ dhcp6_valid_lifetime }},
"renew-timer": {{ dhcp6_renew_timer }},
"rebind-timer": {{ dhcp6_rebind_timer }},
"preferred-lifetime": {{ dhcp6_preferred_lifetime }},
// 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": "{{ dhcp6_dns }}"
},
// Domain-Search-Liste:
{
"name": "domain-search",
"data": "{{ dhcp6_domain }}"
}
],
// 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": "{{ guest_nic_2 }}",
// 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 {{ guest_zone_2 }}
"id": {{ dhcp6_subnetid_1 }},
// This is mandatory parameter for each subnet.
"subnet": "{{ dhcp6_subnet_1 }}",
// Pools define the actual part of your subnet that is governed
// by Kea.
"pools": [ { "pool": "{{ dhcp6_pool_1 }}" } ],
"option-data": [
// You can specify additional options here that are subnet
// specific. Also, you can override global options here.
{
"name": "dns-servers",
"data": "{{ dhcp6_dns }}"
},
{
"name": "sntp-servers",
"data": "{{ dhcp6_dns }}"
}
],
// 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.
{% for host in groups['intra'] %}
// "{{ hostvars[host]['host_beschreibung'] }}"
{
"duid": "{{ hostvars[host]['host_duid'] }}",
"ip-addresses": [ "{{ hostvars[host]['host_ipv6'] }}" ],
"hostname": "{{ host }}.{{ guest_zone_2 }}.{{ guest_domain }}"
},
{% endfor %}
// Dummy entry - example definition
{
"duid": "00:00:00:00:00:00:00:00:00:00",
"ip-addresses": [ "fd00:0:0:7:10:0:10:9999" ],
"hostname": "dummy.{{ guest_zone_2 }}.{{ guest_domain }}"
}
]
}
],
// 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": "{{ dhcp6_logger_name }}",
"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": "{{ dhcp6_logger_output }}"
}
],
// This specifies the severity of log messages to keep. Supported values
// are: FATAL, ERROR, WARN, INFO, DEBUG
"severity": "{{ dhcp6_logger_severity }}",
// 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": {{ dhcp6_logger_debug_level }}
}
]
}
}
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 Konfigurationsdateien 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.
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
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.
django