Tachtler's DokuWiki

Homepage | Kontakt | Rechtliche Informationen | Impressum

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Zuletzt angesehen: • dhcp_isc_kea_archlinux
tachtler:dhcp_isc_kea_archlinux

Inhaltsverzeichnis

DHCP ISC Kea ArchLinux

DHCP ISC Kea ist ein DHCP-Server, welcher die IP-Adressverteilung in einem Netzwerk realisieren kann. Der DHCP-Server des ISC (Internet System Consortium) ist eine Neuentwicklung und lösten den in die Jahre gekommenen DHCP ISC dhcpd ab.

:!: Hinweis - Die nachfolgenden Ausführungen erheben keinen Anspruch auf Vollständigkeit, sondern stellen eine „Basiskonfiguration“ eins DHCP-Servers für ein kleines privates Netzwerk dar!!!

Beschreibung Externer Link
Homepage https://www.isc.org/kea/
Dokumentation https://kea.readthedocs.io/en/latest/index.html
Migrationstool https://gitlab.isc.org/isc-projects/dhcp/-/tree/master/keama

Ab hier werden zur Ausführung nachfolgender Befehle root-Rechte benötigt. Um der Benutzer root zu werden, melden Sie sich bitte als root-Benutzer am System an, oder wechseln mit nachfolgendem Befehl zum Benutzer root: 

$ su -
Password:

Überblick

Im nachfolgenden soll die Konfiguration

  • eines DHCP-Servers für IPv4
  • eines DHCP-Servers für IPv6

welche als internes, nicht nach außen agierender DHCP-Server Konstrukt für ein privates Netzwerk mit einem Netz durchgeführt werden. Nachfolgendes Netz wird dabei verwaltet:

  • Intranet - Domain: intra.tachtler.net - IPv4-Adressbereich: 192.168.0.0/24
  • Intranet - Domain: intra.tachtler.net - IPv6-Adressbereich: fd00::dead:192:168:0:0/64

Installation

Zur Installation von DHCP ISC Kea wird nachfolgendes Paket benötigt:

  • kea - ist im community-Repository von ArchLinux enthalten.

Mit nachfolgendem Befehl, wird das Pakete kea installiert: 

# pacman --noconfirm -S kea

Installationsverlauf

Mit nachfolgendem Befehl kann überprüft werden, welche Inhalte mit den Paket kea installiert wurden. 

# pacman -Qil kea

Installierte Dateien

Dienst/Deamon-Start einrichten

Um einen DHCP-Servers für IPv4 und für DHCP-Servers für IPv6, welche als Dienst/Deamon als Hintergrundprozess laufen sollen, auch nach einem Neustart des Servers zur Verfügung zu haben, soll die Dienste/Daemons mit dem Server mit gestartet werden, was mit nachfolgenden Befehlen realisiert werden kann: 

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

Eine Überprüfung, ob beim Neustart des Server der kea-dhcp4- und der kea-dhcp6-Dienst/Deamon wirklich mit gestartet werden, kann mit nachfolgenden Befehlen erfolgen und sollte eine Anzeige, wie ebenfalls nachfolgend dargestellt ausgeben: 

# systemctl list-unit-files --type=service | grep kea-dhcp..service
kea-dhcp4.service                          enabled         disabled
kea-dhcp6.service                          enabled         disabled

bzw. 

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

iptables/ip6tables Regeln

Damit der DHCP ISC Kea auch erreichbar ist und nicht die Proxy-Anfragen vom Paketfilter iptables blockiert werden, müssen nachfolgende Regeln zum iptables-Regelwerk hinzugefügt werden.

Um die aktuellen iptables-Regeln erweitern zu können, sollten diese erst einmal aufgelistet werden, was mit nachfolgendem Befehl durchgeführt werden kann: 

