Déployer Kea DHCP sous Rocky Linux 9 : réservations, validation et haute disponibilité

EdwardMoon

Kea est un serveur DHCPv4 moderne qui fournit automatiquement aux clients leur adresse IPv4, passerelle par défaut, DNS et durée de bail. L'ancienne configuration dhcpd sous CentOS 7.9 ne convient plus aux nouveaux déploiements : CentOS 7 est en fin de vie et la maintenance d'ISC DHCP s'est terminée en 2022.

Ce guide part d'un sous-réseau unique sécurisé avec Rocky Linux 9 et les RPM officiels Kea 3.0 LTS. Il relie le choix des interfaces et le plan d'adressage à la validation JSON, aux règles de pare-feu ciblées, à la capture de paquets, à la prévention des conflits de réservation, aux relais DHCP et à la conception de la haute disponibilité.

Pourquoi choisir Kea plutôt qu'ISC DHCP ?

ISC a annoncé DHCP 4.4.3-P1 comme dernière version de maintenance et recommande Kea ou un autre serveur maintenu pour les nouveaux environnements. Kea propose une configuration JSON, des commandes de contrôle, des statistiques, des hooks, des backends de baux memfile/MySQL/PostgreSQL et la haute disponibilité. La série 3.0 bénéficie d'un support à long terme.

Kea DHCP et l'échange DORA

Si les clients et le serveur sont dans des domaines de diffusion distincts, un relais DHCP sur un équipement L3 transmet les demandes en unicast. L'adresse du relais, la sélection du sous-réseau, la route de retour et les ACL UDP 67/68 doivent toutes être correctes.

Vérifications préalables sous Rocky Linux 9

Le serveur de l'exemple utilise 192.168.100.2/24 sur ens192, avec la passerelle 192.168.100.1. Avant de le reprendre, identifiez la véritable interface, le VLAN, les adresses en doublon et les serveurs DHCP existants.

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

Vérifier les conflits de plages d'adresses

• Séparer les plages dynamiques des adresses statiques des passerelles, serveurs, imprimantes et équipements réseau.
• Placer les réservations hors de la plage dynamique, comme dans l'exemple, ou tester explicitement la politique de gestion des conflits de Kea.
• Capturer le trafic pour vérifier si un serveur DHCP existant répond sur le même VLAN.
• Vérifier si la randomisation MAC du client peut modifier l'identifiant d'une réservation hw-address.

Installer les RPM officiels Kea 3.0 LTS

ISC distribue les paquets de la famille RHEL via Cloudsmith. Téléchargez le script de configuration localement et examinez son contenu et sa source TLS avant exécution, au lieu d'envoyer directement un script distant dans un shell. Si votre organisation contrôle sa chaîne d'approvisionnement, synchronisez les paquets dans un dépôt interne approuvé.

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

Installer uniquement DHCPv4 et consigner les versions

sudo dnf install -y isc-kea-dhcp4
rpm -q isc-kea-dhcp4 isc-kea-common
kea-dhcp4 -V
dnf repolist --enabled | grep -i kea

Les dépendances des RPM ISC peuvent nécessiter des dépôts supplémentaires comme EPEL. En cas d'échec de dépendances, ne contournez pas le problème avec --skip-broken. Suivez la documentation ISC pour vérifier les dépôts Rocky 9 approuvés et la disponibilité des paquets nécessaires.

Configurer Kea DHCP en JSON

Le RPM officiel utilise généralement /etc/kea/kea-dhcp4.conf. Sauvegardez-le, puis adaptez l'exemple avec sudoedit. Commentaires, virgules et guillemets sont des sources fréquentes d'erreurs : faites toujours valider la configuration par Kea avant de démarrer le service.

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"
      }
    ]
  }
}

Valeurs à adapter dans l'exemple

Valider la configuration et démarrer Kea

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

Règles de pare-feu et exposition minimale

Un serveur DHCPv4 utilise UDP 67, et les clients UDP 68. Pour un VLAN directement connecté, autorisez le service DHCP dans la zone firewalld de l'interface concernée. Avec un relais, restreignez et validez aussi ses accès, les ACL et le routage.

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'

Vérifiez d'abord que la zone internal de l'exemple est bien attachée à l'interface réelle du service. N'ouvrez pas les ports dans toutes les zones. Sur les équipements réseau, marquez uniquement les chemins vers les relais et serveurs légitimes comme ports de confiance DHCP snooping.

Diagnostiquer les paquets et les baux

Capturer DORA en temps réel

sudo tcpdump -ni ens192 -vvv   '(udp port 67 or udp port 68)'

Examiner les journaux et les fichiers de baux

sudo journalctl -u kea-dhcp4 -f
sudo ls -lh /var/lib/kea/
sudo tail -n 20 /var/lib/kea/kea-leases4.csv

Relais DHCP et sous-réseaux multiples

Le serveur DHCP n'a pas besoin d'être directement connecté à chaque VLAN. Quand un routeur ou commutateur L3 relaie une demande, Kea utilise les informations de lien du relais pour choisir le sous-réseau. Attribuez un id unique à chacun et vérifiez la route de réponse du serveur et les ACL des relais. Suivez la documentation de l'équipement pour les commandes de relais.

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'

