DHCP c'est quoi ? Le protocole discret qui fait tourner vos réseaux informatiques

Vous branchez un ordi portable dans un open space, vous allumez votre téléphone sur le WiFi de l’hôtel ou vous ajoutez une imprimante réseau : tout se passe comme par magie. L’appareil récupère une adresse IP valide, sait où envoyer ses paquets et trouve les serveurs DNS sans que personne n’ait touché à une configuration. DHCP c’est quoi vraiment ? C’est le protocole qui rend ce quotidien possible, et qui évite aux administrateurs réseau de passer leur vie à remplir des tableaux Excel avec des adresses IP.

En fait, le DHCP (Dynamic Host Configuration Protocol) est un service client/serveur qui distribue automatiquement tout ce dont un équipement a besoin pour parler sur un réseau IP. Pas seulement l’adresse IP elle-même, mais aussi le masque de sous-réseau, la passerelle par défaut, les serveurs DNS, parfois même le nom de domaine ou des options plus spécifiques. Sans lui, on serait encore en train de configurer chaque machine à la main comme au début des années 90.

Pourquoi ce protocole est devenu indispensable sur n’importe quel réseau un peu sérieux

Le vrai problème, avant le DHCP, c’était l’adressage statique. Chaque poste, chaque imprimante, chaque téléphone IP devait recevoir une IP fixe, notée quelque part, et mise à jour à chaque changement. Sur dix machines, ça passe encore. Sur cinquante, cent ou plusieurs centaines, c’est la catastrophe garantie : conflits d’adresses, erreurs de frappe, mises à jour DNS oubliées, et des heures perdues à chaque arrivée ou départ d’un collaborateur.

Le DHCP change complètement la donne. Il centralise tout sur un ou plusieurs serveurs. Quand une machine arrive sur le réseau, elle demande poliment (ou plutôt elle crie en broadcast) et le serveur lui loue une IP pour une durée limitée, le fameux bail. À la fin du bail, ou avant, le client peut demander à le renouveler. Les adresses qui ne sont plus utilisées retournent dans le pool et peuvent servir à quelqu’un d’autre. C’est particulièrement précieux dans les environnements très mobiles : open spaces, coworking, écoles, hôtels, ou même les réseaux invités d’entreprise.

Et honnêtement, pour les fournisseurs d’accès internet qui ont bien plus de clients que d’adresses IPv4 disponibles, c’est même vital. Les adresses ne sont attribuées que quand les box sont allumées.

Comment ça marche concrètement : le dialogue entre client et serveur

Quand un appareil démarre sans adresse IP, il envoie un premier message en diffusion : « Est-ce qu’il y a un serveur DHCP dans les parages ? » Tous les serveurs qui entendent ça répondent en proposant une IP disponible, avec le masque, la passerelle et les DNS qu’ils connaissent. Le client choisit une des offres (généralement la première arrivée) et rediffuse sa demande pour dire « je prends celle-ci, les autres, laissez tomber ». Le serveur retenu confirme alors l’attribution avec tous les détails et la durée du bail.

C’est un échange en quatre temps qui se passe en quelques secondes, via des paquets UDP sur les ports 67 et 68. Le client n’a encore aucune IP au début, donc tout se fait en broadcast. Une fois qu’il a son IP, les échanges suivants peuvent devenir plus directs.

Le bail n’est jamais éternel. Par défaut, beaucoup de serveurs le mettent à 8 jours ou 24 heures selon l’environnement. Le client commence à demander le renouvellement à mi-chemin (T1) et redouble d’efforts un peu plus tard (T2). Si le serveur ne répond plus, l’adresse reste valide jusqu’à la fin du bail, puis l’appareil repart à zéro. C’est pour ça que parfois, après une coupure serveur longue, certains postes perdent leur connexion même s’ils étaient déjà en train de travailler.

Ce que vous y gagnez vraiment au quotidien

Le premier gain, c’est le temps. Plus besoin de courir après chaque nouvelle machine ou de reconfigurer tout quand on change de plage d’adresses ou de serveurs DNS. Une seule modification sur le serveur DHCP et tout le monde récupère les bons paramètres au prochain renouvellement ou au prochain démarrage.

Deuxième point fort : moins d’erreurs humaines. Les conflits d’IP deviennent rares (le serveur gère le pool et peut même détecter les doublons). Les adresses sont utilisées de façon plus efficace, surtout quand les baux sont courts sur les réseaux très dynamiques.

Troisième avantage, moins visible mais crucial : la mobilité. Un laptop qui passe du filaire au WiFi, ou qui change de bâtiment, récupère une IP cohérente avec le nouveau sous-réseau sans intervention. Pareil pour les invités ou les prestataires qui viennent avec leur matériel.

Dans la pratique, sur les réseaux d’entreprise que je croise, on combine souvent attributions dynamiques pour les postes de travail et réservations statiques (liaison MAC/IP) pour les serveurs, imprimantes et équipements critiques. Comme ça, tout le monde est content.

Les limites et les vrais risques qu’on rencontre encore

