Sur un réseau Linux, un serveur DHCP bien configuré fait la différence entre un parc qui se gère tranquillement et un environnement où chaque nouvelle machine devient une corvée. Automatiser l’allocation d’adresse IP, pousser la bonne passerelle, les bons DNS et des durées de bail DHCP cohérentes reste l’un des gestes les plus rentables pour un admin. L’objectif ici est clair : poser les bases des principes DHCP, puis montrer concrètement comment monter une configuration DHCP fonctionnelle sous Linux avec un exemple complet en IPv4. L’idée n’est pas de recopier une recette aveuglément, mais de comprendre ce que fait chaque bloc et comment l’adapter à un LAN de PME, un homelab ou un environnement de test virtualisé.
Pour illustrer tout cela, imaginons un petit réseau d’entreprise où une dizaine de postes, quelques imprimantes et un hyperviseur doivent recevoir automatiquement une adresse IP dynamique ou réservée. Le responsable n’a pas envie de courir après chaque poste pour corriger un masque ou une passerelle mal renseignée. En mettant en place un serveur DHCP sur une machine Debian, avec un fichier de configuration propre et des réservations pour les équipements critiques, ce réseau devient soudain pilotable. Ajoutez à cela quelques bonnes pratiques de sécurité, deux ou trois réflexes de diagnostic, et l’admin gagne un temps précieux à chaque arrivée d’un nouveau client sur le LAN. C’est exactement ce que ce contenu se propose de détailler, sans jargon inutile mais sans simplifier au point de perdre l’aspect technique.
En bref
- DHCP automatise la configuration réseau des clients (IP, masque, passerelle, DNS) et limite les conflits d’adresses.
- Le protocole repose sur un échange simple en 4 étapes entre client et serveur, basé sur UDP et les ports 67/68.
- Sous Linux, on peut s’appuyer sur ISC DHCP (classique) ou Kea DHCP (plus récent) pour monter un serveur fiable.
- Une bonne configuration passe par un fichier dhcpd.conf ou un JSON Kea propre, des pools cohérents et des réservations pour les équipements sensibles.
- Les commandes systemd, les logs et des outils comme tcpdump aident à diagnostiquer les soucis d’allocation ou de renouvellement de bail.
Linux DHCP : principes de fonctionnement et notions clés à maîtriser avant toute configuration
Avant d’éditer le moindre fichier de configuration DHCP sous Linux, il vaut mieux poser les bases. Le Dynamic Host Configuration Protocol est un service de la couche application qui sert à distribuer automatiquement une configuration réseau aux machines d’un même segment. Cette configuration inclut au minimum l’adresse IP et le masque, mais aussi, dans la pratique, la passerelle, les serveurs DNS, parfois les serveurs NTP ou des paramètres plus spécifiques. Dans un parc même modeste, se passer de DHCP revient à multiplier les erreurs humaines et à rendre la gestion des adresses vite pénible.
Le modèle repose sur un couple simple : un client qui demande une configuration, un serveur qui répond. Le client écoute sur le port UDP 68, le serveur sur le port UDP 67. Comme la machine qui démarre ne connaît pas encore sa propre IP, le premier message part en broadcast sur tout le sous-réseau. Ce comportement explique d’ailleurs pourquoi un serveur DHCP mal positionné ou mal filtré peut perturber plusieurs segments s’il n’est pas maîtrisé.
L’échange standard se résume en quatre messages. Le client commence par un DHCPDISCOVER diffusé à 255.255.255.255 pour signaler sa présence et chercher un serveur. Tout serveur à l’écoute qui accepte de répondre envoie ensuite une offre (DHCPOFFER) avec une proposition d’adresse et de paramètres. Le client choisit alors une offre et confirme sa décision par un DHCPREQUEST. Le serveur conclut en validant le bail par un DHCPACK, ce qui finalise l’allocation d’adresse IP. Cet aller-retour paraît basique, mais suffit pour alimenter en IP plusieurs centaines de postes.
Un point clé souvent négligé concerne la notion de bail DHCP. L’adresse fournie l’est pour une durée définie, exprimée en secondes dans les configurations. Pendant ce temps, l’adresse reste associée au client, même s’il redémarre. À mi-parcours environ, le client tente de renouveler. Si la machine s’éteint définitivement ou disparaît du réseau, le bail finit par expirer et l’IP retourne dans le pool disponible. Dans un réseau très dynamique, une durée trop longue encombre le pool. À l’inverse, une durée trop courte entraîne des renouvellements permanents qui gonflent les logs et, parfois, les temps de démarrage.
Autre concept à avoir en tête : le serveur DHCP ne se trouve pas toujours dans le même sous-réseau que les clients. Dans les infrastructures un peu structurées, les VLAN utilisateurs sont séparés du réseau d’admin. C’est là qu’intervient le relais DHCP, généralement configuré sur les routeurs ou les switches de niveau 3. Il reçoit les broadcasts des clients, encapsule la requête, et la transmet au serveur central. La réponse repart ensuite vers le bon segment. Sans relais, un serveur DHCP unique ne verrait tout simplement pas les demandes des sous-réseaux distants.
Sur le plan pratique, un environnement peut héberger plusieurs serveurs DHCP. Cela arrive dans les scénarios de haute disponibilité ou dans des migrations. Le client, lui, prendra la première offre reçue, ce qui peut poser des problèmes si un serveur « sauvage » vient perturber un LAN. Les baies réseau des petites entreprises cachent parfois un vieux routeur Wi-Fi qui continue à distribuer des adresses, et ce genre de situation crée des comportements étranges difficiles à diagnostiquer si l’on ne pense pas à DHCP.
Enfin, il faut rappeler que DHCP n’apporte aucune authentification forte par défaut. Un client peut s’annoncer avec presque n’importe quelle identité. De la même manière, mettre en place un serveur DHCP non autorisé sur un réseau est trivial. C’est l’une des raisons pour lesquelles les équipes réseau prennent souvent la peine de filtrer les ports, de contrôler l’accès aux baies et d’activer les protections de type DHCP snooping sur les commutateurs managés. Sans ces garde-fous, le service DHCP devient un point d’attaque assez confortable.
En résumé, comprendre cette mécanique évite les mauvaises surprises au moment de déployer un serveur DHCP sous Linux, que ce soit avec ISC DHCP ou Kea. La suite consiste à traduire ces principes dans une configuration concrète adaptée à un réseau donné.
Choisir et installer un serveur DHCP sous Linux : ISC DHCP ou Kea, et dans quel contexte
Une fois les concepts en place, reste la question pratique : quel logiciel utiliser pour héberger le service sur un serveur Linux. Historiquement, ISC DHCP Server a régné sur ce rôle pendant longtemps, avec son fameux fichier dhcpd.conf à la syntaxe déclarative. Depuis quelques années, Kea, porté par le même éditeur, prend progressivement le relais avec une approche plus moderne et une configuration en JSON. Les deux solutions fonctionnent bien, mais elles ne ciblent pas exactement les mêmes besoins.
Pour un réseau de petite taille ou un homelab, ISC DHCP garde un énorme avantage : il est très documenté, présent dans beaucoup de supports de cours, et son installation se résume à quelques commandes. Sous Debian ou Ubuntu, un simple apt install isc-dhcp-server suffit, complété par l’activation du service via systemd. Sur CentOS ou Rocky Linux, la logique équivalente passe par yum ou dnf avec un paquet nommé dhcp. Cette solution rend service pour démarrer rapidement un réseau Linux en virtualisation, par exemple sur un lab Proxmox ou VMware. Au passage, un guide comme ce tutoriel dédié à Proxmox et VMware complète bien la démarche pour ceux qui montent un environnement de test complet.
Kea DHCP, de son côté, présente des atouts dès que l’infrastructure grandit. Sa configuration JSON est plus simple à parser et à intégrer dans des outils d’automatisation. Il sait stocker ses baux et ses données dans une base SQL comme MySQL ou PostgreSQL, ce qui ouvre la porte à des intégrations plus poussées, de la supervision avancée ou même des portails de gestion personnalisés. Kea gère aussi mieux certaines options avancées et des scénarios de montée en charge. Pour une PME avec plusieurs sites, ou un hébergeur qui souhaite centraliser la gestion de nombreux sous-réseaux, cette orientation devient vite un argument.
Sur une Debian récente, l’installation de Kea pour l’IPv4 se déroule en quelques étapes. On commence par mettre à jour l’index des paquets avec apt update, puis on installe le service principal avec apt install kea-dhcp4-server. Une fois l’installation terminée, le service kea-dhcp4-server se lance automatiquement. Un coup de systemctl status kea-dhcp4-server confirme son état. Cette simplicité encourage à monter un premier serveur rapidement, quitte à revenir ensuite affiner la configuration.
Par défaut, les fichiers de configuration Kea résident sous /etc/kea. Le fichier kea-dhcp4.conf contient un exemple de configuration prêt à l’emploi. Plutôt que d’écraser ce modèle, une bonne habitude consiste à le renommer en kea-dhcp4.conf.bak pour conserver une référence fonctionnelle avant de créer son propre fichier. Dans beaucoup de cas, repartir d’un fichier propre, adapté au plan d’adressage réel, évite de traîner des options peu utiles héritées de la configuration fournie.
La philosophie à adopter ressemble à celle d’autres services réseau. Installer le paquet ne suffit pas : tant que le plan d’adressage, la segmentation en VLAN et les plages d’IP disponibles ne sont pas clairs, la configuration restera bancale. Dans un projet client typique, l’étape critique consiste d’abord à cartographier l’existant. Machines fixes, imprimantes, bornes Wi-Fi, hyperviseurs, tout ce petit monde a souvent déjà une IP statique plus ou moins documentée. Sans inventaire, le risque de conflit est réel dès l’activation du DHCP.
Dans un homelab, l’approche peut être plus détendue, mais un minimum de méthode reste utile. Par exemple, réserver systématiquement les adresses .1 à .19 pour les équipements d’infrastructure, et démarrer le pool dynamique à .20 laisse de la marge en cas d’ajout de routeurs ou de nouveaux services. Cette discipline se retrouve autant dans un lab Proxmox que dans un cluster VMware, deux plateformes qui fonctionnent très bien au-dessus d’un serveur DHCP Linux robuste.
En fin de compte, le choix entre ISC DHCP et Kea dépend du niveau d’industrialisation recherché. Pour des besoins classiques et un unique site, ISC reste suffisant, d’autant qu’il se pilote facilement par un simple fichier texte. Pour des environnements plus évolués, ou si l’on anticipe une forte croissance du parc, Kea structure mieux la configuration DHCP et s’intègre plus naturellement dans une logique d’automatisation et de supervision centralisée.
Exemple complet de configuration d’un serveur DHCP Kea sous Linux avec baux dynamiques et réservations
Passons maintenant à un cas concret. Imaginons un segment réseau en 192.168.10.0/24 utilisé pour des postes utilisateurs, avec une passerelle en 192.168.10.254 et quelques machines qui nécessitent une IP fixe, comme un serveur de fichiers ou une imprimante réseau. L’objectif est de monter un serveur DHCP Kea sur une Debian et de lui faire distribuer des adresses IP dynamiques aux postes tout en réservant des adresses pour certains équipements en se basant sur leur adresse MAC.
Le fichier /etc/kea/kea-dhcp4.conf va contenir la définition de l’interface d’écoute, des durées de bail, de la base de données de baux et de la section subnet4. La structure globale ressemble à un objet JSON nommé Dhcp4. Premier bloc important, interfaces-config précise sur quelle interface réseau le service écoute les requêtes. Dans un exemple simple, l’interface s’appelle eth0. Une commande comme ip link affiche la liste des interfaces disponibles, ce qui évite d’utiliser un nom erroné et de se demander ensuite pourquoi aucun client ne reçoit d’adresse.
Viennent ensuite les paramètres liés au bail DHCP. Le champ valid-lifetime définit la durée de validité des baux en secondes. Une valeur de 172800 correspond à 48 heures, ce qui fait sens pour un réseau de postes de bureau. Le champ renew-timer, lui, fixe le moment où le client tente de renouveler son bail, par exemple à 86400 secondes, soit la moitié. Ce découpage évite que tous les clients renouvellent en même temps et lisse la charge sur le serveur. Un autre paramètre, authoritative, positionné à true, indique à Kea qu’il fait autorité sur ce réseau. Il pourra ainsi refuser des demandes de renouvellement provenant de clients configurés sur un autre plan d’adressage, ce qui aide à garder la cohérence du LAN.
La configuration de la base des baux occupe un bloc lease-database. Dans une configuration simple, le type memfile suffit. Les baux sont stockés en mémoire, mais une option persist à true permet de sauvegarder leur état dans un fichier CSV, par exemple /var/lib/kea/kea-leases4.csv. Le paramètre lfc-interval indique à quelle fréquence Kea nettoie et compresse cette base, ici toutes les 3 600 secondes. Pour un premier déploiement, cette approche reste largement suffisante et évite d’embarquer une base SQL dès le début.
Le coeur du sujet réside dans la section subnet4. On y décrit le sous-réseau sur lequel Kea distribuera les configurations. Dans l’exemple, subnet vaut « 192.168.10.0/24 ». Le champ id attribue simplement un identifiant interne, ici 1. Le tableau pools contient ensuite la plage d’adresses disponibles pour l’allocation d’adresse IP dynamique. Un pool défini entre 192.168.10.20 et 192.168.10.200 laisse les adresses basses libres pour la passerelle, le serveur DHCP lui-même et d’autres équipements à IP manuelle éventuels.
Pour ajouter de la valeur aux configurations envoyées, l’élément option-data liste les informations complémentaires. On y trouve par exemple une option domain-name-servers avec, comme valeur, l’IP d’un DNS local et éventuellement un DNS public en secours. Une autre option, domain-search, définit le domaine de recherche local, par exemple un domaine interne. Enfin, l’option routers précise la passerelle par défaut, ce qui permet aux clients d’atteindre l’extérieur du sous-réseau sans intervention manuelle.
La dernière partie souvent négligée mais très utile concerne les réservations. Le bloc reservations contient une liste d’objets définissant des couples adresse MAC / adresse IP. Par exemple, une entrée peut fixer que l’adresse MAC d’une imprimante réseau recevra toujours 192.168.10.2. Cette approche combine les avantages d’une IP fixe (facile à cibler pour les utilisateurs et les scripts) et d’une gestion centralisée (la configuration ne se fait pas sur l’équipement lui-même). Pour une PME, réserver les IP des serveurs, des imprimantes, des bornes Wi-Fi et des NAS se révèle vite indispensable.
Une fois le fichier kea-dhcp4.conf rédigé, la prochaine étape consiste à en vérifier la syntaxe. Kea fournit une commande pratique pour cela : kea-dhcp4 -t /etc/kea/kea-dhcp4.conf. Tant que cette commande remonte des erreurs, inutile d’espérer que le service démarre correctement. Dès que la validation passe, un redémarrage via systemctl restart kea-dhcp4-server applique la nouvelle configuration. Sur un homelab, on peut alors démarrer une VM ou un poste en DHCP pour vérifier qu’il obtient bien une adresse dans la plage prévue.
Pour comparer rapidement quelques éléments de configuration entre un environnement simple et un contexte plus avancé, le tableau suivant donne un aperçu synthétique :
| Élément | Petite infrastructure | Infrastructure étendue |
|---|---|---|
| Type de serveur DHCP | ISC DHCP ou Kea avec memfile | Kea avec base SQL (MySQL/PostgreSQL) |
| Durée de bail recommandée | 24 à 48 heures | 8 à 24 heures selon la rotation des postes |
| Plages d’adresses | 1 pool par sous-réseau | Plusieurs subnets, parfois par VLAN ou par site |
| Réservations | Imprimantes, NAS, quelques serveurs | Équipements critiques, bornes, infra VoIP, IoT |
| Surveillance | Consultation ponctuelle des logs | Supervision centralisée des baux et des alertes |
Ce genre de configuration sert de base solide, que ce soit dans un simple lab ou dans un environnement plus construit. Une fois ce bloc fonctionnel, il devient assez naturel d’étendre la logique à d’autres subnets ou de pousser des options plus spécifiques à certains types de clients.
Diagnostic, supervision et dépannage d’un serveur DHCP sous Linux en environnement réel
Mettre en place un service DHCP qui démarre, c’est bien. Savoir quoi faire quand un poste ne reçoit plus d’IP, c’est ce qui fait la différence en production. Sur un serveur DHCP Linux, le diagnostic s’appuie à la fois sur les logs, les outils système et parfois sur une capture réseau ciblée. Dans la pratique, une bonne partie des incidents tournent toujours autour des mêmes causes : interface mal choisie, erreur de masque, plage saturée ou second serveur non désiré qui répond plus vite.
Premier réflexe, vérifier l’état du service via systemctl status, que ce soit isc-dhcp-server ou kea-dhcp4-server. Un service en échec, avec un message de configuration invalide, oriente vite la recherche. Sur les distributions modernes, journalctl -u kea-dhcp4-server ou journalctl -u isc-dhcp-server donne une vue temporelle des événements, des démarrages, et des erreurs de parsing éventuelles des fichiers de configuration. Beaucoup d’admins passent directement à des hypothèses compliquées alors que le problème se trouve déjà là.
Côté client, un outil comme dhclient permet de forcer une nouvelle requête DHCP. Sur une machine Linux en poste, dhclient -r libère le bail actuel, puis dhclient sans option demande une nouvelle adresse. Voir cette commande tourner sans recevoir de bail alors que le service semble actif oriente vers un problème de réseau : interface bloquée, VLAN absent, relais DHCP mal configuré ou, plus rarement, filtrage au niveau des commutateurs.
Pour les cas plus retors, une capture réseau peut sauver des heures de recherche. tcpdump -i eth0 port 67 or port 68 permet d’observer en direct les échanges DHCP. On y voit les DHCPDISCOVER, DHCPOFFER et autres messages défiler. Si aucun paquet n’arrive sur l’interface du serveur alors que des postes clients démarrent, le souci se situe probablement en amont. À l’inverse, si plusieurs serveurs répondent, la capture les mettra en évidence rapidement.
Le suivi des baux joue aussi un rôle central. Avec ISC DHCP, le fichier /var/lib/dhcp/dhcpd.leases répertorie les baux actifs et expirés, avec les adresses MAC associées. Sur Kea en mode memfile, c’est le CSV configuré dans lease-database qui joue ce rôle. En cas de saturation du pool, ce genre de fichier permet de vérifier si des clients conservent des baux longtemps après leur disparition. Dans certains environnements de formation où les machines changent souvent, une durée de bail DHCP trop généreuse aboutit vite à un pool complètement utilisé, alors que peu de postes sont réellement connectés.
Autre source de problèmes fréquents : les erreurs d’alignement entre le plan d’adressage et la configuration DHCP. Un masque mal saisi dans le fichier dhcpd.conf ou dans le JSON Kea casse la cohérence du réseau. Un client qui reçoit une IP en /24 alors que le segment est en /23 ne verra pas tous ses voisins. Là encore, revenir sur le plan IP théorique, vérifier les masques sur les interfaces des routeurs et des serveurs, puis aligner la configuration DHCP évite des sessions de debug interminables.
Dans les entreprises un peu structurées, la supervision doit intégrer le service DHCP au même titre que les autres briques d’infrastructure. Vérifier que le service écoute bien sur l’interface prévue, que les fichiers de baux ne grossissent pas indéfiniment, ou que le nombre de baux actifs reste dans une plage normale alerte rapidement en cas de dérive. Des outils de monitoring classiques, qu’ils soient libres ou commerciaux, savent parfaitement surveiller un service systemd, la taille d’un fichier ou la disponibilité d’un port.
En cas de migration d’ISC DHCP vers Kea, un autre type de panne partielle peut apparaître. Si l’ancien serveur n’est pas stoppé proprement ou reste connecté sur un VLAN, certains clients peuvent continuer à recevoir des offres concurrentes. Les symptômes ressemblent parfois à un problème de connexion aléatoire alors que la cause tient juste à un vieux service laissé en route. Ce type d’incident rappelle l’intérêt de documenter l’infrastructure et de garder une trace claire des changements, surtout lors des grands soirs de migration.
Tout cela montre qu’un serveur DHCP Linux n’est pas un composant à laisser vivre en roue libre. Une fois configuré, il mérite un minimum de suivi, au même titre qu’un DNS ou qu’un contrôleur de domaine. La bonne nouvelle, c’est qu’une fois les bons réflexes en place, les incidents deviennent assez prévisibles et rapides à analyser.
Bonnes pratiques de configuration DHCP, sécurité et organisation des adresses dans un réseau Linux
Quand on commence à accumuler les machines, les VLAN, les hyperviseurs et les services, le plus gros risque n’est pas technique, mais organisationnel. Une configuration DHCP propre dans un réseau Linux repose d’abord sur un plan d’adressage réfléchi. Sans cela, le moindre ajout de sous-réseau devient un casse-tête. Réserver des plages d’IP par type d’équipement, définir clairement les segments utilisateurs, les segments serveurs, les zones DMZ si nécessaire, simplifie ensuite la rédaction des blocs subnet ou des scopes du serveur.
Concrètement, un schéma courant consiste à garder les premières adresses d’un subnet pour l’infrastructure : .1 pour la passerelle, .2 pour le serveur DHCP, .3 pour un DNS, puis une poignée d’IP statiques pour des équipements particuliers. Le pool d’adresses dynamiques commence plus loin, par exemple à .20 ou .50. Cette séparation visuelle aide beaucoup quand on doit analyser rapidement une IP dans les logs ou sur un firewall. C’est un réflexe qui se transpose aussi bien sur un LAN physique que sur un lab hébergé dans Proxmox ou VMware.
Sur le plan de la sécurité, laisser n’importe qui brancher un routeur domestique sur une prise murale et jouer les serveurs DHCP de fortune reste une mauvaise idée. Les commutateurs managés modernes proposent des fonctions comme le DHCP snooping, qui permettent de marquer les ports autorisés à émettre des offres DHCP. Les autres ports sont considérés comme non fiables, et leurs messages DHCP seront bloqués. Pour les petites structures, une politique plus simple consiste déjà à contrôler physiquement l’accès aux baies réseau et à limiter l’usage de switchs non gérés enfichés un peu partout.
Côté serveur, une pratique raisonnable consiste à limiter l’exposition. Un service DHCP n’a rien à faire ouvert sur une interface orientée Internet. Sur une machine Linux multihomée, préciser l’interface d’écoute dans le fichier dhcpd.conf ou dans le bloc interfaces-config de Kea est non seulement propre, mais réduit aussi les risques de fuite sur un réseau inattendu. Dans certains environnements sensibles, le serveur DHCP est même placé sur un VLAN dédié et accessible uniquement via des flux ciblés.
Une autre bonne habitude consiste à documenter les réservations. Sur le moment, assigner 192.168.10.2 à une imprimante peut sembler trivial. Trois ans plus tard, quand il faudra la remplacer ou déplacer le service, personne ne se souviendra de l’historique sans une petite fiche d’inventaire ou un wiki interne. Lier chaque réservation à un ticket de demande, à une entrée dans un inventaire ou à un outil de gestion de configuration évite cette amnésie collective fréquente dans les équipes IT.
Pour les réseaux qui hébergent de la virtualisation en masse, comme des clusters Proxmox ou VMware, DHCP joue souvent un rôle central pour les VMs temporaires, les labs de développement ou les environnements de test. Là, des durées de bail DHCP plus courtes et des pools plus resserrés facilitent la rotation des machines. Un guide d’infra complet, combinant la mise en place de l’hyperviseur et du DHCP, comme sur ce type de ressource, permet d’éviter les erreurs de cohérence entre les segments réseau virtuels et le serveur d’adressage.
Enfin, se poser régulièrement la question « qui a vraiment besoin d’un accès réseau permanent » fait gagner de la lisibilité. Certains équipements historiques peuvent parfois basculer vers une IP statique hors pool, ou même être retirés du LAN. En nettoyant régulièrement le plan d’adressage, on évite d’ajouter des subnets à peine remplis alors qu’un peu de ménage suffirait. DHCP ne remplace pas un vrai travail d’architecture, il en est l’un des outils, à condition de l’utiliser avec méthode.
ISC DHCP et dhcpd.conf : repères pour ceux qui administrent encore l’ancien serveur DHCP Linux
Beaucoup de parcs en production tournent encore avec ISC DHCP comme service principal. Même si Kea gagne du terrain, savoir lire et modifier un fichier dhcpd.conf reste utile. La syntaxe se compose de blocs et de directives relativement lisibles, mais une erreur de point-virgule ou un mauvais héritage de paramètres peut provoquer des effets de bord surprenants. Pour un admin qui reprend une infra existante, un des premiers réflexes consiste souvent à ouvrir ce fichier pour comprendre la logique des attributions d’adresses.
Un dhcpd.conf typique commence par des options globales : durée des baux, domaine, DNS, etc. Par exemple, default-lease-time et max-lease-time fixent la durée standard et la durée maximale d’un bail DHCP. Les options domain-name et domain-name-servers définissent le suffixe DNS et les serveurs à utiliser. Ces paramètres s’appliquent à l’ensemble des subnets, sauf si certains d’entre eux les redéfinissent localement. Mal accompagné, ce mécanisme d’héritage peut créer des situations où un sous-réseau reçoit des DNS différents de ce qui était prévu initialement.
Les blocs subnet, ensuite, décrivent chaque sous-réseau. On y retrouve le network, le netmask, et l’intervalle d’adresses autorisées via la directive range. Dans un réseau Linux simple, on aura un bloc subnet par VLAN utilisateur. La cohérence entre ces blocs et la configuration des routeurs ou des pare-feu doit être rigoureuse. Une simple faute de frappe dans un masque ou une plage mal choisie suffit à rendre certains postes injoignables ou à générer des conflits d’adresses avec des équipements à IP statique.
Pour les réservations, ISC DHCP utilise des blocs host. Chaque bloc porte un nom symbolique (par exemple, host imprimante_salle1) et contient au minimum deux directives : hardware ethernet, avec l’adresse MAC, et fixed-address, avec l’adresse IP qui sera attribuée. Cette approche ressemble à ce que fait Kea avec ses réservations en JSON, mais dans un style plus ancien. Elle reste particulièrement adaptée aux environnements où quelques dizaines d’équipements doivent conserver une IP stable, sans basculer vers une gestion complète dans une base SQL.
La gestion des fichiers de baux avec ISC mérite aussi un mot. Le fichier dhcpd.leases enregistre l’historique des baux. Sa taille augmente avec le temps, mais son contenu reste exploitable pour comprendre qui a utilisé telle IP à un moment donné. Certains admins négligent de surveiller ce fichier, alors qu’il fournit des indices utiles lors d’un audit interne ou pour retracer l’usage d’une adresse impliquée dans un incident. Un simple grep sur la MAC ou sur l’IP concernée donne parfois la réponse qu’aucun outil plus sophistiqué n’a réussi à fournir.
Enfin, aborder la transition vers Kea reste d’actualité. Les deux approches ne s’excluent pas complètement : certains environnements gardent un ISC DHCP « legacy » pour un périmètre précis, tout en expérimentant Kea pour de nouveaux segments. Le choix dépend souvent du temps disponible pour la migration, du niveau d’automatisation souhaité et des compétences de l’équipe. Pour ceux qui envisagent aussi une refonte plus large de leur infra, avec par exemple un cluster Proxmox ou une montée en puissance de VMware, combiner ce chantier DHCP avec la réorganisation réseau peut avoir du sens. Le lien avec des ressources comme ce guide de mise en place d’hyperviseur s’impose alors assez naturellement.
Au final, ISC DHCP n’est pas obligé de disparaître du jour au lendemain. Mais ignorer Kea ressemble de plus en plus à repousser l’inévitable. Prendre le temps de comprendre les deux approches permet de choisir sereinement la trajectoire adaptée à chaque organisation.
Quelle est la différence principale entre ISC DHCP et Kea sur un serveur Linux ?
ISC DHCP s’appuie sur un fichier dhcpd.conf monolithique avec une syntaxe historique, alors que Kea utilise des fichiers JSON plus structurés et peut stocker ses baux dans une base SQL. Pour une petite infrastructure, ISC DHCP reste suffisant. Dès que l’on cherche plus d’automatisation, de supervision ou une gestion multi-sites propre, Kea devient plus adapté.
Comment choisir la durée d’un bail DHCP dans un réseau Linux ?
Dans un environnement de postes fixes (bureaux, salles de formation), une durée de 24 à 48 heures fonctionne bien. Pour des labos, des environnements de test ou des VMs qui tournent peu de temps, des baux plus courts (2 à 8 heures) évitent de saturer le pool. L’idée est de trouver un compromis entre rotation des adresses et volume de renouvellements.
Où se trouve la configuration DHCP sous Linux pour ISC DHCP et pour Kea ?
Pour ISC DHCP, la configuration principale réside généralement dans /etc/dhcp/dhcpd.conf. Pour Kea DHCP en IPv4, le fichier de configuration par défaut se trouve dans /etc/kea/kea-dhcp4.conf. Dans les deux cas, il est conseillé de sauvegarder le fichier d’origine avant de le modifier, afin de pouvoir revenir en arrière en cas de problème.
Comment vérifier qu’un serveur DHCP Linux répond bien aux clients ?
On peut utiliser systemctl status pour vérifier l’état du service, consulter les logs avec journalctl, puis tester depuis un client avec dhclient pour forcer une demande d’adresse. En cas de doute, une capture tcpdump sur les ports 67/68 permet de voir si les messages DHCPDISCOVER et DHCPOFFER circulent bien entre client et serveur.
Pourquoi réserver certaines adresses IP via DHCP plutôt que de les configurer en statique sur les machines ?
Les réservations centralisent la gestion : le serveur DHCP associe une IP fixe à une adresse MAC sans configuration locale sur l’équipement. Cela simplifie le remplacement de matériel, la documentation et les audits. En cas de changement d’IP, une modification dans la configuration DHCP suffit, sans devoir intervenir sur la machine cible.
