DHCPv4|v6-Server mit DHCP ISC Kea unter Arch Linux einrichten und nutzen
under construction - an dem Artikel wird gerade gefeilt … coming soon!
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 Komponentenbasierenden 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 zwei Hosts mit den entsprechenden Adressen vermerkt:
Subnetz (ID) | Subnetz (Use) | Subnetz Addresse - | Host Address-Range (global Unicast) | Host - | IPv4 - | Link-Local-Scope - | Site-Local-Scope - | Global-Scope - |
---|---|---|---|---|---|---|---|---|
7 | Intra | 2003:a:e0d:7607::/64 | 2003:a:e0d:7607:: | |||||
pml010102 | 10.0.10.102 | fd00::7:10:0:10:102 | fe80::7:10:ff:fe10:102 | 2003:a:e0d:7607:10:0:10:102 |
||||
vml010110 | 10.0.10.110 | fd00::7:10:0:10:110 | fe80::7:10:ff:fe10:110 | 2003:a:e0d:7607:10:0:10:110 |
Grundsätzliches
DHCPv4-Adressvergabe
Der grundsätzliche Ablauf bei der Adress-Anfrage folgt dabei folgendem Schema. Die Kommunikation zwischen dem Server (Port 67) und dem Klienten (Port 68) erfolgte mittels UPD1).
Beim Booten des Klienten 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 MAC2)-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.
Sep 12 21:34:12 nss dhcpd: DHCPDISCOVER from 00:04:13:23:3f:b5 via eth0
Dieses Broadcast-Paket beantwortet nun der DHCP-Server mit einer DHCPOFFER-Nachricht. Das Antwortpaket beinhaltet bereits als Zieladresse die IP, welche der Klient in Zukunft bekommen soll. Da bei der vorherigen Anfrage des Klienten, dieser seine eigene MAC-Adresse mitschickte, kann nun auf diese Weise die DHCPOFFER-Nachricht ihr Ziel finden.
Sep 12 21:34:12 nss dhcpd: DHCPOFFER on 192.168.10.61 to 00:04:13:23:3f:b5 via eth0
Der Klient hat also vom DHCP-Server ein sogenanntes Angebot (offer) bekommen und entscheidet nun, ob es für ihn so in Ordnung ist. Trifft dies zu, sendet er eine DHCPREQUEST-Nachricht, an den DHCP-Server um diesen mitzuteilen, daß er diese Konfiguration nutzen will.
Sep 12 21:34:12 nss dhcpd: DHCPREQUEST for 192.168.10.61 (192.168.10.1) from 00:04:13:23:3f:b5 via eth0
Der DHCP-Server bestätigt dies und sendet eine DHCPACK-Nachricht, somit besitzt der Klient nun seine eigene IP-Adresse und kennt ggf. noch weitere Parameter für seine weitere Netzwerkkommunkation.
Sep 12 21:34:12 nss dhcpd: DHCPACK on 192.168.10.61 to 00:04:13:23:3f:b5 via eth0
Der gesamte erfolgreiche Ablauf aus Sicht des DHCP-Servers entspricht folgendem Diagramm.
Im syslog des DHCP-Servers wird der Ablauf wie folgt festgehalten:
Sep 12 21:34:12 nss dhcpd: DHCPDISCOVER from 00:04:13:23:3f:b5 via eth0 Sep 12 21:34:12 nss dhcpd: DHCPOFFER on 192.168.10.61 to 00:04:13:23:3f:b5 via eth0 Sep 12 21:34:12 nss dhcpd: DHCPREQUEST for 192.168.10.61 (192.168.10.1) from 00:04:13:23:3f:b5 via eth0 Sep 12 21:34:12 nss dhcpd: DHCPACK on 192.168.10.61 to 00:04:13:23:3f:b5 via eth0
Sollte die ganze Prozedur Fehl schlagen, z.B. weil der Klient herausgefunden hat, daß die IP-Adresse doppelt vergeben ist, sendet er eine DHCPDECLINE-Nachricht an der Server. Im Falle einer DHCPDECLINE-Nachricht, sperrt der Server die Adresse für die interne Vergabe und die gesamte Vergabeprozedur beginnt erneut von vorne.
Zusammen mit seiner IP-Adresse erhält der Klient 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, daß der Klient nach der Hälfte der Lease-Time einen erneuten DHCPREQUEST sendet. So teilt er dem Server mit, daß 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 Klient 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 Klienten kann dieser dem Server mit einer DHCPRELEASE-Nachricht den Server informieren, damit dieser die Adresse wieder freigeben kann.
Sep 12 21:58:17 nss dhcpd: DHCPRELEASE of 192.168.10.238 from 00:17:a4:7d:26:1a (hpc6180) via eth0 (found)
Der Klient 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 Klienten eine feste IP-Adresse zugeteilt wurde. Dann entfallen die Initialisierungsschritte und der Klient schickt direkt eine DHCPREQUEST-Nachricht an den DHCP-Server. Dieser bestätigt entweder die Anfrage oder sendet eine DHCPNAK-Nachricht um dem Klienten mitzuteilen, daß dieser seine gespeicherten Konfigurationen zu löschen, und die Anfrage komplett von vorne zu beginnen hat.
Sep 12 22:01:13 nss dhcpd: DHCPREQUEST for 192.168.10.15 from 00:17:a4:7d:26:1a via eth0 Sep 12 22:01:13 nss dhcpd: DHCPACK on 192.168.10.15 to 00:17:a4:7d:26:1a via eth0
DHCPv6-Adressvergabe
t.b.d.
Installation
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
Paketinhalt
Was uns das Paket kea alles in das System unseres Arch Linux Server gebracht hat, können wir wie folgt abfragen:
# pacman -Qil kea
Dokumentation
Eine ausführliche Onlinedokumentation des modernen Open Source DHCPv4 & DHCPv6 Server Kea findet sich auf der entsprechenden Dokumentationsseite bei Read the Docs → https://kea.readthedocs.io/en/latest/ .
Konfiguration
Die Konfiguration unseres DHCPv4 und DHCPv6-Servers wie auch des Controll-Agenten und ggf. des Kea DHCP DDNS Daemaons erfolgt über JSON-Konfigurationsdateien im Verzeichnis /etc/kea/
.
DHCPv4 Server
Zunächst wollen wir uns eingehend mit der Konfiguration unseres DHCPv4-Daemons befassen. Die zugehörige Original-Dokumentation findet sich im Abschnitt 8.2. DHCPv4 Server Configuration.
In unserer Betriebsumgebung haben wir folgende Rahmenbedingungen für unseren DHCPv4-Server:
- Netzwerkinterface :
Unser DHCPv4-Daemon soll auf dem Netzwerkinterfaceeth1
auf entsprechende Adressanfragen lauschen und ausliefern. - 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. - Name-Server :
Der interne DNS-Daemon ist unter der IP-Adresse10.0.0.27
erreichbar. - Domain-Name :
Der Name unserer Domain lautetnausch.org
. - Domain-Search-Liste :
Der DHCPv4-Server soll als Domain-Search-List ausgeben:"edmz.nausch.org, idmz.nausch.org, intra.nausch.org"
- Time-Server :
Der interne Time-Server ist unter der IP-Adresse10.0.0.17
erreichbar. - Router :
Der Default-Router ist unter der IP-Adresse10.0.0.17
erreichbar. - Subnetz :
Der DHCPv4-Server ist zuständig für das Netz10.0.10.0/24
- Pool (dynamischer Adress-Bereich) :
Dynamische IP-Adressen sollen aus dem Bereich von10.0.10.230 - 10.0.10.250
vergeben werden.
Bei der Installation unseres Kea-Servers wurde uns eine entsprechende Musterkonfigurations-Datei bereits mitgeliefert.
# less /etc/kea/kea-dhcp4.conf
Bevor wir nun aber unseren Kea-DHCPv4-Daemon individuell nach unseren Bedürfnissen hin anpassen, werden wir zunächst die im Paket mitgelieferte Original-Konfigurationsdatei /etc/kea/kea-dhcp4.conf
für spätere Referenzen sichern.
# cp -a /etc/kea/kea-dhcp4.conf /etc/kea/kea-dhcp4.conf.orig
So können wir später bei etwaigen Bedarf Vergleiche zur originalen Konfigurationsdatei mit unserer individuellen Konfigurationsdatei anstreben, wie in diesem Beispiel hier:
# vimdiff /etc/kea/kea-dhcp4.conf /etc/kea/kea-dhcp4.conf.orig