# iptables -L -nv --line-numbers
Chain INPUT (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1     1169 2101K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
2        0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
3        0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
4        1    60 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
5        0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 5 prefix "REC-INP Defend "
6        0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with tcp-reset
7        0     0 REJECT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable
8        0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-proto-unreachable

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 917 packets, 84944 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Nachfolgende Befehle, fügen folgende iptables-Regeln dem iptables-Regelwerk nach der Position 4 hinzu, ohne das der Paketfilter angehalten werden muss: 

  • -A INPUT -p udp --dport 67 -j ACCEPT
  • -A OUTPUT -p udp --dport 68 -j ACCEPT

und hier die Befehle: 

# iptables -I INPUT 5 -p udp --dport 67 -j ACCEPT
# iptables -I OUTPUT 1 -p udp --dport 68 -j ACCEPT

Ein erneute Abfrage des iptables-Regelwerts, sollte dann nachfolgend dargestellte Ausgabe ergeben, was mit folgendem Befehl durchgeführt werden kann: 

# iptables -L -nv --line-numbers
Chain INPUT (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1     1202 2103K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
2        0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
3        0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
4        1    60 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
5        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:67
6        0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 5 prefix "REC-INP Defend "
7        0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with tcp-reset
8        0     0 REJECT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable
9        0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-proto-unreachable

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 7 packets, 936 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:68

Die neuen Zeilen sind an Position 5 (INPUT) und Position 1 (OUTPUT) zu sehen, hier nachfolgend zur Verdeutlichung noch einmal dargestellt (nur relevanter Ausschnitt): 

...
5        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:67
1        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:68
...

Um diese iptables-Regel dauerhaft, auch nach einem Neustart des Server, weiterhin im iptables-Regelwerk zu speichern, muss nachfolgend dargestellter Befehl abschliessend noch ausgeführt werden: 

# /usr/sbin/iptables-save > /etc/iptables/iptables.rules

Nachfolgender Befehl kann dazu verwendet werden, um zu überprüfen, ob das iptables-Regelwerk auch korrekt gespeichert wurde: 

# cat /etc/iptables/iptables.rules
# Generated by iptables-save v1.8.7 on Wed Mar 31 10:13:23 2022
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [13:3332]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -j LOG --log-prefix "REC-INP Defend " --log-level 5
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
-A OUTPUT -p udp -m udp --dport 68 -j ACCEPT
COMMIT
# Completed on Wed Mar 31 10:13:23 2022
# Generated by iptables-save v1.8.7 on Wed Mar 31 10:13:23 2022
*nat
:PREROUTING ACCEPT [5:352]
:INPUT ACCEPT [1:60]
:OUTPUT ACCEPT [8:577]
:POSTROUTING ACCEPT [8:577]
COMMIT
# Completed on Wed Mar 31 10:13:23 2022
# Generated by iptables-save v1.8.7 on Wed Mar 31 10:13:23 2022
*mangle
:PREROUTING ACCEPT [1216:2104461]
:INPUT ACCEPT [1212:2104169]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [944:91396]
:POSTROUTING ACCEPT [944:91396]
COMMIT
# Completed on Wed Mar 31 10:13:23 2022

Um die aktuellen ip6tables-Regeln erweitern zu können, sollten diese erst einmal aufgelistet werden, was mit nachfolgendem Befehl durchgeführt werden kann: 

# ip6tables -nvL --line-numbers
Chain INPUT (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 ACCEPT     all      *      *       ::/0                 ::/0                 ctstate RELATED,ESTABLISHED
2        0     0 ACCEPT     icmp     *      *       ::/0                 ::/0                
3        0     0 ACCEPT     all      lo     *       ::/0                 ::/0                
4        0     0 ACCEPT     tcp      *      *       ::/0                 ::/0                 tcp dpt:22
5        0     0 LOG        all      *      *       ::/0                 ::/0                 LOG flags 0 level 5 prefix "REC-INP Defend "
6        0     0 REJECT     tcp      *      *       ::/0                 ::/0                 reject-with tcp-reset
7        0     0 REJECT     udp      *      *       ::/0                 ::/0                 reject-with icmp6-port-unreachable
8        0     0 REJECT     all      *      *       ::/0                 ::/0                 reject-with icmp6-addr-unreachable

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 LOG        all      *      *       ::/0                 ::/0                 LOG flags 0 level 5 prefix "REC-FWD Defend "
2        0     0 REJECT     tcp      *      *       ::/0                 ::/0                 reject-with tcp-reset
3        0     0 REJECT     udp      *      *       ::/0                 ::/0                 reject-with icmp6-port-unreachable
4        0     0 REJECT     all      *      *       ::/0                 ::/0                 reject-with icmp6-addr-unreachable

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Nachfolgende Befehle, fügen folgende ip6tables-Regeln dem ip6tables-Regelwerk nach der Position 4 hinzu, ohne das der Paketfilter angehalten werden muss: 

  • -A INPUT -p udp --dport 67 -j ACCEPT
  • -A OUTPUT -p udp --dport 68 -j ACCEPT

und hier die Befehle: 

# ip6tables -I INPUT 5 -p udp --dport 67 -j ACCEPT
# ip6tables -I OUTPUT 1 -p udp --dport 68 -j ACCEPT

Ein erneute Abfrage des ip6tables-Regelwerts, sollte dann nachfolgend dargestellte Ausgabe ergeben, was mit folgendem Befehl durchgeführt werden kann: 

# ip6tables -nvL --line-numbers
Chain INPUT (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 ACCEPT     all      *      *       ::/0                 ::/0                 ctstate RELATED,ESTABLISHED
2        0     0 ACCEPT     icmp     *      *       ::/0                 ::/0                
3        0     0 ACCEPT     all      lo     *       ::/0                 ::/0                
4        0     0 ACCEPT     tcp      *      *       ::/0                 ::/0                 tcp dpt:22
5        0     0 ACCEPT     udp      *      *       ::/0                 ::/0                 udp dpt:67
6        0     0 LOG        all      *      *       ::/0                 ::/0                 LOG flags 0 level 5 prefix "REC-INP Defend "
7        0     0 REJECT     tcp      *      *       ::/0                 ::/0                 reject-with tcp-reset
8        0     0 REJECT     udp      *      *       ::/0                 ::/0                 reject-with icmp6-port-unreachable
9        0     0 REJECT     all      *      *       ::/0                 ::/0                 reject-with icmp6-addr-unreachable

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 LOG        all      *      *       ::/0                 ::/0                 LOG flags 0 level 5 prefix "REC-FWD Defend "
2        0     0 REJECT     tcp      *      *       ::/0                 ::/0                 reject-with tcp-reset
3        0     0 REJECT     udp      *      *       ::/0                 ::/0                 reject-with icmp6-port-unreachable
4        0     0 REJECT     all      *      *       ::/0                 ::/0                 reject-with icmp6-addr-unreachable

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     udp  --  *      *       ::/0                 ::/0                 udp dpt:68

Die neuen Zeilen sind an Position 5 (INPUT) und Postition 6 (INTPUT) zu sehen, hier nachfolgend zur Verdeutlichung noch einmal dargestellt (nur relevanter Ausschnitt): 

...
5        0     0 ACCEPT     udp      *      *       ::/0                 ::/0                 udp dpt:67 
1        0     0 ACCEPT     udp  --  *      *       ::/0                 ::/0                 udp dpt:68 
...

Um diese ip6tables-Regel dauerhaft, auch nach einem Neustart des Server, weiterhin im ip6tables-Regelwerk zu speichern, muss nachfolgend dargestellter Befehl abschließend noch ausgeführt werden: 

# /usr/sbin/ip6tables-save > /etc/iptables/ip6tables.rules

Nachfolgender Befehl kann dazu verwendet werden, um zu überprüfen, ob das ip6tables-Regelwerk auch korrekt gespeichert wurde: 

# cat /etc/iptables/ip6tables.rules
# Generated by ip6tables-save v1.8.7 on Wed Mar 31 10:15:10 2022
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed on Wed Mar 31 10:15:10 2022
# Generated by ip6tables-save v1.8.7 on Wed Mar 31 10:15:10 2022
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -j LOG --log-prefix "REC-INP Defend " --log-level 5
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -p udp -j REJECT --reject-with icmp6-port-unreachable
-A INPUT -j REJECT --reject-with icmp6-addr-unreachable
-A FORWARD -j LOG --log-prefix "REC-FWD Defend " --log-level 5
-A FORWARD -p tcp -j REJECT --reject-with tcp-reset
-A FORWARD -p udp -j REJECT --reject-with icmp6-port-unreachable
-A FORWARD -j REJECT --reject-with icmp6-addr-unreachable
-A OUTPUT -p udp -m udp --dport 68 -j ACCEPT
COMMIT
# Completed on Wed Mar 31 10:15:10 2022
# Generated by ip6tables-save v1.8.7 on Wed Mar 31 10:15:10 2022
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed on Wed Mar 31 10:15:10 2022

Basis-Konfiguration:

Nachfolgende Konfigurationsschritte sollen eine grundlegende Konfiguration des DHCP ISC Kea darstellen und erheben keinen Anspruch auf Vollständigkeit in Bezug auf die Möglichkeiten die der DHCP ISC Kea bietet.

/etc/kea/kea-dhcp4.conf

Nachfolgende Konfigurationsdatei /etc/kea/kea-dhcp4.conf, stellt die Möglichkeit dar DHCP via IPv4 durchzuführen.

Dies ist die komplette Konfigurationsdatei: 

{
//
// DHCPv4 configuration starts here. This section will be read by DHCPv4 server
// and will be ignored by other components.
//
"Dhcp4": {
        // ---------------------------------------------------------------------
        // 8.2.2. Lease Storage
        // 8.2.2.1. Memfile - Basic Storage for Leases
        // ---------------------------------------------------------------------
        "lease-database": {
                "type": "memfile",
                "persist": true,
                "name": "/var/lib/kea/kea-leases4.csv",
                "lfc-interval": 3600,
                "max-row-errors": 0
        },
        // ---------------------------------------------------------------------
        // 8.2.4. Interface Configuration
        // ---------------------------------------------------------------------
        "interfaces-config": {
                "interfaces": [ "*" ],
                "dhcp-socket-type": "raw"
        },
        // ---------------------------------------------------------------------
        // 8.2.9. Sending T1 (Option 58) and T2 (Option 59) 
        // ---------------------------------------------------------------------
        "calculate-tee-times": true,
        "t1-percent": 0.50,
        "t2-percent": 0.875,
        // ---------------------------------------------------------------------
        // 8.2.21. Echoing Client-ID (RFC 6842)
        // ---------------------------------------------------------------------
        "echo-client-id": false,
        // ---------------------------------------------------------------------
        // 8.2.22. Using Client Identifier and Hardware Address
        // ---------------------------------------------------------------------
        "match-client-id": true,
        // ---------------------------------------------------------------------                                      
        // 8.2.25. Sanity Checks in DHCPv4
        // ---------------------------------------------------------------------
        "sanity-checks": {
                "lease-checks": "del"
        },
        // ---------------------------------------------------------------------
        // 8.2.27. Multi-Threading Settings
        // ---------------------------------------------------------------------
        "multi-threading": {
                "enable-multi-threading": true,
                "thread-pool-size": 4,
                "packet-queue-size": 7
        },
        // ---------------------------------------------------------------------
        // 8.3.8. Fine-Tuning DHCPv4 Host Reservation
        // ---------------------------------------------------------------------
        "reservations-global": false,
        "reservations-in-subnet": true,
        "reservations-out-of-pool": false,
        // ---------------------------------------------------------------------
        // 8.7. Duplicate Addresses (DHCPDECLINE Support)
        // ---------------------------------------------------------------------
        "decline-probation-period": 3600,
        // ---------------------------------------------------------------------
        // 8.9. Management API for the DHCPv4 Server
        // ---------------------------------------------------------------------
        "control-socket": {
                "socket-type": "unix",
                "socket-name": "/var/lib/kea/kea4-ctrl-socket"
        },
        // ---------------------------------------------------------------------                                      
        // 8.2.6. IPv4 Subnet Identifier
        // 8.2.7. IPv4 Subnet Prefix
        // 8.2.8. Configuration of IPv4 Address Pools
        // ---------------------------------------------------------------------
        "subnet4": [
                {
                        // =====================================================
                        // Subnet 192.168.0.0/24 (Intranet).
                        // =====================================================
                        "id": 1,
                        "subnet": "192.168.0.0/24",
                        // -----------------------------------------------------
                        // 8.2.10. Standard DHCPv4 Options
                        // -----------------------------------------------------
                        "option-data": [
                                // ---------------------------------------------
                                // 8.5. Server Identifier in DHCPv4
                                // ---------------------------------------------
                                {
                                        "space": "dhcp4",
                                        "name": "dhcp-server-identifier",
                                        "code": 54,
                                        "data": "192.168.0.1"
                                },
                                {
                                        "space": "dhcp4",
                                        "name": "broadcast-address",
                                        "code": 28,
                                        "data": "192.168.0.255"
                                },
                                {
                                        "space": "dhcp4",
                                        "name": "domain-name",
                                        "code": 15,
                                        "data": "intra.tachtler.net"
                                },
                                {
                                        "space": "dhcp4",
                                        "name": "domain-name-servers",
                                        "code": 6,
                                        "data": "10.0.0.20"
                                },
                                {
                                        "space": "dhcp4",
                                        "name": "domain-search",
                                        "code": 119,
                                        "data": "tachtler.net, intra.tachtler.net"
                                },
                                {
                                        "space": "dhcp4",
                                        "name": "ntp-servers",
                                        "code": 42,
                                        "data": "192.168.0.1"
                                },
                                {
                                        "space": "dhcp4",
                                        "name": "routers",
                                        "code": 3,
                                        "data": "192.168.0.1"
                                },
                                {
                                        "space": "dhcp4",
                                        "name": "subnet-mask",
                                        "code": 1,
                                        "data": "255.255.255.0"
                                },
                                {
                                        "space": "dhcp4",
                                        "name": "time-servers",
                                        "code": 4,
                                        "data": "192.168.0.1"
                                }
                        ],
                        "pools": [
                                // ---------------------------------------------
                                // Reserved for Guests.
                                // ---------------------------------------------
                                {
                                        "pool": "192.168.0.100 - 192.168.0.119"
                                },
                        ],
                        // -----------------------------------------------------
                        // 8.2.22. Using Client Identifier and Hardware Address
                        // -----------------------------------------------------
                        "match-client-id": true,
                        // -----------------------------------------------------
                        // 8.2.30. Lease Caching
                        // -----------------------------------------------------
                        "cache-threshold": 0.25,
                        "cache-max-age": 300,
                        // -----------------------------------------------------
                        // 8.3. Host Reservations in DHCPv4
                        // 8.3.3. Reserving a Hostname
                        // -----------------------------------------------------
                        "ddns-qualifying-suffix": "intra.tachtler.net.",
                        "reservations": [
                                // ---------------------------------------------
                                // Infrastructure.
                                // ---------------------------------------------
                                {
                                  "hostname": "server",
                                  "hw-address": "ab:12:34:56:78:90",
                                  "ip-address": "192.168.0.120"
                                },
                                {
                                  "hostname": "ipmi",
                                  "hw-address": "ac:12:34:56:78:90",
                                  "ip-address": "192.168.0.121"
                                },
                        ],
                        // -----------------------------------------------------
                        // 8.2.1. Introduction
                        // -----------------------------------------------------
                        "valid-lifetime": 10800,
                        "max-valid-lifetime": 28800,
                        "min-valid-lifetime": 300
                },
        ],
        "loggers": [
                {   
                        "name": "kea-dhcp4",
                        "output_options": [
                        {
                                "output": "syslog:kea-dhcp4"
                        }   
                        ],  
                        "severity": "INFO",
                        "debuglevel": 99
                }
        ]
}
}

Erklärungen: 

  • {
//
// DHCPv4 configuration starts here. This section will be read by DHCPv4 server
// and will be ignored by other components.
//
"Dhcp4": {

Dieser „Eröffnungstag“ in JSON©-Format, leitet die Konfigurationsdatei ein und gibt an, das die nachfolgenden Direktiven zur Konfiguration eines DHCP IPv4 Servers bestimmt sind. 

  •         // ---------------------------------------------------------------------
        // 8.2.2. Lease Storage
        // 8.2.2.1. Memfile - Basic Storage for Leases
        // ---------------------------------------------------------------------
        "lease-database": {
                "type": "memfile",
                "persist": true,
                "name": "/var/lib/kea/kea-leases4.csv",
                "lfc-interval": 3600,
                "max-row-errors": 0
        },

Die Konfiguration bestimmt die Ausgestaltung der lease-database („Lease“-Datenbank), welche in diesem Fall durch Angabe des Parameters type eine Datei ist, welche unter nachfolgendem Verzeichnis mit nachfolgendem Namen abgelegt wird:

  • /var/lib/kea/kea-leases4.csv

Die Datei, welche mit dem Parameter name definiert wird, wird auf dem entsprechenden Datenträger persistent (dauerhaft) gespeichert und wird zur Laufzeit in dem RAM (Hauptspeicher) eingelesen. Der Parameter persist steuert, ob neue „Leases“ und Aktualisierungen bestehender „Leases“ in die Datei geschrieben werden. Es wird dringend empfohlen, dass der Wert dieses Parameters während des normalen Betriebs des Servers immer auf „true“ gesetzt wird. Der Parameter lfc-interval gibt das Intervall in Sekunden an, in dem der Server eine Bereinigung der Lease-Datei (LFC) durchführt. der Parameter max-row-error gibt die Anzahl der Zeilenfehler an, nach denen der Server nicht mehr versucht, eine Lease-Datei zu laden. Es gibt nachfolgende zwei Möglichkeiten „Lease“-Informationen zu speichern

  1. memfile - Datei auf dem entsprechenden Datenträger
  2. mysql oder postgresql - Datenbank mit entsprechender Konfiguration

:!: HINWEIS - Durch die Verwendung des Parameters type mit der Angabe memfile kann die Abhängigkeit zu einer funktionierenden und zur Verfügung stehenden Datenbank vermieden werden, was hier aus Stabilitätsgründen im Vordergrund steht, auch wenn dies wie unter nachfolgendem externen Link gewisse Einschränkungen mit sich bringt

Feature Memfile MySQL PostgreSQL
Status stabil stabil stabil
Daten Format CSV Datei SQL RMDB SQL RMDB
„Leases“ ja ja ja
HOST Reservierungen nein ja ja
Optionen definiert auf HOST Basis nein ja ja
Konfigurierbares „backend“ nein ja ja 
  •         // ---------------------------------------------------------------------
        // 8.2.4. Interface Configuration
        // ---------------------------------------------------------------------
        "interfaces-config": {
                "interfaces": [ "*" ],
                "dhcp-socket-type": "raw"
        },

Nachfolgend wird definiert auf welchen Interfaces (Netzwerkkarten) der DHCP ISC Kea-Server auf Anfragen reagieren soll. Der hier gesetzte Parameter interfaces gibt mit der Konfiguration (*) Stern gibt an, das auf allen Interfaces (Netzwerkkarten) Anfragen beantwortet werden sollen. Der Parameter dhcp_socket-type gibt an, dass DHCP ISC Kea-Server „Raw Sockets“ verwendet, um Datenverkehr von Clients zu empfangen. Die Schwierigkeit besteht darin, Pakete von Geräten zu empfangen, die noch keine IPv4-Adresse haben. Bei direktem Datenverkehr (bei dem Client und Server an der selben Verbindung angeschlossen und nicht durch „relays“ getrennt sind) verwirft der „kernel“ normalerweise das Paket, da die Quell-IP-Adresse 0.0.0.0 lautet.

Dies ist jedoch nicht notwendig, wenn der gesamte Verkehr über „relays“ läuft, was in vielen Netzen der Fall ist. In diesem Fall können stattdessen normale „UDP-Sockets“ verwendet werden.

Standardmässig wird die Verwendung von „Raw-Sockets“ bevorzugt da dies vielseitiger ist. 

  •         // ---------------------------------------------------------------------
        // 8.2.9. Sending T1 (Option 58) and T2 (Option 59) 
        // ---------------------------------------------------------------------
        "calculate-tee-times": true,
        "t1-percent": 0.50,
        "t2-percent": 0.875,

Gemäss RFC 2131 sollten DHCP-Server Werte für T1 und T2 senden, die 50 % bzw. 87,5 % der „Lease-Life“-Zeit betragen. Standardmässig sendet der DHCP ISC Kea-Server keinen der beiden Werte. Der DHCP ISC Kea-Server kann jedoch so konfiguriert werden, dass dieser die Werte sendet, die entweder explizit angegeben werden oder als Prozentsätze der „Lease“-Zeit berechnet werden. Das Verhalten des DHCP ISC Kea-Servers wird durch eine Kombination von Konfigurationsparametern bestimmt. Um bestimmte feste Werte zu senden, werden hier die nachfolgenden beiden Parameter t1-percent und t2-percent verwendet. 

  •         // ---------------------------------------------------------------------
        // 8.2.21. Echoing Client-ID (RFC 6842)
        // ---------------------------------------------------------------------
        "echo-client-id": false,

Die ursprüngliche DHCPv4-Spezifikation RFC 2131 besagt, dass der DHCPv4-Server keine „client-id“-Optionen zurücksenden darf, wenn er an Clients antwortet. In einigen Fällen führt dies jedoch zu verwirrten Clients, die weder eine MAC-Adresse noch eine Client-ID haben; siehe RFC 6842 für weitere Details. Dieses Verhalten änderte sich mit der Veröffentlichung von RFC 6842, der RFC 2131 aktualisierte. Diese Aktualisierung besagt, dass der Server die Client-ID senden muss, wenn der Client sie gesendet hat, und das ist das Standardverhalten des DHCP ISC Kea-Servers. In einigen Fällen kann es jedoch vorkommen, dass ältere Geräte, die RFC 6842 nicht unterstützen, sich weigern, Antworten zu akzeptieren, die die Option „client-id“ enthalten. Um Abwärtskompatibilität zu ermöglichen, wurde der optionaler Konfigurationsparameter echo-client-id eingeführt. 

  •         // ---------------------------------------------------------------------
        // 8.2.22. Using Client Identifier and Hardware Address
        // ---------------------------------------------------------------------
        "match-client-id": true,

Ein häufiges Problem ist, dass schlechte Client-Implementierungen keine stabilen Client-Kennungen verwenden, sondern jedes Mal wenn sich der Client mit dem Netz verbindet, eine neue Client-Kennung erzeugen. Ein weiterer bekannter Fall ist, wenn der Client seine Client-Kennung während des z.B. mehrstufigen Boot-Prozesses (PXE) ändert. In solchen Fällen bleibt die MAC-Adresse der Client-Schnittstelle stabil, und die Verwendung des „chaddr“-Feldes zur Identifizierung des Clients garantiert, dass das jeweilige System als derselbe Client angesehen wird, auch wenn sich seine Client-Kennung ändert.

Um dieses Problem zu lösen, enthält der DHCP ISC Kea-Server eine Konfigurationsoption, die die Identifizierung des Clients nur über „chaddr“ ermöglicht. Dies weist den Server an, den Client-Identifikator bei der Suche nach „Leases“ und Zuweisungen für ein bestimmtes Subnetz zu ignorieren.

Der Parameter match-client-id ist ein boolescher Wert, der dieses Verhalten steuert. Der Standardwert true bedeutet, dass der Server die Client-Kennung für die Suche nach „Leases“ -„chaddr“ verwendet, wenn die erste Suche keine Ergebnisse liefert. Hingegen false bedeutet, dass der Server nur die „chaddr“ für die Suche nach dem Lease des Clients verwendet. Ob die „DHCID“ für DNS-Updates aus dem „Client-Identifier“ oder dem „chaddr“ generiert wird, wird über denselben Parameter gesteuert. 

  •         // ---------------------------------------------------------------------                                      
        // 8.2.25. Sanity Checks in DHCPv4
        // ---------------------------------------------------------------------
        "sanity-checks": {
                "lease-checks": "del"
        },

Ein wichtiger Aspekt eines gut funktionierenden DHCP-Servers ist die Gewährleistung, dass die Daten konsistent bleiben. In einigen Fällen kann es jedoch sinnvoll sein, bestimmte inkonsistente Daten zu tolerieren. Ein Netzwerkadministrator, der vorübergehend ein Subnetz aus einer Konfiguration entfernt, möchte zum Beispiel nicht, dass alle damit verbundenen „Leases“ aus der Lease-Datenbank verschwinden. Der DHCP ISC Kea-Server verfügt über einen Mechanismus zur Implementierung von „Sanity Checks“ für derartige Situationen.

Der DHCP ISC Kea-Server unterstützt einen Konfigurationsbereich namens „sanity-checks“. Derzeit ist nur ein einziger Parameter namens „lease-checks“ zulässig, der die Überprüfung beim Laden eines neuen „Leases“ aus einer „Lease“-Datei regelt. Mit diesem Mechanismus kann der DHCP ISC Kea-Server versuchen, inkonsistente Daten zu korrigieren.

Es gibt fünf Stufen, die unterstützt werden:

Stufe Beschreibung
none Es werden keine besonderen Prüfungen durchgeführt; die „Lease“ wird so akzeptiert, wie sie ist.
warn Bei Problemen wird eine Warnung angezeigt, aber die Daten werden trotzdem akzeptiert. Dies ist der Standardwert.
fix Wenn eine Dateninkonsistenz entdeckt wird, wird versuchen diese zu korrigieren. Wenn die Korrektur nicht erfolgreich ist, werden die falschen Daten trotzdem eingefügt.
fix-del Wenn eine Dateninkonsistenz entdeckt wird, wird versuchen diese zu korrigieren. Wenn die Korrektur nicht erfolgreich ist, wird die „Lease“ zurückgewiesen. Diese Einstellung gewährleistet die Korrektheit der Daten, aber einige fehlerhafte Daten können verloren gehen. Diese Einstellung ist mit Vorsicht zu verwenden!
del Wenn eine Unstimmigkeit festgestellt wird, wird die „Lease“ abgelehnt. Dies ist der strengste Modus und ebenfalls mit Vorsicht zu verwenden! 
  •         // ---------------------------------------------------------------------
        // 8.2.27. Multi-Threading Settings
        // ---------------------------------------------------------------------
        "multi-threading": {
                "enable-multi-threading": true,
                "thread-pool-size": 4,
                "packet-queue-size": 7
        },

Der DHCP ISC Kea-Server kann so konfiguriert werden, dass er Pakete parallel in mehreren „Threads“ verarbeitet. Diese Einstellungen finden sich unter der „Multi-Threading-Struktur“ und wir mit nachfolgenden Parameter konfiguriert:

  • enable-multi-threading - mehrere „Threads“ zur parallelen Verarbeitung von Paketen verwenden. Die Voreinstellung ist false.
  • thread-pool-size - gibt die Anzahl der „Threads“ für die parallele Verarbeitung von Paketen an. Sie kann auf 0 gesetzt werden (automatische Erkennung), oder jede positive Zahl legt explizit die Anzahl der „Threads“ fest. Die Voreinstellung ist 0.
  • packet-queue-size - gibt die Grösse der Warteschlange an, die vom „Thread-Pool“ zur Verarbeitung von Paketen verwendet wird. Sie kann auf 0 (unbegrenzt) gesetzt werden, oder jede positive Zahl legt explizit die Grösse der Warteschlange fest. Die Vorgabe ist 64.

Zur optimalen Bestimmung der Werte kann nachfolgender externe Link zu Rate gezogen werden

Die besten Ergebnisse erzielte das DHCP ISC Kea-Server-Team bei Tests mit den nachfolgenden Einstellungen:

„Thread-Pool-Size“ Typ Wert, wenn „Lease“-Informationen gespeichert werden sollen
thread-pool-size memfile 4
thread-pool-size mysql 12
thread-pool-size postgresql 8
„Packet-Queue-Size“ Typ Wert, wenn „Lease“-Informationen gespeichert werden sollen
packet-queue-size memfile 7 * 4 = 28. Das bedeutet, dass zu einem beliebigen Zeitpunkt bis zu 28 Pakete in der Warteschlange stehen können.
packet-queue-size mysql 66 * 12 = 792. Das bedeutet, dass bis zu 792 Pakete in die Warteschlange gestellt werden können.
packet-queue-size postgresql 11 * 8 = 88. Das bedeutet, dass bis zu 88 Pakete in die Warteschlange gestellt werden können. 
  •         // ---------------------------------------------------------------------
        // 8.3.8. Fine-Tuning DHCPv4 Host Reservation
        // ---------------------------------------------------------------------
        "reservations-global": false,
        "reservations-in-subnet": true,
        "reservations-out-of-pool": false,

Die HOST-Reservierungsfunktion führt zusätzliche Beschränkungen für den „allocation engine“ (die Komponente DHCP ISC Kea-Servers, die eine Adresse für einen Client auswählt) bei der Auswahl und Erneuerung von „Leases“ ein.

Insbesondere sind drei wichtige Prüfungen erforderlich. Erstens reicht es bei der Auswahl einer neuen „Lease“ nicht aus, dass der „Lease“-Kandidat nicht von einem anderen DHCP-Client verwendet wird. Er darf auch nicht für einen anderen Client reserviert sein. Ebenso muss bei der Erneuerung einer „Lease“ eine zusätzliche Prüfung durchgeführt werden, um festzustellen, ob die zu erneuernde Adresse für einen anderen Client reserviert ist. Wenn schliesslich ein HOST eine Adresse erneuert, muss der Server prüfen, ob für diesen HOST eine Reservierung besteht, was bedeuten würde, dass die bestehende (dynamisch zugewiesene) Adresse widerrufen und stattdessen die reservierte Adresse verwendet werden sollte.

Die Bedeutung der „Reservierungsflags“ sind:

  • reservations-global - ermöglicht globale Reservierungen (Egal wo in der Konfigurationsdatei).
  • reservations-in-subnet - Abruf von Subnetz-Reservierungen. Bei einem gemeinsam genutzten Netz schliesst dies alle Subnetzmitglieder des gemeinsamen Netzes ein.
  • reservations-out-of-pool - Dies ist nur sinnvoll, wenn das „Flag“ reservations-in-subnet true (wahr) ist. Wenn reservations-out-of-pool true (wahr) ist, nimmt der Server an, dass alle HOST-Reservierungen für Adressen sind, die nicht zum dynamischen Pool gehören. Daher kann er die Reservierungsprüfungen bei der Bearbeitung von „In-Pool-Adressen“ überspringen und so die Leistung verbessern. Der Server weist reservierte Adressen, die sich innerhalb der dynamischen Pools befinden, den jeweiligen Clients nicht zu. Das bedeutet auch, dass die Adressen, die mit den entsprechenden Reservierungen innerhalb der dynamischen Pools übereinstimmen (falls vorhanden), jedem Client dynamisch zugewiesen werden können.
  •         // ---------------------------------------------------------------------
        // 8.7. Duplicate Addresses (DHCPDECLINE Support)
        // ---------------------------------------------------------------------
        "decline-probation-period": 3600,

Der DHCP ISC Kea-Server wird mit einem bestimmten Pool von Adressen konfiguriert, die er an DHCPv4-Clients weitergeben soll. Es wird davon ausgegangen, dass der Server massgebend ist und die vollständige Zuständigkeit für diese Adressen hat. Aus verschiedenen Gründen, wie z. B. einer Fehlkonfiguration oder einer fehlerhaften Client-Implementierung, die ihre Adresse über die gültige Lebensdauer hinaus beibehält, können jedoch Geräte angeschlossen sein, die diese Adressen ohne die Zustimmung oder das Wissen des Servers verwenden.

Ein solches unerwünschtes Ereignis kann von legitimen Clients (mit Hilfe von „ARP“- oder „ICMP-Echo-Request“-Mechanismen) erkannt und dem DHCPv4-Server mit einer „DHCPDECLINE“-Nachricht gemeldet werden. Der Server führt eine Plausibilitätsprüfung durch (um festzustellen, ob der Client, der eine Adresse abgelehnt hat, diese auch wirklich verwenden sollte) und führt dann eine Bereinigungsoperation durch. Alle DNS-Einträge, die sich auf diese Adresse beziehen, werden entfernt, das Ereignis wird protokolliert, und es werden „Hooks“ ausgelöst. Nach Abschluss dieses Vorgangs wird die Adresse als abgelehnt markiert (was bedeutet, dass sie von einer unbekannten Entität verwendet wird und daher nicht für eine Zuweisung zur Verfügung steht), und es wird eine Bewährungszeit für sie festgelegt. Sofern nicht anders konfiguriert, dauert die Probezeit 24 Stunden, welche mit dem Parameter decline-probation-period gesetzt werden kann. Nach Ablauf dieser Zeit stellt der Server die Lease wieder her (d.h. er versetzt sie wieder in den Status „verfügbar“) und die Adresse steht wieder für die Zuweisung zur Verfügung. Es ist zu beachten, dass sich das Szenario mit der doppelten Adresse wiederholt, wenn das zugrunde liegende Problem eines falsch konfigurierten Geräts nicht behoben wird. Bei korrekter Neukonfiguration bietet dieser Mechanismus die Möglichkeit, ein solches Ereignis automatisch und ohne Eingreifen des Systemadministrators zu beheben. 

  •         // ---------------------------------------------------------------------
        // 8.9. Management API for the DHCPv4 Server
        // ---------------------------------------------------------------------
        "control-socket": {
                "socket-type": "unix",
                "socket-name": "/var/lib/kea/kea4-ctrl-socket"
        },

Die „Verwaltungs-API“ ermöglicht die Ausgabe spezifischer Verwaltungsbefehle, wie z. B. das Abrufen von Statistiken, die Neukonfiguration oder das Herunterfahren. Derzeit ist der einzige unterstützte Kommunikationskanaltyp der „UNIX-Stream-Socket“. Standardmässig sind keine Sockets geöffnet. Um den DHCP ISC Kea-Server anzuweisen, einen Socket zu öffnen, kann der vorhergehende Konfiguration verwendet werden

Weitere Einzelheiten der Verwaltungs-API können unter nachfolgendem externen Link nachgelesen werden: 

  •         // ---------------------------------------------------------------------                                      
        // 8.2.6. IPv4 Subnet Identifier
        // 8.2.7. IPv4 Subnet Prefix
        // 8.2.8. Configuration of IPv4 Address Pools
        // ---------------------------------------------------------------------
        "subnet4": [

Definition, das ab hier ein Subnetz IPv4 beginnt. 

  •                 {
                        // =====================================================
                        // Subnet 192.168.0.0/24 (Intranet).
                        // =====================================================
                        "id": 1,
                        "subnet": "192.168.0.0/24",

Die Subnetz-Kennung mit dem Parameter id(Subnetz-ID) ist eine eindeutige Nummer, die einem bestimmten Subnetz zugeordnet ist. Sie wird im Prinzip dazu verwendet, die „Leases“ der Clients mit ihren jeweiligen Subnetzen zu verknüpfen. Wenn für ein zu konfigurierendes Subnetz keine Subnetzkennung angegeben ist, wird sie automatisch vom Konfigurationsmechanismus zugewiesen. Die Bezeichner werden beginnend mit 1 zugewiesen und werden für jedes folgende Subnetz erhöht: 1, 2, 3, usw. Der Parameter subnet gibt das Subnetzpräfix an und ist die zweite Möglichkeit, ein Subnetz zu identifizieren. Der DHCP ISC Kea-Server kann „non-canonical“ Subnetzadressen akzeptieren. 

  •                         // -----------------------------------------------------
                        // 8.2.10. Standard DHCPv4 Options
                        // -----------------------------------------------------
                        "option-data":

Eine der wichtigsten Funktionen eines DHCPv4-Servers ist die Möglichkeit, den Clients Konfigurationsoptionen zur Verfügung zu stellen. Die meisten Optionen werden vom Server nur gesendet, wenn der Client sie ausdrücklich mit der Option „Parameter Request List“ anfordert. Bei den Optionen, die nicht in die „Parameter Request List“ aufgenommen werden müssen, handelt es sich um häufig verwendete Optionen, z. B. „Domain Server“ und um Optionen, die ein besonderes Verhalten erfordern, z. B. „Client FQDN“, der an den Client zurückgegeben wird, wenn der Client diese Option in seine Nachricht an den Server aufgenommen hat. Die kann durch den einleitenden Parameter option-data erfolgen. 

  •                                 // ---------------------------------------------
                                // 8.5. Server Identifier in DHCPv4
                                // ---------------------------------------------
                                {
                                        "space": "dhcp4",
                                        "name": "dhcp-server-identifier",
                                        "code": 54,
                                        "data": "192.168.0.1"
                                },
                                {
                                        "space": "dhcp4",
                                        "name": "broadcast-address",
                                        "code": 28,
                                        "data": "192.168.0.255"
                                },
                                {
                                        "space": "dhcp4",
                                        "name": "domain-name",
                                        "code": 15,
                                        "data": "intra.tachtler.net"
                                },
                                {
                                        "space": "dhcp4",
                                        "name": "domain-name-servers",
                                        "code": 6,
                                        "data": "10.0.0.20"
                                },
                                {
                                        "space": "dhcp4",
                                        "name": "domain-search",
                                        "code": 119,
                                        "data": "tachtler.net, intra.tachtler.net"
                                },
                                {
                                        "space": "dhcp4",
                                        "name": "ntp-servers",
                                        "code": 42,
                                        "data": "192.168.0.1"
                                },
                                {
                                        "space": "dhcp4",
                                        "name": "routers",
                                        "code": 3,
                                        "data": "192.168.0.1"
                                },
                                {
                                        "space": "dhcp4",
                                        "name": "subnet-mask",
                                        "code": 1,
                                        "data": "255.255.255.0"
                                },
                                {
                                        "space": "dhcp4",
                                        "name": "time-servers",
                                        "code": 4,
                                        "data": "192.168.0.1"
                                }
                        ],

Nachfolgender externe Link gibt eine Liste der möglichen Optionen am, welche zur Anwendung kommen können:

Nachfolgende Optionen wurden aktuell hier verwendet:

Option Beschreibung
dhcp-server-identifier Das DHCPv4-Protokoll verwendet einen „Server-Identifikator“, damit die Clients zwischen mehreren Servern auf derselben Verbindung unterscheiden können. Dieser Wert ist eine IPv4-Adresse des Servers. Der Server wählt die IPv4-Adresse der Schnittstelle, auf der die Nachricht vom Client (oder Relay) empfangen wurde. Eine einzelne Serverinstanz verwendet mehrere Server-Identifikatoren, wenn sie Abfragen auf mehreren Schnittstellen empfängt.
broadcast-address Die Adresse über die die „broadcast“-Anfrage ins Netz übermittelt wird.
domain-name Der FQDN, welche die Domäne bezeichnet, welche dem Client mit übermittelt wird.
domain-name-servers Die Adresse, welche den DNS-Server angibt, welche dem Client mit übermittelt wird, an den dieser DNS-Anfragen senden soll.
domain-search Der Teil des FQDN, welcher an HOST-Namen angehängt wird um einen vollständigen FQDN als Suchgrundlage für DNS-Anfragen des Clients fomilieren zu können.
ntp-servers Die Adresse, welche den Zeit-Server (NTP) angibt, welche dem Client mit übermittelt wird, an den dieser Zeit-Synchronisations-Anfragen senden soll.
routers Die Adresse, welche „Router“ definiert, die im Netzsegemnt erreicht werden können und z.B. auch die Betzübergreifende Kommunikation ermöglichen.
subnet-mask Die Subnetz-Maske, welche im Netzsegemnt herrscht, in dem sich der Client nach Bezug einer IP-Adresse befindet.
time-servers Die Adresse, welche den Zeit-Server (Time Protocol RFC 868) angibt, welche dem Client mit übermittelt wird, an den dieser Zeit-Synchronisations-Anfragen senden soll. 
  •                         "pools": [
                                // ---------------------------------------------
                                // Reserved for Guests.
                                // ---------------------------------------------
                                {
                                        "pool": "192.168.0.100 - 192.168.0.119"
                                },
                        ],

Die Hauptaufgabe eines DHCPv4-Servers ist die Adresszuweisung. Dazu muss der Server mit mindestens einem Subnetz und einem Pool von zu verwaltenden dynamischen Adressen konfiguriert werden. Nehmen wir an, der Server ist mit einem Netzwerksegment verbunden, das das Präfix 192.168.0.0/24 verwendet. Es wird nachfolgend konfigureirt, dass Adressen aus dem Bereich 192.168.0.100 bis 192.168.0.119 vom DHCPv4-Server als „pool“-Adressen verwaltet werden sollen. 

  •                         // -----------------------------------------------------
                        // 8.2.22. Using Client Identifier and Hardware Address
                        // -----------------------------------------------------
                        "match-client-id": true,

Ein häufiges Problem ist, dass schlechte Client-Implementierungen keine stabilen Client-Kennungen verwenden, sondern jedes Mal wenn sich der Client mit dem Netz verbindet, eine neue Client-Kennung erzeugen. Ein weiterer bekannter Fall ist, wenn der Client seine Client-Kennung während des z.B. mehrstufigen Boot-Prozesses (PXE) ändert. In solchen Fällen bleibt die MAC-Adresse der Client-Schnittstelle stabil, und die Verwendung des „chaddr“-Feldes zur Identifizierung des Clients garantiert, dass das jeweilige System als derselbe Client angesehen wird, auch wenn sich seine Client-Kennung ändert.

Um dieses Problem zu lösen, enthält der DHCP ISC Kea-Server eine Konfigurationsoption, die die Identifizierung des Clients nur über „chaddr“ ermöglicht. Dies weist den Server an, den Client-Identifikator bei der Suche nach „Leases“ und Zuweisungen für ein bestimmtes Subnetz zu ignorieren.

Der Parameter match-client-id ist ein boolescher Wert, der dieses Verhalten steuert. Der Standardwert true bedeutet, dass der Server die Client-Kennung für die Suche nach „Leases“ -„chaddr“ verwendet, wenn die erste Suche keine Ergebnisse liefert. Hingegen false bedeutet, dass der Server nur die „chaddr“ für die Suche nach dem Lease des Clients verwendet. Ob die „DHCID“ für DNS-Updates aus dem „Client-Identifier“ oder dem „chaddr“ generiert wird, wird über denselben Parameter gesteuert.

Dies soll auch für die Definitionen im Subnetz „subnet4“ gelten! 

  •                         // -----------------------------------------------------
                        // 8.2.30. Lease Caching
                        // -----------------------------------------------------
                        "cache-threshold": 0.25,
                        "cache-max-age": 300,

Clients, die mehrere Erneuerungen in einem kurzen Zeitraum versuchen, können den Server dazu veranlassen, die Datenbank häufig zu aktualisieren und zu beschreiben, was sich auf die Leistung des Servers auswirkt. Die Cache-Parameter weisen den DHCP-Server an, zu häufige Aktualisierungen von Leases zu vermeiden, wodurch dieses Verhalten vermieden wird. Stattdessen weist der Server dieselbe „Lease“ zu (d. h. er verwendet sie wieder), ohne Änderungen vorzunehmen, mit Ausnahme der CLTT (Client Last Transmission Time), die keine Plattenoperationen erfordert.

Die beiden Parameter sind cache-threshold (Typ: double) und cache-max-age (Typ: integer). Sie sind nicht voreingestellt, d.h. das Lease-Caching muss explizit aktiviert werden. Diese Parameter können auf globaler, Shared-Network- und Subnet-Ebene konfiguriert werden. Die Subnetzebene hat Vorrang vor der Shared-Network-Ebene, während die globale Ebene als letzte Möglichkeit verwendet wird. 

  •                         // -----------------------------------------------------
                        // 8.3. Host Reservations in DHCPv4
                        // 8.3.3. Reserving a Hostname
                        // -----------------------------------------------------
                        "ddns-qualifying-suffix": "intra.tachtler.net.",
                        "reservations": [
                                // ---------------------------------------------
                                // Infrastructure.
                                // ---------------------------------------------
                                {
                                  "hostname": "server",
                                  "hw-address": "ab:12:34:56:78:90",
                                  "ip-address": "192.168.0.120"
                                },
                                {
                                  "hostname": "ipmi",
                                  "hw-address": "ac:12:34:56:78:90",
                                  "ip-address": "192.168.0.121"
                                },
                        ],

Es gibt viele Fälle, in denen es sinnvoll ist, eine Konfiguration auf Hostbasis vorzunehmen. Der offensichtlichste Fall ist die Reservierung einer bestimmten, statischen Adresse für die ausschließliche Verwendung durch einen bestimmten Client (Host). Der anfragende Client erhält jedes Mal dieselbe Adresse vom Server, und andere Clients erhalten diese Adresse im Allgemeinen nicht. Host-Reservierungen sind auch praktisch, wenn ein Host spezielle Anforderungen hat, z. B. ein Drucker, der zusätzliche DHCP-Optionen benötigt. Ein weiterer möglicher Anwendungsfall ist die Festlegung eindeutiger Namen für Hosts.

Das Suffix, das bei der Erzeugung eines FQDN oder bei der Qualifizierung eines Teilnamens verwendet wird, wird durch den Parameter ddns-qualifying-suffix angegeben. Es wird dringend empfohlen, dass der Benutzer einen Wert für das qualifizierende Präfix angibt, wenn DDNS-Aktualisierungen aktiviert sind.

Der DHCP ISC Kea-Server bietet die Möglichkeit, Optionen für jeden einzelnen Host festzulegen. Diese Optionen folgen den gleichen Regeln wie alle anderen Optionen. Diese werden mit dem Parameter reservation eingeleitet und beeinhalten die Definitionen für einzelne Clients. 

  •                         // -----------------------------------------------------
                        // 8.2.1. Introduction
                        // -----------------------------------------------------
                        "valid-lifetime": 10800,
                        "max-valid-lifetime": 28800,
                        "min-valid-lifetime": 300

Die Gültigkeitsdauer von „Leases“ wird als Triplett mit Mindest-, Standard- und Maximalwerten durch die Konfigurationseinträge min-valid-lifetime, valid-lifetime und max-valid-lifetime ausgedrückt. 

  •         "loggers": [
                {   
                        "name": "kea-dhcp4",
                        "output_options": [
                        {
                                "output": "syslog:kea-dhcp4"
                        }   
                        ],  
                        "severity": "INFO",
                        "debuglevel": 99
                }
        ]

Beim DHCP ISC Kea-Server wird eine Nachricht durch eine Entität namens „Logger“ protokolliert. Verschiedene Komponenten protokollieren Nachrichten über verschiedene Logger, und jeder Logger kann unabhängig von den anderen konfiguriert werden. Einige Komponenten, insbesondere die DHCP-Serverprozesse, können mehrere Logger verwenden, um Nachrichten zu protokollieren, die zu verschiedenen logischen Funktionen der Komponente gehören. Der DHCPv4-Server verwendet beispielsweise einen Logger für Meldungen über den Empfang und die Übertragung von Paketen, einen anderen Logger für Meldungen im Zusammenhang mit der Zuweisung von Leases und so weiter.

Die drei Hauptelemente einer Logger-Konfiguration sind: name (die Komponente, die die Meldungen erzeugt), severity (was protokolliert werden soll) und output_commands (wo protokolliert werden soll). Es gibt auch ein debuglevel-Element, das nur relevant ist, wenn die Debug-Level-Protokollierung ausgewählt wurde.

Die Logger bilden eine Hierarchie. Für jedes Programm beim DHCP ISC Kea-Server gibt es einen „Stamm-Logger“, der nach dem Programm benannt ist (z. B. heißt der Stamm-Logger für kea-dhcp4, den DHCPv4-Server, kea-dhcp4). Alle anderen Logger sind Kinder dieses Loggers und werden entsprechend benannt, z. B. protokolliert die Zuweisungs-Engine im DHCPv4-Server Nachrichten mit einem Logger namens kea-dhcp4.alloc-engine.

Diese Beziehung ist wichtig, da jeder untergeordnete Logger seine Standardkonfiguration von seinem übergeordneten Root-Logger ableitet. Im Normalfall ist die Root-Logger-Konfiguration die einzige in der Konfigurationsdatei angegebene Logging-Konfiguration und gilt daher für alle Logger. Wenn ein Eintrag für einen bestimmten Logger gemacht wird, überschreiben alle angegebenen Attribute die des Root-Loggers, während alle nicht angegebenen von diesem geerbt werden.

Um dies zu veranschaulichen, nehmen wir an, wir verwenden den DHCPv4-Server mit dem Root-Logger kea-dhcp4, der auf der Ebene INFO protokolliert. Um die DEBUG-Ausführlichkeit für DHCPv4-Paketverluste zu aktivieren, müssen wir einen Konfigurationseintrag für den Logger mit dem Namen kea-dhcp4.bad-packets erstellen und den Schweregrad DEBUG für diesen Logger angeben. Alle anderen Konfigurationsparameter können für diesen Logger weggelassen werden, wenn der Logger die in der Konfiguration des Root-Loggers angegebenen Standardwerte verwenden soll.

Für weitere ausführliche Informationen und eine Übersicht der möglichen „Logger“, kann nachfplgender externer Link eingesehen werden:

/etc/kea/kea-dhcp6.conf

Nachfolgende Konfigurationsdatei /etc/kea/kea-dhcp6.conf, stellt die Möglichkeit dar DHCP via IPv6 durchzuführen.

Dies ist die komplette Konfigurationsdatei: 

{
//
// DHCPv6 configuration starts here. This section will be read by DHCPv6 server
// and will be ignored by other components.
//
"Dhcp6": {
        // ---------------------------------------------------------------------
        // 9.2.2. Lease Storage
        // 9.2.2.1. Memfile - Basic Storage for Leases
        // ---------------------------------------------------------------------
        "lease-database": {
                "type": "memfile",
                "persist": true,
                "name": "/var/lib/kea/kea-leases6.csv",
                "lfc-interval": 3600,
                "max-row-errors": 0
        },
        // ---------------------------------------------------------------------
        // 9.2.4. Interface Configuration
        // ---------------------------------------------------------------------
        "interfaces-config": {
                "interfaces": [ "*" ],
                "service-sockets-max-retries": 5,
                "service-sockets-retry-wait-time": 5000
        },
        // ---------------------------------------------------------------------
        // 9.2.17. Controlling the Values Sent for T1 and T2 Times
        // ---------------------------------------------------------------------
        "calculate-tee-times": true,
        "t1-percent": 0.50,
        "t2-percent": 0.875,
        // ---------------------------------------------------------------------
        // 9.2.25. Sanity Checks in DHCPv6
        // ---------------------------------------------------------------------
        "sanity-checks": {
                "lease-checks": "del"
        },
        // ---------------------------------------------------------------------
        // 9.2.27. Multi-Threading Settings
        // ---------------------------------------------------------------------
        "multi-threading": {
                "enable-multi-threading": true,
                "thread-pool-size": 4,
                "packet-queue-size": 150
        },
        // ---------------------------------------------------------------------
        // 9.3.7. Fine-Tuning DHCPv6 Host Reservation
        // ---------------------------------------------------------------------
        "reservations-global": false,
        "reservations-in-subnet": true,
        "reservations-out-of-pool": false,
        // ---------------------------------------------------------------------
        // 9.12. Duplicate Addresses (DHCPDECLINE Support)
        // ---------------------------------------------------------------------
        "decline-probation-period": 3600,
        // ---------------------------------------------------------------------
        // 9.14. Management API for the DHCPv6 Server   
        // ---------------------------------------------------------------------
        "control-socket": {
                "socket-type": "unix",
                "socket-name": "/var/lib/kea/kea6-ctrl-socket"
        },
        // ---------------------------------------------------------------------
        // 9.2.5. IPv4 Subnet Identifier
        // 9.2.6. IPv4 Subnet Prefix
        // 9.2.7. Configuration of IPv6 Address Pools
        // ---------------------------------------------------------------------
        "subnet6": [
                {
                        // =====================================================
                        // Subnet fd00:0:0:dead::/64 (HOME).
                        // =====================================================
                        "id": 1,
                        "subnet": "fd00:0:0:dead::/64",
                        // -----------------------------------------------------
                        // 9.2.11. Standard DHCPv6 Options
                        // -----------------------------------------------------
                        "option-data": [
                                // ---------------------------------------------
                                // 9.5. Server Identifier in DHCPv6
                                // ---------------------------------------------
                                {
                                  "space": "dhcp6",
                                  "name": "sip-server-dns",
                                  "code": 21,
                                  "data": "intra.tachtler.net"
                                },
                                {
                                  "space": "dhcp6",
                                  "name": "dns-servers",
                                  "code": 23,
                                  "data": "fd00::dead:10:0:0:20"
                                },
                                {
                                  "space": "dhcp6",
                                  "name": "domain-search",
                                  "code": 24,
                                  "data": "tachtler.net, intra.tachtler.net"
                                },
                                {
                                  "space": "dhcp6",
                                  "name": "sntp-servers",
                                  "code": 31,
                                  "data": "fd00::dead:192:168:0:1"
                                }
                        ],
                        "pools": [
                                // ---------------------------------------------
                                // Reserved for Guests (after PXE-Boot too).
                                // ---------------------------------------------
                                {
                                        "pool": "fd00::dead:192:168:0:100 - fd00::dead:192:168:0:119"
                                },
                        ],
                        // -----------------------------------------------------
                        // 9.2.29. Lease Caching
                        // -----------------------------------------------------
                        "cache-threshold": 0.25,
                        "cache-max-age": 300,
                        // -----------------------------------------------------
                        // 9.3. Host Reservations in DHCPv6
                        // 9.3.3. Reserving a Hostname
                        // -----------------------------------------------------
                        "ddns-qualifying-suffix": "intra.tachtler.net.",
                        "reservations": [
                                // ---------------------------------------------
                                // Infrastructure.
                                // ---------------------------------------------
                                {
                                        "hostname": "server",
                                        "hw-address": "ab:12:34:56:78:90",
                                        "ip-addresses": [
                                                "fd00::dead:192:168:0:120"
                                        ]
                                },
                                {
                                        "hostname": "ipmi",
                                        "hw-address": "ac:12:34:56:78:90",
                                        "ip-addresses": [
                                                "fd00::dead:192:168:0:121"
                                        ]
                                },
                        ],
                        // -----------------------------------------------------
                        // 9.2.1. Introduction
                        // -----------------------------------------------------
                        "preferred-lifetime": 300,
                        "max-preferred-lifetime": 900,
                        "min-preferred-lifetime": 60,
                        "valid-lifetime": 300,
                        "max-valid-lifetime": 900,
                        "min-valid-lifetime": 60
                }
        ],
        "loggers": [
                {   
                        "name": "kea-dhcp6",
                        "output_options": [
                        {
                                "output": "syslog:kea-dhcp6"
                        }   
                        ],  
                        "severity": "INFO",
                        "debuglevel": 99
                }
        ]
}
}

Erklärungen: 

  • {
//
// DHCPv6 configuration starts here. This section will be read by DHCPv6 server
// and will be ignored by other components.
//
"Dhcp6": {

Dieser „Eröffnungstag“ in JSON©-Format, leitet die Konfigurationsdatei ein und gibt an, das die nachfolgenden Direktiven zur Konfiguration eines DHCP IPv6 Servers bestimmt sind. 

  •         // ---------------------------------------------------------------------
        // 9.2.2. Lease Storage
        // 9.2.2.1. Memfile - Basic Storage for Leases
        // ---------------------------------------------------------------------
        "lease-database": {
                "type": "memfile",
                "persist": true,
                "name": "/var/lib/kea/kea-leases6.csv",
                "lfc-interval": 3600,
                "max-row-errors": 0
        },

Die Konfiguration bestimmt die Ausgestaltung der lease-database („Lease“-Datenbank), welche in diesem Fall durch Angabe des Parameters type eine Datei ist, welche unter nachfolgendem Verzeichnis mit nachfolgendem Namen abgelegt wird:

  • /var/lib/kea/kea-leases6.csv

Die Datei, welche mit dem Parameter name definiert wird, wird auf dem entsprechenden Datenträger persistent (dauerhaft) gespeichert und wird zur Laufzeit in dem RAM (Hauptspeicher) eingelesen. Der Parameter persist steuert, ob neue „Leases“ und Aktualisierungen bestehender „Leases“ in die Datei geschrieben werden. Es wird dringend empfohlen, dass der Wert dieses Parameters während des normalen Betriebs des Servers immer auf „true“ gesetzt wird. Der Parameter lfc-interval gibt das Intervall in Sekunden an, in dem der Server eine Bereinigung der Lease-Datei (LFC) durchführt. der Parameter max-row-error gibt die Anzahl der Zeilenfehler an, nach denen der Server nicht mehr versucht, eine Lease-Datei zu laden. Es gibt nachfolgende zwei Möglichkeiten „Lease“-Informationen zu speichern

  1. memfile - Datei auf dem entsprechenden Datenträger
  2. mysql oder postgresql - Datenbank mit entsprechender Konfiguration

:!: HINWEIS - Durch die Verwendung des Parameters type mit der Angabe memfile kann die Abhängigkeit zu einer funktionierenden und zur Verfügung stehenden Datenbank vermieden werden, was hier aus Stabilitätsgründen im Vordergrund steht, auch wenn dies wie unter nachfolgendem externen Link gewisse Einschränkungen mit sich bringt

Feature Memfile MySQL PostgreSQL
Status stabil stabil stabil
Daten Format CSV Datei SQL RMDB SQL RMDB
„Leases“ ja ja ja
HOST Reservierungen nein ja ja
Optionen definiert auf HOST Basis nein ja ja
Konfigurierbares „backend“ nein ja ja 
  •         // ---------------------------------------------------------------------
        // 9.2.4. Interface Configuration
        // ---------------------------------------------------------------------
        "interfaces-config": {
                "interfaces": [ "*" ],
                "service-sockets-max-retries": 5,
                "service-sockets-retry-wait-time": 5000
        },

Nachfolgend wird definiert auf welchen Interfaces (Netzwerkkarten) der DHCP ISC Kea-Server auf Anfragen reagieren soll. Der hier gesetzte Parameter interfaces gibt mit der Konfiguration (*) Stern gibt an, das auf allen Interfaces (Netzwerkkarten) Anfragen beantwortet werden sollen. Der Parameter service-sockets-max-retries ermöglicht, beim DHCP ISC Kea-Server Wiederholung zu spezifizieren, wie oft versucht wird einen Socket zu öffnen. Der Parameter service-sockets-retry-wait-time definiert die Wartezeit zwischen den Versuchen.

Die erste Option definiert die maximale Anzahl von Wiederholungsversuchen, die der DHCP ISC Kea-Server unternimmt, um einen Socket zu öffnen. Der Wert Null (Standard) bedeutet, dass der DHCP ISC Kea-Server den Prozess nicht wiederholt. 

  •         // ---------------------------------------------------------------------
        // 9.2.17. Controlling the Values Sent for T1 and T2 Times
        // ---------------------------------------------------------------------
        "calculate-tee-times": true,
        "t1-percent": 0.50,
        "t2-percent": 0.875,

Gemäss RFC 2131 sollten DHCP-Server Werte für T1 und T2 senden, die 50 % bzw. 87,5 % der „Lease-Life“-Zeit betragen. Standardmässig sendet der DHCP ISC Kea-Server keinen der beiden Werte. Der DHCP ISC Kea-Server kann jedoch so konfiguriert werden, dass dieser die Werte sendet, die entweder explizit angegeben werden oder als Prozentsätze der „Lease“-Zeit berechnet werden. Das Verhalten des DHCP ISC Kea-Servers wird durch eine Kombination von Konfigurationsparametern bestimmt. Um bestimmte feste Werte zu senden, werden hier die nachfolgenden beiden Parameter t1-percent und t2-percent verwendet. 

  •         // ---------------------------------------------------------------------
        // 9.2.25. Sanity Checks in DHCPv6
        // ---------------------------------------------------------------------
        "sanity-checks": {
                "lease-checks": "del"
        },

Ein wichtiger Aspekt eines gut funktionierenden DHCP-Servers ist die Gewährleistung, dass die Daten konsistent bleiben. In einigen Fällen kann es jedoch sinnvoll sein, bestimmte inkonsistente Daten zu tolerieren. Ein Netzwerkadministrator, der vorübergehend ein Subnetz aus einer Konfiguration entfernt, möchte zum Beispiel nicht, dass alle damit verbundenen „Leases“ aus der Lease-Datenbank verschwinden. Der DHCP ISC Kea-Server verfügt über einen Mechanismus zur Implementierung von „Sanity Checks“ für derartige Situationen.

Der DHCP ISC Kea-Server unterstützt einen Konfigurationsbereich namens „sanity-checks“. Derzeit ist nur ein einziger Parameter namens „lease-checks“ zulässig, der die Überprüfung beim Laden eines neuen „Leases“ aus einer „Lease“-Datei regelt. Mit diesem Mechanismus kann der DHCP ISC Kea-Server versuchen, inkonsistente Daten zu korrigieren.

Es gibt fünf Stufen, die unterstützt werden:

Stufe Beschreibung
none Es werden keine besonderen Prüfungen durchgeführt; die „Lease“ wird so akzeptiert, wie sie ist.
warn Bei Problemen wird eine Warnung angezeigt, aber die Daten werden trotzdem akzeptiert. Dies ist der Standardwert.
fix Wenn eine Dateninkonsistenz entdeckt wird, wird versuchen diese zu korrigieren. Wenn die Korrektur nicht erfolgreich ist, werden die falschen Daten trotzdem eingefügt.
fix-del Wenn eine Dateninkonsistenz entdeckt wird, wird versuchen diese zu korrigieren. Wenn die Korrektur nicht erfolgreich ist, wird die „Lease“ zurückgewiesen. Diese Einstellung gewährleistet die Korrektheit der Daten, aber einige fehlerhafte Daten können verloren gehen. Diese Einstellung ist mit Vorsicht zu verwenden!
del Wenn eine Unstimmigkeit festgestellt wird, wird die „Lease“ abgelehnt. Dies ist der strengste Modus und ebenfalls mit Vorsicht zu verwenden! 
  •         // ---------------------------------------------------------------------
        // 9.2.27. Multi-Threading Settings
        // ---------------------------------------------------------------------
        "multi-threading": {
                "enable-multi-threading": true,
                "thread-pool-size": 4,
                "packet-queue-size": 150
        },

Der DHCP ISC Kea-Server kann so konfiguriert werden, dass er Pakete parallel in mehreren „Threads“ verarbeitet. Diese Einstellungen finden sich unter der „Multi-Threading-Struktur“ und wir mit nachfolgenden Parameter konfiguriert:

  • enable-multi-threading - mehrere „Threads“ zur parallelen Verarbeitung von Paketen verwenden. Die Voreinstellung ist false.
  • thread-pool-size - gibt die Anzahl der „Threads“ für die parallele Verarbeitung von Paketen an. Sie kann auf 0 gesetzt werden (automatische Erkennung), oder jede positive Zahl legt explizit die Anzahl der „Threads“ fest. Die Voreinstellung ist 0.
  • packet-queue-size - gibt die Grösse der Warteschlange an, die vom „Thread-Pool“ zur Verarbeitung von Paketen verwendet wird. Sie kann auf 0 (unbegrenzt) gesetzt werden, oder jede positive Zahl legt explizit die Grösse der Warteschlange fest. Die Vorgabe ist 64.

Zur optimalen Bestimmung der Werte kann nachfolgender externe Link zu Rate gezogen werden

Die besten Ergebnisse erzielte das DHCP ISC Kea-Server-Team bei Tests mit den nachfolgenden Einstellungen:

„Thread-Pool-Size“ Typ Wert, wenn „Lease“-Informationen gespeichert werden sollen
thread-pool-size memfile 4
thread-pool-size mysql 12
thread-pool-size postgresql 6
„Packet-Queue-Size“ Typ Wert, wenn „Lease“-Informationen gespeichert werden sollen
packet-queue-size memfile 150 * 4 = 600. Das bedeutet, dass zu einem beliebigen Zeitpunkt bis zu 600 Pakete in der Warteschlange stehen können.
packet-queue-size mysql 200 * 12 = 2400. Das bedeutet, dass bis zu 2400 Pakete in die Warteschlange gestellt werden können.
packet-queue-size postgresql 11 * 6 = 66. Das bedeutet, dass bis zu 66 Pakete in die Warteschlange gestellt werden können. 
  •         // ---------------------------------------------------------------------
        // 9.3.7. Fine-Tuning DHCPv6 Host Reservation
        // ---------------------------------------------------------------------
        "reservations-global": false,
        "reservations-in-subnet": true,
        "reservations-out-of-pool": false,

Die HOST-Reservierungsfunktion führt zusätzliche Beschränkungen für den „allocation engine“ (die Komponente DHCP ISC Kea-Servers, die eine Adresse für einen Client auswählt) bei der Auswahl und Erneuerung von „Leases“ ein.

Insbesondere sind drei wichtige Prüfungen erforderlich. Erstens reicht es bei der Auswahl einer neuen „Lease“ nicht aus, dass der „Lease“-Kandidat nicht von einem anderen DHCP-Client verwendet wird. Er darf auch nicht für einen anderen Client reserviert sein. Ebenso muss bei der Erneuerung einer „Lease“ eine zusätzliche Prüfung durchgeführt werden, um festzustellen, ob die zu erneuernde Adresse für einen anderen Client reserviert ist. Wenn schliesslich ein HOST eine Adresse erneuert, muss der Server prüfen, ob für diesen HOST eine Reservierung besteht, was bedeuten würde, dass die bestehende (dynamisch zugewiesene) Adresse widerrufen und stattdessen die reservierte Adresse verwendet werden sollte.

Die Bedeutung der „Reservierungsflags“ sind:

  • reservations-global - ermöglicht globale Reservierungen (Egal wo in der Konfigurationsdatei).
  • reservations-in-subnet - Abruf von Subnetz-Reservierungen. Bei einem gemeinsam genutzten Netz schliesst dies alle Subnetzmitglieder des gemeinsamen Netzes ein.
  • reservations-out-of-pool - Dies ist nur sinnvoll, wenn das „Flag“ reservations-in-subnet true (wahr) ist. Wenn reservations-out-of-pool true (wahr) ist, nimmt der Server an, dass alle HOST-Reservierungen für Adressen sind, die nicht zum dynamischen Pool gehören. Daher kann er die Reservierungsprüfungen bei der Bearbeitung von „In-Pool-Adressen“ überspringen und so die Leistung verbessern. Der Server weist reservierte Adressen, die sich innerhalb der dynamischen Pools befinden, den jeweiligen Clients nicht zu. Das bedeutet auch, dass die Adressen, die mit den entsprechenden Reservierungen innerhalb der dynamischen Pools übereinstimmen (falls vorhanden), jedem Client dynamisch zugewiesen werden können.
  •         // ---------------------------------------------------------------------
        // 9.12. Duplicate Addresses (DHCPDECLINE Support)
        // ---------------------------------------------------------------------
        "decline-probation-period": 3600,

Der DHCP ISC Kea-Server wird mit einem bestimmten Pool von Adressen konfiguriert, die er an DHCPv4-Clients weitergeben soll. Es wird davon ausgegangen, dass der Server massgebend ist und die vollständige Zuständigkeit für diese Adressen hat. Aus verschiedenen Gründen, wie z. B. einer Fehlkonfiguration oder einer fehlerhaften Client-Implementierung, die ihre Adresse über die gültige Lebensdauer hinaus beibehält, können jedoch Geräte angeschlossen sein, die diese Adressen ohne die Zustimmung oder das Wissen des Servers verwenden.

Ein solches unerwünschtes Ereignis kann von legitimen Clients (mit Hilfe von „ARP“- oder „ICMP-Echo-Request“-Mechanismen) erkannt und dem DHCPv4-Server mit einer „DHCPDECLINE“-Nachricht gemeldet werden. Der Server führt eine Plausibilitätsprüfung durch (um festzustellen, ob der Client, der eine Adresse abgelehnt hat, diese auch wirklich verwenden sollte) und führt dann eine Bereinigungsoperation durch. Alle DNS-Einträge, die sich auf diese Adresse beziehen, werden entfernt, das Ereignis wird protokolliert, und es werden „Hooks“ ausgelöst. Nach Abschluss dieses Vorgangs wird die Adresse als abgelehnt markiert (was bedeutet, dass sie von einer unbekannten Entität verwendet wird und daher nicht für eine Zuweisung zur Verfügung steht), und es wird eine Bewährungszeit für sie festgelegt. Sofern nicht anders konfiguriert, dauert die Probezeit 24 Stunden, welche mit dem Parameter decline-probation-period gesetzt werden kann. Nach Ablauf dieser Zeit stellt der Server die Lease wieder her (d.h. er versetzt sie wieder in den Status „verfügbar“) und die Adresse steht wieder für die Zuweisung zur Verfügung. Es ist zu beachten, dass sich das Szenario mit der doppelten Adresse wiederholt, wenn das zugrunde liegende Problem eines falsch konfigurierten Geräts nicht behoben wird. Bei korrekter Neukonfiguration bietet dieser Mechanismus die Möglichkeit, ein solches Ereignis automatisch und ohne Eingreifen des Systemadministrators zu beheben. 

  •         // ---------------------------------------------------------------------
        // 9.14. Management API for the DHCPv6 Server   
        // ---------------------------------------------------------------------
        "control-socket": {
                "socket-type": "unix",
                "socket-name": "/var/lib/kea/kea6-ctrl-socket"
        },

Die „Verwaltungs-API“ ermöglicht die Ausgabe spezifischer Verwaltungsbefehle, wie z. B. das Abrufen von Statistiken, die Neukonfiguration oder das Herunterfahren. Derzeit ist der einzige unterstützte Kommunikationskanaltyp der „UNIX-Stream-Socket“. Standardmässig sind keine Sockets geöffnet. Um den DHCP ISC Kea-Server anzuweisen, einen Socket zu öffnen, kann der vorhergehende Konfiguration verwendet werden

Weitere Einzelheiten der Verwaltungs-API können unter nachfolgendem externen Link nachgelesen werden: 

  •         // ---------------------------------------------------------------------
        // 9.2.5. IPv4 Subnet Identifier
        // 9.2.6. IPv4 Subnet Prefix
        // 9.2.7. Configuration of IPv6 Address Pools
        // ---------------------------------------------------------------------
        "subnet6": [

Definition, das ab hier ein Subnetz IPv6 beginnt. 

  •                 {
                        // =====================================================
                        // Subnet fd00:0:0:dead::/64 (HOME).
                        // =====================================================
                        "id": 1,
                        "subnet": "fd00:0:0:dead::/64",,

Die Subnetz-Kennung mit dem Parameter id(Subnetz-ID) ist eine eindeutige Nummer, die einem bestimmten Subnetz zugeordnet ist. Sie wird im Prinzip dazu verwendet, die „Leases“ der Clients mit ihren jeweiligen Subnetzen zu verknüpfen. Wenn für ein zu konfigurierendes Subnetz keine Subnetzkennung angegeben ist, wird sie automatisch vom Konfigurationsmechanismus zugewiesen. Die Bezeichner werden beginnend mit 1 zugewiesen und werden für jedes folgende Subnetz erhöht: 1, 2, 3, usw. Der Parameter subnet gibt das Subnetzpräfix an und ist die zweite Möglichkeit, ein Subnetz zu identifizieren. Der DHCP ISC Kea-Server kann „non-canonical“ Subnetzadressen akzeptieren. 

  •                         // -----------------------------------------------------
                        // 9.2.11. Standard DHCPv6 Options
                        // -----------------------------------------------------
                        "option-data": [

Eine der möglichen Funktionen auch eines DHCPv6-Servers ist die Möglichkeit, den Clients Konfigurationsoptionen zur Verfügung zu stellen. Die meisten Optionen werden vom Server nur gesendet, wenn der Client sie ausdrücklich mit der Option „Parameter Request List“ anfordert. Bei den Optionen, die nicht in die „Parameter Request List“ aufgenommen werden müssen, handelt es sich um häufig verwendete Optionen, z. B. „Domain Server“ und um Optionen, die ein besonderes Verhalten erfordern, z. B. „Client FQDN“, der an den Client zurückgegeben wird, wenn der Client diese Option in seine Nachricht an den Server aufgenommen hat. Die kann durch den einleitenden Parameter option-data erfolgen. 

  •                                 // ---------------------------------------------
                                // 9.5. Server Identifier in DHCPv6
                                // ---------------------------------------------
                                {
                                  "space": "dhcp6",
                                  "name": "sip-server-dns",
                                  "code": 21,
                                  "data": "intra.tachtler.net"
                                },
                                {
                                  "space": "dhcp6",
                                  "name": "dns-servers",
                                  "code": 23,
                                  "data": "fd00::dead:10:0:0:20"
                                },
                                {
                                  "space": "dhcp6",
                                  "name": "domain-search",
                                  "code": 24,
                                  "data": "tachtler.net, intra.tachtler.net"
                                },
                                {
                                  "space": "dhcp6",
                                  "name": "sntp-servers",
                                  "code": 31,
                                  "data": "fd00::dead:192:168:0:1"
                                }
                        ],

Nachfolgender externe Link gibt eine Liste der möglichen Optionen am, welche zur Anwendung kommen können:

Nachfolgende Optionen wurden aktuell hier verwendet:

Option Beschreibung
dhcp-server-identifier Das DHCPv4-Protokoll verwendet einen „Server-Identifikator“, damit die Clients zwischen mehreren Servern auf derselben Verbindung unterscheiden können. Dieser Wert ist eine IPv4-Adresse des Servers. Der Server wählt die IPv4-Adresse der Schnittstelle, auf der die Nachricht vom Client (oder Relay) empfangen wurde. Eine einzelne Serverinstanz verwendet mehrere Server-Identifikatoren, wenn sie Abfragen auf mehreren Schnittstellen empfängt.
sip-server-dns Session Initiation Protocol (SIP) kann DNS-Prozeduren (Domain Name Server) für einen Client verwenden, um einen SIP-URI aufzulösen..
dns-servers Die Adresse, welche den DNS-Server angibt, welche dem Client mit übermittelt wird, an den dieser DNS-Anfragen senden soll.
domain-search Der Teil des FQDN, welcher an HOST-Namen angehängt wird um einen vollständigen FQDN als Suchgrundlage für DNS-Anfragen des Clients fomilieren zu können.
sntp-servers Die Adresse, welche den Zeit-Server (NTP) angibt, welche dem Client mit übermittelt wird, an den dieser Zeit-Synchronisations-Anfragen senden soll. 
  •                         "pools": [
                                // ---------------------------------------------
                                // Reserved for Guests (after PXE-Boot too).
                                // ---------------------------------------------
                                {
                                        "pool": "fd00::dead:192:168:0:100 - fd00::dead:192:168:0:119"
                                },
                        ],

Die Hauptaufgabe eines DHCPv6-Servers ist die Adresszuweisung. Dazu muss der Server mit mindestens einem Subnetz und einem Pool von zu verwaltenden dynamischen Adressen konfiguriert werden. Nehmen wir an, der Server ist mit einem Netzwerksegment verbunden, das das Präfix fd00::dead:192:168:0:0/64 verwendet. Es wird nachfolgend konfigureirt, dass Adressen aus dem Bereich fd00::dead:192:168:0:100 bis fd00::dead:192:168:0:119 vom DHCPv6-Server als „pool“-Adressen verwaltet werden sollen. 

  •                         // -----------------------------------------------------
                        // 9.2.29. Lease Caching
                        // -----------------------------------------------------
                        "cache-threshold": 0.25,
                        "cache-max-age": 300,

Clients, die mehrere Erneuerungen in einem kurzen Zeitraum versuchen, können den Server dazu veranlassen, die Datenbank häufig zu aktualisieren und zu beschreiben, was sich auf die Leistung des Servers auswirkt. Die Cache-Parameter weisen den DHCP-Server an, zu häufige Aktualisierungen von Leases zu vermeiden, wodurch dieses Verhalten vermieden wird. Stattdessen weist der Server dieselbe „Lease“ zu (d. h. er verwendet sie wieder), ohne Änderungen vorzunehmen, mit Ausnahme der CLTT (Client Last Transmission Time), die keine Plattenoperationen erfordert.

Die beiden Parameter sind cache-threshold (Typ: double) und cache-max-age (Typ: integer). Sie sind nicht voreingestellt, d.h. das Lease-Caching muss explizit aktiviert werden. Diese Parameter können auf globaler, Shared-Network- und Subnet-Ebene konfiguriert werden. Die Subnetzebene hat Vorrang vor der Shared-Network-Ebene, während die globale Ebene als letzte Möglichkeit verwendet wird. 

  •                         // -----------------------------------------------------
                        // 9.3. Host Reservations in DHCPv6
                        // 9.3.3. Reserving a Hostname
                        // -----------------------------------------------------
                        "ddns-qualifying-suffix": "intra.tachtler.net.",
                        "reservations": [
                                // ---------------------------------------------
                                // Infrastructure.
                                // ---------------------------------------------
                                {
                                        "hostname": "server",
                                        "hw-address": "ab:12:34:56:78:90",
                                        "ip-addresses": [
                                                "fd00::dead:192:168:0:120"
                                        ]
                                },
                                {
                                        "hostname": "ipmi",
                                        "hw-address": "ac:12:34:56:78:90",
                                        "ip-addresses": [
                                                "fd00::dead:192:168:0:121"
                                        ]
                                },
                        ],

Es gibt viele Fälle, in denen es sinnvoll ist, eine Konfiguration auf Hostbasis vorzunehmen. Der offensichtlichste Fall ist die Reservierung einer bestimmten, statischen Adresse für die ausschließliche Verwendung durch einen bestimmten Client (Host). Der anfragende Client erhält jedes Mal dieselbe Adresse vom Server, und andere Clients erhalten diese Adresse im Allgemeinen nicht. Host-Reservierungen sind auch praktisch, wenn ein Host spezielle Anforderungen hat, z. B. ein Drucker, der zusätzliche DHCP-Optionen benötigt. Ein weiterer möglicher Anwendungsfall ist die Festlegung eindeutiger Namen für Hosts.

Das Suffix, das bei der Erzeugung eines FQDN oder bei der Qualifizierung eines Teilnamens verwendet wird, wird durch den Parameter ddns-qualifying-suffix angegeben. Es wird dringend empfohlen, dass der Benutzer einen Wert für das qualifizierende Präfix angibt, wenn DDNS-Aktualisierungen aktiviert sind.

Der DHCP ISC Kea-Server bietet die Möglichkeit, Optionen für jeden einzelnen Host festzulegen. Diese Optionen folgen den gleichen Regeln wie alle anderen Optionen. Diese werden mit dem Parameter reservation eingeleitet und beeinhalten die Definitionen für einzelne Clients. 

  •                         // -----------------------------------------------------
                        // 9.2.1. Introduction
                        // -----------------------------------------------------
                        "preferred-lifetime": 300,
                        "max-preferred-lifetime": 900,
                        "min-preferred-lifetime": 60,
                        "valid-lifetime": 300,
                        "max-valid-lifetime": 900,
                        "min-valid-lifetime": 60
                }
        ],

Die Gültigkeitsdauer von „Leases“ wird als Triplett mit Mindest-, Standard- und Maximalwerten durch die Konfigurationseinträge min-valid-lifetime, valid-lifetime und max-valid-lifetime ausgedrückt. Zusätzlich gibt preferred-lifetime die bevorzugte Standardlebensdauer an, min-preferred-lifetime die minimale bevorzugte Lebensdauer an (optional) und max-preferred-lifetimelegt die maximale bevorzugte Lebensdauer fest (optional). 

  •         "loggers": [
                {   
                        "name": "kea-dhcp6",
                        "output_options": [
                        {
                                "output": "syslog:kea-dhcp6"
                        }   
                        ],  
                        "severity": "INFO",
                        "debuglevel": 99
                }
        ]

Beim DHCP ISC Kea-Server wird eine Nachricht durch eine Entität namens „Logger“ protokolliert. Verschiedene Komponenten protokollieren Nachrichten über verschiedene Logger, und jeder Logger kann unabhängig von den anderen konfiguriert werden. Einige Komponenten, insbesondere die DHCP-Serverprozesse, können mehrere Logger verwenden, um Nachrichten zu protokollieren, die zu verschiedenen logischen Funktionen der Komponente gehören. Der DHCPv4-Server verwendet beispielsweise einen Logger für Meldungen über den Empfang und die Übertragung von Paketen, einen anderen Logger für Meldungen im Zusammenhang mit der Zuweisung von Leases und so weiter.

Die drei Hauptelemente einer Logger-Konfiguration sind: name (die Komponente, die die Meldungen erzeugt), severity (was protokolliert werden soll) und output_commands (wo protokolliert werden soll). Es gibt auch ein debuglevel-Element, das nur relevant ist, wenn die Debug-Level-Protokollierung ausgewählt wurde.

Die Logger bilden eine Hierarchie. Für jedes Programm beim DHCP ISC Kea-Server gibt es einen „Stamm-Logger“, der nach dem Programm benannt ist (z. B. heißt der Stamm-Logger für kea-dhcp4, den DHCPv6-Server, kea-dhcp6). Alle anderen Logger sind Kinder dieses Loggers und werden entsprechend benannt, z. B. protokolliert die Zuweisungs-Engine im DHCPv6-Server Nachrichten mit einem Logger namens kea-dhcp6.alloc-engine.

Diese Beziehung ist wichtig, da jeder untergeordnete Logger seine Standardkonfiguration von seinem übergeordneten Root-Logger ableitet. Im Normalfall ist die Root-Logger-Konfiguration die einzige in der Konfigurationsdatei angegebene Logging-Konfiguration und gilt daher für alle Logger. Wenn ein Eintrag für einen bestimmten Logger gemacht wird, überschreiben alle angegebenen Attribute die des Root-Loggers, während alle nicht angegebenen von diesem geerbt werden.

Um dies zu veranschaulichen, nehmen wir an, wir verwenden den DHCPv4-Server mit dem Root-Logger kea-dhcp4, der auf der Ebene INFO protokolliert. Um die DEBUG-Ausführlichkeit für DHCPv4-Paketverluste zu aktivieren, müssen wir einen Konfigurationseintrag für den Logger mit dem Namen kea-dhcp4.bad-packets erstellen und den Schweregrad DEBUG für diesen Logger angeben. Alle anderen Konfigurationsparameter können für diesen Logger weggelassen werden, wenn der Logger die in der Konfiguration des Root-Loggers angegebenen Standardwerte verwenden soll.

Für weitere ausführliche Informationen und eine Übersicht der möglichen „Logger“, kann nachfplgender externer Link eingesehen werden:

:!: Hier geht es weiter… / To be continued…

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
tachtler/dhcp_isc_kea_archlinux.txt · Zuletzt geändert: 2023/03/27 16:04 von klaus