Le DHCP n’est pas magique non plus. Le plus gros point faible, c’est la dépendance au serveur. Si le serveur DHCP tombe et qu’il n’y a pas de redondance, les nouveaux arrivants ou les machines qui renouvellent leur bail se retrouvent sans IP. Sur un réseau avec des baux longs, l’impact peut mettre du temps à apparaître… puis tout le monde panique en même temps.

Autre sujet : les broadcasts. Sur des réseaux très étendus ou très chargés, le volume de messages DHCP peut devenir visible, même si c’est rarement le goulot d’étranglement principal.

Et puis il y a la sécurité. C’est probablement le point sur lequel on passe trop souvent à côté. Un serveur DHCP « voyou » (rogue DHCP) peut apparaître très facilement : un employé qui branche son propre routeur WiFi pour avoir un meilleur signal, un point d’accès de test oublié, ou carrément un attaquant qui veut rediriger le trafic. Le faux serveur peut distribuer une mauvaise passerelle ou de faux DNS, ce qui ouvre la porte à des attaques de type homme du milieu ou à du phishing ciblé. Les symptômes classiques : des utilisateurs qui accèdent à des sites bizarres, des IP qui se dupliquent, ou des passerelles qui ne répondent plus.

Dans les audits que je fais, c’est encore un des problèmes les plus fréquents que je trouve sur les réseaux de taille moyenne. La bonne nouvelle, c’est qu’on peut s’en protéger : activer le DHCP snooping sur les commutateurs (seuls les ports uplink vers les vrais serveurs sont « trusted »), autoriser explicitement les serveurs DHCP légitimes dans Active Directory quand on est sous Windows, surveiller les logs et les captures Wireshark, et former les équipes à ne jamais brancher n’importe quel équipement réseau sans validation.

Où se trouve le serveur DHCP selon la taille du réseau

À la maison ou dans une toute petite structure, c’est presque toujours la box de l’opérateur ou le routeur grand public qui fait office de serveur DHCP. Simple, suffisant, et généralement bien caché dans l’interface d’admin.

Dès qu’on passe à une entreprise un peu sérieuse ou à plusieurs VLAN, on installe un vrai serveur dédié : Windows Server avec le rôle DHCP, un serveur Linux avec isc-dhcp-server ou Kea, ou parfois directement sur un firewall/pare-feu moderne. Pour les réseaux qui s’étendent sur plusieurs sous-réseaux, on déploie des agents relais (DHCP relay ou ip helper-address sur du matériel Cisco/HP/Aruba) qui transmettent les demandes vers le serveur central sans avoir besoin d’un serveur par VLAN.

Dans le cloud, les fournisseurs proposent aussi des services DHCP managés, souvent couplés à leur offre de virtual networking. Et pour la haute disponibilité, on met en place du failover entre deux serveurs qui se synchronisent leur base de baux.

Comment vérifier que le DHCP fait bien son travail (et dépanner vite)

Sur un poste Windows, la commande la plus simple reste ipconfig /all. Vous cherchez la ligne « DHCP activé » (elle doit être à Oui) et l’adresse du serveur DHCP qui a répondu. Si vous voyez une IP qui commence par 169.254, c’est que l’appareil n’a pas réussi à joindre de serveur et s’est auto-configuré en mode APIPA : pas de réseau, pas de passerelle, juste une adresse link-local inutile.

Sur Linux ou macOS, ip addr ou ifconfig (selon la distro) et dhclient pour forcer un renouvellement. Côté serveur, les logs (syslog, Event Viewer sur Windows) et la console d’administration vous montrent les baux actifs, les refus, les erreurs.

Pour activer ou réactiver le DHCP sur un réseau WiFi, c’est généralement déjà le cas par défaut sur les clients. Si quelqu’un a mis une IP statique par erreur, il suffit de repasser en mode « Obtenir une adresse IP automatiquement ». Côté point d’accès ou routeur, l’option « Serveur DHCP » se trouve dans l’interface d’admin ; attention juste à ne pas créer de chevauchement avec un autre serveur déjà présent.

Un dernier mot sur l’IPv6 et ce qui change (ou pas)

Avec l’IPv6, le paysage est un peu différent. Beaucoup d’équipements utilisent l’auto-configuration stateless (SLAAC) via les messages Router Advertisement, sans passer par un serveur DHCP. Mais le DHCPv6 existe toujours pour les environnements qui veulent un contrôle plus fin, des adresses stateful ou des options supplémentaires. Dans la pratique, la plupart des réseaux mixtes IPv4/IPv6 gardent un serveur DHCPv4 pour la compatibilité et ajoutent du DHCPv6 seulement quand c’est vraiment nécessaire.

Au bout du compte, le DHCP reste l’un de ces protocoles qu’on ne remarque que quand il ne marche plus. Il a presque trente ans, il a très peu changé dans son principe de base, et il continue de rendre service tous les jours sur des millions de réseaux. Le comprendre un minimum, savoir où il se cache et comment le surveiller, c’est encore aujourd’hui une des compétences les plus utiles pour qui bosse sur des infrastructures réseau.