linux:kea

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:

  • Netzwerkinterface :
    Unser DHCPv4-Daemon soll auf dem Netzwerkinterface eth1 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-Adresse 10.0.0.27 erreichbar.
  • Domain-Name :
    Der Name unserer Domain lautet nausch.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-Adresse 10.0.0.17 erreichbar.
  • Router :
    Der Default-Router ist unter der IP-Adresse 10.0.0.17 erreichbar.
  • Subnetz :
    Der DHCPv4-Server ist zuständig für das Netz 10.0.10.0/24
  • Pool (dynamischer Adress-Bereich) :
    Dynamische IP-Adressen sollen aus dem Bereich von 10.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

/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
Diese Website verwendet Cookies. Durch die Nutzung der Website stimmen Sie dem Speichern von Cookies auf Ihrem Computer zu. Außerdem bestätigen Sie, dass Sie unsere Datenschutzbestimmungen gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information
  • linux/kea.txt
  • Zuletzt geändert: 02.03.2024 21:50.
  • von django