Configuration kea-dhcp4 sur Debian¶

Bannière ECOCERT

Informations

Auteur : KADA Amine
Date : 08/09/2026
Domaine : Debian

1. Sommaire¶

1. Sommaire
2. Contexte
3. Préparation et sauvegarde
4. Configuration du fichier JSON (kea-dhcp4.conf)
5. Application et tests
6. Configuration du relais DHCP (Switch Cisco)

2. Contexte¶

Ce document détaille la procédure de déploiement et de configuration du service Kea-dhcp4 sur un système Debian 13 (nœud pve2, ID 20804). Le serveur (nommé DHCPECOCERT, adresse IP 172.16.54.2) fait office de serveur DHCP centralisé et a pour mission d'allouer dynamiquement les adresses IP aux hôtes répartis sur plusieurs VLANs. L'architecture nécessitant des franchissements de domaines de diffusion, l'intégration implique l'activation d'agents relais DHCP sur l'équipement réseau de cœur de réseau (Switch Cisco de niveau 3).

3. Préparation et sauvegarde¶

Conformité JSON

Le service Kea s'appuie sur une structure de configuration JSON. Le parsing étant extrêmement strict, une erreur de syntaxe (telle qu'une virgule superflue ou manquante) bloquera l'instanciation du daemon.

3.1. Sauvegarde de la configuration d'origine. Archivage du fichier initial fourni par le gestionnaire de paquets afin de garantir une procédure de rollback rapide.

backup_kea_config.sh

sudo mv /etc/kea/kea-dhcp4.conf /etc/kea/kea-dhcp4.conf.bkp
sudo nano /etc/kea/kea-dhcp4.conf

mv : Déplace et renomme la configuration active pour l'isoler de l'exécution.
nano : Génère un buffer vide pour la création d'une configuration ex-nihilo.

4. Configuration du fichier JSON (kea-dhcp4.conf)¶

4.1. Définition des options DHCP et des sous-réseaux. Implémentation du mapping réseau (scopes, baux, options de passerelle et résolveurs DNS) requis pour provisionner les différents VLANs depuis le sous-réseau 172.16.54.0/24.

DHCP VLANs Wifi & Technique

Le serveur DHCP est configuré pour distribuer les adresses IP sur les VLANs Technique et Wifi-Visiteurs. En effet, l'utilisation d'un contrôleur Wi-Fi Unifi virtuel sur un hyperviseur de type 1 n'est pas possible dans notre contexte (un contrôleur matériel physique est requis), justifiant ainsi la gestion des baux par le serveur DHCP centralisé.

/etc/kea/kea-dhcp4.conf

{
  "Dhcp4": {
    "interfaces-config": {
      "interfaces": [ "ens18" ]
    },

    "valid-lifetime": 691200,
    "renew-timer": 345600,
    "rebind-timer": 604800,
    "authoritative": true,

    "lease-database": {
      "type": "memfile",
      "persist": true,
      "name": "/var/lib/kea/kea-leases4.csv",
      "lfc-interval": 3600
    },

    "subnet4": [
      {
        "id": 11,
        "subnet": "192.168.4.0/26",
        "pools": [ { "pool": "192.168.4.10 - 192.168.4.60" } ],
        "option-data": [
          { "name": "routers", "data": "192.168.4.62" },
          { "name": "domain-name-servers", "data": "172.16.54.1, 9.9.9.9" }
        ],
        "user-context": { "description": "VLAN 11 - Administration" }
      },
      {
        "id": 21,
        "subnet": "192.168.4.64/27",
        "pools": [ { "pool": "192.168.4.70 - 192.168.4.90" } ],
        "option-data": [
          { "name": "routers", "data": "192.168.4.94" },
          { "name": "domain-name-servers", "data": "172.16.54.1, 9.9.9.9" }
        ],
        "user-context": { "description": "VLAN 21 - Service de certification" }
      },
      {
        "id": 81,
        "subnet": "192.168.4.96/27",
        "pools": [ { "pool": "192.168.4.100 - 192.168.4.120" } ],
        "option-data": [
          { "name": "routers", "data": "192.168.4.126" },
          { "name": "domain-name-servers", "data": "172.16.54.1, 9.9.9.9" }
        ],
        "user-context": { "description": "VLAN 81 - Wifi visiteurs" }
      },
      {
        "id": 61,
        "subnet": "192.168.4.128/27",
        "pools": [ { "pool": "192.168.4.135 - 192.168.4.150" } ],
        "option-data": [
          { "name": "routers", "data": "192.168.4.158" },
          { "name": "domain-name-servers", "data": "172.16.54.1, 9.9.9.9" }
        ],
        "user-context": { "description": "VLAN 61 - Expertise technique et conseil" }
      },
      {
        "id": 31,
        "subnet": "192.168.4.160/27",
        "pools": [ { "pool": "192.168.4.165 - 192.168.4.185" } ],
        "option-data": [
          { "name": "routers", "data": "192.168.4.190" },
          { "name": "domain-name-servers", "data": "172.16.54.1, 9.9.9.9" }
        ],
        "user-context": { "description": "VLAN 31 - Service referentiels" }
      },
      {
        "id": 71,
        "subnet": "192.168.4.192/28",
        "pools": [ { "pool": "192.168.4.195 - 192.168.4.200" } ],
        "option-data": [
          { "name": "routers", "data": "192.168.4.206" },
          { "name": "domain-name-servers", "data": "172.16.54.1, 9.9.9.9" }
        ],
        "user-context": { "description": "VLAN 71 - Services techniques" }
      },
      {
        "id": 41,
        "subnet": "192.168.4.208/28",
        "pools": [ { "pool": "192.168.4.212 - 192.168.4.220" } ],
        "option-data": [
          { "name": "routers", "data": "192.168.4.222" },
          { "name": "domain-name-servers", "data": "172.16.54.1, 9.9.9.9" }
        ],
        "user-context": { "description": "VLAN 41 - Formations professionnelles" }
      },
      {
        "id": 14,
        "subnet": "192.168.14.248/29",
        "pools": [ { "pool": "192.168.14.250 - 192.168.14.252" } ],
        "option-data": [
          { "name": "routers", "data": "192.168.14.254" },
          { "name": "domain-name-servers", "data": "172.16.54.1, 9.9.9.9" }
        ],
        "user-context": { "description": "VLAN 14 - Interconnexion" }
      }
    ]
  }
}

