Accueil/Réseaux & Systèmes /Chapitre 11

DHCP — l'adressage automatique

Comment une machine qui n'a aucune adresse arrive à en demander une — et pourquoi ce paradoxe se résout en quatre messages.

📌

Résumé flash

DHCPv4 distribue automatiquement adresse IP, masque, passerelle et DNS, pour une durée limitée appelée bail. Le dialogue tient en quatre messages — DORA : Discover, Offer, Request, Ack. Il fonctionne sur UDP, ports 67 (serveur) et 68 (client). Comme les deux premiers messages sont des diffusions, un routeur les bloque : d'où le relais DHCP quand le serveur est sur un autre réseau.

🔑 #DHCPv4 #bail #DORA #UDP-67-68 #pool #réservation #exclusion #ip-helper-address #relais #isc-dhcp-server #APIPA

01Statique ou dynamique

	Attribution statique	Attribution dynamique
Principe	Adresse IP, masque, passerelle et DNS saisis à la main sur la machine	Un serveur DHCP attribue automatiquement une adresse depuis un pool, pour une durée de bail limitée
Pour	Serveurs, imprimantes réseau, équipements qui doivent garder toujours la même adresse	Postes clients, smartphones, portables — là où l'on ne veut pas gérer les adresses une par une

💡 Analogie

L'adresse statique, c'est une place de parking nominative : elle vous attend, personne d'autre ne la prend, mais il faut la gérer. Le DHCP, c'est le parking en libre-service : vous prenez une place au hasard en arrivant, vous la libérez en partant. Parfait pour les visiteurs, inacceptable pour l'ambulance de garde.

02Ce que distribue DHCPv4

DHCPv4 permet à un ordinateur qui se connecte sur un réseau local d'obtenir et de configurer dynamiquement et automatiquement :

son adresse IP ;
le masque de son sous-réseau ;
sa passerelle par défaut ;
l'adresse IP du serveur DNS ;
le nom de son domaine.

🧰 Les ports à retenir

DHCP est encapsulé dans UDP :

port 67 côté serveur · port 68 côté client

Un routeur Cisco peut lui-même être configuré pour fournir les services DHCPv4.

🌍 Pourquoi UDP et non TCP

TCP exige une connexion établie entre deux adresses IP connues. Or, au moment où le client demande une adresse, il n'en a pas — et il ignore celle du serveur. Une poignée de main TCP est donc impossible.

UDP, sans connexion, permet d'émettre en diffusion vers 255.255.255.255 : « quelqu'un ici sait-il me donner une adresse ? ». C'est la seule façon de résoudre le paradoxe de départ.

03Les trois méthodes d'attribution

Méthode	Principe	Bail	Usage
Manuelle (par réservation)	L'administrateur associe une IP fixe à une adresse MAC dans le serveur. DHCP ne fait que communiquer cette adresse au client	—	Serveurs, imprimantes — on veut une adresse fixe et la centralisation
Automatique	Le serveur choisit une adresse libre dans le pool et la réserve définitivement pour ce client. En pratique, une dynamique qui devient fixe après la première attribution	Aucun	Rare
Dynamique	Le serveur loue une adresse du pool pour une durée limitée. À l'expiration ou à l'arrêt du poste, l'adresse peut être réutilisée	Oui	La méthode la plus courante

⚠️ Réservation ≠ adresse statique

Dans les deux cas la machine a toujours la même adresse. Mais :

Adresse statique — saisie sur la machine. Pour la changer, il faut aller sur chaque poste.
Réservation DHCP — configurée sur le serveur. Le poste reste en « obtenir automatiquement » ; on modifie tout depuis un seul endroit.

La réservation est donc presque toujours préférable : même résultat, gestion centralisée. C'est ce que demande la mission BioVision pour les trois stations critiques.

04Le dialogue DORA

En pointillé ambre : les messages émis en diffusion. Le client n'a pas encore d'adresse — il ne peut parler qu'à tout le monde.

