Le DHCP évite de configurer à la main chaque ordinateur, téléphone ou imprimante connecté à un réseau. Sous Linux, un serveur DHCP attribue une adresse IP et transmet aussi des paramètres utiles, comme le masque réseau, la passerelle et les serveurs DNS. Côté poste, le client DHCP demande cette configuration et conserve l’adresse reçue pendant une durée déterminée : le bail.
Comprendre les échanges entre client et serveur aide à diagnostiquer les pannes qui ressemblent parfois à un problème de Wi-Fi, de câble ou de DNS. La séquence DORA explique l’attribution initiale ; le renouvellement du bail et la gestion des baux permettent ensuite de comprendre pourquoi une adresse reste attribuée, change ou redevient disponible. Un laboratoire Debian avec Netkit rend ces mécanismes observables sans toucher au réseau de production.
Un point mérite aussi d’être gardé en tête : ISC DHCP, longtemps utilisé dans les tutoriels Linux, n’est plus maintenu par l’ISC depuis 2022. Il reste utile pour comprendre un parc existant ou monter un test isolé, tandis que Kea est à considérer pour un nouveau déploiement. Dans les deux cas, une configuration lisible, des journaux consultables et un plan d’adressage cohérent évitent bien des surprises.
En bref
- Le DHCP fournit automatiquement une adresse IP et des options de configuration réseau.
- DORA désigne les quatre messages échangés lors d’une attribution initiale.
- Un bail fixe une adresse pour une durée donnée, avec possibilité de renouvellement.
- Les réservations par adresse MAC associent une machine à une adresse prévue.
- Un faux serveur DHCP ou l’épuisement du pool peut perturber tout un réseau.
Serveur DHCP Linux : rôle et paramètres distribués
Un serveur DHCP répond aux machines qui cherchent une configuration IP. Il peut attribuer une adresse IP dynamique depuis une plage définie, puis transmettre les paramètres nécessaires pour communiquer au-delà du réseau local. Une machine cliente reçoit donc davantage qu’un numéro d’adresse.
Dans une petite agence, par exemple, le serveur peut fournir une adresse, un masque, une passerelle par défaut, un ou plusieurs DNS et un nom de domaine local. Une imprimante peut, elle, recevoir toujours la même adresse grâce à une réservation, sans qu’il soit nécessaire de saisir manuellement toute sa configuration réseau.
Le service ne doit écouter que sur l’interface du réseau qu’il dessert. Sur Debian, le paquet historique isc-dhcp-server utilise notamment le fichier /etc/default/isc-dhcp-server pour préciser l’interface, et /etc/dhcp/dhcpd.conf pour déclarer les plages et options. Un mauvais nom d’interface suffit à empêcher le service de démarrer ou de répondre au bon endroit.
Voici un exemple de paramètres pour un réseau de laboratoire. Les adresses DNS et la passerelle doivent correspondre à des équipements réellement présents ; le serveur DHCP ne crée pas ces services à lui seul.
Exemple de plage : réseau 192.168.1.0/24, adresses dynamiques de 192.168.1.10 à 192.168.1.19, passerelle 192.168.1.254, domaine sae.lan. Le serveur lui-même peut utiliser l’adresse fixe 192.168.1.1, en dehors de la plage distribuée.
La directive authoritative indique que le serveur fait autorité pour le sous-réseau déclaré. Dans ce contexte, il peut envoyer un DHCPNAK lorsqu’un client tente de conserver une adresse incompatible avec le réseau. Ce réglage ne doit pas être copié sans réflexion sur un réseau où un autre serveur DHCP légitime gère déjà les clients.
ISC DHCP fonctionne encore dans des environnements existants, mais l’ISC recommande de migrer vers Kea pour les nouveaux déploiements. La documentation du projet est disponible sur le site officiel d’ISC Kea. Pour un exercice isolé, ISC DHCP reste pratique ; pour un service neuf destiné à durer, mieux vaut évaluer Kea plutôt que bâtir une nouvelle dépendance sur un logiciel ancien.
Client DHCP et séquence DORA : comment une adresse est attribuée
Quand une interface n’a pas encore d’adresse, le client DHCP lance une recherche par diffusion. Le serveur répond avec une proposition, le client la demande explicitement, puis le serveur confirme l’attribution. Ces quatre étapes portent le nom de DORA : Discover, Offer, Request, Acknowledge.
| Étape | Échange | Rôle |
|---|---|---|
| Discover | Client vers réseau local | Recherche d’un serveur DHCP disponible. |
| Offer | Serveur vers client | Proposition d’une adresse et d’options réseau. |
| Request | Client vers réseau local | Le client signale l’offre qu’il souhaite accepter. |
| Acknowledge | Serveur vers client | Confirmation du bail et de sa durée. |
Ces messages DHCPv4 utilisent UDP : le serveur écoute sur le port 67 et le client sur le port 68. Au démarrage, le client ne connaît pas encore forcément l’adresse du serveur ni sa propre adresse ; la diffusion permet de lancer l’échange malgré cette absence de configuration.
Dans un laboratoire Netkit, cinq machines peuvent partager un même hub virtuel : un serveur en 192.168.1.1 et quatre clients. Deux clients, M1 et M4, peuvent recevoir des adresses réservées par adresse MAC, tandis que M2 et M3 obtiennent une adresse dans la plage dynamique. Ce montage montre clairement que réservation et attribution dynamique ne sont pas deux protocoles différents : elles reposent sur le même service, avec des règles d’allocation distinctes.
Pour observer les messages en détail, une capture réseau est souvent plus parlante qu’une longue liste de journaux. Un filtre DHCP dans Wireshark et ses filtres d’affichage permet de repérer les échanges et de vérifier à quel moment une offre ou une confirmation manque.
Renouvellement du bail et gestion des adresses attribuées
Un bail DHCP n’est pas une attribution permanente. Il associe une adresse à un client pour une durée du bail donnée. Tant que cette durée n’est pas arrivée à échéance, le client tente généralement de renouveler son bail auprès du serveur, plutôt que d’attendre de perdre son adresse.
Dans le comportement DHCPv4 défini par la RFC 2131, le client tente habituellement un premier renouvellement au temps T1, souvent fixé à 50 % de la durée du bail. Si le serveur ne répond pas, une nouvelle tentative plus large intervient au temps T2, souvent à 87,5 %. Ces valeurs sont des valeurs par défaut courantes, pas une promesse que toutes les configurations les appliquent à l’identique. La RFC 2131 sur DHCP décrit le protocole et ses états.
Avec un bail de 600 secondes, le client peut donc tenter de le renouveler autour de 300 secondes, puis élargir sa recherche si le serveur reste injoignable. Pour un laboratoire, cette durée courte accélère les essais. Dans un réseau utilisateur, des baux trop courts ajoutent du trafic et compliquent le suivi ; des baux très longs ralentissent la récupération d’adresses après le départ d’équipements.
Sur Debian, la base côté serveur se trouve généralement dans /var/lib/dhcp/dhcpd.leases, et le client conserve ses informations de bail dans /var/lib/dhcp/dhclient.leases. Ces fichiers aident à vérifier l’adresse attribuée et la durée associée. Ils ne remplacent pas les journaux du service : lors d’un diagnostic, comparer les deux sources permet de distinguer une offre reçue d’un bail effectivement confirmé.
Pour tester un client Linux, les commandes dhclient -r eth0 puis dhclient eth0 libèrent puis demandent une configuration. L’interface et les outils disponibles varient selon la distribution : ip address est préférable à l’ancien ifconfig pour vérifier l’adresse actuelle, et ip route affiche la route par défaut. Un ping vers la passerelle teste la connectivité locale, mais ne prouve pas à lui seul que le DNS fonctionne.
Configurer et tester un serveur DHCP sous Debian
Avant d’activer un serveur DHCP, vérifie que son interface possède une adresse statique et qu’aucun autre serveur non prévu ne répond sur le même réseau. Deux serveurs qui distribuent des paramètres incompatibles peuvent donner à deux clients une configuration différente, même si chacun semble fonctionner de son côté.
Dans une maquette Debian avec Netkit, le serveur peut être configuré statiquement en 192.168.1.1, avec une plage dynamique de 192.168.1.10 à 192.168.1.19. Les machines M1 et M4 peuvent être réservées respectivement en 192.168.1.100 et 192.168.1.200. Il faut vérifier que ces adresses réservées ne chevauchent pas la plage dynamique et qu’elles appartiennent bien au sous-réseau déclaré.
La validation gagne à suivre une séquence simple :
- Contrôler l’interface d’écoute et la syntaxe de la configuration du serveur.
- Démarrer le client en mode DHCP, puis vérifier l’adresse et la route obtenues.
- Consulter les journaux ainsi que les fichiers de baux côté serveur et côté client.
- Tester la communication avec le serveur et un autre client du réseau.
- Libérer le bail, relancer une demande et observer si l’adresse est réattribuée.
Un serveur qui ne démarre pas signale souvent une erreur de syntaxe, une interface inexistante ou un sous-réseau mal décrit. Sur Debian, systemctl status isc-dhcp-server et journalctl -u isc-dhcp-server donnent des indices utiles. Il est préférable de lire le message précis plutôt que de modifier plusieurs options au hasard.
Pour une réservation, le serveur associe une adresse MAC connue à une adresse fixe. C’est utile pour une imprimante ou un équipement de supervision dont l’adresse doit rester prévisible. Ce n’est toutefois pas un mécanisme d’authentification : une adresse MAC peut être usurpée, donc une réservation ne suffit pas à protéger un réseau.
Sécurité DHCP : faux serveur, épuisement de pool et protections
Le DHCP est pratique précisément parce que les clients acceptent une configuration reçue automatiquement. Cette confiance crée aussi un risque : un serveur DHCP malveillant ou simplement branché par erreur peut annoncer une fausse passerelle ou de mauvais DNS. Un attaquant placé sur le réseau peut alors tenter d’intercepter ou de détourner une partie du trafic.
Un autre scénario consiste à multiplier les demandes avec des identifiants clients ou adresses MAC aléatoires afin de consommer les adresses disponibles. Quand le pool est épuisé, les appareils légitimes ne peuvent plus obtenir de configuration. Dans un hub virtuel, toutes les machines partagent le même domaine de collision, ce qui rend les échanges visibles aux autres participants du laboratoire ; cette topologie est pédagogique, mais ne doit pas être prise pour une architecture de production sécurisée.
Sur un réseau commuté administrable, le DHCP Snooping permet de déclarer les ports autorisés à recevoir des réponses de serveur DHCP. Il bloque ainsi les offres venant de ports non approuvés. Le contrôle d’accès réseau avec 802.1X peut compléter cette défense en limitant les équipements admis, sans remplacer la segmentation ni la surveillance.
Pour un réseau de petite taille, une première mesure concrète consiste à limiter physiquement et logiquement les ports accessibles, surveiller les attributions inhabituelles et documenter les serveurs autorisés. Sur un parc plus large, les protections du commutateur et la journalisation centralisée deviennent plus pertinentes. La sécurité DHCP ne se règle pas dans le seul fichier de configuration du serveur.
À quoi sert un serveur DHCP sous Linux ?
Il attribue automatiquement une adresse IP aux clients et peut transmettre le masque, la passerelle, les serveurs DNS et d’autres options de configuration réseau.
Que signifie DORA en DHCP ?
DORA résume les quatre messages de l’attribution initiale : Discover, Offer, Request et Acknowledge.
Comment forcer le renouvellement du bail sous Linux ?
Avec dhclient, dhclient -r eth0 libère le bail associé à eth0 ; dhclient eth0 demande ensuite une nouvelle configuration. Le nom de l’interface peut différer.
Une réservation DHCP donne-t-elle une adresse IP fixe ?
Elle associe généralement une adresse IP prévue à l’identifiant ou à l’adresse MAC du client. L’adresse reste gérée par DHCP, mais la réservation ne constitue pas une protection contre l’usurpation.
ISC DHCP est-il encore adapté à un nouveau serveur ?
ISC DHCP reste utile pour comprendre ou maintenir une installation existante. Pour un nouveau déploiement, il est préférable d’évaluer Kea, le successeur recommandé par l’ISC.
