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
  • eines DHCP ISC Kea-Control-Agents (Steuerungs Agenten)

welche als internes, nicht nach aussen 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, DHCP-Servers für IPv6 und für den DHCP ISC Kea-Control-Agent (Steuerungs-Agenten), welche als Dienst/Daemon 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 kea-ctrl-agent.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.
Created symlink /etc/systemd/system/multi-user.target.wants/kea-ctrl-agent.service → /usr/lib/systemd/system/kea-ctrl-agent.service.

Eine Überprüfung, ob beim Neustart des Server der kea-dhcp4-, kea-dhcp6- und der kea-ctrl-agent-Dienst/Daemon 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
kea-ctrl-agent.service                     enabled         disabled
kea-dhcp-ddns.service                      disabled        disabled
kea-dhcp4.service                          enabled         disabled
kea-dhcp6.service                          enabled         disabled

bzw. 

# systemctl is-enabled kea-dhcp4.service kea-dhcp6.service kea-ctrl-agent.service
enabled
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 547 -j ACCEPT
  • -A OUTPUT -p udp --dport 546 -j ACCEPT

und hier die Befehle: 

# ip6tables -I INPUT 5 -p udp --dport 547 -j ACCEPT
# ip6tables -I OUTPUT 1 -p udp --dport 546 -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:547
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:546

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:547 
1        0     0 ACCEPT     udp  --  *      *       ::/0                 ::/0                 udp dpt:546
...

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 547 -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 546 -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).
                        // =====================================================
                        "interface": "eth0",
                        "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",
                                        "duid": "00:04:01:02:03:04:05:06:07:08:09:0a:0b:0c",
                                        "ip-addresses": [
                                                "fd00::dead:192:168:0:120"
                                        ]
                                },
                                {
                                        "hostname": "ipmi",
                                        "duid": "00:04:01:02:03:04:05:06:07:08:09:0a:0b:0d",
                                        "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).
                        // =====================================================
                        "interface": "eth0",
                        "id": 1,
                        "subnet": "fd00:0:0:dead::/64",,

Das Interface interface muss zwingend angegeben werden und 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",
                                        "duid": "00:04:01:02:03:04:05:06:07:08:09:0a:0b:0c",
                                        "ip-addresses": [
                                                "fd00::dead:192:168:0:120"
                                        ]
                                },
                                {
                                        "hostname": "ipmi",
                                        "duid": "00:04:01:02:03:04:05:06:07:08:09:0a:0b:0d",
                                        "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 DHCPv6-Server mit dem Root-Logger kea-dhcp6, der auf der Ebene INFO protokolliert. Um die DEBUG-Ausführlichkeit für DHCPv6-Paketverluste zu aktivieren, müssen wir einen Konfigurationseintrag für den Logger mit dem Namen kea-dhcp6.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-ctrl-agent.conf

Nachfolgende Konfigurationsdatei /etc/kea/kea-ctrl-agent.conf, stellt die Möglichkeit den DHCP ISC Kea-Server mittels einer HTTP-API zu kontrollieren.

Dies ist die komplette Konfigurationsdatei: 

// This is a basic configuration for the Kea Control Agent.
//
// This is just a very basic configuration. Kea comes with large suite (over 30)
// of configuration examples and extensive Kea User's Guide. Please refer to
// those materials to get better understanding of what this software is able to
// do. Comments in this configuration file sometimes refer to sections for more
// details. These are section numbers in Kea User's Guide. The version matching
// your software should come with your Kea package, but it is also available
// in ISC's Knowledgebase (https://kea.readthedocs.io; the direct link for
// the stable version is https://kea.readthedocs.io/).
//
// This configuration file contains only Control Agent's configuration.
// If configurations for other Kea services are also included in this file they
// are ignored by the Control Agent.
{
 
// This is a basic configuration for the Kea Control Agent.
// RESTful interface to be available at http://127.0.0.1:8000/
"Control-agent": {
    "http-host": "127.0.0.1",
    // If enabling HA and multi-threading, the 8000 port is used by the HA
    // hook library http listener. When using HA hook library with
    // multi-threading to function, make sure the port used by dedicated
    // listener is different (e.g. 8001) than the one used by CA. Note
    // the commands should still be sent via CA. The dedicated listener
    // is specifically for HA updates only.
    "http-port": 8000,
 
    // Specify location of the files to which the Control Agent
    // should connect to forward commands to the DHCPv4, DHCPv6
    // and D2 servers via unix domain sockets.
    "control-sockets": {
        "dhcp4": {
            "socket-type": "unix",
            // Tachtler
            // default: "socket-name": "/tmp/kea4-ctrl-socket"
            "socket-name": "/var/lib/kea/kea4-ctrl-socket"
        },
        "dhcp6": {
            "socket-type": "unix",
            // Tachtler
            // "socket-name": "/tmp/kea6-ctrl-socket"
            "socket-name": "/var/lib/kea/kea6-ctrl-socket"
        },
        "d2": {
            "socket-type": "unix",
            "socket-name": "/tmp/kea-ddns-ctrl-socket"
        }
    },
 
    // Specify hooks libraries that are attached to the Control Agent.
    // Such hooks libraries should support 'control_command_receive'
    // hook point. This is currently commented out because it has to
    // point to the existing hooks library. Otherwise the Control
    // Agent will fail to start.
    "hooks-libraries": [
//  {
//      "library": "/usr/lib/kea/hooks/control-agent-commands.so",
//      "parameters": {
//          "param1": "foo"
//      }
//  }
    ],
 
// Logging configuration starts here. Kea uses different loggers to log various
// activities. For details (e.g. names of loggers), see Chapter 18.
    "loggers": [
    {
        // This specifies the logging for Control Agent daemon.
        "name": "kea-ctrl-agent",
        "output_options": [
            {
                // Specifies the output file. There are several special values
                // supported:
                // - stdout (prints on standard output)
                // - stderr (prints on standard error)
                // - syslog (logs to syslog)
                // - syslog:name (logs to syslog using specified name)
                // Any other value is considered a name of the file
                // Tachtler
                // default: "output": "/var/log/kea-ctrl-agent.log"
                "output": "syslog:kea-ctrl-agent"
 
                // Shorter log pattern suitable for use with systemd,
                // avoids redundant information
                // "pattern": "%-5p %m\n"
 
                // This governs whether the log output is flushed to disk after
                // every write.
                // "flush": false,
 
                // This specifies the maximum size of the file before it is
                // rotated.
                // "maxsize": 1048576,
 
                // This specifies the maximum number of rotated files to keep.
                // "maxver": 8
            }
        ],
        // This specifies the severity of log messages to keep. Supported values
        // are: FATAL, ERROR, WARN, INFO, DEBUG
        "severity": "INFO",
 
        // If DEBUG level is specified, this value is used. 0 is least verbose,
        // 99 is most verbose. Be cautious, Kea can generate lots and lots
        // of logs if told to do so.
        // Tachtler
        // default: "debuglevel": 0
        "debuglevel": 99
    }
  ]
}
}

Erklärungen: 

  •             "socket-name": "/var/lib/kea/kea4-ctrl-socket"

Der Speicherort der Datei, mit denen sich der DHCP ISC Kea-Control-Agent (Steuerungs Agent) mit dem DHCP ISC Kea-Server verbinden soll, um Befehle über Unix-Domain-Sockets an die DHCPv4-Server weiter zu leiten. 

  •             "socket-name": "/var/lib/kea/kea6-ctrl-socket"

Der Speicherort der Datei, mit denen sich der DHCP ISC Kea-Control-Agent (Steuerungs Agent) mit dem DHCP ISC Kea-Server verbinden soll, um Befehle über Unix-Domain-Sockets an die DHCPv6-Server weiter zu leiten. 

  •                 "output": "syslog:kea-ctrl-agent"
  •         "debuglevel": 99

Beim Logging für den DHCP ISC Kea-Control-Agent (Steuerungs Agent) mit dem Root-Logger kea-ctrl-agent, der auf der Ebene INFO protokolliert. Um die DEBUG-Ausführlichkeit für DHCP ISC Kea-Control-Agent (Steuerungs Agent)-Paketverluste zu aktivieren, müssen wir einen Konfigurationseintrag für den Logger mit dem Namen kea-ctrl-agent.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:

TLS-Zertifikat erstellen

Um den DHCP ISC Kea-Server nicht nur unverschlüsselt, sondern auch via TLS/StartTLS-Verschlüsselung ansprechen zu können, muss zuerst ein Zertifikat erzeugt werden. Dies kann durch eine offizielle Zertifizierungsstelle durchgeführt werden, was jedoch natürlich mit Kosten verbunden ist, oder es kommt ein sogenanntes Self-Signed-Certificate (Selbst erstelltes/unterschriebenes) Zertifikat zum Einsatz.

Um die Verschlüsselung einsetzen zu können, sind folgende Komponenten erforderlich:

  • eine eigen Certificate Authority (CA), welche Self-Signed-Certificate (Selbst erstelltes/unterschriebenes) Zertifikat esrtellen kann
  • einen CSR (Certificate Request), welcher von einer Certificate Authority (CA) signiert wird
  • einem private key (privaten Schlüssel), welcher zum CRT (Certificate) gehört und zum Einsatz eines CRT (Certificate) benötigt wird
  • das CRT (Certificate) selbst, welcher von der Certificate Authority (CA) ausgestellt wird

Zur Erstellung eines Self-Signed-Certificate und zur Erstellung der oben genannten Komponenten, wird das Paket

  • openssl

benötigt, welches i.d.R. bereits installiert sein sollte.

Abschliessend soll mit nachfolgendem Befehl in das Verzeichnis /etc/ssl gewechselt werden: 

# cd /etc/ssl

/etc/ssl/openssl.cnf

Nachfolgende Anpassungen müssen mindestens in der Konfigurationsdatei /etc/ssl/openssl.cnf durchgeführt werden, um SAN (Subject Alternative Names) in das Zertifikat mit aufnehmen zu können:

(Nur relevanter Ausschnitt): 

[ v3_req ]
 
# Extensions to add to a certificate request
 
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
# Tachtler - NEW -
subjectAltName = @alt_names
 
# Tachtler - NEW -
[ alt_names ]
DNS.1 = localhost
DNS.2 = 127.0.0.1
DNS.3 = ::1

* Danke an Stefan Mayr für den Hinweis das Zertifikat mit Subject Alternative Names auszustatten → Hintergrund: Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) - Section 6.4.4