#	Message	Émis par	Type	Contenu
1	DHCPDISCOVER	Client	Diffusion	« Y a-t-il un serveur DHCP ? » — le client n'a aucune adresse, il émet depuis `0.0.0.0` vers `255.255.255.255`
2	DHCPOFFER	Serveur	Unicast ou diffusion	Une adresse proposée, avec masque, passerelle, DNS et durée de bail
3	DHCPREQUEST	Client	Diffusion	« J'accepte cette offre » — en diffusion, pour prévenir les autres serveurs que leur offre est déclinée
4	DHCPACK	Serveur	Unicast	Confirmation, et le bail commence

🧰 Le moyen mnémotechnique

Discover · Offer · Request · Ack → DORA

Et l'ordre est logique : je cherche, on me propose, j'accepte, on me confirme.

⚠️ Pourquoi le REQUEST est en diffusion

C'est la subtilité que l'on comprend rarement. S'il y a deux serveurs DHCP sur le réseau, le client reçoit deux OFFER. Il en choisit une — mais il doit prévenir l'autre serveur que son offre est refusée, faute de quoi celui-ci garderait l'adresse réservée inutilement.

Le REQUEST est donc émis en diffusion : il porte l'identité du serveur retenu, et les autres comprennent qu'ils peuvent libérer leur proposition.

Le renouvellement du bail

Un bail n'attend pas son expiration pour être renouvelé :

à 50 % de la durée (T1), le client envoie un REQUEST directement au serveur qui lui a donné l'adresse ;
à 87,5 % (T2), s'il n'a pas eu de réponse, il repasse en diffusion pour interroger n'importe quel serveur ;
à 100 %, il abandonne l'adresse et recommence un DORA complet.

🌍 Et si aucun serveur ne répond : l'APIPA

Un poste Windows qui n'obtient rien s'attribue lui-même une adresse en 169.254.x.x — c'est l'APIPA (Automatic Private IP Addressing).

Voir une adresse en 169.254 est donc un diagnostic immédiat : le poste n'a pas joint de serveur DHCP. Câble débranché, service arrêté, VLAN incorrect, ou relais manquant. Cette adresse ne permet de communiquer qu'avec d'autres machines en APIPA sur le même segment.

05Où placer le serveur

Emplacement	Exemples	Adapté à
Sur un routeur	Routeur Cisco, box opérateur, routeur de bordure	Petits réseaux, laboratoires
Sur un serveur dédié	Windows Server (rôle DHCP), Linux (`isc-dhcp-server`)	Réseaux d'entreprise structurés
Sur un équipement multifonction	Pare-feu/UTM, appliance de sécurité, contrôleur Wi-Fi, NAS	Selon l'infrastructure existante

Au niveau du routeur, DHCP peut être configuré de trois façons : en serveur, en relais, ou en client — ce dernier cas quand le routeur lui-même reçoit son adresse de l'opérateur.

06Configurer un routeur Cisco

🧰 Les 5 étapes, dans l'ordre

Exclure des adresses du pool — adresse de passerelle, adresses attribuées statiquement.
Définir le nom du pool DHCP.
Définir la plage d'adresses et le masque.
La passerelle par défaut, avec default-router.
Les paramètres facultatifs : serveur DNS, nom de domaine.

Cisco IOS

! ─── 1. EXCLURE avant de créer le pool ───
R1(config)# ip dhcp excluded-address 192.168.20.1 192.168.20.99
R1(config)# ip dhcp excluded-address 192.168.20.201 192.168.20.254

! ─── 2 à 5. Le pool ───
R1(config)# ip dhcp pool LAN-BUREAU
R1(dhcp-config)# network 192.168.20.0 255.255.255.0
R1(dhcp-config)# default-router 192.168.20.1
R1(dhcp-config)# dns-server 8.8.8.8 1.1.1.1
R1(dhcp-config)# domain-name biovision.local
R1(dhcp-config)# lease 8                        ← durée du bail en JOURS
R1(dhcp-config)# end

! ─── désactiver le service DHCP ───
R1(config)# no service dhcp

⚠️ L'exclusion se déclare AVANT le pool

ip dhcp excluded-address est une commande de configuration globale, pas une commande du pool. Si on la tape depuis (dhcp-config)#, IOS refuse.

