Inhaltsverzeichnis
DHCP ISC Kea ArchLinux
DHCP ISC Kea ist ein DHCP-Server, welcher die IP-Adressverteilung in einem Netzwerk realisieren kann. Der DHCP-Server des ISC (Internet System Consortium) ist eine Neuentwicklung und lösten den in die Jahre gekommenen DHCP ISC dhcpd ab.
Hinweis - Die nachfolgenden Ausführungen erheben keinen Anspruch auf Vollständigkeit, sondern stellen eine „Basiskonfiguration“ eins DHCP-Servers für ein kleines privates Netzwerk dar!!!
Beschreibung | Externer Link |
---|---|
Homepage | https://www.isc.org/kea/ |
Dokumentation | https://kea.readthedocs.io/en/latest/index.html |
Migrationstool | https://gitlab.isc.org/isc-projects/dhcp/-/tree/master/keama |
Ab hier werden zur Ausführung nachfolgender Befehle root
-Rechte benötigt. Um der Benutzer root
zu werden, melden Sie sich bitte als root
-Benutzer am System an, oder wechseln mit nachfolgendem Befehl zum Benutzer root
:
$ su - Password:
Überblick
Im nachfolgenden soll die Konfiguration
- eines DHCP-Servers für IPv4
- eines DHCP-Servers für IPv6
welche als internes, nicht nach außen agierender DHCP-Server Konstrukt für ein privates Netzwerk mit einem Netz durchgeführt werden. Nachfolgendes Netz wird dabei verwaltet:
- Intranet - Domain: intra.tachtler.net - IPv4-Adressbereich: 192.168.0.0/24
- Intranet - Domain: intra.tachtler.net - IPv6-Adressbereich: fd00::dead:192:168:0:0/64
Installation
Zur Installation von DHCP ISC Kea wird nachfolgendes Paket benötigt:
Mit nachfolgendem Befehl, wird das Pakete kea
installiert:
# pacman --noconfirm -S kea
Mit nachfolgendem Befehl kann überprüft werden, welche Inhalte mit den Paket kea
installiert wurden.
# pacman -Qil kea
Dienst/Deamon-Start einrichten
Um einen DHCP-Servers für IPv4 und für DHCP-Servers für IPv6, welche als Dienst/Deamon als Hintergrundprozess laufen sollen, auch nach einem Neustart des Servers zur Verfügung zu haben, soll die Dienste/Daemons mit dem Server mit gestartet werden, was mit nachfolgenden Befehlen realisiert werden kann:
# systemctl enable kea-dhcp4.service kea-dhcp6.service Created symlink /etc/systemd/system/multi-user.target.wants/kea-dhcp4.service → /usr/lib/systemd/system/kea-dhcp4.service. Created symlink /etc/systemd/system/multi-user.target.wants/kea-dhcp6.service → /usr/lib/systemd/system/kea-dhcp6.service.
Eine Überprüfung, ob beim Neustart des Server der kea-dhcp4
- und der kea-dhcp6
-Dienst/Deamon wirklich mit gestartet werden, kann mit nachfolgenden Befehlen erfolgen und sollte eine Anzeige, wie ebenfalls nachfolgend dargestellt ausgeben:
# systemctl list-unit-files --type=service | grep kea-dhcp..service kea-dhcp4.service enabled disabled kea-dhcp6.service enabled disabled
bzw.
# systemctl is-enabled kea-dhcp4.service kea-dhcp6.service enabled enabled
iptables/ip6tables Regeln
Damit der DHCP ISC Kea auch erreichbar ist und nicht die Proxy-Anfragen vom Paketfilter iptables
blockiert werden, müssen nachfolgende Regeln zum iptables
-Regelwerk hinzugefügt werden.
Um die aktuellen iptables
-Regeln erweitern zu können, sollten diese erst einmal aufgelistet werden, was mit nachfolgendem Befehl durchgeführt werden kann:
# iptables -L -nv --line-numbers Chain INPUT (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 1169 2101K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED 2 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 3 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 4 1 60 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 5 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 5 prefix "REC-INP Defend " 6 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset 7 0 0 REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 8 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-proto-unreachable Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 917 packets, 84944 bytes) num pkts bytes target prot opt in out source destination
Nachfolgende Befehle, fügen folgende iptables
-Regeln dem iptables
-Regelwerk nach der Position 4 hinzu, ohne das der Paketfilter angehalten werden muss:
-A INPUT -p udp --dport 67 -j ACCEPT
-A OUTPUT -p udp --dport 68 -j ACCEPT
und hier die Befehle:
# iptables -I INPUT 5 -p udp --dport 67 -j ACCEPT # iptables -I OUTPUT 1 -p udp --dport 68 -j ACCEPT
Ein erneute Abfrage des iptables
-Regelwerts, sollte dann nachfolgend dargestellte Ausgabe ergeben, was mit folgendem Befehl durchgeführt werden kann:
# iptables -L -nv --line-numbers Chain INPUT (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 1202 2103K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED 2 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 3 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 4 1 60 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 5 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:67 6 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 5 prefix "REC-INP Defend " 7 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset 8 0 0 REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 9 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-proto-unreachable Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 7 packets, 936 bytes) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:68
Die neuen Zeilen sind an Position 5 (INPUT) und Position 1 (OUTPUT) zu sehen, hier nachfolgend zur Verdeutlichung noch einmal dargestellt (nur relevanter Ausschnitt):
... 5 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:67 1 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:68 ...
Um diese iptables
-Regel dauerhaft, auch nach einem Neustart des Server, weiterhin im iptables
-Regelwerk zu speichern, muss nachfolgend dargestellter Befehl abschliessend noch ausgeführt werden:
# /usr/sbin/iptables-save > /etc/iptables/iptables.rules
Nachfolgender Befehl kann dazu verwendet werden, um zu überprüfen, ob das iptables-Regelwerk auch korrekt gespeichert wurde:
# cat /etc/iptables/iptables.rules # Generated by iptables-save v1.8.7 on Wed Mar 31 10:13:23 2022 *filter :INPUT DROP [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [13:3332] -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p udp -m udp --dport 67 -j ACCEPT -A INPUT -j LOG --log-prefix "REC-INP Defend " --log-level 5 -A INPUT -p tcp -j REJECT --reject-with tcp-reset -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable -A INPUT -j REJECT --reject-with icmp-proto-unreachable -A OUTPUT -p udp -m udp --dport 68 -j ACCEPT COMMIT # Completed on Wed Mar 31 10:13:23 2022 # Generated by iptables-save v1.8.7 on Wed Mar 31 10:13:23 2022 *nat :PREROUTING ACCEPT [5:352] :INPUT ACCEPT [1:60] :OUTPUT ACCEPT [8:577] :POSTROUTING ACCEPT [8:577] COMMIT # Completed on Wed Mar 31 10:13:23 2022 # Generated by iptables-save v1.8.7 on Wed Mar 31 10:13:23 2022 *mangle :PREROUTING ACCEPT [1216:2104461] :INPUT ACCEPT [1212:2104169] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [944:91396] :POSTROUTING ACCEPT [944:91396] COMMIT # Completed on Wed Mar 31 10:13:23 2022
Um die aktuellen ip6tables
-Regeln erweitern zu können, sollten diese erst einmal aufgelistet werden, was mit nachfolgendem Befehl durchgeführt werden kann:
# ip6tables -nvL --line-numbers Chain INPUT (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT all * * ::/0 ::/0 ctstate RELATED,ESTABLISHED 2 0 0 ACCEPT icmp * * ::/0 ::/0 3 0 0 ACCEPT all lo * ::/0 ::/0 4 0 0 ACCEPT tcp * * ::/0 ::/0 tcp dpt:22 5 0 0 LOG all * * ::/0 ::/0 LOG flags 0 level 5 prefix "REC-INP Defend " 6 0 0 REJECT tcp * * ::/0 ::/0 reject-with tcp-reset 7 0 0 REJECT udp * * ::/0 ::/0 reject-with icmp6-port-unreachable 8 0 0 REJECT all * * ::/0 ::/0 reject-with icmp6-addr-unreachable Chain FORWARD (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 LOG all * * ::/0 ::/0 LOG flags 0 level 5 prefix "REC-FWD Defend " 2 0 0 REJECT tcp * * ::/0 ::/0 reject-with tcp-reset 3 0 0 REJECT udp * * ::/0 ::/0 reject-with icmp6-port-unreachable 4 0 0 REJECT all * * ::/0 ::/0 reject-with icmp6-addr-unreachable Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination
Nachfolgende Befehle, fügen folgende ip6tables
-Regeln dem ip6tables
-Regelwerk nach der Position 4 hinzu, ohne das der Paketfilter angehalten werden muss:
-A INPUT -p udp --dport 67 -j ACCEPT
-A OUTPUT -p udp --dport 68 -j ACCEPT
und hier die Befehle:
# ip6tables -I INPUT 5 -p udp --dport 67 -j ACCEPT # ip6tables -I OUTPUT 1 -p udp --dport 68 -j ACCEPT
Ein erneute Abfrage des ip6tables
-Regelwerts, sollte dann nachfolgend dargestellte Ausgabe ergeben, was mit folgendem Befehl durchgeführt werden kann:
# ip6tables -nvL --line-numbers Chain INPUT (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT all * * ::/0 ::/0 ctstate RELATED,ESTABLISHED 2 0 0 ACCEPT icmp * * ::/0 ::/0 3 0 0 ACCEPT all lo * ::/0 ::/0 4 0 0 ACCEPT tcp * * ::/0 ::/0 tcp dpt:22 5 0 0 ACCEPT udp * * ::/0 ::/0 udp dpt:67 6 0 0 LOG all * * ::/0 ::/0 LOG flags 0 level 5 prefix "REC-INP Defend " 7 0 0 REJECT tcp * * ::/0 ::/0 reject-with tcp-reset 8 0 0 REJECT udp * * ::/0 ::/0 reject-with icmp6-port-unreachable 9 0 0 REJECT all * * ::/0 ::/0 reject-with icmp6-addr-unreachable Chain FORWARD (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 LOG all * * ::/0 ::/0 LOG flags 0 level 5 prefix "REC-FWD Defend " 2 0 0 REJECT tcp * * ::/0 ::/0 reject-with tcp-reset 3 0 0 REJECT udp * * ::/0 ::/0 reject-with icmp6-port-unreachable 4 0 0 REJECT all * * ::/0 ::/0 reject-with icmp6-addr-unreachable Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT udp -- * * ::/0 ::/0 udp dpt:68
Die neuen Zeilen sind an Position 5 (INPUT) und Postition 6 (INTPUT) zu sehen, hier nachfolgend zur Verdeutlichung noch einmal dargestellt (nur relevanter Ausschnitt):
... 5 0 0 ACCEPT udp * * ::/0 ::/0 udp dpt:67 1 0 0 ACCEPT udp -- * * ::/0 ::/0 udp dpt:68 ...
Um diese ip6tables
-Regel dauerhaft, auch nach einem Neustart des Server, weiterhin im ip6tables
-Regelwerk zu speichern, muss nachfolgend dargestellter Befehl abschließend noch ausgeführt werden:
# /usr/sbin/ip6tables-save > /etc/iptables/ip6tables.rules
Nachfolgender Befehl kann dazu verwendet werden, um zu überprüfen, ob das ip6tables
-Regelwerk auch korrekt gespeichert wurde:
# cat /etc/iptables/ip6tables.rules # Generated by ip6tables-save v1.8.7 on Wed Mar 31 10:15:10 2022 *mangle :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT # Completed on Wed Mar 31 10:15:10 2022 # Generated by ip6tables-save v1.8.7 on Wed Mar 31 10:15:10 2022 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p udp -m udp --dport 67 -j ACCEPT -A INPUT -j LOG --log-prefix "REC-INP Defend " --log-level 5 -A INPUT -p tcp -j REJECT --reject-with tcp-reset -A INPUT -p udp -j REJECT --reject-with icmp6-port-unreachable -A INPUT -j REJECT --reject-with icmp6-addr-unreachable -A FORWARD -j LOG --log-prefix "REC-FWD Defend " --log-level 5 -A FORWARD -p tcp -j REJECT --reject-with tcp-reset -A FORWARD -p udp -j REJECT --reject-with icmp6-port-unreachable -A FORWARD -j REJECT --reject-with icmp6-addr-unreachable -A OUTPUT -p udp -m udp --dport 68 -j ACCEPT COMMIT # Completed on Wed Mar 31 10:15:10 2022 # Generated by ip6tables-save v1.8.7 on Wed Mar 31 10:15:10 2022 *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT # Completed on Wed Mar 31 10:15:10 2022
Basis-Konfiguration:
Nachfolgende Konfigurationsschritte sollen eine grundlegende Konfiguration des DHCP ISC Kea darstellen und erheben keinen Anspruch auf Vollständigkeit in Bezug auf die Möglichkeiten die der DHCP ISC Kea bietet.
/etc/kea/kea-dhcp4.conf
Nachfolgende Konfigurationsdatei /etc/kea/kea-dhcp4.conf
, stellt die Möglichkeit dar DHCP via IPv4 durchzuführen.
Dies ist die komplette Konfigurationsdatei:
{ // // DHCPv4 configuration starts here. This section will be read by DHCPv4 server // and will be ignored by other components. // "Dhcp4": { // --------------------------------------------------------------------- // 8.2.2. Lease Storage // 8.2.2.1. Memfile - Basic Storage for Leases // --------------------------------------------------------------------- "lease-database": { "type": "memfile", "persist": true, "name": "/var/lib/kea/kea-leases4.csv", "lfc-interval": 3600, "max-row-errors": 0 }, // --------------------------------------------------------------------- // 8.2.4. Interface Configuration // --------------------------------------------------------------------- "interfaces-config": { "interfaces": [ "*" ], "dhcp-socket-type": "raw" }, // --------------------------------------------------------------------- // 8.2.9. Sending T1 (Option 58) and T2 (Option 59) // --------------------------------------------------------------------- "calculate-tee-times": true, "t1-percent": 0.50, "t2-percent": 0.875, // --------------------------------------------------------------------- // 8.2.21. Echoing Client-ID (RFC 6842) // --------------------------------------------------------------------- "echo-client-id": false, // --------------------------------------------------------------------- // 8.2.22. Using Client Identifier and Hardware Address // --------------------------------------------------------------------- "match-client-id": true, // --------------------------------------------------------------------- // 8.2.25. Sanity Checks in DHCPv4 // --------------------------------------------------------------------- "sanity-checks": { "lease-checks": "del" }, // --------------------------------------------------------------------- // 8.2.27. Multi-Threading Settings // --------------------------------------------------------------------- "multi-threading": { "enable-multi-threading": true, "thread-pool-size": 4, "packet-queue-size": 7 }, // --------------------------------------------------------------------- // 8.3.8. Fine-Tuning DHCPv4 Host Reservation // --------------------------------------------------------------------- "reservations-global": false, "reservations-in-subnet": true, "reservations-out-of-pool": false, // --------------------------------------------------------------------- // 8.7. Duplicate Addresses (DHCPDECLINE Support) // --------------------------------------------------------------------- "decline-probation-period": 3600, // --------------------------------------------------------------------- // 8.9. Management API for the DHCPv4 Server // --------------------------------------------------------------------- "control-socket": { "socket-type": "unix", "socket-name": "/var/lib/kea/kea4-ctrl-socket" }, // --------------------------------------------------------------------- // 8.2.6. IPv4 Subnet Identifier // 8.2.7. IPv4 Subnet Prefix // 8.2.8. Configuration of IPv4 Address Pools // --------------------------------------------------------------------- "subnet4": [ { // ===================================================== // Subnet 192.168.0.0/24 (Intranet). // ===================================================== "id": 1, "subnet": "192.168.0.0/24", // ----------------------------------------------------- // 8.2.10. Standard DHCPv4 Options // ----------------------------------------------------- "option-data": [ // --------------------------------------------- // 8.5. Server Identifier in DHCPv4 // --------------------------------------------- { "space": "dhcp4", "name": "dhcp-server-identifier", "code": 54, "data": "192.168.0.1" }, { "space": "dhcp4", "name": "broadcast-address", "code": 28, "data": "192.168.0.255" }, { "space": "dhcp4", "name": "domain-name", "code": 15, "data": "intra.tachtler.net" }, { "space": "dhcp4", "name": "domain-name-servers", "code": 6, "data": "10.0.0.20" }, { "space": "dhcp4", "name": "domain-search", "code": 119, "data": "tachtler.net, intra.tachtler.net" }, { "space": "dhcp4", "name": "ntp-servers", "code": 42, "data": "192.168.0.1" }, { "space": "dhcp4", "name": "routers", "code": 3, "data": "192.168.0.1" }, { "space": "dhcp4", "name": "subnet-mask", "code": 1, "data": "255.255.255.0" }, { "space": "dhcp4", "name": "time-servers", "code": 4, "data": "192.168.0.1" } ], "pools": [ // --------------------------------------------- // Reserved for Guests. // --------------------------------------------- { "pool": "192.168.0.100 - 192.168.0.119" }, ], // ----------------------------------------------------- // 8.2.22. Using Client Identifier and Hardware Address // ----------------------------------------------------- "match-client-id": true, // ----------------------------------------------------- // 8.2.30. Lease Caching // ----------------------------------------------------- "cache-threshold": 0.25, "cache-max-age": 300, // ----------------------------------------------------- // 8.3. Host Reservations in DHCPv4 // 8.3.3. Reserving a Hostname // ----------------------------------------------------- "ddns-qualifying-suffix": "intra.tachtler.net.", "reservations": [ // --------------------------------------------- // Infrastructure. // --------------------------------------------- { "hostname": "server", "hw-address": "ab:12:34:56:78:90", "ip-address": "192.168.0.120" }, { "hostname": "ipmi", "hw-address": "ac:12:34:56:78:90", "ip-address": "192.168.0.121" }, ], // ----------------------------------------------------- // 8.2.1. Introduction // ----------------------------------------------------- "valid-lifetime": 10800, "max-valid-lifetime": 28800, "min-valid-lifetime": 300 }, ], "loggers": [ { "name": "kea-dhcp4", "output_options": [ { "output": "syslog:kea-dhcp4" } ], "severity": "INFO", "debuglevel": 99 } ] } }
Erklärungen:
{ // // DHCPv4 configuration starts here. This section will be read by DHCPv4 server // and will be ignored by other components. // "Dhcp4": {
Dieser „Eröffnungstag“ in JSON©-Format, leitet die Konfigurationsdatei ein und gibt an, das die nachfolgenden Direktiven zur Konfiguration eines DHCP IPv4 Servers bestimmt sind.
// --------------------------------------------------------------------- // 8.2.2. Lease Storage // 8.2.2.1. Memfile - Basic Storage for Leases // --------------------------------------------------------------------- "lease-database": { "type": "memfile", "persist": true, "name": "/var/lib/kea/kea-leases4.csv", "lfc-interval": 3600, "max-row-errors": 0 },
Die Konfiguration bestimmt die Ausgestaltung der lease-database
(„Lease“-Datenbank), welche in diesem Fall durch Angabe des Parameters type
eine Datei ist, welche unter nachfolgendem Verzeichnis mit nachfolgendem Namen abgelegt wird:
/var/lib/kea/kea-leases4.csv
Die Datei, welche mit dem Parameter name
definiert wird, wird auf dem entsprechenden Datenträger persistent (dauerhaft) gespeichert und wird zur Laufzeit in dem RAM (Hauptspeicher) eingelesen. Der Parameter persist
steuert, ob neue „Leases“ und Aktualisierungen bestehender „Leases“ in die Datei geschrieben werden. Es wird dringend empfohlen, dass der Wert dieses Parameters während des normalen Betriebs des Servers immer auf „true“ gesetzt wird. Der Parameter lfc-interval
gibt das Intervall in Sekunden an, in dem der Server eine Bereinigung der Lease-Datei (LFC) durchführt. der Parameter max-row-error
gibt die Anzahl der Zeilenfehler an, nach denen der Server nicht mehr versucht, eine Lease-Datei zu laden.
Es gibt nachfolgende zwei Möglichkeiten „Lease“-Informationen zu speichern
memfile
- Datei auf dem entsprechenden Datenträgermysql
oderpostgresql
- 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 istfalse
.
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 ist0
.
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 ist64
.
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. Wennreservations-out-of-pool
true
(wahr) ist, nimmt der Server an, dass alle HOST-Reservierungen für Adressen sind, die nicht zum dynamischen Pool gehören. Daher kann er die Reservierungsprüfungen bei der Bearbeitung von „In-Pool-Adressen“ überspringen und so die Leistung verbessern. Der Server weist reservierte Adressen, die sich innerhalb der dynamischen Pools befinden, den jeweiligen Clients nicht zu. Das bedeutet auch, dass die Adressen, die mit den entsprechenden Reservierungen innerhalb der dynamischen Pools übereinstimmen (falls vorhanden), jedem Client dynamisch zugewiesen werden können.
// --------------------------------------------------------------------- // 8.7. Duplicate Addresses (DHCPDECLINE Support) // --------------------------------------------------------------------- "decline-probation-period": 3600,
Der DHCP ISC Kea-Server wird mit einem bestimmten Pool von Adressen konfiguriert, die er an DHCPv4-Clients weitergeben soll. Es wird davon ausgegangen, dass der Server massgebend ist und die vollständige Zuständigkeit für diese Adressen hat. Aus verschiedenen Gründen, wie z. B. einer Fehlkonfiguration oder einer fehlerhaften Client-Implementierung, die ihre Adresse über die gültige Lebensdauer hinaus beibehält, können jedoch Geräte angeschlossen sein, die diese Adressen ohne die Zustimmung oder das Wissen des Servers verwenden.
Ein solches unerwünschtes Ereignis kann von legitimen Clients (mit Hilfe von „ARP“- oder „ICMP-Echo-Request“-Mechanismen) erkannt und dem DHCPv4-Server mit einer „DHCPDECLINE“-Nachricht gemeldet werden. Der Server führt eine Plausibilitätsprüfung durch (um festzustellen, ob der Client, der eine Adresse abgelehnt hat, diese auch wirklich verwenden sollte) und führt dann eine Bereinigungsoperation durch. Alle DNS-Einträge, die sich auf diese Adresse beziehen, werden entfernt, das Ereignis wird protokolliert, und es werden „Hooks“ ausgelöst. Nach Abschluss dieses Vorgangs wird die Adresse als abgelehnt markiert (was bedeutet, dass sie von einer unbekannten Entität verwendet wird und daher nicht für eine Zuweisung zur Verfügung steht), und es wird eine Bewährungszeit für sie festgelegt. Sofern nicht anders konfiguriert, dauert die Probezeit 24 Stunden, welche mit dem Parameter decline-probation-period
gesetzt werden kann. Nach Ablauf dieser Zeit stellt der Server die Lease wieder her (d.h. er versetzt sie wieder in den Status „verfügbar“) und die Adresse steht wieder für die Zuweisung zur Verfügung. Es ist zu beachten, dass sich das Szenario mit der doppelten Adresse wiederholt, wenn das zugrunde liegende Problem eines falsch konfigurierten Geräts nicht behoben wird. Bei korrekter Neukonfiguration bietet dieser Mechanismus die Möglichkeit, ein solches Ereignis automatisch und ohne Eingreifen des Systemadministrators zu beheben.
// --------------------------------------------------------------------- // 8.9. Management API for the DHCPv4 Server // --------------------------------------------------------------------- "control-socket": { "socket-type": "unix", "socket-name": "/var/lib/kea/kea4-ctrl-socket" },
Die „Verwaltungs-API“ ermöglicht die Ausgabe spezifischer Verwaltungsbefehle, wie z. B. das Abrufen von Statistiken, die Neukonfiguration oder das Herunterfahren. Derzeit ist der einzige unterstützte Kommunikationskanaltyp der „UNIX-Stream-Socket“. Standardmässig sind keine Sockets geöffnet. Um den DHCP ISC Kea-Server anzuweisen, einen Socket zu öffnen, kann der vorhergehende Konfiguration verwendet werden
Weitere Einzelheiten der Verwaltungs-API können unter nachfolgendem externen Link nachgelesen werden:
// --------------------------------------------------------------------- // 8.2.6. IPv4 Subnet Identifier // 8.2.7. IPv4 Subnet Prefix // 8.2.8. Configuration of IPv4 Address Pools // --------------------------------------------------------------------- "subnet4": [
Definition, das ab hier ein Subnetz IPv4 beginnt.
{ // ===================================================== // Subnet 192.168.0.0/24 (Intranet). // ===================================================== "id": 1, "subnet": "192.168.0.0/24",
Die Subnetz-Kennung mit dem Parameter id
(Subnetz-ID) ist eine eindeutige Nummer, die einem bestimmten Subnetz zugeordnet ist. Sie wird im Prinzip dazu verwendet, die „Leases“ der Clients mit ihren jeweiligen Subnetzen zu verknüpfen. Wenn für ein zu konfigurierendes Subnetz keine Subnetzkennung angegeben ist, wird sie automatisch vom Konfigurationsmechanismus zugewiesen. Die Bezeichner werden beginnend mit 1 zugewiesen und werden für jedes folgende Subnetz erhöht: 1, 2, 3, usw. Der Parameter subnet
gibt das Subnetzpräfix an und ist die zweite Möglichkeit, ein Subnetz zu identifizieren. Der DHCP ISC Kea-Server kann „non-canonical“ Subnetzadressen akzeptieren.
// ----------------------------------------------------- // 8.2.10. Standard DHCPv4 Options // ----------------------------------------------------- "option-data":
Eine der wichtigsten Funktionen eines DHCPv4-Servers ist die Möglichkeit, den Clients Konfigurationsoptionen zur Verfügung zu stellen. Die meisten Optionen werden vom Server nur gesendet, wenn der Client sie ausdrücklich mit der Option „Parameter Request List“ anfordert. Bei den Optionen, die nicht in die „Parameter Request List“ aufgenommen werden müssen, handelt es sich um häufig verwendete Optionen, z. B. „Domain Server“ und um Optionen, die ein besonderes Verhalten erfordern, z. B. „Client FQDN“, der an den Client zurückgegeben wird, wenn der Client diese Option in seine Nachricht an den Server aufgenommen hat. Die kann durch den einleitenden Parameter option-data
erfolgen.
// --------------------------------------------- // 8.5. Server Identifier in DHCPv4 // --------------------------------------------- { "space": "dhcp4", "name": "dhcp-server-identifier", "code": 54, "data": "192.168.0.1" }, { "space": "dhcp4", "name": "broadcast-address", "code": 28, "data": "192.168.0.255" }, { "space": "dhcp4", "name": "domain-name", "code": 15, "data": "intra.tachtler.net" }, { "space": "dhcp4", "name": "domain-name-servers", "code": 6, "data": "10.0.0.20" }, { "space": "dhcp4", "name": "domain-search", "code": 119, "data": "tachtler.net, intra.tachtler.net" }, { "space": "dhcp4", "name": "ntp-servers", "code": 42, "data": "192.168.0.1" }, { "space": "dhcp4", "name": "routers", "code": 3, "data": "192.168.0.1" }, { "space": "dhcp4", "name": "subnet-mask", "code": 1, "data": "255.255.255.0" }, { "space": "dhcp4", "name": "time-servers", "code": 4, "data": "192.168.0.1" } ],
Nachfolgender externe Link gibt eine Liste der möglichen Optionen am, welche zur Anwendung kommen können:
Nachfolgende Optionen wurden aktuell hier verwendet:
Option | Beschreibung |
---|---|
dhcp-server-identifier | Das DHCPv4-Protokoll verwendet einen „Server-Identifikator“, damit die Clients zwischen mehreren Servern auf derselben Verbindung unterscheiden können. Dieser Wert ist eine IPv4-Adresse des Servers. Der Server wählt die IPv4-Adresse der Schnittstelle, auf der die Nachricht vom Client (oder Relay) empfangen wurde. Eine einzelne Serverinstanz verwendet mehrere Server-Identifikatoren, wenn sie Abfragen auf mehreren Schnittstellen empfängt. |
broadcast-address | Die Adresse über die die „broadcast“-Anfrage ins Netz übermittelt wird. |
domain-name | Der FQDN, welche die Domäne bezeichnet, welche dem Client mit übermittelt wird. |
domain-name-servers | Die Adresse, welche den DNS-Server angibt, welche dem Client mit übermittelt wird, an den dieser DNS-Anfragen senden soll. |
domain-search | Der Teil des FQDN, welcher an HOST-Namen angehängt wird um einen vollständigen FQDN als Suchgrundlage für DNS-Anfragen des Clients fomilieren zu können. |
ntp-servers | Die Adresse, welche den Zeit-Server (NTP) angibt, welche dem Client mit übermittelt wird, an den dieser Zeit-Synchronisations-Anfragen senden soll. |
routers | Die Adresse, welche „Router“ definiert, die im Netzsegemnt erreicht werden können und z.B. auch die Betzübergreifende Kommunikation ermöglichen. |
subnet-mask | Die Subnetz-Maske, welche im Netzsegemnt herrscht, in dem sich der Client nach Bezug einer IP-Adresse befindet. |
time-servers | Die Adresse, welche den Zeit-Server (Time Protocol RFC 868) angibt, welche dem Client mit übermittelt wird, an den dieser Zeit-Synchronisations-Anfragen senden soll. |
"pools": [ // --------------------------------------------- // Reserved for Guests. // --------------------------------------------- { "pool": "192.168.0.100 - 192.168.0.119" }, ],
Die Hauptaufgabe eines DHCPv4-Servers ist die Adresszuweisung. Dazu muss der Server mit mindestens einem Subnetz und einem Pool von zu verwaltenden dynamischen Adressen konfiguriert werden. Nehmen wir an, der Server ist mit einem Netzwerksegment verbunden, das das Präfix 192.168.0.0/24 verwendet. Es wird nachfolgend konfigureirt, dass Adressen aus dem Bereich 192.168.0.100 bis 192.168.0.119 vom DHCPv4-Server als „pool“-Adressen verwaltet werden sollen.
// ----------------------------------------------------- // 8.2.22. Using Client Identifier and Hardware Address // ----------------------------------------------------- "match-client-id": true,
Ein häufiges Problem ist, dass schlechte Client-Implementierungen keine stabilen Client-Kennungen verwenden, sondern jedes Mal wenn sich der Client mit dem Netz verbindet, eine neue Client-Kennung erzeugen. Ein weiterer bekannter Fall ist, wenn der Client seine Client-Kennung während des z.B. mehrstufigen Boot-Prozesses (PXE) ändert. In solchen Fällen bleibt die MAC-Adresse der Client-Schnittstelle stabil, und die Verwendung des „chaddr“-Feldes zur Identifizierung des Clients garantiert, dass das jeweilige System als derselbe Client angesehen wird, auch wenn sich seine Client-Kennung ändert.
Um dieses Problem zu lösen, enthält der DHCP ISC Kea-Server eine Konfigurationsoption, die die Identifizierung des Clients nur über „chaddr“ ermöglicht. Dies weist den Server an, den Client-Identifikator bei der Suche nach „Leases“ und Zuweisungen für ein bestimmtes Subnetz zu ignorieren.
Der Parameter match-client-id
ist ein boolescher Wert, der dieses Verhalten steuert. Der Standardwert true
bedeutet, dass der Server die Client-Kennung für die Suche nach „Leases“ -„chaddr“ verwendet, wenn die erste Suche keine Ergebnisse liefert. Hingegen false
bedeutet, dass der Server nur die „chaddr“ für die Suche nach dem Lease des Clients verwendet. Ob die „DHCID“ für DNS-Updates aus dem „Client-Identifier“ oder dem „chaddr“ generiert wird, wird über denselben Parameter gesteuert.
Dies soll auch für die Definitionen im Subnetz „subnet4“ gelten!
// ----------------------------------------------------- // 8.2.30. Lease Caching // ----------------------------------------------------- "cache-threshold": 0.25, "cache-max-age": 300,
Clients, die mehrere Erneuerungen in einem kurzen Zeitraum versuchen, können den Server dazu veranlassen, die Datenbank häufig zu aktualisieren und zu beschreiben, was sich auf die Leistung des Servers auswirkt. Die Cache-Parameter weisen den DHCP-Server an, zu häufige Aktualisierungen von Leases zu vermeiden, wodurch dieses Verhalten vermieden wird. Stattdessen weist der Server dieselbe „Lease“ zu (d. h. er verwendet sie wieder), ohne Änderungen vorzunehmen, mit Ausnahme der CLTT (Client Last Transmission Time), die keine Plattenoperationen erfordert.
Die beiden Parameter sind cache-threshold
(Typ: double) und cache-max-age
(Typ: integer). Sie sind nicht voreingestellt, d.h. das Lease-Caching muss explizit aktiviert werden. Diese Parameter können auf globaler, Shared-Network- und Subnet-Ebene konfiguriert werden. Die Subnetzebene hat Vorrang vor der Shared-Network-Ebene, während die globale Ebene als letzte Möglichkeit verwendet wird.
// ----------------------------------------------------- // 8.3. Host Reservations in DHCPv4 // 8.3.3. Reserving a Hostname // ----------------------------------------------------- "ddns-qualifying-suffix": "intra.tachtler.net.", "reservations": [ // --------------------------------------------- // Infrastructure. // --------------------------------------------- { "hostname": "server", "hw-address": "ab:12:34:56:78:90", "ip-address": "192.168.0.120" }, { "hostname": "ipmi", "hw-address": "ac:12:34:56:78:90", "ip-address": "192.168.0.121" }, ],
Es gibt viele Fälle, in denen es sinnvoll ist, eine Konfiguration auf Hostbasis vorzunehmen. Der offensichtlichste Fall ist die Reservierung einer bestimmten, statischen Adresse für die ausschließliche Verwendung durch einen bestimmten Client (Host). Der anfragende Client erhält jedes Mal dieselbe Adresse vom Server, und andere Clients erhalten diese Adresse im Allgemeinen nicht. Host-Reservierungen sind auch praktisch, wenn ein Host spezielle Anforderungen hat, z. B. ein Drucker, der zusätzliche DHCP-Optionen benötigt. Ein weiterer möglicher Anwendungsfall ist die Festlegung eindeutiger Namen für Hosts.
Das Suffix, das bei der Erzeugung eines FQDN oder bei der Qualifizierung eines Teilnamens verwendet wird, wird durch den Parameter ddns-qualifying-suffix
angegeben. Es wird dringend empfohlen, dass der Benutzer einen Wert für das qualifizierende Präfix angibt, wenn DDNS-Aktualisierungen aktiviert sind.
Der DHCP ISC Kea-Server bietet die Möglichkeit, Optionen für jeden einzelnen Host festzulegen. Diese Optionen folgen den gleichen Regeln wie alle anderen Optionen. Diese werden mit dem Parameter reservation
eingeleitet und beeinhalten die Definitionen für einzelne Clients.
// ----------------------------------------------------- // 8.2.1. Introduction // ----------------------------------------------------- "valid-lifetime": 10800, "max-valid-lifetime": 28800, "min-valid-lifetime": 300
Die Gültigkeitsdauer von „Leases“ wird als Triplett mit Mindest-, Standard- und Maximalwerten durch die Konfigurationseinträge min-valid-lifetime
, valid-lifetime
und max-valid-lifetime
ausgedrückt.
"loggers": [ { "name": "kea-dhcp4", "output_options": [ { "output": "syslog:kea-dhcp4" } ], "severity": "INFO", "debuglevel": 99 } ]
Beim DHCP ISC Kea-Server wird eine Nachricht durch eine Entität namens „Logger“ protokolliert. Verschiedene Komponenten protokollieren Nachrichten über verschiedene Logger, und jeder Logger kann unabhängig von den anderen konfiguriert werden. Einige Komponenten, insbesondere die DHCP-Serverprozesse, können mehrere Logger verwenden, um Nachrichten zu protokollieren, die zu verschiedenen logischen Funktionen der Komponente gehören. Der DHCPv4-Server verwendet beispielsweise einen Logger für Meldungen über den Empfang und die Übertragung von Paketen, einen anderen Logger für Meldungen im Zusammenhang mit der Zuweisung von Leases und so weiter.
Die drei Hauptelemente einer Logger-Konfiguration sind: name
(die Komponente, die die Meldungen erzeugt), severity (was protokolliert werden soll) und output_commands
(wo protokolliert werden soll). Es gibt auch ein debuglevel
-Element, das nur relevant ist, wenn die Debug-Level-Protokollierung ausgewählt wurde.
Die Logger bilden eine Hierarchie. Für jedes Programm beim DHCP ISC Kea-Server gibt es einen „Stamm-Logger“, der nach dem Programm benannt ist (z. B. heißt der Stamm-Logger für kea-dhcp4
, den DHCPv4-Server, kea-dhcp4
). Alle anderen Logger sind Kinder dieses Loggers und werden entsprechend benannt, z. B. protokolliert die Zuweisungs-Engine im DHCPv4-Server Nachrichten mit einem Logger namens kea-dhcp4.alloc-engine
.
Diese Beziehung ist wichtig, da jeder untergeordnete Logger seine Standardkonfiguration von seinem übergeordneten Root-Logger ableitet. Im Normalfall ist die Root-Logger-Konfiguration die einzige in der Konfigurationsdatei angegebene Logging-Konfiguration und gilt daher für alle Logger. Wenn ein Eintrag für einen bestimmten Logger gemacht wird, überschreiben alle angegebenen Attribute die des Root-Loggers, während alle nicht angegebenen von diesem geerbt werden.
Um dies zu veranschaulichen, nehmen wir an, wir verwenden den DHCPv4-Server mit dem Root-Logger kea-dhcp4
, der auf der Ebene INFO protokolliert. Um die DEBUG-Ausführlichkeit für DHCPv4-Paketverluste zu aktivieren, müssen wir einen Konfigurationseintrag für den Logger mit dem Namen kea-dhcp4.bad-packets
erstellen und den Schweregrad DEBUG für diesen Logger angeben. Alle anderen Konfigurationsparameter können für diesen Logger weggelassen werden, wenn der Logger die in der Konfiguration des Root-Loggers angegebenen Standardwerte verwenden soll.
Für weitere ausführliche Informationen und eine Übersicht der möglichen „Logger“, kann nachfplgender externer Link eingesehen werden:
/etc/kea/kea-dhcp6.conf
Nachfolgende Konfigurationsdatei /etc/kea/kea-dhcp6.conf
, stellt die Möglichkeit dar DHCP via IPv6 durchzuführen.
Dies ist die komplette Konfigurationsdatei:
{ // // DHCPv6 configuration starts here. This section will be read by DHCPv6 server // and will be ignored by other components. // "Dhcp6": { // --------------------------------------------------------------------- // 9.2.2. Lease Storage // 9.2.2.1. Memfile - Basic Storage for Leases // --------------------------------------------------------------------- "lease-database": { "type": "memfile", "persist": true, "name": "/var/lib/kea/kea-leases6.csv", "lfc-interval": 3600, "max-row-errors": 0 }, // --------------------------------------------------------------------- // 9.2.4. Interface Configuration // --------------------------------------------------------------------- "interfaces-config": { "interfaces": [ "*" ], "service-sockets-max-retries": 5, "service-sockets-retry-wait-time": 5000 }, // --------------------------------------------------------------------- // 9.2.17. Controlling the Values Sent for T1 and T2 Times // --------------------------------------------------------------------- "calculate-tee-times": true, "t1-percent": 0.50, "t2-percent": 0.875, // --------------------------------------------------------------------- // 9.2.25. Sanity Checks in DHCPv6 // --------------------------------------------------------------------- "sanity-checks": { "lease-checks": "del" }, // --------------------------------------------------------------------- // 9.2.27. Multi-Threading Settings // --------------------------------------------------------------------- "multi-threading": { "enable-multi-threading": true, "thread-pool-size": 4, "packet-queue-size": 150 }, // --------------------------------------------------------------------- // 9.3.7. Fine-Tuning DHCPv6 Host Reservation // --------------------------------------------------------------------- "reservations-global": false, "reservations-in-subnet": true, "reservations-out-of-pool": false, // --------------------------------------------------------------------- // 9.12. Duplicate Addresses (DHCPDECLINE Support) // --------------------------------------------------------------------- "decline-probation-period": 3600, // --------------------------------------------------------------------- // 9.14. Management API for the DHCPv6 Server // --------------------------------------------------------------------- "control-socket": { "socket-type": "unix", "socket-name": "/var/lib/kea/kea6-ctrl-socket" }, // --------------------------------------------------------------------- // 9.2.5. IPv4 Subnet Identifier // 9.2.6. IPv4 Subnet Prefix // 9.2.7. Configuration of IPv6 Address Pools // --------------------------------------------------------------------- "subnet6": [ { // ===================================================== // Subnet fd00:0:0:dead::/64 (HOME). // ===================================================== "id": 1, "subnet": "fd00:0:0:dead::/64", // ----------------------------------------------------- // 9.2.11. Standard DHCPv6 Options // ----------------------------------------------------- "option-data": [ // --------------------------------------------- // 9.5. Server Identifier in DHCPv6 // --------------------------------------------- { "space": "dhcp6", "name": "sip-server-dns", "code": 21, "data": "intra.tachtler.net" }, { "space": "dhcp6", "name": "dns-servers", "code": 23, "data": "fd00::dead:10:0:0:20" }, { "space": "dhcp6", "name": "domain-search", "code": 24, "data": "tachtler.net, intra.tachtler.net" }, { "space": "dhcp6", "name": "sntp-servers", "code": 31, "data": "fd00::dead:192:168:0:1" } ], "pools": [ // --------------------------------------------- // Reserved for Guests (after PXE-Boot too). // --------------------------------------------- { "pool": "fd00::dead:192:168:0:100 - fd00::dead:192:168:0:119" }, ], // ----------------------------------------------------- // 9.2.29. Lease Caching // ----------------------------------------------------- "cache-threshold": 0.25, "cache-max-age": 300, // ----------------------------------------------------- // 9.3. Host Reservations in DHCPv6 // 9.3.3. Reserving a Hostname // ----------------------------------------------------- "ddns-qualifying-suffix": "intra.tachtler.net.", "reservations": [ // --------------------------------------------- // Infrastructure. // --------------------------------------------- { "hostname": "server", "hw-address": "ab:12:34:56:78:90", "ip-addresses": [ "fd00::dead:192:168:0:120" ] }, { "hostname": "ipmi", "hw-address": "ac:12:34:56:78:90", "ip-addresses": [ "fd00::dead:192:168:0:121" ] }, ], // ----------------------------------------------------- // 9.2.1. Introduction // ----------------------------------------------------- "preferred-lifetime": 300, "max-preferred-lifetime": 900, "min-preferred-lifetime": 60, "valid-lifetime": 300, "max-valid-lifetime": 900, "min-valid-lifetime": 60 } ], "loggers": [ { "name": "kea-dhcp6", "output_options": [ { "output": "syslog:kea-dhcp6" } ], "severity": "INFO", "debuglevel": 99 } ] } }
Erklärungen:
{ // // DHCPv6 configuration starts here. This section will be read by DHCPv6 server // and will be ignored by other components. // "Dhcp6": {
Dieser „Eröffnungstag“ in JSON©-Format, leitet die Konfigurationsdatei ein und gibt an, das die nachfolgenden Direktiven zur Konfiguration eines DHCP IPv6 Servers bestimmt sind.
// --------------------------------------------------------------------- // 9.2.2. Lease Storage // 9.2.2.1. Memfile - Basic Storage for Leases // --------------------------------------------------------------------- "lease-database": { "type": "memfile", "persist": true, "name": "/var/lib/kea/kea-leases6.csv", "lfc-interval": 3600, "max-row-errors": 0 },
Die Konfiguration bestimmt die Ausgestaltung der lease-database
(„Lease“-Datenbank), welche in diesem Fall durch Angabe des Parameters type
eine Datei ist, welche unter nachfolgendem Verzeichnis mit nachfolgendem Namen abgelegt wird:
/var/lib/kea/kea-leases6.csv
Die Datei, welche mit dem Parameter name
definiert wird, wird auf dem entsprechenden Datenträger persistent (dauerhaft) gespeichert und wird zur Laufzeit in dem RAM (Hauptspeicher) eingelesen. Der Parameter persist
steuert, ob neue „Leases“ und Aktualisierungen bestehender „Leases“ in die Datei geschrieben werden. Es wird dringend empfohlen, dass der Wert dieses Parameters während des normalen Betriebs des Servers immer auf „true“ gesetzt wird. Der Parameter lfc-interval
gibt das Intervall in Sekunden an, in dem der Server eine Bereinigung der Lease-Datei (LFC) durchführt. der Parameter max-row-error
gibt die Anzahl der Zeilenfehler an, nach denen der Server nicht mehr versucht, eine Lease-Datei zu laden.
Es gibt nachfolgende zwei Möglichkeiten „Lease“-Informationen zu speichern
memfile
- Datei auf dem entsprechenden Datenträgermysql
oderpostgresql
- 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 istfalse
.
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 ist0
.
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 ist64
.
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. Wennreservations-out-of-pool
true
(wahr) ist, nimmt der Server an, dass alle HOST-Reservierungen für Adressen sind, die nicht zum dynamischen Pool gehören. Daher kann er die Reservierungsprüfungen bei der Bearbeitung von „In-Pool-Adressen“ überspringen und so die Leistung verbessern. Der Server weist reservierte Adressen, die sich innerhalb der dynamischen Pools befinden, den jeweiligen Clients nicht zu. Das bedeutet auch, dass die Adressen, die mit den entsprechenden Reservierungen innerhalb der dynamischen Pools übereinstimmen (falls vorhanden), jedem Client dynamisch zugewiesen werden können.
// --------------------------------------------------------------------- // 9.12. Duplicate Addresses (DHCPDECLINE Support) // --------------------------------------------------------------------- "decline-probation-period": 3600,
Der DHCP ISC Kea-Server wird mit einem bestimmten Pool von Adressen konfiguriert, die er an DHCPv4-Clients weitergeben soll. Es wird davon ausgegangen, dass der Server massgebend ist und die vollständige Zuständigkeit für diese Adressen hat. Aus verschiedenen Gründen, wie z. B. einer Fehlkonfiguration oder einer fehlerhaften Client-Implementierung, die ihre Adresse über die gültige Lebensdauer hinaus beibehält, können jedoch Geräte angeschlossen sein, die diese Adressen ohne die Zustimmung oder das Wissen des Servers verwenden.
Ein solches unerwünschtes Ereignis kann von legitimen Clients (mit Hilfe von „ARP“- oder „ICMP-Echo-Request“-Mechanismen) erkannt und dem DHCPv4-Server mit einer „DHCPDECLINE“-Nachricht gemeldet werden. Der Server führt eine Plausibilitätsprüfung durch (um festzustellen, ob der Client, der eine Adresse abgelehnt hat, diese auch wirklich verwenden sollte) und führt dann eine Bereinigungsoperation durch. Alle DNS-Einträge, die sich auf diese Adresse beziehen, werden entfernt, das Ereignis wird protokolliert, und es werden „Hooks“ ausgelöst. Nach Abschluss dieses Vorgangs wird die Adresse als abgelehnt markiert (was bedeutet, dass sie von einer unbekannten Entität verwendet wird und daher nicht für eine Zuweisung zur Verfügung steht), und es wird eine Bewährungszeit für sie festgelegt. Sofern nicht anders konfiguriert, dauert die Probezeit 24 Stunden, welche mit dem Parameter decline-probation-period
gesetzt werden kann. Nach Ablauf dieser Zeit stellt der Server die Lease wieder her (d.h. er versetzt sie wieder in den Status „verfügbar“) und die Adresse steht wieder für die Zuweisung zur Verfügung. Es ist zu beachten, dass sich das Szenario mit der doppelten Adresse wiederholt, wenn das zugrunde liegende Problem eines falsch konfigurierten Geräts nicht behoben wird. Bei korrekter Neukonfiguration bietet dieser Mechanismus die Möglichkeit, ein solches Ereignis automatisch und ohne Eingreifen des Systemadministrators zu beheben.
// --------------------------------------------------------------------- // 9.14. Management API for the DHCPv6 Server // --------------------------------------------------------------------- "control-socket": { "socket-type": "unix", "socket-name": "/var/lib/kea/kea6-ctrl-socket" },
Die „Verwaltungs-API“ ermöglicht die Ausgabe spezifischer Verwaltungsbefehle, wie z. B. das Abrufen von Statistiken, die Neukonfiguration oder das Herunterfahren. Derzeit ist der einzige unterstützte Kommunikationskanaltyp der „UNIX-Stream-Socket“. Standardmässig sind keine Sockets geöffnet. Um den DHCP ISC Kea-Server anzuweisen, einen Socket zu öffnen, kann der vorhergehende Konfiguration verwendet werden
Weitere Einzelheiten der Verwaltungs-API können unter nachfolgendem externen Link nachgelesen werden:
// --------------------------------------------------------------------- // 9.2.5. IPv4 Subnet Identifier // 9.2.6. IPv4 Subnet Prefix // 9.2.7. Configuration of IPv6 Address Pools // --------------------------------------------------------------------- "subnet6": [
Definition, das ab hier ein Subnetz IPv6 beginnt.
{ // ===================================================== // Subnet fd00:0:0:dead::/64 (HOME). // ===================================================== "id": 1, "subnet": "fd00:0:0:dead::/64",,
Die Subnetz-Kennung mit dem Parameter id
(Subnetz-ID) ist eine eindeutige Nummer, die einem bestimmten Subnetz zugeordnet ist. Sie wird im Prinzip dazu verwendet, die „Leases“ der Clients mit ihren jeweiligen Subnetzen zu verknüpfen. Wenn für ein zu konfigurierendes Subnetz keine Subnetzkennung angegeben ist, wird sie automatisch vom Konfigurationsmechanismus zugewiesen. Die Bezeichner werden beginnend mit 1 zugewiesen und werden für jedes folgende Subnetz erhöht: 1, 2, 3, usw. Der Parameter subnet
gibt das Subnetzpräfix an und ist die zweite Möglichkeit, ein Subnetz zu identifizieren. Der DHCP ISC Kea-Server kann „non-canonical“ Subnetzadressen akzeptieren.
// ----------------------------------------------------- // 9.2.11. Standard DHCPv6 Options // ----------------------------------------------------- "option-data": [
Eine der möglichen Funktionen auch eines DHCPv6-Servers ist die Möglichkeit, den Clients Konfigurationsoptionen zur Verfügung zu stellen. Die meisten Optionen werden vom Server nur gesendet, wenn der Client sie ausdrücklich mit der Option „Parameter Request List“ anfordert. Bei den Optionen, die nicht in die „Parameter Request List“ aufgenommen werden müssen, handelt es sich um häufig verwendete Optionen, z. B. „Domain Server“ und um Optionen, die ein besonderes Verhalten erfordern, z. B. „Client FQDN“, der an den Client zurückgegeben wird, wenn der Client diese Option in seine Nachricht an den Server aufgenommen hat. Die kann durch den einleitenden Parameter option-data
erfolgen.
// --------------------------------------------- // 9.5. Server Identifier in DHCPv6 // --------------------------------------------- { "space": "dhcp6", "name": "sip-server-dns", "code": 21, "data": "intra.tachtler.net" }, { "space": "dhcp6", "name": "dns-servers", "code": 23, "data": "fd00::dead:10:0:0:20" }, { "space": "dhcp6", "name": "domain-search", "code": 24, "data": "tachtler.net, intra.tachtler.net" }, { "space": "dhcp6", "name": "sntp-servers", "code": 31, "data": "fd00::dead:192:168:0:1" } ],
Nachfolgender externe Link gibt eine Liste der möglichen Optionen am, welche zur Anwendung kommen können:
Nachfolgende Optionen wurden aktuell hier verwendet:
Option | Beschreibung |
---|---|
dhcp-server-identifier | Das DHCPv4-Protokoll verwendet einen „Server-Identifikator“, damit die Clients zwischen mehreren Servern auf derselben Verbindung unterscheiden können. Dieser Wert ist eine IPv4-Adresse des Servers. Der Server wählt die IPv4-Adresse der Schnittstelle, auf der die Nachricht vom Client (oder Relay) empfangen wurde. Eine einzelne Serverinstanz verwendet mehrere Server-Identifikatoren, wenn sie Abfragen auf mehreren Schnittstellen empfängt. |
sip-server-dns | Session Initiation Protocol (SIP) kann DNS-Prozeduren (Domain Name Server) für einen Client verwenden, um einen SIP-URI aufzulösen.. |
dns-servers | Die Adresse, welche den DNS-Server angibt, welche dem Client mit übermittelt wird, an den dieser DNS-Anfragen senden soll. |
domain-search | Der Teil des FQDN, welcher an HOST-Namen angehängt wird um einen vollständigen FQDN als Suchgrundlage für DNS-Anfragen des Clients fomilieren zu können. |
sntp-servers | Die Adresse, welche den Zeit-Server (NTP) angibt, welche dem Client mit übermittelt wird, an den dieser Zeit-Synchronisations-Anfragen senden soll. |
"pools": [ // --------------------------------------------- // Reserved for Guests (after PXE-Boot too). // --------------------------------------------- { "pool": "fd00::dead:192:168:0:100 - fd00::dead:192:168:0:119" }, ],
Die Hauptaufgabe eines DHCPv6-Servers ist die Adresszuweisung. Dazu muss der Server mit mindestens einem Subnetz und einem Pool von zu verwaltenden dynamischen Adressen konfiguriert werden. Nehmen wir an, der Server ist mit einem Netzwerksegment verbunden, das das Präfix fd00::dead:192:168:0:0/64 verwendet. Es wird nachfolgend konfigureirt, dass Adressen aus dem Bereich fd00::dead:192:168:0:100 bis fd00::dead:192:168:0:119 vom DHCPv6-Server als „pool“-Adressen verwaltet werden sollen.
// ----------------------------------------------------- // 9.2.29. Lease Caching // ----------------------------------------------------- "cache-threshold": 0.25, "cache-max-age": 300,
Clients, die mehrere Erneuerungen in einem kurzen Zeitraum versuchen, können den Server dazu veranlassen, die Datenbank häufig zu aktualisieren und zu beschreiben, was sich auf die Leistung des Servers auswirkt. Die Cache-Parameter weisen den DHCP-Server an, zu häufige Aktualisierungen von Leases zu vermeiden, wodurch dieses Verhalten vermieden wird. Stattdessen weist der Server dieselbe „Lease“ zu (d. h. er verwendet sie wieder), ohne Änderungen vorzunehmen, mit Ausnahme der CLTT (Client Last Transmission Time), die keine Plattenoperationen erfordert.
Die beiden Parameter sind cache-threshold
(Typ: double) und cache-max-age
(Typ: integer). Sie sind nicht voreingestellt, d.h. das Lease-Caching muss explizit aktiviert werden. Diese Parameter können auf globaler, Shared-Network- und Subnet-Ebene konfiguriert werden. Die Subnetzebene hat Vorrang vor der Shared-Network-Ebene, während die globale Ebene als letzte Möglichkeit verwendet wird.
// ----------------------------------------------------- // 9.3. Host Reservations in DHCPv6 // 9.3.3. Reserving a Hostname // ----------------------------------------------------- "ddns-qualifying-suffix": "intra.tachtler.net.", "reservations": [ // --------------------------------------------- // Infrastructure. // --------------------------------------------- { "hostname": "server", "hw-address": "ab:12:34:56:78:90", "ip-addresses": [ "fd00::dead:192:168:0:120" ] }, { "hostname": "ipmi", "hw-address": "ac:12:34:56:78:90", "ip-addresses": [ "fd00::dead:192:168:0:121" ] }, ],
Es gibt viele Fälle, in denen es sinnvoll ist, eine Konfiguration auf Hostbasis vorzunehmen. Der offensichtlichste Fall ist die Reservierung einer bestimmten, statischen Adresse für die ausschließliche Verwendung durch einen bestimmten Client (Host). Der anfragende Client erhält jedes Mal dieselbe Adresse vom Server, und andere Clients erhalten diese Adresse im Allgemeinen nicht. Host-Reservierungen sind auch praktisch, wenn ein Host spezielle Anforderungen hat, z. B. ein Drucker, der zusätzliche DHCP-Optionen benötigt. Ein weiterer möglicher Anwendungsfall ist die Festlegung eindeutiger Namen für Hosts.
Das Suffix, das bei der Erzeugung eines FQDN oder bei der Qualifizierung eines Teilnamens verwendet wird, wird durch den Parameter ddns-qualifying-suffix
angegeben. Es wird dringend empfohlen, dass der Benutzer einen Wert für das qualifizierende Präfix angibt, wenn DDNS-Aktualisierungen aktiviert sind.
Der DHCP ISC Kea-Server bietet die Möglichkeit, Optionen für jeden einzelnen Host festzulegen. Diese Optionen folgen den gleichen Regeln wie alle anderen Optionen. Diese werden mit dem Parameter reservation
eingeleitet und beeinhalten die Definitionen für einzelne Clients.
// ----------------------------------------------------- // 9.2.1. Introduction // ----------------------------------------------------- "preferred-lifetime": 300, "max-preferred-lifetime": 900, "min-preferred-lifetime": 60, "valid-lifetime": 300, "max-valid-lifetime": 900, "min-valid-lifetime": 60 } ],
Die Gültigkeitsdauer von „Leases“ wird als Triplett mit Mindest-, Standard- und Maximalwerten durch die Konfigurationseinträge min-valid-lifetime
, valid-lifetime
und max-valid-lifetime
ausgedrückt.
Zusätzlich gibt preferred-lifetime
die bevorzugte Standardlebensdauer an, min-preferred-lifetime
die minimale bevorzugte Lebensdauer an (optional) und max-preferred-lifetime
legt die maximale bevorzugte Lebensdauer fest (optional).
"loggers": [ { "name": "kea-dhcp6", "output_options": [ { "output": "syslog:kea-dhcp6" } ], "severity": "INFO", "debuglevel": 99 } ]
Beim DHCP ISC Kea-Server wird eine Nachricht durch eine Entität namens „Logger“ protokolliert. Verschiedene Komponenten protokollieren Nachrichten über verschiedene Logger, und jeder Logger kann unabhängig von den anderen konfiguriert werden. Einige Komponenten, insbesondere die DHCP-Serverprozesse, können mehrere Logger verwenden, um Nachrichten zu protokollieren, die zu verschiedenen logischen Funktionen der Komponente gehören. Der DHCPv4-Server verwendet beispielsweise einen Logger für Meldungen über den Empfang und die Übertragung von Paketen, einen anderen Logger für Meldungen im Zusammenhang mit der Zuweisung von Leases und so weiter.
Die drei Hauptelemente einer Logger-Konfiguration sind: name
(die Komponente, die die Meldungen erzeugt), severity (was protokolliert werden soll) und output_commands
(wo protokolliert werden soll). Es gibt auch ein debuglevel
-Element, das nur relevant ist, wenn die Debug-Level-Protokollierung ausgewählt wurde.
Die Logger bilden eine Hierarchie. Für jedes Programm beim DHCP ISC Kea-Server gibt es einen „Stamm-Logger“, der nach dem Programm benannt ist (z. B. heißt der Stamm-Logger für kea-dhcp4
, den DHCPv6-Server, kea-dhcp6
). Alle anderen Logger sind Kinder dieses Loggers und werden entsprechend benannt, z. B. protokolliert die Zuweisungs-Engine im DHCPv6-Server Nachrichten mit einem Logger namens kea-dhcp6.alloc-engine
.
Diese Beziehung ist wichtig, da jeder untergeordnete Logger seine Standardkonfiguration von seinem übergeordneten Root-Logger ableitet. Im Normalfall ist die Root-Logger-Konfiguration die einzige in der Konfigurationsdatei angegebene Logging-Konfiguration und gilt daher für alle Logger. Wenn ein Eintrag für einen bestimmten Logger gemacht wird, überschreiben alle angegebenen Attribute die des Root-Loggers, während alle nicht angegebenen von diesem geerbt werden.
Um dies zu veranschaulichen, nehmen wir an, wir verwenden den DHCPv4-Server mit dem Root-Logger kea-dhcp4
, der auf der Ebene INFO protokolliert. Um die DEBUG-Ausführlichkeit für DHCPv4-Paketverluste zu aktivieren, müssen wir einen Konfigurationseintrag für den Logger mit dem Namen kea-dhcp4.bad-packets
erstellen und den Schweregrad DEBUG für diesen Logger angeben. Alle anderen Konfigurationsparameter können für diesen Logger weggelassen werden, wenn der Logger die in der Konfiguration des Root-Loggers angegebenen Standardwerte verwenden soll.
Für weitere ausführliche Informationen und eine Übersicht der möglichen „Logger“, kann nachfplgender externer Link eingesehen werden:
Hier geht es weiter… / To be continued…