Erstellen CA (Certificate Authority)

Zur Erstellung einer eigene Certificate Authority (CA) kann ein Script, welches bei der Installation von openssl mitgeliefert wird und sich im Verzeichnis /etc/ssl/misc/ befindet, genutzt werden. Der Name des Scripts lautet

  • /etc/ssl/misc/CA.pl.

:!: HINWEIS - Um Subject Alternative Names hinzufügen zu können, muss nachfolgende zweite Ergänzung abgeändert werden, das sonst die -extensions v3_req NICHT angezogen wird!

:!: HINWEIS - Die zu erstellende Certificate Authority (CA) hat standardmässig eine Laufzeit von 3 Jahren !!!

Falls eine längere Laufzeit als drei Jahre gewünscht sein soll, kann nachfolgender Parameter im Skript, in nachfolgendem Verzeichnis, mit nachfolgendem Namen

  • /etc/ssl/misc/CA.pl

angepasst werden:

(Nur relevanter Ausschnitt) 

...
# Tachtler
# default: my $DAYS = "-days 365";
my $DAYS = "-days 28023"; # 10.04.2023 - 30.12.2099
# Tachtler
# default: my $CADAYS = "-days 1095";   # 3 years
my $CADAYS = "-days 28024"; # 10.04.2023 - 31.12.2099
...
...
...
} elsif ($WHAT eq '-sign' ) {
    $RET = run("$CA -policy policy_anything -out $NEWCERT"
            # Tachtler
            # default: . " -infiles $NEWREQ $EXTRA{ca}");
            . " -extensions v3_req -infiles $NEWREQ $EXTRA{ca}");
    print "Signed certificate is in $NEWCERT\n" if $RET == 0;
...

:!: WICHTIG - Die Laufzeit der Certificate Authority (CA) muss länger als die Laufzeit des Zertifikates sein !!!

Folgender Aufruf erstellt eine eigene Certificate Authority (CA):

:!: HINWEIS - Nicht benötigte Angaben werden mit Eingabe eines Punktes [.] übersprungen! 

# /etc/ssl/misc/CA.pl -newca
# /etc/ssl/misc/CA.pl -newca
CA certificate filename (or enter to create)
 
Making CA certificate ...
====
openssl req  -new -keyout /etc/ssl/private/cakey.pem -out /etc/ssl/careq.pem 
Generating a RSA private key
.............................+++++
......+++++
writing new private key to '/etc/ssl/private/cakey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Bavaria (Bayern)
Locality Name (eg, city) []:Munich (Muenchen)
Organization Name (eg, company) [Internet Widgits Pty Ltd]:tachtler.net
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:www.tachtler.net
Email Address []:hostmaster@tachtler.net
 
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:.
==> 0
====
====
openssl ca  -create_serial -out /etc/ssl/cacert.pem -days 28024 -batch -keyfile /etc/ssl/private/cakey.pem -selfsign -extensions v3_ca  -infiles /etc/ssl/careq.pem
Using configuration from /etc/ssl/openssl.cnf
Enter pass phrase for /etc/ssl/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number:
            58:b7:f2:c0:f9:30:8d:48:4f:77:d3:56:3d:9d:a9:98:19:e6:a2:49
        Validity
            Not Before: Apr 10 10:48:57 2023 GMT
            Not After : Dec 31 10:48:57 2099 GMT
        Subject:
            countryName               = DE
            stateOrProvinceName       = Bavaria (Bayern)
            organizationName          = tachtler.net
            commonName                = www.tachtler.net
            emailAddress              = hostmaster@tachtler.net
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                07:39:3F:8F:38:B5:EA:69:3E:FA:BC:C4:AB:7C:30:18:93:26:B8:77
            X509v3 Authority Key Identifier: 
                keyid:07:39:3F:8F:38:B5:EA:69:3E:FA:BC:C4:AB:7C:30:18:93:26:B8:77
 
            X509v3 Basic Constraints: critical
                CA:TRUE
Certificate is to be certified until Dec 31 10:48:57 2099 GMT (28403 days)
 
Write out database with 1 new entries
Data Base Updated
==> 0
====
CA certificate is in /etc/ssl/cacert.pem

Durch ausführen des Skriptes mit nachfolgendem Aufrufparameter /etc/ssl/misc/CA.pl -newca ist eine neue Verzeichnisstruktur und neue Dateien unter

  • /etc/ssl

entstanden, deren Inhalt mit nachfolgendem Befehl bequem aufgelistet werden kann: 

# ls -l /etc/ssl
total 64
-rw-r--r-- 1 root root  4611 Apr 10 12:48 cacert.pem
-rw-r--r-- 1 root root  1078 Apr 10 12:48 careq.pem
lrwxrwxrwx 1 root root    46 Jun  3  2021 cert.pem -> ../ca-certificates/extracted/tls-ca-bundle.pem
drwxr-xr-x 1 root root 13526 Apr 16 09:30 certs
drwxr-xr-x 1 root root     0 Apr 10 12:47 crl
-rw-r--r-- 1 root root     3 Apr 10 12:47 crlnumber
-rw-r--r-- 1 root root   412 Dec 18 11:31 ct_log_list.cnf
-rw-r--r-- 1 root root   412 Dec 18 11:31 ct_log_list.cnf.dist
-rw-r--r-- 1 root root   166 Apr 10 12:48 index.txt
-rw-r--r-- 1 root root    21 Apr 10 12:48 index.txt.attr
-rw-r--r-- 1 root root     0 Apr 10 12:47 index.txt.old
drwxr-xr-x 1 root root    36 Apr 10 12:47 misc
drwxr-xr-x 1 root root    88 Apr 10 12:48 newcerts
-rw-r--r-- 1 root root 11160 Apr 10 12:46 openssl.cnf
-rw-r--r-- 1 root root 10909 Dec 18 11:31 openssl.cnf.dist
drwxr-xr-x 1 root root    18 Apr 10 12:47 private
-rw-r--r-- 1 root root    41 Apr 10 12:48 serial
# ls -l /etc/ssl/newcerts
total 8
-rw-r--r-- 1 root root 4611 Apr 10 12:48 58B7F2C0F9308D484F77D3563D9DA99819E6A249.pem
# ls -l /etc/ssl/private
total 4
-rw------- 1 root root 1854 Apr 10 12:48 cakey.pem

Erstellen CSR (Certificate Request)

Ebenfalls mit dem Script, welches schon bei der Erstellung einer eigene Certificate Authority (CA) genutzt wurde und sich unter /etc/ssl/misc befindet und den Namen CA trägt, kann nun dieses auch zur Erstellung von

  • einem CSR (Certificate Request)
  • einem private key (privaten Schlüssel)

genutzt werden.

:!: HINWEIS - Das zu erstellende Zertifikat hat standardmässig eine Laufzeit von 1 Jahr !!!

Falls eine längere Laufzeit als ein Jahr gewünscht sein soll, kann nachfolgender Parameter im Skript, in nachfolgendem Verzeichnis, mit nachfolgendem Namen

  • /etc/ssl/openssl.cnf

angepasst werden:

(Nur relevanter Ausschnitt) 

...
# Tachtler
# default: default_days = 365           # how long to certify for
default_days    = 28023         # how long to certify for 10.04.2023 - 30.12.2099
...

:!: HINWEIS - Nicht benötigte Angaben werden mit Eingabe eines Punktes [.] übersprungen! 

# /etc/ssl/misc/CA.pl -newreq -extra-req -extensions=v3_req
# /etc/ssl/misc/CA.pl -newreq -extra-req -extensions=v3_req
Use of uninitialized value $1 in concatenation (.) or string at /etc/ssl/misc/CA.pl line 137.
====
openssl req  -new  -keyout newkey.pem -out newreq.pem -days 28023 -extensions=v3_req
Ignoring -days; not generating a certificate
Generating a RSA private key
...+++++
....................................+++++
writing new private key to 'newkey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Bavaria (Bayern)
Locality Name (eg, city) []:Munich (Muenchen)
Organization Name (eg, company) [Internet Widgits Pty Ltd]:tachtler.net
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:kea-api.idmz.tachtler.net
Email Address []:hostmaster@tachtler.net
 
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []: 
An optional company name []:.
==> 0
====
Request is in newreq.pem, private key is in newkey.pem

Durch ausführen des Scripts mit nachfolgendem Aufrufparameter /etc/ssl/misc/CA.pl -newreq -extra-req -extensions=v3_req sind zwei neue Dateien unter

  • /etc/ssl

entstanden, welche mit nachfolgendem Befehl aufgelistet werden können: 

# ls -l /etc/ssl/new*.pem
-rw------- 1 root root 1854 Apr 10 14:01 /etc/ssl/newkey.pem
-rw-r--r-- 1 root root 1086 Apr 10 14:03 /etc/ssl/newreq.pem

:!: WICHTIG - Die so entstandene Datei /etc/ssl/newreq.pem enthält den CSR (Certificate Request).

Signieren CSR (Certificate Request)

Um den in obigen Beispiel entstandenen CSR (Certificate Request) nun mit der Certificate Authority (CA) zu unterschreiben und somit ein signiertes CRT (Certificate) zu erzeugen, kann wieder das Script, welches schon bei der Erstellung der Certificate Authority (CA) genutzt wurde und sich unter /etc/ssl/misc befindet und den Namen CA.pl trägt, mit nachfolgendem Befehl genutzt werden:

:!: WICHTIG - Das Passwort, ist das Passwort, welches im Schritt DHCP ISC Kea ArchLinux - Erstellen CA (Certificate Authority) verwendet wurde! 

# /etc/ssl/misc/CA.pl -sign -extra-ca
# /etc/ssl/misc/CA.pl -sign -extra-ca
====
openssl ca  -policy policy_anything -out newcert.pem -extensions=v3_req -infiles newreq.pem
Using configuration from /etc/ssl/openssl.cnf
Enter pass phrase for /etc/ssl/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number:
            58:b7:f2:c0:f9:30:8d:48:4f:77:d3:56:3d:9d:a9:98:19:e6:a2:4a
        Validity
            Not Before: Apr 10 12:04:22 2023 GMT
            Not After : Dec 30 12:04:22 2099 GMT
        Subject:
            countryName               = DE
            stateOrProvinceName       = Bavaria (Bayern)
            localityName              = Munich (Muenchen)
            organizationName          = tachtler.net
            commonName                = kea-api.idmz.tachtler.net
            emailAddress              = hostmaster@tachtler.net
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            X509v3 Key Usage: 
                Digital Signature, Non Repudiation, Key Encipherment
            X509v3 Subject Alternative Name: 
                DNS:localhost, DNS:127.0.0.1, DNS:::1
Certificate is to be certified until Dec 30 12:04:22 2099 GMT (28402 days)
Sign the certificate? [y/n]:y
 
 
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
==> 0
====
Signed certificate is in newcert.pem

Durch ausführen des Skriptes mit nachfolgendem Aufrufparameter /etc/ssl/misc/CA.pl -sign -extra-ca ist eine weitere neue Dateien unter

  • /etc/ssl

entstanden, welche mit nachfolgendem Befehl aufgelistet werden kann: 

# ls -l /etc/ssl/new*.pem
-rw-r--r-- 1 root root 4639 Apr 10 14:04 /etc/ssl/newcert.pem
-rw------- 1 root root 1854 Apr 10 14:01 /etc/ssl/newkey.pem
-rw-r--r-- 1 root root 1086 Apr 10 14:03 /etc/ssl/newreq.pem

:!: WICHTIG - Die so entstandene Datei /etc/ssl/newcert.pem enthält das neue signierte CRT (Certificate)!

Entfernen des Passwortes vom private key

Ein Problem ist durch die Erstellung der einzelnen Komponenten, wie in den drei vorhergehenden Schritten beschrieben worden noch offen.

:!: WICHTIG - Der private key (privaten Schlüssel) ist mit einer Passphrase gesichert !

Um dieses Problem zu lösen und das Passwort aus dem private key (privaten Schlüssel) zu entfernen, kann folgender Aufruf von openssl genutzt werden:

:!: WICHTIG - Das Passwort, ist das Passwort, welches im Schritt DHCP ISC Kea ArchLinux - Erstellen CA (Certificate Authority) verwendet wurde! 

# openssl rsa < /etc/ssl/newkey.pem > /etc/ssl/key.pem
Enter pass phrase: 
writing RSA key

Durch ausführen des oben genannten Befehls ist eine weitere neue Dateien unter

  • /etc/ssl

entstanden, welche mit nachfolgendem Befehl aufgelistet werden kann: 

# ls -l /etc/ssl/*key*
-rw-r--r-- 1 root root 1679 Apr 10 13:16 /etc/ssl/key.pem
-rw------- 1 root root 1854 Apr 10 13:12 /etc/ssl/newkey.pem

:!: WICHTIG - Die so entstandene Datei /etc/ssl/key.pem enthält den private key (privaten Schlüssel) OHNE Passphrase!

Installation Zertifikat

Nach dem ein Zertifikat wie hier: DHCP ISC Kea ArchLinux - TLS-Zertifikat erstellen beschrieben erstellt wurde, müssen die benötigen Komponenten noch an die entsprechenden Stellen im Betriebssystem kopiert werden. Dazu sind nachfolgende Befehle notwendig.

Bevor mit der abschliessenden Konfiguration von DHCP ISC Kea zur Nutzung von HTTPS begonnen werden kann, sind die in den vorhergehenden Schritten erstellten Dateien:

  • /etc/ssl/key.pem
  • /etc/ssl/newcert.pem
  • /etc/ssl/cacert.pem

noch zu kopieren und ggf. umzubenennen und die Besitz- und Dateirechte der entsprechend Dateien noch anzupassen!

Als erstes werden mit den nachfolgenden Befehlen zwei neue Verzeichnisse im bestehen Verzeichnis /etc/kea angelegt: 

# mkdir -p /etc/kea/ssl/{certs,private}

Anschliessend werden mit den nachfolgenden Befehlen die entsprechenden Dateien an den jeweiligen Bestimmungsort kopiert und ggf. umbenannt: 

# cp -a /etc/ssl/key.pem /etc/kea/ssl/private/kea-api.idmz.tachtler.net.key
# cp -a /etc/ssl/newcert.pem /etc/kea/ssl/certs/kea-api.idmz.tachtler.net.pem
# cp -a /etc/ssl/cacert.pem /etc/kea/ssl/certs/CAcert.pem

Die Besitz- und Dateirechte der soeben kopieren und ggf. umbenannten Dateien

  • /etc/kea/ssl/private/kea-api.idmz.tachtler.net.key
  • /etc/kea/ssl/certs/kea-api.idmz.tachtler.net.pem
  • /etc/kea/ssl/certs/CAcert.pem

können mit folgenden Befehlen die Besitzrechte wie folgt korrigiert werden: 

# chown root:root /etc/kea/ssl/private/kea-api.idmz.tachtler.net.key
# chown root:root /etc/kea/ssl/certs/kea-api.idmz.tachtler.net.pem
# chown root:root /etc/kea/ssl/certs/CAcert.pem

und mit folgenden Befehlen die Dateirechte: 

# chmod 400 /etc/kea/ssl/private/kea-api.idmz.tachtler.net.key
# chmod 444 /etc/kea/ssl/certs/kea-api.idmz.tachtler.net.pem
# chmod 444 /etc/kea/ssl/certs/CAcert.pem

Durch Ausführen der oben genannten Befehle sieht der Inhalt des Verzeichnisses

  • /etc/kea/ssl

wie folgt aus, welches mit nachfolgendem Befehl aufgelistet werden kann: 

# ls -l /etc/kea/ssl/*
/etc/kea/ssl/certs:
total 16
-r--r--r-- 1 root root 4611 Apr 10 14:59 CAcert.pem
-r--r--r-- 1 root root 4810 Apr 10 14:59 kea-api.idmz.tachtler.net.pem

/etc/kea/ssl/private:
total 4
-r-------- 1 root root 1675 Apr 10 14:59 kea-api.idmz.tachtler.net.key

Erweiterte-Konfiguration:

Nachfolgende Konfigurationsschritte sollen eine erweiterte 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-ctrl-agent.conf

Nachfolgende Konfigurationsdatei /etc/kea/kea-ctrl-agent.conf, stellt die Möglichkeit den DHCP ISC Kea-Server mittels einer

  • HTTPS-API zu kontrollieren und die entsprechenden Zertifikate zu implementieren.
  • Einen Benutzernamen und ein Passwort für die Authentifizierung an der HTTPS-API vor zu nehmen.

Dies ist die komplette Konfigurationsdatei: 

// This is a basic configuration for the Kea Control Agent.
//
// This is just a very basic configuration. Kea comes with large suite (over 30)
// of configuration examples and extensive Kea User's Guide. Please refer to
// those materials to get better understanding of what this software is able to
// do. Comments in this configuration file sometimes refer to sections for more
// details. These are section numbers in Kea User's Guide. The version matching
// your software should come with your Kea package, but it is also available
// in ISC's Knowledgebase (https://kea.readthedocs.io; the direct link for
// the stable version is https://kea.readthedocs.io/).
//
// This configuration file contains only Control Agent's configuration.
// If configurations for other Kea services are also included in this file they
// are ignored by the Control Agent.
{
 
// This is a basic configuration for the Kea Control Agent.
// RESTful interface to be available at http://127.0.0.1:8000/
"Control-agent": {
    "http-host": "127.0.0.1",
    // If enabling HA and multi-threading, the 8000 port is used by the HA
    // hook library http listener. When using HA hook library with
    // multi-threading to function, make sure the port used by dedicated
    // listener is different (e.g. 8001) than the one used by CA. Note
    // the commands should still be sent via CA. The dedicated listener
    // is specifically for HA updates only.
    "http-port": 8000,
 
    // Tachtler - NEW -
    "trust-anchor": "/etc/kea/ssl/certs/CAcert.pem",
    "cert-file": "/etc/kea/ssl/certs/kea-api.idmz.tachtler.net.pem",
    "key-file": "/etc/kea/ssl/private/kea-api.idmz.tachtler.net.key",
    "cert-required": false,
    "authentication": {
        "type": "basic",
        "realm": "kea-control-agent",
        "clients": [
        {   
            "user": "admin",
            "password": "geheim"
        }   
    ]   
    },      
 
    // Specify location of the files to which the Control Agent
    // should connect to forward commands to the DHCPv4, DHCPv6
    // and D2 servers via unix domain sockets.
    "control-sockets": {
        "dhcp4": {
            "socket-type": "unix",
            // Tachtler
            // default: "socket-name": "/tmp/kea4-ctrl-socket"
            "socket-name": "/var/lib/kea/kea4-ctrl-socket"
        },
        "dhcp6": {
            "socket-type": "unix",
            // Tachtler
            // "socket-name": "/tmp/kea6-ctrl-socket"
            "socket-name": "/var/lib/kea/kea6-ctrl-socket"
        },
        "d2": {
            "socket-type": "unix",
            "socket-name": "/tmp/kea-ddns-ctrl-socket"
        }
    },
 
    // Specify hooks libraries that are attached to the Control Agent.
    // Such hooks libraries should support 'control_command_receive'
    // hook point. This is currently commented out because it has to
    // point to the existing hooks library. Otherwise the Control
    // Agent will fail to start.
    "hooks-libraries": [
//  {
//      "library": "/usr/lib/kea/hooks/control-agent-commands.so",
//      "parameters": {
//          "param1": "foo"
//      }
//  }
    ],
 
// Logging configuration starts here. Kea uses different loggers to log various
// activities. For details (e.g. names of loggers), see Chapter 18.
    "loggers": [
    {
        // This specifies the logging for Control Agent daemon.
        "name": "kea-ctrl-agent",
        "output_options": [
            {
                // Specifies the output file. There are several special values
                // supported:
                // - stdout (prints on standard output)
                // - stderr (prints on standard error)
                // - syslog (logs to syslog)
                // - syslog:name (logs to syslog using specified name)
                // Any other value is considered a name of the file
                // Tachtler
                // default: "output": "/var/log/kea-ctrl-agent.log"
                "output": "syslog:kea-ctrl-agent"
 
                // Shorter log pattern suitable for use with systemd,
                // avoids redundant information
                // "pattern": "%-5p %m\n"
 
                // This governs whether the log output is flushed to disk after
                // every write.
                // "flush": false,
 
                // This specifies the maximum size of the file before it is
                // rotated.
                // "maxsize": 1048576,
 
                // This specifies the maximum number of rotated files to keep.
                // "maxver": 8
            }
        ],
        // This specifies the severity of log messages to keep. Supported values
        // are: FATAL, ERROR, WARN, INFO, DEBUG
        "severity": "INFO",
 
        // If DEBUG level is specified, this value is used. 0 is least verbose,
        // 99 is most verbose. Be cautious, Kea can generate lots and lots
        // of logs if told to do so.
        // Tachtler
        // default: "debuglevel": 0
        "debuglevel": 99
    }
  ]
}
}

Erklärungen: 

  •     // Tachtler - NEW -
    "trust-anchor": "/etc/kea/ssl/certs/CAcert.pem",

Dieser Parameter gibt den Namen einer Datei oder eines Verzeichnisses an, in dem das Zertifikat der Zertifizierungsstelle (CA) gefunden werden kann. 

  •     "cert-file": "/etc/kea/ssl/certs/kea-api.idmz.tachtler.net.pem",

Dieser Parameter gibt den Namen der Datei an, die das Endteilnehmerzertifikat des zu konfigurierenden DHCP ISC Kea-Servers enthält. 

  •     "key-file": "/etc/kea/ssl/private/kea-api.idmz.tachtler.net.key",

Dieser Parameter gibt den privaten Schlüssel des Endteilnehmer-Zertifikats des zu konfigurierenden DHCP ISC Kea-Servers an. Die Datei darf nicht verschlüsselt sein; es wird dringend empfohlen, den Zugriff auf sie zu beschränken. 

  •     "cert-required": false,

Dieser boolesche Parameter erlaubt es einem Server, das Client-Zertifikat nicht zu verlangen. Sein Standardwert ist true, was bedeutet, dass das Client-Zertifikat erforderlich ist und der Client authentifiziert werden muss. Dieses Flag hat auf der Client-Seite keine Bedeutung; der Server stellt immer ein Zertifikat bereit, das vom Client validiert wird. 

  •     "authentication": {
        "type": "basic",
        "realm": "kea-control-agent",
        "clients": [
        {   
            "user": "admin",
            "password": "geheim"
        }   
    ]   
    },

Dies ist ein kompletter Block, welcher eine Authentifizierung am DHCP ISC Kea-Control-Agent (Steuerungs-Agenten) erfordert.

Die Parameter ”type”: ”basic”,, ”realm”: ”kea-control-agent”, geben an, das es sich hier um eine Basic-Authentification, ähnlich wie bei einem Apache HTTPD Webserver - Authentication and Authorization handelt.

Die Parameter ”clients”: [ - und die darin enthaltenen Parameter ”user”: ”admin”, und ”password”: ”geheim” definieren die „Credentials“ für die Authentifizierung.

Erster Start

Mit nachfolgenden Befehlen werden die zuvor konfigurierten Dienste/Daemons von DHCP ISC Kea gestartet werden: 

# systemctl start kea-dhcp4.service kea-dhcp6.service kea-ctrl-agent.service

Mit nachfolgenden Befehlen kann überprüft werden, ob die enstrpechenden Startvorgänge korrekt und wie gewünscht erfolgt sind:

Start kea-dhcp4.service

# systemctl status kea-dhcp4.service
● kea-dhcp4.service - ISC Kea IPv4 DHCP daemon
     Loaded: loaded (/usr/lib/systemd/system/kea-dhcp4.service; enabled; preset>
     Active: active (running) since Sun 2023-04-16 08:51:09 CEST; 13s ago
       Docs: man:kea-dhcp4(8)
   Main PID: 941 (kea-dhcp4)
      Tasks: 9 (limit: 2318)
     Memory: 2.5M
        CPU: 21ms
     CGroup: /system.slice/kea-dhcp4.service
             └─941 /usr/bin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf

Apr 16 08:51:09 server kea-dhcp4[941]: INFO  [kea-dhcp4.dhcpsrv.140087494487104>
Apr 16 08:51:09 server kea-dhcp4[941]: INFO  [kea-dhcp4.dhcpsrv.140087494487104>
Apr 16 08:51:09 server kea-dhcp4[941]: INFO  [kea-dhcp4.commands.14008749448710>
Apr 16 08:51:09 server kea-dhcp4[941]: INFO  [kea-dhcp4.dhcp4.140087494487104] >
Apr 16 08:51:09 server kea-dhcp4[941]: INFO  [kea-dhcp4.dhcpsrv.140087494487104>
Apr 16 08:51:09 server kea-dhcp4[941]: INFO  [kea-dhcp4.dhcpsrv.140087494487104>
Apr 16 08:51:09 server kea-dhcp4[941]: INFO  [kea-dhcp4.dhcpsrv.140087494487104>
Apr 16 08:51:09 server kea-dhcp4[941]: INFO  [kea-dhcp4.dhcpsrv.140087494487104>
Apr 16 08:51:09 server kea-dhcp4[941]: WARN  [kea-dhcp4.dhcp4.140087494487104] >
Apr 16 08:51:09 server kea-dhcp4[941]: INFO  [kea-dhcp4.dhcp4.140087494487104] >

:!: HINWEIS - Der nachfolgende WARN-Hinweis dient nur der Information: 

kea-dhcp4[941]: WARN  [kea-dhcp4.dhcp4.140087494487104] DHCP4_MULTI_THREADING_INFO enabled: yes, number of
threads: 4, queue size: 7

Start kea-dhcp6.service

# systemctl status kea-dhcp6.service
● kea-dhcp6.service - ISC Kea IPv6 DHCP daemon
     Loaded: loaded (/usr/lib/systemd/system/kea-dhcp6.service; enabled; preset>
     Active: active (running) since Sun 2023-04-16 08:51:09 CEST; 50s ago
       Docs: man:kea-dhcp6(8)
   Main PID: 943 (kea-dhcp6)
      Tasks: 9 (limit: 2318)
     Memory: 2.5M
        CPU: 20ms
     CGroup: /system.slice/kea-dhcp6.service
             └─943 /usr/bin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf

Apr 16 08:51:09 server kea-dhcp6[943]: INFO  [kea-dhcp6.dhcpsrv.139894292601920>
Apr 16 08:51:09 server kea-dhcp6[943]: INFO  [kea-dhcp6.commands.13989429260192>
Apr 16 08:51:09 server kea-dhcp6[943]: INFO  [kea-dhcp6.dhcp6.139894292601920] >
Apr 16 08:51:09 server kea-dhcp6[943]: INFO  [kea-dhcp6.dhcpsrv.139894292601920>
Apr 16 08:51:09 server kea-dhcp6[943]: INFO  [kea-dhcp6.dhcpsrv.139894292601920>
Apr 16 08:51:09 server kea-dhcp6[943]: INFO  [kea-dhcp6.dhcpsrv.139894292601920>
Apr 16 08:51:09 server kea-dhcp6[943]: INFO  [kea-dhcp6.dhcpsrv.139894292601920>
Apr 16 08:51:09 server kea-dhcp6[943]: INFO  [kea-dhcp6.dhcp6.139894292601920] >
Apr 16 08:51:09 server kea-dhcp6[943]: WARN  [kea-dhcp6.dhcp6.139894292601920] >
Apr 16 08:51:09 server kea-dhcp6[943]: INFO  [kea-dhcp6.dhcp6.139894292601920] >

:!: HINWEIS - Der nachfolgende WARN-Hinweis dient nur der Information: 

kea-dhcp6[943]: WARN  [kea-dhcp6.dhcp6.139894292601920] DHCP6_MULTI_THREADING_INFO enabled: yes, number of
threads: 4, queue size: 150

Start kea-ctrl-agent.service

# systemctl status kea-ctrl-agent.service
● kea-ctrl-agent.service - ISC Kea control agent daemon
     Loaded: loaded (/usr/lib/systemd/system/kea-ctrl-agent.service; enabled; p>
     Active: active (running) since Sun 2023-04-16 08:51:09 CEST; 1min 33s ago
       Docs: man:kea-ctrl-agent(8)
   Main PID: 942 (kea-ctrl-agent)
      Tasks: 5 (limit: 2318)
     Memory: 1.9M
        CPU: 15ms
     CGroup: /system.slice/kea-ctrl-agent.service
             └─942 /usr/bin/kea-ctrl-agent -c /etc/kea/kea-ctrl-agent.conf

Apr 16 08:51:09 server systemd[1]: Started ISC Kea control agent daemon.
Apr 16 08:51:09 server kea-ctrl-agent[942]: 2023-04-16 08:51:09.750 INFO  [kea->
Apr 16 08:51:09 server kea-ctrl-agent[942]: INFO  [kea-ctrl-agent.ctrl-agent.13>
Apr 16 08:51:09 server kea-ctrl-agent[942]: INFO  [kea-ctrl-agent.dctl.13974915>
Apr 16 08:51:09 server kea-ctrl-agent[942]: INFO  [kea-ctrl-agent.ctrl-agent.13>

Erste Tests

Nachfolgende Test ermöglichen den Nachweis, das DHCP-Anfragen und die Steuerung des DHCP ISC Kea-Servers und seiner Komponenten erfolgreich durchgeführt werden kann.

Test kea-dhcp4.service

Nachfolgender Befehl, ausgeführt auf und von einem weiteren Server, auf dem das Programm perfdhcp ebenfalls installiert ist - welches im Paket kea enthalten ist - simuliert eine DHCP-Anfrage an den DHCP ISC Kea-Server via IPv4. 

# perfdhcp -4 -b mac=ab:12:34:56:78:90 -n 1 -l eth0
Running: perfdhcp -4 -b mac=ab:12:34:56:78:90 -n 1 -l eth0
Scenario: basic.
Multi-thread mode enabled.
***Rate statistics***
Rate: 0 4-way exchanges/second
***Malformed Packets***
Malformed packets: 0
***Statistics for: DISCOVER-OFFER***
sent packets: 1
received packets: 0
drops: 1
drops ratio: 100 %
orphans: 0
rejected leases: 0
non unique addresses: 0

min delay: inf ms
avg delay: min delay: n/a
avg delay: n/a
max delay: n/a
std deviation: n/a
collected packets: 0

***Statistics for: REQUEST-ACK***
sent packets: 0
received packets: 0
drops: 0
drops ratio: -nan %
orphans: 0
rejected leases: 0
non unique addresses: 0

min delay: inf ms
avg delay: min delay: n/a
avg delay: n/a
max delay: n/a
std deviation: n/a
collected packets: 0

Das Ergebnis, ist dann im LOG, des DHCP ISC Kea-Server zu sehen und ergibt einer Ausgabe wie nachfolgende, wenn erfolgreich eine DHCP-Anfrage in der Auslieferung einer IPv4-Adresse erfolgt. Die Anfrage der Ausgabe der LOG-Datei des DHCP ISC Kea-Servers kann mit nachfolgendem Befehl durchgeführt werden: 

# journalctl -ft kea-dhcp4
Apr 16 09:10:55 server kea-dhcp4[941]: INFO  [kea-dhcp4.leases.140087443568320] DHCP4_LEASE_ADVERT
[hwtype=1 ab:12:34:56:78:90], cid=[01:ab:12:34:56:78:90], tid=0x0: lease 192.168.0.120 will be advertised

Test kea-dhcp6.service

Nachfolgender Befehl, ausgeführt auf und von einem weiteren Server, auf dem das Programm perfdhcp ebenfalls installiert ist - welches im Paket kea enthalten ist - simuliert eine DHCP-Anfrage an den DHCP ISC Kea-Server via IPv6. 

# perfdhcp -6 -b duid=00040102030405060708090a0b0c -n 1 -l eth0
Running: perfdhcp -6 -b duid=00040102030405060708090a0b0c -n 1 -l eth0
Scenario: basic.
Multi-thread mode enabled.
***Rate statistics***
Rate: 0 4-way exchanges/second
***Malformed Packets***
Malformed packets: 0
***Statistics for: SOLICIT-ADVERTISE***
sent packets: 1
received packets: 0
drops: 1
drops ratio: 100 %
orphans: 0
rejected leases: 0
non unique addresses: 0

min delay: inf ms
avg delay: min delay: n/a
avg delay: n/a
max delay: n/a
std deviation: n/a
collected packets: 0

***Statistics for: REQUEST-REPLY***
sent packets: 0
received packets: 0
drops: 0
drops ratio: -nan %
orphans: 0
rejected leases: 0
non unique addresses: 0

min delay: inf ms
avg delay: min delay: n/a
avg delay: n/a
max delay: n/a
std deviation: n/a
collected packets: 0

Das Ergebnis, ist dann im LOG, des DHCP ISC Kea-Server zu sehen und ergibt einer Ausgabe wie nachfolgende, wenn erfolgreich eine DHCP-Anfrage in der Auslieferung einer IPv6-Adresse erfolgt. Die Anfrage der Ausgabe der LOG-Datei des DHCP ISC Kea-Servers kann mit nachfolgendem Befehl durchgeführt werden: 

# journalctl -ft kea-dhcp6
Apr 16 09:19:02 server kea-dhcp6[943]: INFO  [kea-dhcp6.alloc-engine.139894258468544]
ALLOC_ENGINE_V6_HR_ADDR_GRANTED reserved address fd00::dead:192:168:0:120 was assigned to client
duid=[00:04:01:02:03:04:05:06:07:08:09:0a:0b:0c], tid=0x0
Apr 16 09:19:02 server kea-dhcp6[943]: INFO  [kea-dhcp6.leases.139894258468544] DHCP6_LEASE_ADVERT
duid=[00:04:01:02:03:04:05:06:07:08:09:0a:0b:0c], tid=0x0: lease for address fd00::dead:192:168:0:120
and iaid=1 will be advertised

Test kea-ctrl-agent.service

Nachfolgender Befehl, ausgeführt auf dem DHCP ISC Kea-Server, auf dem das Programm kea-shell installiert ist - welches im Paket kea enthalten ist - simuliert die HTTPS-Anfragen zur Steuerung an den DHCP ISC Kea-Server lokal.

:!: WICHTIG - Erst nach dem drücken der Tastenkombination [Strg-C]/[Crtl-C] erfolgt eine Ausgabe ! 

# kea-shell --host localhost --port 8000 --ca /etc/kea/ssl/certs/CAcert.pem --auth-user admin --auth-password geheim --service dhcp4 version-get | python -m json.tool

Die Ausgabe, welche durch die Umleitung (pipe) an den Befehl python -m json.tool eine bessere Lesbarkeit der JSON Formatierung erhält, kann nun wie folgt aussehen: 

[
    {
        "arguments": {
            "extended": "2.2.0\ntarball\nlinked with:\nlog4cplus 2.0.8\nOpenSSL 3.0.8 7 Feb 2023\ndatabase
:\nMySQL backend 14.0, library 3.3.4\nPostgreSQL backend 13.0, library 150002\nMemfile backend 2.1"
        },
        "result": 0,
        "text": "2.2.0"
    }
]

oder

:!: WICHTIG - Erst nach dem drücken der Tastenkombination [Strg-C]/[Crtl-C] erfolgt eine Ausgabe ! 

# kea-shell --host localhost --port 8000 --ca /etc/kea/ssl/certs/CAcert.pem --auth-user admin --auth-password geheim --service dhcp6 version-get | python -m json.tool

Die Ausgabe, welche durch die Umleitung (pipe) an den Befehl python -m json.tool eine bessere Lesbarkeit der JSON Formatierung erhält, kann nun wie folgt aussehen: 

[
    {
        "arguments": {
            "extended": "2.2.0\ntarball\nlinked with:\nlog4cplus 2.0.8\nOpenSSL 3.0.8 7 Feb 2023\ndatabase
:\nMySQL backend 14.0, library 3.3.4\nPostgreSQL backend 13.0, library 150002\nMemfile backend 4.0"
        },
        "result": 0,
        "text": "2.2.0"
    }
]

Nachfolgender Befehl gibt eine Übersicht aus, welche Steuerungsbefehle über den Aufruf der kea-shell und des Dienstes/Daemons möglich sind: 

# kea-shell --host localhost --port 8000 --ca /etc/kea/ssl/certs/CAcert.pem --auth-user admin --auth-password geheim --service dhcp4 list-commands | python -m json.tool
[
    {
        "arguments": [
            "build-report",
            "config-backend-pull",
            "config-get",
            "config-reload",
            "config-set",
            "config-test",
            "config-write",
            "dhcp-disable",
            "dhcp-enable",
            "leases-reclaim",
            "libreload",
            "list-commands",
            "server-tag-get",
            "shutdown",
            "statistic-get",
            "statistic-get-all",
            "statistic-remove",
            "statistic-remove-all",
            "statistic-reset",
            "statistic-reset-all",
            "statistic-sample-age-set",
            "statistic-sample-age-set-all",
            "statistic-sample-count-set",
            "statistic-sample-count-set-all",
            "status-get",
            "version-get"
        ],
        "result": 0
    }
]

Weitere Informationen, welche Abfragen mit der kea-shell möglich sind, können unter nachfolgendem externen Link abgerufen werden:

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: 2024/09/01 15:13 von klaus