Et il faut toujours exclure la passerelle ainsi que toutes les adresses attribuées statiquement : sinon le serveur les distribuera, et deux machines se retrouveront avec la même adresse. Le symptôme est un conflit d'adresse IP difficile à diagnostiquer.

Vérifier

Cisco IOS

R1# show ip dhcp binding        ← quelles adresses sont attribuées, à quelles MAC
R1# show ip dhcp pool           ← utilisation du pool, adresses restantes
R1# show ip dhcp conflict       ← conflits détectés
R1# clear ip dhcp binding *     ← libérer toutes les attributions
R1# debug ip dhcp server events

07Le relais DHCP

⚠️ Le problème que le relais résout

Le DHCPDISCOVER est une diffusion. Or un routeur ne relaie jamais les diffusions — c'est le principe même de la séparation des domaines de diffusion, vu au chapitre 02.

Conséquence : un serveur DHCP ne sert que son propre segment. Avec dix VLAN, il faudrait dix serveurs. C'est précisément ce que le relais évite.

Le relais n'ouvre pas les diffusions : il les convertit en messages dirigés vers le serveur.

Cisco IOS

! sur l'interface QUI REÇOIT les demandes des clients
R1(config)# interface g0/0.20
R1(config-subif)# ip helper-address 192.168.100.10
!                                   └── l'adresse du serveur DHCP distant

🧰 Deux points qui font échouer le relais

La commande va sur l'interface côté CLIENT, celle qui reçoit les diffusions — pas côté serveur. C'est l'erreur la plus fréquente.
Le serveur doit avoir un pool pour chaque réseau relayé. Le routeur insère son adresse d'interface dans la demande, ce qui permet au serveur de savoir de quel sous-réseau vient le client. Sans pool correspondant, il n'a rien à proposer.

08Un serveur ISC sous Debian

Mission BioVision : le pôle Bureau d'étude pharmaceutique (192.168.20.0/24) a besoin d'un serveur DHCP ISC sous Debian 12, avec une étendue dynamique 192.168.20.100-200 et des réservations MAC pour trois stations critiques (.10, .11, .12).

Les prérequis

Une machine Debian avec une adresse IP fixe — 192.168.20.2/24 ;
aucun autre serveur DHCP actif sur le réseau, pour éviter les conflits ;
une machine cliente sans configuration IP, pour tester ;
une connexion Internet sur la Debian, pour télécharger les paquets.

Les six étapes

bash

# 1 — mettre à jour la distribution
apt update && apt upgrade -y

# 2 — installer le paquet
dpkg -l isc-dhcp-server          # vérifier s'il est déjà présent
apt install isc-dhcp-server -y

# 3 — passer le serveur en adresse fixe
ip a                              # relever le nom exact de l'interface
nano /etc/network/interfaces

/etc/network/interfaces

auto enp0s3
iface enp0s3 inet static
    address  192.168.20.2
    netmask  255.255.255.0
    gateway  192.168.20.1

bash

systemctl restart networking      # ou : /etc/init.d/networking restart

# 4 — configurer le serveur DHCP
cp /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.conf.old      # SAUVEGARDER d'abord
nano /etc/dhcp/dhcpd.conf

/etc/dhcp/dhcpd.conf

default-lease-time 600;
max-lease-time 7200;
authoritative;

subnet 192.168.20.0 netmask 255.255.255.0 {
    range 192.168.20.100 192.168.20.200;
    option routers             192.168.20.1;
    option subnet-mask         255.255.255.0;
    option domain-name-servers 8.8.8.8, 1.1.1.1;
    option domain-name         "biovision.local";
}

# 5 — RÉSERVATIONS : en dehors du bloc subnet
host station-simul-1 {
    hardware ethernet 08:00:27:1a:2b:3c;
    fixed-address 192.168.20.10;
}
host station-simul-2 {
    hardware ethernet 08:00:27:4d:5e:6f;
    fixed-address 192.168.20.11;
}
host station-simul-3 {
    hardware ethernet 08:00:27:7a:8b:9c;
    fixed-address 192.168.20.12;
}

bash

# déclarer l'interface d'écoute
nano /etc/default/isc-dhcp-server
    INTERFACESv4="enp0s3"

