Kea DHCP-server opzetten: Gids voor Rocky Linux 9, reserveringen, validatie en HA
AI_Manager
Kea DHCP-server: Een moderne DHCPv4-implementatie die automatisch IPv4-adressen, standaardgateways, DNS en leasetijden verstrekt aan clients in het netwerk. De bestaande dhcpd-configuratie voor CentOS 7.9 is om twee redenen niet geschikt voor nieuwe implementaties. CentOS 7 heeft het einde van zijn levensduur bereikt en het onderhoud van ISC DHCP is sinds 2022 beëindigd.
Dit artikel gebruikt de officiële RPM’s van Rocky Linux 9 en Kea 3.0 LTS om eerst veilig een enkel subnet te configureren. We controleren de fysieke interfaces en adresplannen, voeren JSON-syntaxcontroles uit, stellen minimale firewalls in, voeren pakketcaptures uit, voorkomen reserveringsconflicten en koppelen dit aan DHCP-relay en redundantieontwerpen.

Waarom Kea DHCP-server in plaats van ISC DHCP?
ISC heeft DHCP 4.4.3-P1 uitgebracht als de laatste onderhoudsrelease en adviseert om voor nieuwe omgevingen te kiezen voor Kea of een andere server die nog wordt onderhouden. Kea biedt JSON-configuratie, Control Commands, statistieken, hooks, lease-backends voor memfile, MySQL en PostgreSQL, en hoge beschikbaarheidsfuncties, waarbij de 3.0-serie een Long Term Support-branch is.
Hoewel Kea 3.2 in juli 2026 de nieuwste stabiele branch is, kiest deze gids voor 3.0 LTS voor operationele omgevingen die een lange ondersteuningscyclus vereisen. Controleer vóór installatie het ISC-ondersteuningsbeleid en de beveiligingsadviezen voor de exacte onderhoudsversie die u wilt gebruiken.
Kea DHCP-server en de DORA-processtroom
| Stap | Bericht | Praktische controlepunten |
|---|---|---|
| 1 | DHCPDISCOVER | Broadcast of relay-doorsturing van een client zonder adres |
| 2 | DHCPOFFER | Server selecteert subnet en stelt lease en opties voor |
| 3 | DHCPREQUEST | Client vraagt het geselecteerde serveradres aan |
| 4 | DHCPACK | Server registreert de lease en bevestigt de definitieve configuratie |
Als de client en de server zich niet in hetzelfde broadcast-domein bevinden, stuurt de DHCP-relay van de L3-apparatuur het verzoek door als unicast. In dit geval moeten het relay-adres, de subnetselectie, het pad van de server terug naar de relay en de ACL-toestemming voor UDP 67 en 68 allemaal correct zijn ingesteld.
Kea DHCP-server: Voorafgaande controle voor Rocky Linux 9
De voorbeeldserveradressen zijn 192.168.100.2/24, de interface is ens192 en de gateway is 192.168.100.1. Kopieer deze niet zomaar, maar onderzoek eerst de werkelijke NIC, VLAN, dubbele adressen en bestaande DHCP-servers.
cat /etc/os-release
ip -br link
ip -br address
ip route
nmcli -t -f NAME,DEVICE,TYPE,STATE connection show --active
ss -lunp | grep -E ':(67|68)\b' || true
Controle op conflicten in de adrespool
- Zorg ervoor dat de dynamische pool niet overlapt met statische adressen van gateways, servers, printers en netwerkapparatuur.
- Plaats gereserveerde adressen buiten de dynamische pool, zoals in het voorbeeld, of verifieer het beleid van Kea voor het afhandelen van conflicten grondig.
- Controleer met pakketcaptures of er een bestaande DHCP-server reageert in hetzelfde VLAN.
- Controleer of reserveringen op basis van hw-address kunnen veranderen als gevolg van het beleid voor MAC-randomisatie van clients.
Kea DHCP-server: Installatie van de officiële 3.0 LTS RPM
ISC levert pakketten voor de RHEL-familie via de Cloudsmith-repository. Voor het gemak voert u het externe script niet direct uit via een pipe, maar downloadt u het lokaal om de inhoud en de TLS-bron te controleren voordat u het uitvoert. Als uw organisatie een beleid voor de toeleveringsketen heeft, synchroniseer het dan met een goedgekeurde interne repository.
curl --fail --location --proto '=https' --tlsv1.2 https://dl.cloudsmith.io/public/isc/kea-3-0/setup.rpm.sh --output /tmp/isc-kea-3-0-setup.rpm.sh
less /tmp/isc-kea-3-0-setup.rpm.sh
sudo bash /tmp/isc-kea-3-0-setup.rpm.sh
Installeer alleen de DHCPv4-componenten en noteer de versie.
sudo dnf install -y isc-kea-dhcp4
rpm -q isc-kea-dhcp4 isc-kea-common
kea-dhcp4 -V
dnf repolist --enabled | grep -i kea
De afhankelijkheden van de ISC RPM kunnen extra repositories zoals EPEL vereisen. Als er tijdens de installatie afhankelijkheidsfouten optreden, omzeil deze dan niet met --skip-broken, maar controleer volgens de ISC-pakketdocumentatie of de goedgekeurde repository voor Rocky 9 en de benodigde pakketten beschikbaar zijn.
Kea DHCP-server JSON-configuratie
Het standaardbestand van de officiële RPM is doorgaans /etc/kea/kea-dhcp4.conf. Maak eerst een back-up en voer het onderstaande voorbeeld in met sudoedit, aangepast aan uw omgeving. Omdat JSON gevoelig is voor fouten met commentaar, komma’s en aanhalingstekens, moet u de configuratie vóór het starten van de service altijd door de ingebouwde validator van Kea laten controleren.
sudo cp -a /etc/kea/kea-dhcp4.conf /etc/kea/kea-dhcp4.conf.before-$(date +%F-%H%M%S)
sudoedit /etc/kea/kea-dhcp4.conf
{
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "ens192" ]
},
"lease-database": {
"type": "memfile",
"persist": true,
"name": "/var/lib/kea/kea-leases4.csv",
"lfc-interval": 3600
},
"valid-lifetime": 3600,
"renew-timer": 900,
"rebind-timer": 1800,
"subnet4": [
{
"id": 100,
"subnet": "192.168.100.0/24",
"pools": [
{ "pool": "192.168.100.100 - 192.168.100.200" }
],
"option-data": [
{ "name": "routers", "data": "192.168.100.1" },
{ "name": "domain-name-servers", "data": "192.168.100.53" },
{ "name": "domain-name", "data": "example.internal" }
],
"reservations": [
{
"hw-address": "00:11:22:33:44:55",
"ip-address": "192.168.100.50",
"hostname": "printer1"
}
]
}
],
"loggers": [
{
"name": "kea-dhcp4",
"output-options": [ { "output": "syslog" } ],
"severity": "INFO"
}
]
}
}
Waarden die in het voorbeeld moeten worden gewijzigd
| Item | Voorbeeld | Verificatiemethode |
|---|---|---|
| interface | ens192 | De werkelijke service-NIC van ip -br address |
| subnet | 192.168.100.0/24 | Het werkelijke netwerk en prefix van het VLAN |
| pool | .100-.200 | Geen overlap met statische, gereserveerde of andere DHCP-pools |
| router | .1 | De werkelijke gateway die door clients wordt gebruikt |
| DNS | .53 | Interne DNS die toegankelijk is vanaf de client |
| reservering | .50 | Ongebruikt adres buiten de pool en een stabiele identificatie |
Kea DHCP-server syntaxiscontrole en opstarten
sudo kea-dhcp4 -t /etc/kea/kea-dhcp4.conf
sudo systemctl enable --now kea-dhcp4
sudo systemctl status kea-dhcp4 --no-pager
sudo journalctl -u kea-dhcp4 -b --no-pager | tail -n 100
Een succesvolle syntaxiscontrole betekent niet dat het netwerkontwerp correct is. Onjuiste interfaces, gateways, DNS-instellingen of overlappende pools kunnen syntactisch geldig zijn, dus valideer de daadwerkelijke lease van clients, routering en naamomzetting in een geïsoleerd VLAN.
Firewall en minimale blootstelling
De DHCPv4-server gebruikt UDP 67 en clients gebruiken UDP 68. Als de server alleen direct verbonden VLAN’s afhandelt, sta dan de DHCP-service toe in de firewalld-zone waartoe de service-NIC behoort. Beperk in relay-omgevingen ook de relay, ACL’s en routering.
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=internal --add-service=dhcp --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --zone=internal --list-services
sudo ss -lunp | grep ':67'
Controleer eerst of de internal-zone uit het voorbeeld is verbonden met de daadwerkelijke service-NIC. Gebruik geen methode waarbij poorten in alle zones worden geopend. Wijs op netwerkapparatuur de ‘trusted’-poorten van DHCP-snooping alleen toe aan relay- en normale serverpaden.
Diagnose van Kea DHCP-serverpakketten en leases
Realtime DORA-pakketcontrole
sudo tcpdump -ni ens192 -vvv '(udp port 67 or udp port 68)'
Controle van servicelogboeken en leasebestanden
sudo journalctl -u kea-dhcp4 -f
sudo ls -lh /var/lib/kea/
sudo tail -n 20 /var/lib/kea/kea-leases4.csv
| Symptoom | Status zichtbaar in pakketten | Eerste controle |
|---|---|---|
| Geen DISCOVER | Clientverzoek zelf is niet zichtbaar | VLAN, NIC, relay, capture-interface |
| Alleen DISCOVER aanwezig | Geen OFFER | Subnetselectie, pool uitgeput, serverlogboeken, firewall |
| Geen REQUEST na OFFER | Client kan een andere server kiezen | Rogue DHCP, opties, clientbeleid |
| Geen communicatie na ACK | Lease is normaal | Gateway, DNS, ACL, dubbel IP |
| Reservering werkt niet | Verzoek met andere identificatie | Random MAC, client-id, reserverings-ID |
DHCP-relay en meerdere subnetten
Het is niet nodig om de DHCP-server direct met elk VLAN te verbinden. Wanneer het relay-adres van een router of L3-switch het verzoek doorstuurt, gebruikt Kea de door de relay opgegeven linkinformatie om het subnet te selecteren. Gebruik een unieke ID voor elk subnet en valideer het antwoordpad van de server en de toegangs-ACL’s van de relay. Volg voor leveranciersspecifieke relay-opdrachten de officiële documentatie van de apparatuur.
ip route get <RELAY_IP>
sudo tcpdump -ni any -vvv 'host <RELAY_IP> and (udp port 67 or udp port 68)'
sudo journalctl -u kea-dhcp4 --since '-10 min'
Ontwerp van Kea DHCP-serverreserveringen
Een reservering is niet hetzelfde als het ‘handmatig instellen van een vast IP’. Het is een beleid waarbij de server een specifieke lease verstrekt wanneer deze dezelfde client-identificatie ziet. Beheerde printers en server-NIC’s kunnen stabiele MAC-adressen hebben, maar mobiele apparaten kunnen private MAC-adressen per SSID gebruiken. Evalueer bij het selecteren van reserveringsdoelen het beleid voor hw-address, client-id en flex-id gezamenlijk.
- Test het beleid voor het voorkomen van conflicten wanneer een gereserveerd adres overlapt met een dynamische pool.
- Koppel het MAC-adres, de eigenaar en het doel uit het assetbeheersysteem aan de wijzigingsgeschiedenis van de reservering.
- Stel een goedkeuringsprocedure in voor het opschonen van oude identificaties en leases bij het vervangen van apparatuur.
- Als het aantal reserveringen toeneemt, overweeg dan het gebruik van ondersteunde host-backends en de wijzigings-API in plaats van handmatige JSON-bewerking.
Migratie van ISC DHCP naar Kea
De Kea Migration Assistant van ISC voert een gedeeltelijke conversie uit van het bestaande dhcpd.conf-bestand, maar dit betekent niet dat de resultaten direct in een productieomgeving kunnen worden toegepast. Voorwaardelijke instructies, DDNS, failover, klassen, lease-afhandeling en niet-ondersteunde opties moeten handmatig door een beheerder worden gecontroleerd. Ontwerp een overgangsvenster zodat de oude en de nieuwe server niet tegelijkertijd autoritatief dezelfde IP-pools aanbieden.
- Maak een back-up en inventarisatie van de bestaande configuraties, leases, DNS-integraties, relays, opties en reserveringen.
- Controleer de waarschuwingen en niet-geconverteerde syntaxis van de KeaMA-resultaten om een minimaal JSON-configuratiebestand op te stellen.
- Test in een geïsoleerd VLAN het gedrag van DORA, reserveringen, vernieuwingen, DNS, PXE en langdurige lease-activiteiten.
- Bepaal een methode om adresconflicten tijdens de overgang te voorkomen, zoals het stapsgewijs verkorten van de lease-tijden.
- Stop tijdens het wijzigingsvenster de oude antwoorden en start Kea, terwijl u pakketten, logboeken en dubbele adressen in de gaten houdt.
- Documenteer vooraf de terugkeervoorwaarden en de procedures voor het opnieuw activeren van de oude server.
Ontwerp voor hoge beschikbaarheid (HA) van de Kea DHCP-server
De voorgaande JSON is een configuratie voor een enkele DHCP-server en activeert geen HA. Om HA daadwerkelijk in te zetten, moet u het HA-hook-pakket van de gekozen versie, de partner-instellingen binnen hooks-libraries, HTTP/HTTPS-controlekanalen en relay-instellingen die naar beide servers verwijzen, toevoegen. Onderstaande punten zijn ontwerpcriteria en geen vervanging voor een voltooide HA-configuratie. Gebruik de voorbeelden voor de betreffende versie in de ISC HA Quickstart als uitgangspunt en valideer de configuratie van beide nodes gezamenlijk.
De Kea HA-hook kan de status van partners en lease-updates beheren, zoals bij hot-standby of load-balancing. Het simpelweg kopiëren van dezelfde JSON naar beide servers betekent niet dat HA is geconfigureerd. Ontwerp samen met de heartbeat, statusovergangen, lease-synchronisatie, antwoordbeleid bij split-brain, relay-doelen, hook-compatibiliteit en scenario’s voor storingen.
- Zorg dat de tijdssynchronisatie, versies, hooks en subnetconfiguraties van beide servers identiek zijn.
- Sta HA-communicatiepoorten alleen toe via het beheer-netwerk en controleer de ondersteuning voor TLS en authenticatie.
- Test afzonderlijk het stoppen van de primaire server, het verbreken van de HA-link, het verbreken van het relay-pad en het falen van de lease-backend.
- Meet de impact op clients tijdens de partner-down overgangstijd met echte eindapparaten en perfdhcp.
- Omdat HA onjuiste opties, verwijderingen en beheerdersfouten repliceert, zijn versiebeheer van configuraties en afzonderlijke back-ups noodzakelijk.
Operationele checklist
- Houd rekening met het einde van de levensduur (EOL) van CentOS 7 en ISC DHCP en kies een ondersteund besturingssysteem en Kea-branch.
- Controleer de fysieke interfaces, subnetten, pools, gateways, DNS, relays en de bestaande DHCP-antwoorden.
- Start de service na het valideren van de JSON en leg DISCOVER-, OFFER-, REQUEST- en ACK-pakketten vast.
- Beperk de firewall tot het service-VLAN of het relay-pad.
- Beheer gereserveerde adressen, identifiers, random MAC-beleid en waarschuwingen voor uitgeputte pools.
- Maak back-ups van configuraties, de lease-backend, hooks en pakketversies en test het herstel.
- Valideer HA niet alleen bij het stoppen van een server, maar ook bij netwerksegmentatie en mislukte lease-synchronisatie.
Officiële documentatie en gerelateerde handleidingen
- Informatie over het einde van de ondersteuning voor ISC DHCP
- Officiële Kea 3.0 LTS beheerhandleiding
- Officiële ISC Kea-pakketten en servicenamen
- Configuratie van de Kea 3.0 Cloudsmith-repository
- Migratie van ISC DHCP naar Kea
- Officiële Kea HA Quickstart
- Handleiding voor het diagnosticeren van Linux-schijf- en inode-fouten
Samenvatting
Kea DHCP-server: In een nieuwe omgeving is het beter om te kiezen voor ondersteunde Kea- en OS-versies in plaats van te vertrouwen op EOL dhcpd-voorbeelden, en de validatie moet gebaseerd zijn op adresontwerp en werkelijke pakketten. Belangrijker dan de installatie zelf zijn het voorkomen van dubbele DHCP-servers, het beheer van pools en reserveringen, relay-paden, minimale firewall-instellingen, het herstel van leases en configuraties, en HA-tests inclusief netwerksegmentatie.