DHCP, Comment votre machine obtient son IP

Votre VM affiche 169.254.x.x au lieu d'une vraie adresse IP ? C'est le signe que le DHCP n'a pas fonctionné. Ce module vous explique comment DHCP attribue automatiquement les adresses IP et comment diagnostiquer quand ça ne marche pas, une compétence indispensable quand vous déployez des VMs ou des conteneurs.

TL;DR, L'essentiel en 30 secondes

Un seul indice suffit pour trancher : regardez l'adresse. Si elle commence par 169.254, aucun serveur n'a répondu et le problème est en amont de la machine. Si elle est dans le bon sous-réseau, DHCP a fonctionné et la panne est ailleurs.

• DHCP = attribution automatique d'IP (vous n'avez rien à configurer)
• 169.254.x.x = DHCP a échoué (APIPA, auto-attribution sans serveur)
• DORA = Discover → Offer → Request → Acknowledge
• Si problème VM : vérifiez que le réseau est en mode "Bridge" ou "NAT" (pas "Host-only")

Je sais que c'est bon si...

DHCP ne fournit pas qu'une adresse. Une configuration réellement complète tient en trois vérifications, et c'est souvent la deuxième ou la troisième qui manque quand « le réseau marche à moitié » : une machine peut avoir une IP valide, répondre en local, et rester incapable de sortir faute de passerelle ou de DNS.

• ip addr affiche une IP dans le bon sous-réseau (pas 169.254.x.x)
• ip route montre une passerelle par défaut
• resolvectl status ou /etc/resolv.conf montre un serveur DNS

Commandes minimales à retenir

Ces trois commandes couvrent 90% des interventions : lire l'état, lire la route, forcer une nouvelle négociation. Retenez surtout la troisième, c'est la seule qui modifie quelque chose. Elle coupe brièvement la connectivité, donc évitez de la lancer depuis une session SSH sur la machine concernée.

# 1. Voir mon IP actuelle
ip addr show

# 2. Voir la passerelle
ip route | grep default

# 3. Forcer un renouvellement DHCP
sudo dhclient -v eth0   # remplacer eth0 par votre interface

Un mot sur dhclient avant d'aller plus loin : l'ISC DHCP dont il fait partie n'est plus maintenu depuis fin 2022, l'éditeur ayant arrêté le développement du client et du relais et renvoyant vers Kea côté serveur. Le binaire a donc disparu des installations par défaut de plusieurs distributions récentes. Si la commande renvoie command not found, votre machine est pilotée par systemd-networkd, NetworkManager ou dhcpcd. Les équivalents sont respectivement sudo networkctl renew ens3, sudo nmcli device reapply ens3 et sudo dhcpcd -n ens3.

VM qui ne reçoit pas d'IP ?

Vérifiez le mode réseau de votre VM :

