ADMIN

2021

01

2021-01-01T12:00:00

Infrastruktur- und Assetmanagement

SCHWERPUNKT

074

Netzwerkinfrastruktur

Assetmanagement

DHCP-Server Kea

Adressjockey

von Benjamin Pfister

Veröffentlicht in Ausgabe 01/2021 - SCHWERPUNKT

Die dynamische IP-Adressvergabe via DHCP verrichtet meist verlässlich ihren Dienst. Jedoch fehlt es einigen Implementierungen an modernen Schnittstellen, um sie an bestehende Managementsysteme und Datenbanken anzubinden. Auch lassen in die Tage gekommene Lösungen Funktionen für IPv6 vermissen. Einen zeitgemäßen Unterbau bietet das 2014 gestartete Projekt Kea. Wir haben uns Installation und Konfiguration genauer angesehen.

Kea wurde als Nachfolger für den in Enterprise-Netzwerken seit 1999 häufig verwendeten Open-Source-DHCP-Server "ISC DHCP" des Internet Systems Consortium konzipiert. Der DHCP-Server kam vor kurzer Zeit in der Version 1.8.1 heraus [1] und steht für Linux-, Unix- und macOS-Betriebssysteme zur Verfügung. Der Dienst verfügt über einen modularen Aufbau. Beispielsweise gibt es separate Daemons für DHCPv4 und DHCPv6 sowie für die dynamische DNS-Registrierung.
Die Serverkonfiguration fußt auf einer JSON-basierten Datenstruktur. Konfigurationsänderungen bedürfen, mit Ausnahme eines Schnittstellenwechsels, keines Dienstneustarts. Dies war beispielsweise eines der zentralen Kriterien für einen der Early Adopter des Projekts: Facebook. Der Social-Media-Konzern setzte den Vorgänger ISC DHCP gemäß eigenen Aussagen für die Provisionierung der Betriebssysteme von Bare-Metal-Servern und Out-of-Band-Managementsystemen ein.
Automatisierte Mechanismen waren mit statischen Konfigurationsdateien aber komplex zu implementieren und erforderten häufige Neustarts von Diensten, um die Änderungen übernehmen zu können. Zusätzlich waren erweiterte Verfügbarkeitsanforderungen sowie die dynamische Anbindung an das interne Inventarisierungssystem als "Single Point of Truth" zusätzliche Argumente für die Ablösung durch Kea.
Kea wurde als Nachfolger für den in Enterprise-Netzwerken seit 1999 häufig verwendeten Open-Source-DHCP-Server "ISC DHCP" des Internet Systems Consortium konzipiert. Der DHCP-Server kam vor kurzer Zeit in der Version 1.8.1 heraus [1] und steht für Linux-, Unix- und macOS-Betriebssysteme zur Verfügung. Der Dienst verfügt über einen modularen Aufbau. Beispielsweise gibt es separate Daemons für DHCPv4 und DHCPv6 sowie für die dynamische DNS-Registrierung.
Die Serverkonfiguration fußt auf einer JSON-basierten Datenstruktur. Konfigurationsänderungen bedürfen, mit Ausnahme eines Schnittstellenwechsels, keines Dienstneustarts. Dies war beispielsweise eines der zentralen Kriterien für einen der Early Adopter des Projekts: Facebook. Der Social-Media-Konzern setzte den Vorgänger ISC DHCP gemäß eigenen Aussagen für die Provisionierung der Betriebssysteme von Bare-Metal-Servern und Out-of-Band-Managementsystemen ein.
Automatisierte Mechanismen waren mit statischen Konfigurationsdateien aber komplex zu implementieren und erforderten häufige Neustarts von Diensten, um die Änderungen übernehmen zu können. Zusätzlich waren erweiterte Verfügbarkeitsanforderungen sowie die dynamische Anbindung an das interne Inventarisierungssystem als "Single Point of Truth" zusätzliche Argumente für die Ablösung durch Kea.
Hochverfügbar und erweiterbar
Einige optionale Funktionen lassen sich über dynamisch geladene "Hook-Module" nachladen. Es besteht die Möglichkeit, eigene Hooks in C++ zu schreiben, um den Funktionsumfang zu erweitern. Dies erlaubt es, den Kern des Dienstes klein zu halten, gleichzeitig jedoch den möglichen Funktionsumfang nicht einzuschränken.
Zusätzlich bietet das Internet Systems Consortium ein webbasiertes GUI namens Stork [2] für das Monitoring. Dies erfordert Agenten auf den überwachten Kea-Servern. Die Anbindung von Kea an SQL-Datenbanken für DHCP-Lease-Daten, DHCP-Reservierungen und einige Konfigurationsdaten erscheint ebenfalls interessant. Dies ermöglicht zum Beispiel einen einheitlichen Zugriff von geclusterten DHCP-Servern auf einen Lease-Datenbestand. Eine RESTful API bietet die Möglichkeit einer Anbindung an eigene Managementsysteme. Ebenso realisierbar ist eine hochverfügbare Ausrichtung (HA). Im Gegensatz zum betagten ISC DHCP bietet Kea HA auch für IPv4 und IPv6. Die Redundanz für IPv6 ist gemäß RFC8156 implementiert. Zusätzlich besteht die Möglichkeit, nicht nur eine klassische 1:1-Redundanz aufzubauen, sondern neben zwei aktiven Servern noch mehrere Backupserver laufen zu lassen.
Im klassischen ISC-DHCP konnte eine Aufteilung von Adresspools sehr flexibel geschehen. Kea kann dies nur in einer 50/50-Verteilung.
Neben all diesen Funktionen bietet Kea noch die Integration mit RADIUS-Servern. Der RADIUS-Server kann zum Beispiel, wenn eine MAC-Adresse bekannt ist, eine spezielle IPv4- oder IPv6-Adresse vorschlagen und so quasi eine RADIUS-basierte DHCP-Reservierung anbieten. Alternativ kann der RADIUS-Server auch einen bestimmten Adresspool benennen. Dies kann sinnvoll sein, falls an bestimmten IP-Adressen an anderen Stellen, etwa Firewalls, dedizierte Regelwerke hängen.
Installation mit Abhängigkeiten
Vor der Installation sollten Sie zwei entscheidende Fragen beantworten: Zum einen, ob eine Redundanz angedacht ist, und zweitens, ob Sie eine CSV-Datei für die Lease-Daten oder eine Datenbank nutzen möchten. Denn diese benötigen Sie später beim Build-Prozess.
Nach dem Download von Kea besteht die Notwendigkeit einer eigenen Kompilierung. Bei cloudsmith.io lassen sich allerdings vorkompilierte Pakete [3] herunterladen. Einige Linux-Distributionen bieten solche Pakete in ihrem Paketmanager, jedoch sind diese meist nicht aktuell. Seit Kea 1.6.0 besteht die Möglichkeit, ein Build über ein Python-3-Skript namens "Hammer.py" zu erzeugen. Dieses ist im Git-Repository enthalten.
In unserem Beispiel installieren wir zunächst einige Abhängigkeiten, inklusive eines MySQL-Servers für die spätere Ablage der DHCP-Lease-Daten. Im Standard erfolgt eine Ablage dieser Daten in memfile, womit wir auch in unserem Beispiel starten möchten. Als alternative Backends finden MySQL, PostgreSQL und Cassandra Unterstützung. Im Nachgang klonen wir das aktuelle GitLab-Repository und führen den Build-Prozess aus:
sudo apt-get -y install liblog4cplus-dev libboost-all-dev make build-essential autoconf libtool libssl-dev mysql-server libmysqlclient-dev
 