# 6 — redémarrer et tester
systemctl restart isc-dhcp-server
systemctl status isc-dhcp-server        # doit être « active (running) »
journalctl -u isc-dhcp-server -f        # suivre les attributions en direct
cat /var/lib/dhcp/dhcpd.leases          # les baux accordés

⚠️ Les quatre pièges du fichier dhcpd.conf

Chaque ligne se termine par un point-virgule. Un oubli et le service refuse de démarrer, avec un message peu explicite.
Les réservations host se placent en dehors du bloc subnet — c'est explicitement demandé par l'énoncé.
La plage range ne doit pas recouvrir les adresses réservées. Ici .100-.200 et les réservations en .10-.12 : aucun chevauchement.
L'interface d'écoute doit être déclarée dans /etc/default/isc-dhcp-server. Sans cela, le service démarre mais n'écoute nulle part.

Le réflexe : dhcpd -t -cf /etc/dhcp/dhcpd.conf teste la syntaxe avant de redémarrer le service.

Tester depuis un client

bash

# Linux
dhclient -r enp0s3        # libérer le bail actuel
dhclient enp0s3           # en demander un nouveau
ip a                      # vérifier l'adresse obtenue

# Windows
ipconfig /release
ipconfig /renew
ipconfig /all             # adresse, bail, serveur DHCP ayant répondu

09Dépanner

Symptôme	Cause probable	Vérification
Le client a une adresse en `169.254.x.x`	Aucun serveur DHCP joint — APIPA	Câble, VLAN du port, service arrêté, relais manquant
Le client obtient une adresse du mauvais réseau	Un serveur DHCP pirate répond avant le bon	`ipconfig /all` → quelle adresse de serveur ?
Adresse OK, mais aucun accès Internet	`default-router` ou `dns-server` mal renseigné	`ipconfig /all`, puis `ping` de la passerelle
Conflit d'adresse IP	Une adresse statique n'a pas été exclue du pool	`show ip dhcp conflict`
Le pool est épuisé	Plage trop petite, ou baux trop longs	`show ip dhcp pool`
Rien ne fonctionne depuis un autre VLAN	`ip helper-address` absent	Vérifier la sous-interface côté client

❓ Auto-évaluation

Sur un réseau à trois VLAN, un seul serveur DHCP est installé dans le VLAN 100. Les postes du VLAN 100 obtiennent bien une adresse, ceux des VLAN 20 et 30 non. Pourquoi, et comment corriger ?

La cause : le DHCPDISCOVER est une diffusion, et un routeur ne relaie jamais les diffusions. Les demandes des VLAN 20 et 30 s'arrêtent donc au routeur : elles n'atteignent jamais le serveur.

Les postes du VLAN 100 fonctionnent parce qu'ils sont sur le même domaine de diffusion que le serveur.

La correction — deux volets :

Cisco IOS

! 1 — sur le routeur, côté CLIENT de chaque VLAN concerné
R1(config)# interface g0/0.20
R1(config-subif)# ip helper-address 192.168.100.10
R1(config-subif)# exit
R1(config)# interface g0/0.30
R1(config-subif)# ip helper-address 192.168.100.10

2 — sur le serveur, créer un pool par sous-réseau relayé. Le routeur insère son adresse d'interface dans la demande relayée : c'est ainsi que le serveur sait de quel VLAN vient le client et choisit le bon pool. Sans pool correspondant, il ne peut rien proposer, même si le relais fonctionne parfaitement.

Le piège : mettre ip helper-address sur l'interface côté serveur. C'est côté client qu'il faut la placer — là où arrivent les diffusions.

🌍 Le serveur DHCP pirate

N'importe qui branchant une box personnelle sur le réseau crée un second serveur DHCP. Comme le client retient la première offre reçue, une partie des postes reçoit alors une mauvaise adresse, une mauvaise passerelle — et perd le réseau.

C'est l'incident classique en TP, et la raison pour laquelle un serveur DHCP de test se monte toujours sur un réseau isolé. La parade en production s'appelle DHCP snooping : le commutateur n'accepte les réponses DHCP que sur les ports déclarés de confiance.