• NAT : la VM partage l'IP de l'hôte (DHCP fourni par l'hyperviseur)
• Bridge : la VM a sa propre IP sur le réseau physique
• Host-only : réseau isolé, pas d'accès Internet

Si vous êtes en "Host-only", il n'y a probablement pas de serveur DHCP.

Prérequis

• Module 3 complété : vous comprenez les adresses IP et les masques
• Module 4 complété : vous savez ce qu'est une passerelle
• Module 5 complété : vous comprenez le rôle du DNS
• Une machine Linux connectée à un réseau avec DHCP

Quick check en 1 minute (si vous êtes en incident)

Si vous avez un problème DHCP maintenant, voici la séquence rapide :

# 1. Interface UP ?
ip link show

# 2. Quelle IP ? (169.254.x.x = problème)
ip addr show

# 3. Passerelle configurée ?
ip route show | grep default

# 4. DNS configuré ?
resolvectl status  # ou cat /etc/resolv.conf

# 5. Forcer un renouvellement DHCP (verbose)
sudo dhclient -v eth0  # remplacez eth0 par votre interface

# 6. Observer le trafic DHCP
sudo tcpdump -ni eth0 port 67 or port 68

Trouver le nom de votre interface

Sur les systèmes modernes, l'interface s'appelle souvent ens3, enp0s3, enp1s0 plutôt que eth0. Trouvez le bon nom avec :

ip -br link

Ce que vous allez apprendre

• Le problème que DHCP résout : configuration réseau automatique
• Le processus DORA : les 4 étapes de l'attribution d'IP
• Ce que DHCP fournit : IP, masque, passerelle, DNS
• Le bail DHCP : durée et renouvellement
• Les problèmes courants : 169.254.x.x, pas de DHCP, bail expiré
• Cas pratiques : VMs, conteneurs, cloud

Le problème que DHCP résout

Sans DHCP, vous devriez configurer manuellement chaque machine :

• Choisir une adresse IP non utilisée
• Saisir le masque de sous-réseau
• Configurer la passerelle par défaut
• Renseigner les serveurs DNS

Imaginez faire ça pour 100 machines. Ou pire : gérer les conflits quand deux machines ont la même IP.

DHCP (Dynamic Host Configuration Protocol) automatise tout ça. Un serveur DHCP, souvent votre box ou routeur, distribue les configurations réseau à la demande.

Sans DHCP	Avec DHCP
Configuration manuelle	Configuration automatique
Risque de conflits d'IP	IPs uniques garanties
Maintenance fastidieuse	Centralisée
Erreurs de saisie	Pas d'erreur humaine

Glissez pour voir

Où se trouve le serveur DHCP ?

Dans la plupart des réseaux :

• À la maison : votre box Internet (Freebox, Livebox, etc.)
• En entreprise : un serveur dédié ou le routeur
• Dans le cloud : l'hyperviseur (AWS, GCP, Azure)
• Avec Docker : le daemon Docker via son IPAM interne (pas du DHCP protocolaire, mais une allocation d'IP sur le subnet du réseau)

Le processus DORA : comment ça marche

L'attribution d'une adresse IP par DHCP se fait en 4 étapes. On les retient avec l'acronyme DORA : Discover, Offer, Request, Acknowledge.

1. Discover, Le client cherche un serveur

   Quand votre machine démarre sans IP, elle envoie un message broadcast (à tout le réseau) : "Y a-t-il un serveur DHCP ici ?"

   Ce message est envoyé depuis 0.0.0.0 (pas d'IP source) vers 255.255.255.255 (tout le monde).

2. Offer, Le serveur propose une IP

   Le serveur DHCP reçoit la demande et répond : "Voici une IP disponible : 192.168.1.50. Tu la veux ?"

   L'offre inclut aussi le masque, la passerelle et les DNS.

3. Request, Le client accepte

   Le client répond (toujours en broadcast, car il n'a pas encore d'IP) : "OK, je prends 192.168.1.50."

   Pourquoi en broadcast ? Pour informer les autres serveurs DHCP (s'il y en a plusieurs) que l'offre est acceptée.

4. Acknowledge, Le serveur confirme

   Le serveur valide : "C'est noté, 192.168.1.50 est à toi pour les 24 prochaines heures (le bail)."

   Le client peut maintenant utiliser cette configuration.

Tout se passe en UDP

DHCP utilise UDP sur les ports 67 (serveur) et 68 (client). Pourquoi UDP ? Parce que le client n'a pas encore d'IP, il ne peut pas établir de connexion TCP.

Ce que DHCP fournit

DHCP ne donne pas qu'une adresse IP. Il fournit une configuration réseau complète :

Élément	Rôle	Exemple
Adresse IP	Identifie la machine	192.168.1.50
Masque	Définit le réseau local	255.255.255.0
Passerelle	Route vers Internet	192.168.1.1
Serveurs DNS	Résolution de noms	192.168.1.1, 8.8.8.8

Glissez pour voir

Options supplémentaires (selon la configuration) :

• Durée du bail : combien de temps l'IP est réservée
• Serveur NTP : pour synchroniser l'heure
• Domaine de recherche : suffixe DNS ajouté aux noms courts

Options DHCP les plus courantes (à connaître)

Quand vous dépannez DHCP ou configurez un serveur, ces options reviennent souvent :

Option	Nom	Contenu	Utilité
3	Router	Adresse de la passerelle	Sortir du réseau local
6	DNS Servers	Liste des serveurs DNS	Résolution de noms
15	Domain Name	Domaine de recherche	Compléter les noms courts
51	Lease Time	Durée du bail en secondes	Contrôler la fréquence de renouvellement
54	Server Identifier	IP du serveur DHCP	Identifier qui a attribué l'IP
42	NTP Servers	Serveurs de temps	Synchronisation horaire

Glissez pour voir

Référence

La liste complète des options DHCP est définie dans la RFC 2132. En pratique, vous n'utiliserez que les 6 options ci-dessus dans 95% des cas.

Vérifier ce que DHCP vous a donné

Sur Linux, plusieurs commandes permettent de voir la configuration reçue :

# Voir votre IP et masque
ip addr show

# Voir votre passerelle
ip route show

# Voir vos serveurs DNS
cat /etc/resolv.conf
# ou sur systemd
resolvectl status

Le bail DHCP (lease)

L'adresse IP n'est pas donnée définitivement. Elle est louée pour une durée limitée : c'est le bail (lease).

Durée typique

La durée de bail est un arbitrage entre stabilité et rotation. Un bail long évite les renégociations et garde les adresses stables, mais immobilise une adresse longtemps après le départ de la machine. Un bail court libère vite le pool, au prix de bien plus de trafic DHCP. Les valeurs ci-dessous sont des ordres de grandeur constatés, pas des règles : ce sont surtout les contextes qu'il faut retenir, car ils expliquent le choix.

Contexte	Durée de bail
Réseau domestique	24 heures
Réseau d'entreprise	8 heures
Réseau public (café, hôtel)	1-2 heures
Cloud / VM	Variable (souvent 1 heure)

Glissez pour voir

Cycle de vie du bail

Le client n'attend pas l'expiration pour agir : il tente un renouvellement bien avant, à deux moments distincts. Le schéma se lit de gauche à droite comme une frise, chaque marque étant un pourcentage de la durée totale du bail. Ce découpage explique pourquoi une coupure du serveur DHCP passe souvent inaperçue : entre T1 et l'expiration, la machine garde son adresse et continue de fonctionner normalement.

Obtention    50%         87.5%       Expiration
    │         │           │              │
    ▼         ▼           ▼              ▼
[DORA] → [Renewal T1] → [Rebind T2] → [Bail expiré]

• T1 (50%) : le client essaie de renouveler avec le même serveur (unicast)
• T2 (87.5%) : le client essaie avec n'importe quel serveur DHCP (broadcast)
• Expiration : l'IP est libérée, retour à DORA

Ces pourcentages, 50% pour T1 et 87,5% pour T2, sont les valeurs recommandées par la RFC 2131 et la plupart des implémentations les appliquent telles quelles. Elles restent configurables côté serveur : ne concluez pas à un dysfonctionnement si vos captures montrent un renouvellement à un autre moment.

Bail expiré = plus de réseau

Si le bail expire et qu'aucun serveur DHCP ne répond, votre machine perd son IP. Selon l'OS et la configuration du gestionnaire réseau :

• Windows : bascule automatiquement en APIPA (169.254.x.x)
• Linux avec NetworkManager : peut activer l'IPv4 link-local si configuré
• Linux avec dhclient seul : reste souvent sans IP

C'est un problème courant sur les VMs quand le serveur DHCP est temporairement indisponible.

Forcer un renouvellement

La commande à taper dépend du gestionnaire réseau installé, pas de la distribution. Identifiez-le d'abord avec systemctl is-active NetworkManager systemd-networkd, puis choisissez l'onglet correspondant. Lancer dhclient sur une machine pilotée par NetworkManager crée deux clients concurrents sur la même interface, avec des résultats imprévisibles.

dhclient

# Libérer l'IP actuelle
sudo dhclient -r eth0

# Demander une nouvelle IP
sudo dhclient eth0

systemd-networkd

# Renouveler le bail
sudo networkctl renew eth0

# Reconfigurer complètement
sudo networkctl reconfigure eth0

NetworkManager

# Relancer la connexion
sudo nmcli connection down "Connexion filaire 1"
sudo nmcli connection up "Connexion filaire 1"

# Ou en une commande
sudo nmcli device reapply eth0

IP statique vs DHCP : quand choisir quoi ?

Le critère de décision n'est pas « serveur ou poste de travail » mais qui doit connaître l'adresse à l'avance. Dès qu'une autre machine, un enregistrement DNS ou une règle de pare-feu cite l'adresse en dur, elle doit être fixe. Dans tous les autres cas, DHCP évite une configuration à maintenir. La troisième ligne du tableau mérite votre attention : la réservation est presque toujours la bonne réponse, car elle fixe l'adresse côté serveur sans rien figer sur la machine.

Situation	Recommandation	Pourquoi
Poste de travail	DHCP	Flexibilité, pas de maintenance
Serveur en production	IP statique	Stabilité, DNS prévisible
Imprimante réseau	Réservation DHCP	IP fixe sans config manuelle
VM de test	DHCP	Création/destruction fréquentes
Conteneur	DHCP (géré par l'orchestrateur)	IP éphémères

Glissez pour voir

Réservation DHCP

La réservation DHCP combine les avantages des deux : le serveur DHCP attribue toujours la même IP à une machine donnée (basé sur son adresse MAC).

Résultat : IP prévisible sans configuration manuelle sur la machine.

Problèmes DHCP courants et diagnostic

L'adresse 169.254.x.x (APIPA)

Si votre machine affiche une IP en 169.254.x.x, c'est le signe que DHCP a échoué.

ip addr show eth0

Sortie problématique :

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP>
    inet 169.254.45.123/16 brd 169.254.255.255 scope link

APIPA (Automatic Private IP Addressing), aussi appelé IPv4 Link-Local (RFC 3927), est un mécanisme de secours. Selon l'OS et la configuration, la machine peut s'auto-attribuer une IP dans la plage 169.254.0.0/16 quand DHCP échoue.

Comportement variable selon l'OS

• Windows : active APIPA par défaut
• Linux : dépend de NetworkManager, systemd-networkd ou avahi, pas toujours activé par défaut
• macOS : active par défaut

Conséquences :

• Pas d'accès à Internet (pas de passerelle)
• Communication possible uniquement avec d'autres machines APIPA sur le même réseau physique

Diagnostic pas à pas

Suivez ces cinq étapes dans l'ordre : chacune élimine une couche, de la plus basse à la plus haute. Inutile d'analyser le trafic DHCP si l'interface est DOWN, et inutile de soupçonner le serveur si aucun client DHCP ne tourne sur la machine. L'étape 4 est celle qui tranche vraiment : elle montre si le problème vient du client (rien n'est émis) ou du réseau (les Discover partent, rien ne revient).

1. Vérifier l'état de l'interface

   ip link show eth0

   L'interface est-elle UP ? Le câble est-il branché ?

2. Vérifier si DHCP est actif

   # Voir les processus DHCP
   ps aux | grep -E "dhclient|dhcpcd|NetworkManager"

3. Relancer DHCP manuellement

   sudo dhclient -v eth0

   L'option -v (verbose) montre les étapes DORA en temps réel.

4. Vérifier si le serveur DHCP répond

   # Écouter le trafic DHCP (remplacez eth0 par votre interface)
   sudo tcpdump -ni eth0 port 67 or port 68

   Sortie attendue (DORA complet) :

   12:34:56 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from aa:bb:cc:dd:ee:ff, length 300
   12:34:56 IP 192.168.1.1.67 > 192.168.1.50.68: BOOTP/DHCP, Reply, length 300
   12:34:56 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from aa:bb:cc:dd:ee:ff, length 300
   12:34:56 IP 192.168.1.1.67 > 192.168.1.50.68: BOOTP/DHCP, Reply, length 300

   Diagnostic :

   Vous voyez	Signification	Action
   Discover sans Offer	Serveur DHCP injoignable	Vérifier serveur, câble, VLAN, relay
   Discover + Offer sans Request	Client ne répond pas	Vérifier client, pare-feu local
   DORA complet mais pas d'IP	Configuration client	Vérifier dhclient, NetworkManager
   Rien du tout	Interface down ou mauvais filtre	Vérifier ip link, nom interface

   Glissez pour voir

5. Vérifier la configuration obtenue

   # Fichier de bail (selon le client)
   cat /var/lib/dhcp/dhclient.eth0.leases
   # ou
   cat /var/lib/dhclient/dhclient.leases

Tableau de diagnostic rapide

Gardez ce tableau sous la main pendant un incident : il part du symptôme visible, celui que vous constatez sans outil, et non de la cause. Les deux dernières lignes sont les plus traîtresses, parce que la machine semble fonctionner : une adresse qui change ou un conflit ne se voient qu'au moment où une connexion tombe sans explication.

Symptôme	Cause probable	Solution
169.254.x.x	Pas de serveur DHCP	Vérifier le serveur, le câble, le VLAN
IP normale mais pas de gateway	DHCP partiel	Vérifier config serveur DHCP
IP qui change souvent	Bail court	Configurer une réservation
"No lease, failing"	Serveur down ou filtré	Vérifier connectivité au serveur
Conflit d'IP	IP statique sur une plage DHCP	Exclure les IP statiques de la plage

Glissez pour voir

DHCP et VLANs : le relais DHCP

En entreprise, vous rencontrerez souvent des VLANs (réseaux virtuels séparés). Problème : DHCP ne fonctionne pas directement entre VLANs.

Pourquoi un relais est nécessaire

Le blocage vient d'une propriété fondamentale du routage : un broadcast ne franchit pas un routeur. Il reste confiné au sous-réseau où il est émis. La séquence ci-dessous détaille l'impasse, étape par étape.

1. Le client DHCP envoie un broadcast (Discover)
2. Les routeurs ne relaient pas les broadcasts entre sous-réseaux par défaut
3. Le serveur DHCP sur un autre VLAN ne reçoit jamais la requête

Solution : configurer un relais DHCP (DHCP relay / ip helper-address) sur le routeur.

┌─────────────┐                    ┌─────────────┐                    ┌─────────────┐
│   Client    │  1. Discover       │   Routeur   │  2. Relais         │   Serveur   │
│  VLAN 20    │ ──────────────────►│   (relay)   │ ──────────────────►│    DHCP     │
│             │                    │             │                    │   VLAN 10   │
│             │◄──────────────────────────────────────────────────────│             │
└─────────────┘  4. Offer (via relay)              3. Offer            └─────────────┘

Le routeur transforme le broadcast en unicast vers le serveur DHCP, puis retourne la réponse au bon VLAN.

Configuration Cisco (exemple)

interface Vlan20
 ip address 192.168.20.1 255.255.255.0
 ip helper-address 192.168.10.100  # IP du serveur DHCP

Sans cette ligne, les machines du VLAN 20 n'obtiendront jamais d'IP. Référence : RFC 1542.

Sécurité DHCP (à connaître en production)

Même pour un module débutant/intermédiaire, vous devez connaître les risques DHCP en production :

Attaque	Description	Impact
Rogue DHCP	Serveur DHCP pirate sur le réseau	Clients redirigés vers une fausse passerelle (MITM)
DHCP Starvation	Épuisement du pool par requêtes massives	Plus d'IP disponibles, DoS
Spoofing	Usurpation d'identité via MAC forgé	Vol d'IP réservée

Glissez pour voir

Mesures de protection

La défense la plus efficace se joue sur le commutateur, pas sur les machines : c'est le seul équipement qui voit tout le trafic du segment. Le DHCP Snooping est la mesure de base, celle qui neutralise à elle seule le serveur pirate en refusant les réponses DHCP venant d'un port non déclaré. Les trois autres mesures la complètent et ne la remplacent pas.

• DHCP Snooping : le switch n'autorise que les serveurs DHCP légitimes (ports "trusted")
• Port Security : limite le nombre de MAC par port
• Segmentation : isoler les VLANs sensibles
• Logs centralisés : surveiller les attributions anormales

En environnement DevOps

Si vous déployez des VMs ou conteneurs en masse, un serveur DHCP mal dimensionné peut se faire "starver". Surveillez l'utilisation du pool et configurez des alertes.

Cas pratiques en contexte DevOps

VM cloud (AWS, GCP, Azure)

Dans le cloud, le DHCP est géré par l'hyperviseur. Chaque VM reçoit automatiquement :

• Une IP privée du subnet
• La passerelle du VPC
• Les serveurs DNS du cloud (ou les vôtres si configurés)

# Sur une VM AWS, vérifier la configuration
ip addr show
ip route show
cat /etc/resolv.conf

DHCP vs Metadata Service : deux rôles différents

Ne confondez pas :

• DHCP fournit la connectivité réseau (IP, routes, DNS), indispensable pour communiquer
• Le Metadata Service (169.254.169.254) fournit des infos d'instance (ID, région, rôle IAM, clés SSH, user-data), utilisé par les outils de provisioning

Le metadata service utilise une adresse link-local, mais ce n'est pas de l'APIPA. Référence : AWS IMDS.

Conteneurs Docker

Docker n'utilise pas DHCP au sens protocolaire. Il gère l'attribution d'IP via son IPAM interne (IP Address Management) sur les réseaux bridge :

# Créer un conteneur et voir son IP
docker run --rm alpine ip addr

# Voir la configuration du réseau bridge (dont l'IPAM)
docker network inspect bridge

Les conteneurs reçoivent souvent une IP dans la plage 172.17.0.0/16 par défaut, mais cette plage est configurable (daemon.json ou création de réseau custom).

DHCP pour conteneurs sur le LAN ?

Si vous voulez qu'un conteneur obtienne une IP du serveur DHCP de votre réseau physique (pas de l'IPAM Docker), utilisez le driver macvlan ou ipvlan avec un serveur DHCP externe.

Kubernetes

Dans la plupart des clusters Kubernetes, les pods reçoivent leur IP du CNI (Container Network Interface) via son propre IPAM, pas de DHCP. Le principe reste similaire : attribution automatique depuis un pool configuré.

# Voir l'IP d'un pod
kubectl get pod mon-pod -o wide

Cas particuliers

Certains environnements (notamment bare-metal ou réseaux secondaires avec Multus) peuvent utiliser une IPAM basée sur DHCP. Mais c'est l'exception, pas la règle. Référence : Kubernetes Networking.

Travaux pratiques

TP 1 : Observer votre configuration DHCP

Ce premier exercice ne modifie rien : il vous fait lire l'état actuel de votre machine. L'objectif est de savoir où se trouve chaque information, pour ne plus la chercher pendant un incident. Notez vos valeurs sur un papier, elles serviront de référence dans le TP 3.

1. Affichez votre configuration actuelle

   ip addr show
   ip route show
   cat /etc/resolv.conf

   Notez votre IP, masque, passerelle et DNS.

2. Vérifiez le bail DHCP

   # Chercher le fichier de bail
   find /var/lib -name "*lease*" 2>/dev/null
   cat /var/lib/dhcp/dhclient.*.leases

   Quelle est la durée du bail ?

3. Identifiez votre serveur DHCP

   Dans le fichier de bail, cherchez dhcp-server-identifier.

TP 2 : Simuler un renouvellement DHCP

Ici vous observez le protocole en direct. Le point important est l'ordre des opérations : tcpdump doit tourner avant de forcer le renouvellement, sinon vous manquerez les paquets. Prévoyez deux terminaux, et travaillez depuis une console locale plutôt qu'une session SSH sur la machine testée.

1. Lancez tcpdump pour observer

   sudo tcpdump -i eth0 port 67 or port 68 -n

2. Dans un autre terminal, forcez un renouvellement

   sudo dhclient -r eth0 && sudo dhclient -v eth0

3. Observez les 4 étapes DORA

   Vous devriez voir :

   • DHCP Discover (votre machine)
   • DHCP Offer (le serveur)
   • DHCP Request (votre machine)
   • DHCP ACK (le serveur)

TP 3 : Simuler une panne DHCP

Ce dernier exercice reproduit volontairement la panne que vous rencontrerez en production : une machine sans adresse. Il vous fait constater le comportement réel de votre système, qui n'est pas le même partout : certaines configurations basculent en 169.254.x.x, d'autres restent simplement sans adresse IPv4. Ne le lancez pas sur une machine distante, vous perdriez l'accès.

1. Libérez votre IP

   sudo dhclient -r eth0

2. Vérifiez que vous n'avez plus d'IP

   ip addr show eth0

   L'interface devrait n'avoir qu'une adresse IPv6 link-local.

3. Attendez quelques secondes

   Sans intervention, la machine peut passer en APIPA ou rester sans IP.

4. Récupérez une IP

   sudo dhclient eth0

À retenir

• DHCP automatise la configuration réseau (IP, masque, gateway, DNS)
• DORA : Discover → Offer → Request → Acknowledge (4 étapes UDP)
• 169.254.x.x = APIPA = pas de serveur DHCP trouvé
• Bail : l'IP est louée pour une durée limitée (souvent 24h)
• dhclient -v eth0 : force un renouvellement et montre le processus
• Réservation DHCP : IP fixe sans config manuelle sur la machine
• VMs/conteneurs : DHCP géré par l'hyperviseur ou l'orchestrateur

Testez vos connaissances

Les questions portent sur le raisonnement de diagnostic plutôt que sur la mémorisation des numéros d'options : que signifie une adresse en 169.254, à quel moment le client relance une négociation, ce que le relais change dans un réseau segmenté.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

10 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

FAQ : questions fréquentes sur le DHCP

Les questions rassemblées ici reviennent régulièrement en formation et recoupent les cas non traités dans le corps du module : cohabitation de plusieurs serveurs, DHCP en IPv6, comportement des baux après un redémarrage.

Qu'est-ce que le DHCP ?

Le DHCP (Dynamic Host Configuration Protocol) attribue automatiquement une configuration réseau aux machines : adresse IP, masque, passerelle par défaut et serveurs DNS. Sans lui, il faudrait configurer chaque machine à la main. Le serveur DHCP écoute sur le port 67/UDP, le client sur le 68/UDP.

Qu'est-ce que le processus DORA ?

DORA décrit les 4 étapes d'attribution d'une IP : Discover (le client diffuse une demande en broadcast), Offer (un serveur propose une IP), Request (le client la demande), Acknowledge (le serveur confirme le bail). Le Discover est en broadcast car le client n'a pas encore d'IP.

Combien de temps dure un bail DHCP ?

La durée d'un bail (lease) est configurée sur le serveur, souvent de quelques heures à quelques jours. Le client tente de renouveler son bail à 50% de sa durée (T1), puis à 87,5% (T2) s'il n'a pas eu de réponse. Côté Linux, les baux sont stockés dans /var/lib/dhcp/ pour dhclient.

Quel serveur DHCP utiliser en 2026 ?

Le serveur historique ISC dhcpd (isc-dhcp-server) est en fin de vie : l'ISC recommande de migrer vers Kea DHCP, son successeur moderne. Pour un homelab, dnsmasq est très répandu car il fournit DHCP et DNS en un seul outil léger.

Qu'est-ce qu'un rogue DHCP et comment s'en protéger ?

Un rogue DHCP est un serveur DHCP pirate ou mal branché qui distribue de fausses configurations, par exemple une passerelle malveillante pour intercepter le trafic. On s'en protège avec le DHCP snooping sur les switches managés, qui n'autorise les réponses DHCP que depuis les ports de confiance.

Prochaines étapes

Module 8 : Pare-feu Comprendre le filtrage réseau avec iptables et nftables

Module 6 : DNS Revoir la résolution de noms fournie par DHCP

Retour au parcours Vue d'ensemble de la formation réseau

×

📖 Voir la documentation →