Accueil/Réseaux & Systèmes /Chapitre 11 /Exercices corrigés

DHCP — exercices

La mission BioVision en entier, la configuration Cisco, et les pannes qu'on rencontre vraiment.

🎯

Le réflexe de diagnostic

Devant un problème DHCP, la première commande est toujours ipconfig /all ou ip a sur le client. L'adresse obtenue dit déjà presque tout : une 169.254.x.x signifie « aucun serveur joint », une adresse du mauvais réseau signifie « un autre serveur a répondu ».

01Statique, réservation ou pool

1Six équipements à adresser Facile

Pour chaque équipement, choisissez : adresse statique, réservation DHCP ou pool dynamique. Justifiez.

Le routeur de sortie du réseau
Un serveur de fichiers
Le portable d'un commercial
Une imprimante partagée
Un smartphone sur le Wi-Fi visiteurs
Une caméra IP de vidéosurveillance

✅ Correction

Équipement	Choix	Justification
1 — Routeur	Statique	C'est lui la passerelle annoncée par DHCP. Il ne peut pas dépendre du service qu'il fournit
2 — Serveur de fichiers	Réservation	Adresse fixe indispensable, mais gestion centralisée. Statique acceptable si aucun DHCP n'est fiable
3 — Portable commercial	Pool dynamique	Se déplace, se connecte partout : l'adresse fixe n'a aucun sens
4 — Imprimante	Réservation	Les pilotes des postes pointent vers son adresse : elle ne doit pas changer
5 — Smartphone visiteur	Pool dynamique	Éphémère par nature, avec un bail court
6 — Caméra IP	Réservation	L'enregistreur l'interroge à une adresse précise

🧰 La règle en une phrase

Si quelqu'un doit joindre l'équipement à son initiative, il lui faut une adresse fixe. Un serveur, une imprimante, une caméra sont contactés ; un portable ne fait que contacter.

Et entre statique et réservation, préférez toujours la réservation : même résultat, mais tout se modifie depuis le serveur. Seule exception : les équipements qui fournissent le DHCP, qui ne peuvent en dépendre.

02Le dialogue DORA

2Qui parle, à qui, et comment Moyen

Nommez les 4 messages dans l'ordre, en précisant l'émetteur et le type (diffusion / unicast).
Quelle adresse IP source porte le tout premier message, et pourquoi ?
Pourquoi le REQUEST est-il émis en diffusion alors que le client connaît déjà le serveur ?
Sur quels ports UDP travaille DHCP ?
Que se passe-t-il à 50 % de la durée du bail ?

✅ Correction

#	Message	Émetteur	Type
1	DISCOVER	Client	Diffusion
2	OFFER	Serveur	Unicast (ou diffusion)
3	REQUEST	Client	Diffusion
4	ACK	Serveur	Unicast

2. L'adresse source est 0.0.0.0 et la destination 255.255.255.255. Le client n'a aucune adresse — c'est précisément ce qu'il vient chercher. Il ne peut donc que crier à la cantonade.

3. Pour prévenir les autres serveurs DHCP que leur offre est déclinée, afin qu'ils libèrent l'adresse qu'ils avaient mise de côté. Le REQUEST porte l'identité du serveur retenu.

4. UDP 67 côté serveur, UDP 68 côté client.

5. À T1 = 50 %, le client tente de renouveler son bail directement auprès du serveur qui le lui a accordé, en unicast. À T2 = 87,5 %, faute de réponse, il repasse en diffusion. À 100 %, il abandonne l'adresse et recommence un DORA complet.

🌍 Pourquoi renouveler à la moitié du bail

Pour laisser de la marge. Si le serveur est momentanément indisponible, le client a encore la moitié de son bail pour réessayer avant de perdre son adresse. Un renouvellement à 95 % ne laisserait aucune chance en cas de panne brève — et tout le réseau tomberait en même temps.

03Configurer un routeur

3Un pool pour le LAN Moyen

Sur R1, configurez un serveur DHCP pour le réseau 192.168.10.0/24 :

la passerelle est 192.168.10.1 ;
les adresses .1 à .20 sont réservées aux serveurs et équipements ;
le pool distribue de .21 à .200 ;
DNS 192.168.10.5 et 8.8.8.8, domaine entreprise.local ;
bail de 3 jours.

✅ Correction

Cisco IOS — R1

! ─── 1. EXCLURE, en configuration globale, AVANT le pool ───
R1(config)# ip dhcp excluded-address 192.168.10.1 192.168.10.20
R1(config)# ip dhcp excluded-address 192.168.10.201 192.168.10.254