Concevoir les réservations DHCP

Une réservation diffère d'une IP statique configurée manuellement. Elle demande au serveur de proposer un bail précis lorsqu'il reconnaît un identifiant client. Les MAC des imprimantes et serveurs administrés peuvent être stables, tandis que les appareils mobiles peuvent employer une MAC privée par SSID. Examinez les politiques hw-address, client-id et flex-id pour choisir les identifiants.

• Tester la prévention des conflits si des adresses réservées chevauchent la plage dynamique.
• Relier les MAC, propriétaires, usages et historiques de réservation à la gestion des actifs.
• Définir une procédure approuvée de retrait des anciens identifiants et baux lors du remplacement d'un appareil.
• Quand les réservations se multiplient, envisager les backends d'hôtes et API pris en charge plutôt que des modifications JSON manuelles.

Migrer d'ISC DHCP vers Kea

Kea Migration Assistant d'ISC peut convertir partiellement dhcpd.conf, mais sa sortie n'est pas automatiquement prête pour la production. Examinez manuellement les conditions, DDNS, failover, classes, baux et options non prises en charge. Planifiez une bascule empêchant les anciens et nouveaux serveurs de faire simultanément autorité sur la même plage.

1. Sauvegarder et inventorier la configuration, les baux, l'intégration DNS, les relais, options et réservations.
2. Examiner les avertissements KeaMA et les instructions non converties, puis construire un JSON minimal.
3. Tester DORA, réservations, renouvellements, DNS, PXE et baux longs sur un VLAN isolé.
4. Réduire les durées de bail en avance et laisser expirer les baux existants, ou définir une autre prévention des conflits pour la bascule.
5. Pendant la maintenance, arrêter les réponses de l'ancien serveur, démarrer Kea et surveiller paquets, journaux et doublons.
6. Documenter à l'avance les critères de retour arrière et la réactivation de l'ancien serveur.

Concevoir la haute disponibilité Kea

Le JSON précédent configure un serveur DHCP unique ; il n'active pas la haute disponibilité. Celle-ci exige aussi le paquet de hook HA de la version choisie, les paramètres des partenaires dans hooks-libraries, des canaux de contrôle HTTP/HTTPS et des relais transmettant aux deux serveurs. Les points suivants sont des critères de conception et de test, pas une configuration HA complète. Partez de l'exemple correspondant à votre version dans le guide ISC HA Quickstart et validez les deux configurations ensemble.

Le hook HA de Kea gère l'état des partenaires et les mises à jour de baux dans des modes tels que hot-standby et load-balancing. Donner le même JSON à deux serveurs ne crée pas de haute disponibilité. Concevez ensemble les battements de cœur, transitions d'état, synchronisations de baux, réactions au split-brain, cibles des relais, versions de hooks et scénarios de panne.

• Aligner l'heure, les versions, les hooks et les sous-réseaux des deux serveurs.
• Limiter les ports HA au réseau d'administration et vérifier les options TLS et d'authentification prises en charge.
• Tester séparément l'arrêt du primaire, la perte du lien HA, la panne du chemin de relais et celle du backend de baux.
• Mesurer l'impact client lors de la transition partner-down avec de vrais appareils et perfdhcp.
• La HA peut propager des options incorrectes, suppressions et erreurs humaines ; le versionnement et les sauvegardes restent indispensables.

Points à vérifier en exploitation

• Tenir compte de la fin de vie de CentOS 7 et ISC DHCP et choisir un système et une branche Kea pris en charge.
• Vérifier les interfaces, sous-réseaux, plages, passerelles, DNS, relais et réponses DHCP existantes.
• Valider le JSON avant démarrage, puis capturer DISCOVER, OFFER, REQUEST et ACK.
• Autoriser uniquement les accès de pare-feu nécessaires aux VLAN de service ou aux relais.
• Gérer les adresses réservées, identifiants, politiques de MAC aléatoires et alertes de plages épuisées.
• Sauvegarder la configuration, les backends de baux, hooks et versions de paquets, puis tester la récupération.
• Valider la HA face aux partitions réseau et échecs de synchronisation, en plus de l'arrêt des serveurs.

Documentation officielle et guides associés

• Annonce de fin de maintenance ISC DHCP
• Manuel d'administration Kea 3.0 LTS
• Paquets officiels ISC Kea et noms de services
• Configuration du dépôt Cloudsmith Kea 3.0
• Migration d'ISC DHCP vers Kea
• Guide officiel Kea HA Quickstart
• Diagnostic de l'espace disque et des inodes sous Linux

Conclusion

Pour un nouveau déploiement DHCP, choisissez Kea et un système maintenus plutôt que des exemples dhcpd en fin de vie. Validez la conception avec le plan d'adressage et les paquets réels. Prévenir les serveurs concurrents, gérer plages et réservations, vérifier les relais, restreindre le pare-feu, restaurer baux et configuration et tester les partitions réseau compte davantage que l'installation seule.