Sur un réseau Linux, un serveur DHCP bien réglé évite beaucoup de tickets inutiles. Une mauvaise plage d’adresses, un bail trop long ou un second serveur “fantôme” qui répond plus vite, et tout un plateau d’utilisateurs se retrouve sans IP. L’objectif ici est de prendre un service très ancien, mais toujours central, et de le ramener à quelque chose de simple à maintenir : comprendre le cycle DHCP, savoir quelles commandes lancer en cas de panne, où placer la configuration (dhcpd.conf ou Kea), et comment garder une gestion propre des baux et des réservations.
Pour le fil rouge, on va suivre un cas concret : une petite PME, une vingtaine de postes, quelques imprimantes réseau, un hyperviseur, et un serveur Linux qui prend en charge le DHCP pour tout ce monde. Rien d’exotique, mais pile le genre d’environnement où une erreur dans le fichier de configuration se paye cash le lundi matin. Avec un peu de méthode, un plan d’adressage clair, et quelques réflexes de dépannage, ce service devient presque ennuyeux à administrer, ce qui est généralement bon signe pour une brique réseau.
En bref
- DHCP sous Linux automatise l’IP, le masque, la passerelle et les DNS, en s’appuyant sur un échange simple en quatre messages entre serveur et client DHCP.
- Deux moteurs principaux en 2026 : ISC DHCP (classique, dhcpd.conf) et Kea (plus moderne, JSON et base SQL pour les baux).
- Une bonne configuration passe par un plan d’adressage propre, des plages cohérentes, des durées de bail DHCP adaptées et des réservations pour les équipements critiques.
- Les commandes systemctl, journalctl, dhclient et tcpdump restent les outils de base pour diagnostiquer un serveur DHCP Linux récalcitrant.
- Limiter l’exposition du service, activer les protections côté switches et documenter les réservations assure une gestion durable du service DHCP.
Linux DHCP : fonctionnement pratique du protocole et impact sur l’exploitation au quotidien
Sur le papier, DHCP est un protocole simple. Dans la vraie vie, il décide pourtant si un parc démarre proprement ou si le support passe sa journée à redémarrer des cartes réseau. Le client DHCP démarre sans adresse IP, envoie un message de découverte en broadcast (DHCPDISCOVER), et attend qu’un serveur DHCP à l’écoute sur le port UDP 67 lui réponde avec une offre (DHCPOFFER) sur le port UDP 68. Ce dialogue semble trivial, mais c’est lui qui alimente tous les postes du plateau.
Une fois l’offre reçue, le client en choisit une (s’il y a plusieurs serveurs) et envoie un DHCPREQUEST. Le serveur confirme par un DHCPACK, ce qui crée le bail DHCP : l’association entre une adresse IP, une MAC et une durée. Pendant cette période, l’adresse reste réservée, même si la machine redémarre. Au bout d’un certain temps (souvent la moitié de la durée de bail), le client tente un renouvellement. Dans un réseau très dynamique, des baux trop longs bloquent des adresses pour rien, alors que des baux extrêmement courts saturent les journaux de renouvellements.
Autre point qui surprend encore certains admins débutants : un serveur peut très bien fournir des IP à plusieurs réseaux, à condition que des relais DHCP (ip helper sur routeurs ou L3 switches) lui acheminent les broadcasts des différents VLANs. Dans la PME du fil rouge, le serveur Linux trône dans un petit local technique, mais sert aussi bien le VLAN bureautique que le segment dédié au Wi-Fi invité. Quand le relais est mal configuré, les utilisateurs d’un étage entier se retrouvent à l’adresse APIPA. La panne vient souvent plus du réseau que du démon DHCP lui-même.
Cette mécanique explique pourquoi un serveur non maîtrisé peut faire des dégâts. Un vieux routeur Wi-Fi, oublié sous un bureau, qui distribue encore du 192.168.0.0/24 alors que le plan d’adressage officiel est en 192.168.14.0/24, et c’est la chasse au trésor. Comprendre précisément l’échange DHCP et sa portée sur le segment, c’est le socle pour exploiter le service sous Linux sans mauvaise surprise.
Installer un serveur DHCP sous Linux : choix entre ISC DHCP et Kea et première configuration
Sur un serveur Linux, deux choix dominent encore. D’un côté ISC DHCP, le vétéran, avec son fichier unique dhcpd.conf et ses années de documentation. De l’autre Kea, plus récent, poussé par le même éditeur, avec une configuration en JSON, une intégration plus simple avec des bases SQL et des API REST. Dans la petite PME fictive, les deux se défendent, mais les contraintes ne sont pas les mêmes selon que l’on gère un homelab ou plusieurs sites distants.
Pour un réseau simple, ISC DHCP reste très utile. Sous Debian 12, l’installation tient en deux commandes :
- sudo apt-get update pour rafraîchir l’index des paquets.
- sudo apt-get install isc-dhcp-server pour installer le service.
À ce stade, voir un échec au démarrage n’a rien d’exceptionnel : sans interface déclarée ni fichier dhcpd.conf correct, le service refuse de se lancer. La première étape consiste donc à dire explicitement au démon sur quelle interface il doit écouter. Sous Debian, le fichier /etc/default/isc-dhcp-server permet de renseigner INTERFACESv4 avec, par exemple, « ens33 », repéré grâce à la commande ip a. C’est un détail, mais beaucoup d’installations ratées viennent simplement d’un mauvais nom d’interface.
Kea DHCP, lui, se récupère aussi via les paquets Debian : apt install kea-dhcp4-server pose le service pour IPv4 avec un fichier /etc/kea/kea-dhcp4.conf. Sa logique parle davantage aux équipes qui automatisent : syntaxe JSON, blocs bien structurés, capacité à stocker les baux dans MySQL ou PostgreSQL. Sur un site qui commence à multiplier les VLANs utilisateurs, les bornes Wi-Fi et les IoT, cette approche évite d’empiler les bricolages dans un seul fichier texte historique.
Pour la PME de l’exemple, une règle simple fonctionne bien : ISC DHCP pour un site unique sans forte croissance prévue, Kea dès que la DSI commence à parler de multi-sites, d’API ou d’industrialisation. Choisir trop tôt un outil trop complexe ralentit le projet, mais ignorer Kea en 2026 peut vite devenir un frein si l’infrastructure se densifie.
Configurer dhcpd.conf sous Linux : exemple d’étendue, options de base et réservations
Dans beaucoup d’entreprises, le fichier dhcpd.conf a été écrit il y a des années et à peine touché depuis. Pourtant, sa structure reste assez lisible pour peu qu’on la reprenne calmement. L’idée est de distinguer ce qui est global (durée de bail DHCP, DNS, domaine) de ce qui ne vaut que pour un sous-réseau donné. Sur la Debian de la PME, le serveur possède l’IP 192.168.14.99/24 et doit distribuer des adresses aux clients de 192.168.14.100 à 192.168.14.120.
Un squelette minimal pourrait ressembler à ceci, une fois adapté :
Options globales typiques : durée des baux, nom de domaine interne, logs. Ce bloc garantit que tous les postes reçoivent au moins une configuration cohérente sans réécrire les mêmes options dans chaque subnet. Les directives default-lease-time et max-lease-time, exprimées en secondes, permettent d’ajuster le rythme de rotation des IP. Sur un parc de bureaux, 4 jours en durée standard et 8 jours maximum tiennent la route, sauf environnement fortement nomade.
Ensuite vient la déclaration de l’étendue :
Le bloc subnet 192.168.14.0 netmask 255.255.255.0 contient le range 192.168.14.100 192.168.14.120, l’option routers 192.168.14.2 pour la passerelle, et option domain-name-servers pointant vers le DNS de l’entreprise. Pour la PME, ce simple bloc couvre déjà tous les PC bureautiques, les postes de compta et quelques VMs de test.
Enfin, les réservations DHCP se font via des blocs host placés à la suite. Une imprimante réseau ou un serveur de fichiers peuvent ainsi conserver une IP fixe tout en étant gérés par le serveur DHCP. Un exemple classique : un host “Ubuntu-2404” qui associe la MAC 00:0c:29:0a:6f:c3 à l’IP 192.168.14.100. En pratique, cette IP ne sera jamais attribuée à un autre équipement, ce qui simplifie les règles de firewall et les habitudes des utilisateurs.
Une fois les modifications appliquées, un systemctl restart isc-dhcp-server.service permet de relancer le service. Si le démon refuse de démarrer, un passage par journalctl -xe | grep -e dhcpd met quasiment toujours en évidence une virgule ou un point-virgule oublié. La grammaire de dhcpd.conf ne pardonne pas les petites fautes ; prendre le réflexe de lire les logs fait gagner du temps.
Kea DHCP sous Linux : exemple de configuration JSON pour un réseau IPv4
Pour ceux qui préfèrent travailler avec des fichiers structurés et pensés pour l’automatisation, Kea apporte une alternative nette. Dans la PME, l’équipe réseau envisage déjà d’ajouter un second site et quelques VLANs IoT. Partir directement sur Kea permet de ne pas se retrouver coincé dans deux ans avec un dhcpd.conf rempli d’exceptions. Le fichier /etc/kea/kea-dhcp4.conf sert de point de départ.
La première section importante, interfaces-config, indique à Kea sur quels liens il écoute. Si l’interface physique se nomme « eth0 », il suffit de l’ajouter dans la liste. Une vérification par ip link évite les surprises liées aux noms générés par le système. Il est possible de restreindre encore en liant le service à une adresse IP spécifique, mais pour un premier déploiement, rester sur l’interface suffit.
Vient ensuite la politique de baux : valid-lifetime fixe la durée du bail en secondes, renew-timer le moment où le client tentera un renouvellement, et rebind-timer le délai après lequel il interrogera n’importe quel serveur s’il n’a pas eu de réponse de son serveur d’origine. Des valeurs de 172 800 / 86 400 / 151 200, par exemple, correspondent respectivement à 48 h de bail, un renouvellement au bout de 24 h, et un rebind à 42 h, assez cohérent pour des postes de bureau.
Le bloc lease-database définit le mode de stockage des baux. Pour un environnement modeste, le type memfile et un fichier CSV dans /var/lib/kea suffisent largement. Kea garde les baux en mémoire tout en les persistant régulièrement sur disque, suivant un intervalle défini par lfc-interval. Pour une structure plus importante, basculer vers MySQL ou PostgreSQL permet d’analyser les baux avec d’autres outils et d’intégrer le tout dans une supervision plus riche.
La partie subnet4 regroupe enfin la configuration réseau à proprement parler. On y définit le préfixe (« 192.168.10.0/24 »), un identifiant numérique, un ou plusieurs pools avec les plages d’adresses utilisables, et les option-data pour routers, domain-name-servers ou encore domain-search. Dans le cas de la PME, un pool 192.168.10.20 – 192.168.10.200 laisse aux premières adresses de la plage (1 à 19) le rôle de zone “infrastructure” réservée.
Les reservations, enfin, assurent le même rôle que les blocs host d’ISC DHCP. Chaque équipement critique reçoit une IP fixe associée à son adresse MAC. Une imprimante réseau voit ainsi son adresse rester identique, ce qui évite de devoir parcourir l’interface d’administration à chaque changement de bail. Avant d’activer une nouvelle configuration, la commande kea-dhcp4 -t /etc/kea/kea-dhcp4.conf valide la syntaxe. C’est un réflexe que beaucoup d’admins aimeraient retrouver sur d’autres services.
Comparer ISC DHCP et Kea pour la gestion DHCP Linux
Sur le terrain, le choix entre les deux moteurs se résume rarement à une question idéologique. Tout dépend du contexte, du temps disponible et de la trajectoire prévue pour l’infrastructure. Le tableau suivant synthétise quelques différences utiles pour trancher.
| Aspect | ISC DHCP (dhcpd.conf) | Kea DHCP |
|---|---|---|
| Format de configuration | Fichier texte unique, syntaxe historique | JSON structuré, blocs clairs, validable |
| Stockage des baux | Fichier dhcpd.leases plat | memfile ou base SQL (MySQL, PostgreSQL) |
| Adapté à | Site unique, homelab, parc modeste | Multi-sites, intégration API, forte croissance |
| Prise en main | Très répandu, beaucoup d’exemples | Demande de s’habituer au JSON et aux outils Kea |
| Maintenance à long terme | Fonctionnel mais vieillit dans les gros environnements | Mieux armé pour l’automatisation et le monitoring |
Pour un administrateur qui reprend un vieux parc, commencer par dompter dhcpd.conf reste souvent la première étape. Pour un nouveau projet avec plusieurs VLANs, de la virtualisation massive et une exigence forte de traçabilité, refuser d’étudier Kea ressemble plutôt à un pari risqué.
Commandes essentielles pour piloter et dépanner un serveur DHCP Linux
Une belle configuration ne vaut rien si personne ne sait la diagnostiquer quand un poste ne reçoit pas d’IP. Dans la PME, lorsque trois utilisateurs se plaignent le même matin, l’admin doit pouvoir en quelques commandes savoir si le problème vient du réseau, du service DHCP ou du poste lui-même. Le socle d’outils est assez réduit, mais il faut le pratiquer régulièrement pour ne pas perdre de temps en jour de crise.
Sur le serveur DHCP, la première étape consiste à vérifier l’état du service :
- systemctl status isc-dhcp-server ou systemctl status kea-dhcp4-server selon le moteur utilisé.
- journalctl -u isc-dhcp-server ou journalctl -u kea-dhcp4-server pour parcourir les événements récents.
Un échec au démarrage, un message de type « self-test failed. Please fix dhcpd.conf » ou une erreur de parsing JSON pointent quasiment toujours vers un souci de syntaxe. Il est tentant de redémarrer plusieurs fois, mais la résolution passe par la correction du fichier, pas par la répétition de systemctl restart. Du côté des clients, dhclient reste la commande de référence sous Linux : un dhclient -r libère le bail actuel, puis un dhclient seul force une nouvelle requête.
Quand la situation se complique, une capture réseau devient l’alliée la plus fiable. Sur le serveur, tcpdump -i ens33 port 67 or port 68 montre en temps réel les DHCPDISCOVER et DHCPOFFER. Ne voir passer aucune requête alors que des postes démarrent indique souvent un relais DHCP manquant ou un VLAN absent sur le trunk qui relie le switch au serveur. À l’inverse, constater deux offres pour chaque découverte confirme la présence d’un second serveur non désiré sur le segment.
Pour vérifier l’occupation des adresses, les fichiers de baux restent précieux. Sous ISC DHCP, un cat /var/lib/dhcp/dhcpd.leases permet de voir les baux actifs, leur durée, l’adresse MAC et le nom d’hôte associé. Beaucoup de conflits d’adresse se résolvent en identifiant qui utilisait telle IP au moment des faits. Kea propose des outils équivalents, notamment lorsque les baux sont stockés dans une base SQL exploitable par d’autres scripts. En production, ce sont ces gestes-là qui séparent un service “magique” d’un service compris et maîtrisé.
Bonnes pratiques de configuration et d’organisation des adresses dans un réseau Linux
Au fil des années, la plupart des pannes DHCP ne viennent pas d’un bug logiciel, mais de choix de configuration discutables. Un plan d’adressage improvisé, des réservations éparpillées, des durées de bail DHCP incohérentes avec la réalité du terrain, et l’on finit avec un réseau difficile à faire évoluer. Dans la PME du fil rouge, ce sont justement ces points qui ont été revus en premier lors d’une refonte.
Une approche simple consiste à structurer chaque sous-réseau en zones. Les premières adresses (par exemple .1 à .19) restent réservées à l’infrastructure : passerelle, serveur DHCP, DNS, hyperviseur, quelques services critiques en IP fixe. Le pool dynamique commence ensuite (.20, .50, peu importe tant que c’est clairement documenté). Les réservations DHCP pour les imprimantes, les NAS et les contrôleurs divers se situent dans une partie facilement repérable de la plage, souvent en bas ou en haut du sous-réseau. Ce découpage “visuel” simplifie beaucoup la lecture des journaux et des règles de firewall.
Sur le terrain, une mauvaise habitude courante consiste à laisser les réservations s’entasser sans aucune trace dans un inventaire. Trois ans après, plus personne ne sait à quoi correspond 192.168.10.17 alors que la MAC n’existe plus. Lier chaque réservation à une fiche équipement, à un ticket ou à un enregistrement dans un outil de gestion de configuration limite ces angles morts. Les équipes qui s’imposent cette discipline hydratent aussi plus facilement leur supervision ou leurs exports vers des tableaux de bord Grafana.
La question de la sécurité ne doit pas non plus être ignorée. Sans protection, n’importe qui peut brancher un routeur domestique et transformer une prise réseau en source hivernale de bugs. Activer des mécanismes comme le DHCP snooping sur les switches managés, limiter les ports “trusted” au seul lien vers le serveur DHCP officiel, et verrouiller les baies réseau réduit largement ce risque. Sur un site où de nombreux intervenants externes branchent des équipements, c’est quasiment une condition minimale.
Enfin, la durée des baux mérite d’être ajustée selon les usages. Dans un laboratoire de développement où les VMs tournent une journée puis sont détruites, des baux de deux à quatre heures suffisent largement. Dans un open-space de sédentaires, une validité de 24 à 48 heures offre un bon compromis. Les réseaux qui hébergent beaucoup d’objets connectés ou de bornes Wi-Fi peuvent, au contraire, préférer des baux plus longs pour réduire le bruit de fond des renouvellements. L’important, c’est de lier ces chiffres aux usages concrets plutôt qu’à des valeurs par défaut héritées d’un autre contexte.
Comment choisir entre ISC DHCP et Kea pour un serveur DHCP Linux ?
ISC DHCP convient bien à un site unique ou à un homelab, grâce à son fichier dhcpd.conf simple à manipuler et à une base d’exemples très large. Kea devient intéressant dès que l’on parle de multi-sites, d’API, d’automatisation ou de stockage des baux dans une base SQL. Dans le doute, commencer par ISC sur un petit périmètre, puis tester Kea sur un segment pilote permet de comparer sans bloquer la production.
Quelles commandes utiliser pour vérifier qu’un serveur DHCP Linux fonctionne ?
Sur le serveur, systemctl status isc-dhcp-server ou systemctl status kea-dhcp4-server donne l’état du service. Les logs se consultent avec journalctl -u suivi du nom du service. Côté client, dhclient permet de libérer puis de redemander une adresse, tandis que tcpdump sur les ports 67 et 68 permet de vérifier que les messages DHCPDISCOVER et DHCPOFFER circulent bien.
Où se trouve la configuration DHCP sous Linux pour ISC DHCP ?
Pour ISC DHCP en IPv4, la configuration principale est dans /etc/dhcp/dhcpd.conf. Sous Debian et Ubuntu, le fichier /etc/default/isc-dhcp-server permet aussi de définir l’interface d’écoute. Avant toute modification, il est recommandé de sauvegarder le fichier existant, puis de redémarrer le service et de contrôler les logs pour détecter les erreurs de syntaxe.
Pourquoi utiliser des réservations DHCP plutôt que des IP statiques sur les machines ?
Les réservations centralisent la gestion des adresses : le serveur associe une IP fixe à une MAC, sans configuration locale sur l’équipement. Lorsqu’une imprimante ou un NAS est remplacé, il suffit de mettre à jour la réservation dans le serveur DHCP. Cela facilite aussi les audits, la documentation et l’intégration avec des outils de supervision, tout en gardant des adresses stables pour les règles de sécurité.
Comment éviter les conflits entre plusieurs serveurs DHCP sur le même réseau ?
La première étape consiste à recenser et désactiver tous les services DHCP non souhaités, notamment sur les box Internet ou les petits routeurs Wi-Fi oubliés. Sur les switches managés, activer le DHCP snooping permet de marquer les ports autorisés à émettre des offres DHCP et de bloquer les autres. Une capture tcpdump sur les ports 67/68 aide à repérer les serveurs indésirables s’ils sont déjà actifs.