! ─── 2 à 5. Le pool ───
R1(config)# ip dhcp pool LAN-ENTREPRISE
R1(dhcp-config)# network 192.168.10.0 255.255.255.0
R1(dhcp-config)# default-router 192.168.10.1
R1(dhcp-config)# dns-server 192.168.10.5 8.8.8.8
R1(dhcp-config)# domain-name entreprise.local
R1(dhcp-config)# lease 3                        ← 3 jours
R1(dhcp-config)# end

R1# copy running-config startup-config

⚠️ Les deux plages d'exclusion

Beaucoup n'excluent que .1 à .20. Mais la commande network 192.168.10.0 255.255.255.0 met tout le /24 dans le pool : sans la seconde exclusion, le routeur distribuerait aussi .201 à .254, contrairement à l'énoncé.

Le raisonnement à tenir : network définit le sous-réseau entier ; c'est par soustraction que l'on obtient la plage voulue.

🧰 Vérifier

Cisco IOS

show ip dhcp pool           utilisation, adresses restantes
show ip dhcp binding        qui a quoi, avec quelle MAC
show ip dhcp conflict       les conflits détectés
clear ip dhcp binding *     tout libérer (utile en TP)

04Mission BioVision

4Serveur ISC sous Debian 12 Exigeant

Contexte : le Directeur Technique de BioVision exige un serveur DHCP ISC sous Debian 12 pour le pôle Bureau d'étude pharmaceutique (192.168.20.0/24).

Étendue dynamique : 192.168.20.100 à 192.168.20.200 ;
réservations MAC obligatoires pour 3 stations critiques de simulation moléculaire : .10, .11, .12 ;
le serveur lui-même en 192.168.20.2/24, passerelle 192.168.20.1.

Déroulez les six étapes, avec les fichiers de configuration complets.

✅ Correction

bash — étapes 1 à 3

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

# 2 — installer
dpkg -l isc-dhcp-server        # vérifier
apt install isc-dhcp-server -y

# 3 — adresse fixe sur le serveur
ip a                           # relever le nom 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

# 4 — configurer le DHCP, APRÈS avoir sauvegardé
cp /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.conf.old
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 — étape 6

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

# tester la SYNTAXE avant de redémarrer
dhcpd -t -cf /etc/dhcp/dhcpd.conf

systemctl restart isc-dhcp-server
systemctl status isc-dhcp-server       # doit afficher « active (running) »
journalctl -u isc-dhcp-server -f       # suivre les attributions
cat /var/lib/dhcp/dhcpd.leases         # les baux accordés

⚠️ Les cinq points qui font échouer ce TP

Le point-virgule à la fin de chaque ligne. C'est la première cause de « le service refuse de démarrer ».
Les blocs host en dehors du subnet — l'énoncé l'exige explicitement. À l'intérieur, la réservation ne fonctionne pas.
L'interface non déclarée dans /etc/default/isc-dhcp-server : le service démarre mais n'écoute nulle part.
Le serveur pas en adresse fixe. Un serveur DHCP qui obtiendrait son adresse par DHCP est une absurdité — et un prérequis explicite de la mission.
Un autre serveur DHCP actif sur le réseau : les deux répondent et les clients obtiennent n'importe quoi. Le prérequis le dit.

🧰 Comment récupérer les adresses MAC des stations

bash

# sur la station Linux
ip link show enp0s3            # ligne « link/ether »

# sur la station Windows
ipconfig /all                  # « Adresse physique »
getmac /v

# depuis le serveur, si la station a déjà obtenu un bail
cat /var/lib/dhcp/dhcpd.leases | grep -A5 "lease 192.168.20"

L'énoncé le rappelle : « avant de faire ces manipulations, il faut récupérer à partir de la machine cliente son adresse MAC ». Une réservation avec une MAC erronée ne produit aucune erreur — la station reçoit simplement une adresse du pool, et on cherche longtemps.

🌍 authoritative, la ligne qu'on ne comprend pas

Elle déclare que ce serveur fait autorité sur les réseaux qu'il gère. Concrètement, il pourra répondre DHCPNAK — « cette adresse n'est pas valide ici » — à un client qui arrive avec un bail obtenu ailleurs, par exemple un portable revenant de chez lui.

Sans cette ligne, le serveur reste silencieux dans ce cas, et le client garde une adresse inutilisable jusqu'à l'expiration de son bail.

05Relais multi-VLAN

5Un serveur pour trois VLAN Exigeant

Un réseau comporte trois VLAN : 10 (192.168.10.0/24), 20 (192.168.20.0/24) et 100 (192.168.100.0/24). Le serveur DHCP est en 192.168.100.10, dans le VLAN 100. Le routage inter-VLAN fonctionne en router-on-a-stick sur R1.

