Inhaltsverzeichnis

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

:GO: under construction - an dem Artikel wird gerade gefeilt … coming soon! :GO:

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

Im wesentlichen unterscheidet sich Kea von seinem Vorgänger unter anderem durch sein modulares 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

FIXME

DHCPv4-Adressvergabe

FIXME

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.

1. Stufe der DHCP-Adressanfrage - DHCPDISCOVER 

 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.

2. Stufe der DHCP-Adressanfrage - DHCPOFFER 

 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.

3. Stufe der DHCP-Adressanfrage - DHCPREQUEST 

 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.

3. Stufe der DHCP-Adressanfrage - DHCPACK 

 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.

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

Im 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.

FIXME

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.

  1. Als User: 
     $ sudo pacman -S kea
  2. 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

Paketinhalte

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:

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

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

/etc/kea/kea-dhcp4.conf

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

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

So können wir später bei etwaigen Bedarf Vergleiche zur originalen Konfigurationsdatei mit unserer individuellen Konfigurationsdatei anstreben, wie in diesem Beispiel hier: 

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

FIXME

1)
Unreliable Datagram Protocol
2)
Media Access Control