cd /opt/
 
sudo git clone https://gitlab.isc.org/isc-projects/kea.git
 
cd kea
 
sudo autoreconf –install
 
sudo ./configure --with-mysql
 
sudo make
 
sudo make install
Die entsprechenden Binaries sind dann unter "/usr/local/sbin" abgelegt.
Logging und Datenbank vorbereiten
Um global festzulegen, welche Module von Kea geladen werden sollen und über welche Pfade die Konfigurationsdateien erreichbar sind, bearbeiten Sie die Konfigurationsdatei "keactrl.conf". Beispielsweise könnte hier eine Deaktivierung des dynamischen DNS-Diensts erfolgen, falls Sie keine dynamische DNS-Aktualisierung im Netz benötigen.
Ein Starten und Stoppen des Dienstes ist über keactrl start beziehungsweise keactrl stop möglich. Den aktuellen Status fragen Sie über keactrl status ab. In der jeweiligen Modulkonfiguration besteht die Möglichkeit, ein Logging-Ziel festzulegen. Für DHCPv4 wäre dies zum Beispiel "kea-dhcp4.conf", falls Sie nicht über ein Argument eine andere Konfigurationsdatei heranziehen.
Nun müssen Sie die MySQL-Datenbank vor der ersten Verwendung initialisieren. Hierfür stellt das "kea-admin"-Binary das Argument "db-init" zur Verfügung. Die Schritte zur Erteilung der Berechtigung des MySQL-Benutzers führen wir an dieser Stelle nicht detailliert aus. Listing 1 zeigt die Initialisierung inklusive der anschließenden Tabellenstruktur auf.
Listing 1: Initialisieren der MySQL-Datenbank und Ansicht der angelegten Tabellenstruktur
pfister@dhcp:~# kea-admin db-init mysql -u dhcpsvc -p t0ps3cr3t -n dhcp mysql> show tables; +--------------------------------------------+ | Tables_in_dhcp                               | +--------------------------------------------+ | dhcp4_audit                                    | | dhcp4_audit_revision                     | | dhcp4_global_parameter               | | dhcp4_global_parameter_server   | | dhcp4_option_def                           | | dhcp4_option_def_server               | | dhcp4_options                                | | dhcp4_options_server                    | | dhcp4_pool                                     | | dhcp4_server                                  | | dhcp4_shared_network                  | | dhcp4_shared_network_server      | | dhcp4_subnet                                 | | dhcp4_subnet_server                     | | dhcp6_audit                                   | | dhcp6_audit_revision                    | | dhcp6_global_parameter               | | dhcp6_global_parameter_server   | | dhcp6_option_def                          | | dhcp6_option_def_server              | | dhcp6_options                               | | dhcp6_options_server                   | | dhcp6_pd_pool                              | | dhcp6_pool                                    | | dhcp6_server                                 | | dhcp6_shared_network                 | | dhcp6_shared_network_server     | | dhcp6_subnet                                | | dhcp6_subnet_server                    | | dhcp_option_scope                        | | host_identifier_type                       | | hosts                                               | | ipv6_reservations                          | | lease4                                             | | lease4_stat                                     | | lease6                                             | | lease6_stat                                     | | lease6_types                                  | | lease_hwaddr_source                    | |lease_state                                      | | logs                                                | | modification                                  | | parameter_data_type                    | | schema_version                             | +-------------------------------------------+
Initiale Konfiguration erstellen
Im Verzeichnis "/usr/local/etc/kea" befinden sich unter anderem die Konfigurationsdateien der Module für DHCPv4 und DHCPv6, die dynamische DNS-Registrierung und die Parametrisierung des keactrl-Skripts, über das sich der Dienst starten, stoppen sowie dessen Status überprüfen lässt.
Die Anpassung der Konfiguration erfolgt entweder in den Konfigurationsdateien oder über eine RESTful-API. Der zugehörige Daemon nennt sich "Kea Control Agent". Dieser ermöglicht auch die Anbindung an eigene Managementsysteme. Er bietet nativ jedoch keinen verschlüsselten Zugriff. Somit müssten Sie einen Reverse-Proxy wie Apache oder NGINX vorschalten, um verschlüsselte Managementzugriffe zu ermöglichen – was sich natürlich empfiehlt.
Nach der initialen Konfiguration starten Sie über keactrl start -s dhcp4 den DHCPv4-Dienst. Eine Verifikation des Status erfolgt über keactrl status.
Statische Konfiguration vs. Datenbankanbindung
Beginnen wir zunächst mit der statischen DHCPv4-Konfiguration per Konfigurationsdatei. Ein Beispiel haben wir in Listing 2 beigefügt. Wir weisen darauf hin, dass unsere Beispielkonfigurationen nicht für den produktiven Einsatz gedacht sind und zum Teil mit IP-Adressen aus reservierten Adressbereichen speziell für Dokumentationen versehen sind.
Listing 2: Konfigurationsdatei für DHCPv4 mit Anbindung an Memfile
{ "Dhcp4": {       "renew-timer": 900,       "rebind-timer": 1800,       "valid-lifetime": 3600,       "interfaces-config": {            "interfaces": ["ens33"],            "dhcp-socket-type": "raw"       },       "lease-database": {            "type": "memfile",            "persist": true,            "lfc-interval": 3600       }, "option-data": [            {                 "name": "domain-name-servers",                 "data": "192.0.2.1"            },            {                 "code": 15,                 "data": "lab.pfisterit.de"            },            {                 "name": "domain-search",                 "data": "lab.pfisterit.de"            }            ], "subnet4": [            {                 "subnet": "192.0.2.0/24",                 "pools": [                 {                 "pool": "192.0.2.20 – 192.0.2.199"                 }                 ],            "option-data":[                 {                      "name": "routers",                      "data": "192.0.2.1"                      }], "reservations": [                 {                      "hw-address":                      "1a:1b:1c:1d:1e:1f",                      "ip-address": "192.0.2.201"                 } ]            }       ], "loggers": [ {            "name": "kea-dhcp4",            "output_options": [ {                 "output": "/tmp/kea-dhcp4.log"            } ],            "severity": "WARNINGS",            "debuglevel": 0       } ] } }
Eine DHCPv4-Konfigurationsdatei beginnt und endet zunächst mit dem äußeren Element "Dhcp4": { }. Wichtig ist die saubere Kommaseparierung der einzelnen Parameter, um ein valides JSON zu erzeugen. In unserem Beispiel definieren wir zunächst einige Timer. Darunter folgen Timer für die maximale Validität eines DHCP-Lease und für die Verlängerung eines Lease beim vorherigen DHCP-Server oder bei anderen DHCP-Servern. Im Anschluss legen wir das Interface fest, an das eine Bindung des Diensts erfolgen soll, und bestimmen, dass wir Anfragen über den "dhcp-socket-type" per Raw annehmen.
Alternativ könnten Sie, um DHCP-Anfragen per DHCP-Relay am DHCP-Server anzunehmen, den Socket-Type auf "udp" parametrisieren. Als Nächstes konfigurieren wir die Lease-Datenbank auf den Typ "memfile" und die Ablage als persistent in das Verzeichnis "/var/lib/ kea/ dhcp4.leases". Nun gehen wir zu den globalen DHCP-Optionen über. Hierin definieren wir in unserem Beispiel den DNS-Server der Organisation, den Domänennamen sowie die Suchdomäne.
Link-Codes
[1] Kea-Download auf ISC.org: https://www.isc.org/download/
[2] Kea-Dashboard Stork: https://gitlab.isc.org/isc-projects/stork/
[3] Vorkompilierte Kea-Pakete: https://cloudsmith.io/~isc/repos/
[4] Migrationsassistent KeaMA: https://gitlab.isc.org/isc-projects/dhcp/tree/master/keama/
Zusätzlich haben wir einen DHCP-Scope mit der Option zur Vergabe des Default-Gateways angelegt. Zur Erläuterung haben wir eine DHCP-Reservierung für die MAC-Adresse "1a:1b:1c:1d:1e:1f" und die IP-Adresse "192.0.2.201" vorbereitet. Als Logging-Ziel kommt der Pfad "/usr/local/var/log/kea-dhcp4.log" zum Einsatz. Der korrespondierende Log-Level wurde auf Warnungen festgelegt.
Beispiel eines Paketmitschnitts eines DHCP-Offers. Die globale Option des Domänennamens wurde übernommen.
Das Bild zeigt als Beispiel einen DHCPv4-Prozesses in Wireshark. Die globale DHCP-Option der DNS-Domäne "lab.pfisterit.de" wurde im Offer des DHCP-Servers mit der IPv4-Adresse "192.168. 178.194" an den Client übergeben.
Im Gegensatz zu unserem Beispiel in Listing 2 mit einer Lease-Datenbank als Memfile haben wir im nächsten Beispiel eine MySQL-Datenbank angebunden. Hierfür haben wir die entsprechenden Verbindungsparameter wie TCP-Port, Datenbankname und die entsprechenden Credentials im Konfigurations-Snippet in Listing 3 hinterlegt.
Listing 3: Konfigurationsdatei für IPv4 mit Anbindung an MySQL-Datenbank
{ "Dhcp4": {       "renew-timer": 900,       "rebind-timer": 1800,       "valid-lifetime": 3600,       "interfaces-config": {            "interfaces": ["ens33"],            "dhcp-socket-type": "raw"       },       "lease-database": {            "type": "mysql",            "name": "dhcp",            "host": "",            "connect-timeout" : 5,            "max-reconnect-tries": 5,            "reconnect-wait-time": 3000,            "user": "dhcpsvc",            "password": "t0ps3cr3t",            "port": 3306,            "persist": true,            "lfc-interval": 3600       }, "option-data": [            {                 "name": "domain-name-servers",                 "data": "192.0.2.1"            },            {                 "code": 15,                 "data": "lab.pfisterit.de"            },            {                 "name": "domain-search",                 "data": "lab.pfisterit.de"            }            ] , "subnet4": [            {                 "subnet": "192.168.178.0/24",                 "pools": [                 {                      "pool": "192.168.178.20 – 192.168.178.199"                 }                 ],            "option-data":[                 {                      "name": "routers",                      "data": "192.168.178.1"                 }], "reservations": [                 {                      "hw-address":                      "1a:1b:1c:1d:1e:1f",                      "ip-address": "192.168.178.201"                 } ]            }       ], "loggers": [ {            "name": "kea-dhcp4",            "output_options": [ {                 "output": "/tmp/kea-dhcp4.log"            } ],            "severity": "WARNINGS",            "debuglevel": 0       } ] } }
DHCPv6 und Datenmodelle
In unserem Beispiel in Listing 4 verwenden wir eine dedizierte Konfigurationsdatei für IPv6. Die entsprechenden Timer und Schnittstellenbindungen sind bereits aus der IPv4-Konfiguration bekannt. Zentraler Unterschiede sind in unserem sehr einfachen Beispiel anhand der JSON-Struktur in den Angaben "Dhcp6" anstatt "Dhcp4" sowie "subnet6" anstatt "subnet4" für die entsprechenden Scopes erkennbar.
Listing 4: Einfache IPv6-Beispielkonfiguration
{ "Dhcp6": {       "renew-timer": 900,       "rebind-timer": 1800,       "valid-lifetime": 3600,       "interfaces-config": {            "interfaces": ["ens33"],        },       "lease-database": {            "type": "memfile",            "persist": true,            "name": "/var/lib/kea/dhcp6.leases"       },       "subnet6": [            {                 "subnet": "2001:db8:1::/64",                 "pools": [                      {                           "pool": "2001:db8:1::5 - 2001:db8:1::ffff"                      }                 ]            }       ] }   }
Im Zuge zunehmender Automatisierung im Netzwerkumfeld kommt vermehrt das YANG-Datenmodell zum Einsatz. Ein einheitliches Datenmodell empfiehlt sich insbesondere in heterogenen Netzen. Auch Kea bietet eine YANG-Unterstützung auf Basis der Open-Source-Engine Sysrepo. Um mit diesem Datenmodell arbeiten zu können, bietet der unter BSD-Lizenz stehende NETCONF-Server NETOPEER2 eine Schnittstelle für Konfigurationsanpassungen an.
Migrationspfad von ISC DHCP
Wer einen bestehenden ISC-DHCP-Server einsetzt und die neuen Leistungsmerkmale interessant findet, fragt sich nun sicherlich, wie er seine bestehende Konfiguration zu Kea migrieren kann. Hierfür steht ein als KeaMA bezeichneter Migrationsassistent [4] zur Verfügung.
Der Assistent nutzt eine bestehende ISC-Konfigurationsdatei und übersetzt diese in eine Kea-kompatible Konfigurationsdatei. Den Vorgang müssen Sie bei Verwendung beider Protokolle einmal für IPv4 und einmal für IPv6 durchführen. Bei eventuellen Fehlern bei der Übersetzung gibt der Migrationsassistent entsprechende Hinweise. Das Tool gilt gemäß dem korrespondierenden GitLab jedoch noch als experimentell.
Fazit
Kea bietet interessante Ansätze und Funktionen. Ein Umstieg von einem bestehenden ISC-DHCP-Server auf Kea sollte jedoch wohlüberlegt und geplant sein. Wenn Funktionen wie High Availability für IPv6 im eigenen Netz nicht zum Einsatz kommen und Sie keine APIs für Managementsysteme benötigen, ist fraglich, ob ein Umstieg auf Kea Vorteile bringt. Ein Argument stellen natürlich die nicht mehr notwendigen Neustarts bei Scope-Anpassungen dar. Für Rechenzentren mit einer größeren Anzahl an Konfigurationsänderungen innerhalb kurzer Zeitintervalle kann Kea also interessant sein. Die Dokumentation ist ebenfalls gelungen.
(ln)