Les postes des VLAN 10 et 20 n'obtiennent aucune adresse. Pourquoi ?
Quelle configuration ajouter sur R1 ?
Que faut-il configurer en plus sur le serveur ?
Comment le serveur sait-il de quel VLAN vient une demande relayée ?

✅ Correction

1. Le DHCPDISCOVER est une diffusion, et un routeur ne relaie jamais les diffusions. Les demandes des VLAN 10 et 20 s'arrêtent sur R1. Seul le VLAN 100 fonctionne, parce qu'il partage le domaine de diffusion du serveur.

2. Sur R1, côté client de chaque VLAN :

Cisco IOS — R1

R1(config)# interface g0/0.10
R1(config-subif)# ip helper-address 192.168.100.10
R1(config-subif)# exit

R1(config)# interface g0/0.20
R1(config-subif)# ip helper-address 192.168.100.10
R1(config-subif)# end

Rien à faire sur g0/0.100 : le serveur y est déjà.

3. Sur le serveur, il faut un pool par sous-réseau relayé :

/etc/dhcp/dhcpd.conf

subnet 192.168.10.0 netmask 255.255.255.0 {
    range 192.168.10.100 192.168.10.200;
    option routers 192.168.10.1;
}
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;
}
subnet 192.168.100.0 netmask 255.255.255.0 {
    range 192.168.100.100 192.168.100.200;
    option routers 192.168.100.1;
}

4. Le routeur insère sa propre adresse d'interface dans le champ giaddr (gateway IP address) de la demande relayée. Le serveur lit ce champ, constate qu'il vaut 192.168.10.1, en déduit que le client est dans le réseau 192.168.10.0/24 et choisit le pool correspondant.

🧰 Ce que fait vraiment ip helper-address

Elle ne « débloque » pas les diffusions. Elle transforme la diffusion en un message unicast à destination du serveur, en y ajoutant l'adresse de l'interface d'arrivée.

Le serveur reçoit donc un message parfaitement routable, contenant l'information dont il a besoin pour choisir le bon pool. La réponse fait le chemin inverse par le routeur, qui la rediffuse sur le bon segment.

⚠️ Les deux erreurs de placement

Mettre ip helper-address côté serveur — inutile : il n'y a aucune diffusion à convertir de ce côté.
Oublier un pool sur le serveur — le relais fonctionne parfaitement, le serveur reçoit bien la demande, mais n'ayant aucun pool pour ce sous-réseau, il ne répond rien. Le symptôme est identique à « le relais ne marche pas », ce qui envoie chercher au mauvais endroit.

06Dépannage

6Cinq symptômes Moyen

Un poste affiche 169.254.87.12.
Un poste obtient 192.168.1.50 alors que le réseau est en 192.168.20.0/24.
Le poste a une adresse correcte mais n'accède à aucun site web ; le ping vers 8.8.8.8 fonctionne.
Deux machines affichent un conflit d'adresse IP.
Les nouveaux postes n'obtiennent plus rien depuis ce matin, les anciens fonctionnent.

✅ Correction

#	Diagnostic	Cause et correction
1	APIPA — aucun serveur joint	Câble, port dans le mauvais VLAN, service DHCP arrêté, ou `ip helper-address` manquant
2	Serveur DHCP pirate	Une box personnelle ou un routeur mal configuré répond avant le bon serveur. `ipconfig /all` révèle l'adresse du serveur fautif
3	DNS	Le ping IP passe mais pas la résolution de noms : `dns-server` est absent ou erroné dans le pool
4	Exclusion manquante	Une adresse attribuée statiquement n'a pas été exclue du pool. Corriger avec `ip dhcp excluded-address`
5	Pool épuisé	Toutes les adresses sont louées. Élargir la plage, ou raccourcir la durée du bail

🧰 Retrouver un serveur DHCP pirate

diagnostic

# 1 — depuis le poste victime, identifier le coupable
ipconfig /all
    Serveur DHCP . . . . . : 192.168.1.254     ← ce n'est pas le nôtre

# 2 — retrouver sa MAC
arp -a 192.168.1.254

# 3 — localiser le port sur le commutateur
SW# show mac address-table address 00e0.4c68.1a2b

En production, la prévention s'appelle DHCP snooping : le commutateur n'accepte les réponses DHCP que sur les ports déclarés « de confiance », et bloque toutes les autres.

⚠️ Le cas n° 3 est le plus instructif

ping 8.8.8.8 réussit mais aucun site ne s'ouvre : la couche 3 fonctionne parfaitement. Le problème est forcément le DNS.

Ce test — pinguer une IP puis un nom — isole le DNS en dix secondes, et il est valable bien au-delà du DHCP. C'est le même raisonnement qu'au chapitre 06 avec le serveur Windows.