interfaces-config : Paramètre du socket d'écoute définissant l'interface réseau logique sollicitée (adapter ens18 selon l'hyperviseur).
authoritative : Prévient les dysfonctionnements réseau en autorisant le serveur à révoquer activement les baux invalides ou caduques de son segment.
lease-database : Ordonne le stockage persistant des baux DHCP alloués dans un fichier CSV (memfile), assurant la continuité de service après reboot.
subnet4 : Dictionnaire d'objets assignant pour chaque VLAN un ID de sous-réseau, une étendue d'adresses (pools) et les directives réseau standards (routeur par défaut, résolveur DNS).

5. Application et tests¶

5.1. Validation de la configuration DHCP. Avant de redémarrer le service, il est indispensable de vérifier que le fichier de configuration ne comporte aucune erreur de syntaxe JSON.

test_kea_config.sh

kea-dhcp4 -t /etc/kea/kea-dhcp4.conf

Configuration valide

Si la syntaxe est correcte, la commande s'exécutera sans erreur et confirmera la validité du fichier. Cela garantit que le service pourra être relancé en toute sécurité.

5.2. Rechargement de la configuration via Systemd. Injection de la nouvelle configuration dans le processus applicatif.

restart_kea.sh

sudo systemctl restart kea-dhcp4-server

restart : Coupe la session en cours et réinstancie le service avec les nouveaux paramètres.

5.3. Audit du service (Troubleshooting). Vérification de l'état d'exécution et extraction des exceptions ou erreurs de parsing JSON.

troubleshoot_kea.sh

sudo journalctl -xe | grep kea

journalctl -xe : Visualise la fin de la file de journaux avec le maximum d'informations de contexte.
grep kea : Applique un filtre regex pour isoler le flux spécifique au processus DHCP.

6. Configuration du relais DHCP (Switch Cisco)¶

Agent Relais

Le serveur étant hors des segments locaux des clients, les requêtes DHCPDISCOVER (diffusées en broadcast à l'adresse de niveau 2 FF:FF:FF:FF:FF:FF) sont naturellement bloquées par les routeurs. La configuration d'un agent de relais IP est indispensable.

6.1. Configuration des SVIs (Switch Virtual Interfaces). Altération du comportement par défaut des interfaces virtuelles pour rediriger en unicast les paquets de découverte DHCP vers l'IP du serveur Kea.

cisco_relay.cli

enable
configure terminal

interface vlan 11
 ip helper-address 172.16.54.2
 exit

interface vlan 81
 ip helper-address 172.16.54.2
 exit

interface vlan [ID] : Instancie le mode de configuration pour l'interface passerelle du VLAN spécifié.
ip helper-address : Directive Cisco de niveau 3 encapsulant la requête UDP Broadcast entrante et la relayant directement vers le socket du serveur spécifié (172.16.54.2).