Infrastructure réseau

Distribuer dynamiquement des adresses IP

Automatisez la configuration des machines clientes avec un serveur DHCP. Distribuez les configurations IP aux différents VLAN via un relais DHCP et consolidez le réseau avec un second serveur assurant la tolérance de panne.

Je comprends le protocole DHCP

Un parc qui ne tient plus sur un carnet d'adresses

DKTOYS distribue des jouets depuis son site de Dunkerque et vient d'ouvrir une succursale à Reims. Le réseau du siège compte désormais plusieurs VLAN : commercial, administration, entrepôt/production, serveurs et supervision. Attribuer une adresse IP à la main à chaque poste, imprimante ou borne Wi-Fi de cet ensemble, comme on pouvait encore le faire sur un petit atelier, devient intenable dès que le parc dépasse quelques dizaines de machines. Le protocole DHCP (Dynamic Host Configuration Protocol) répond à ce besoin : il attribue automatiquement à chaque poste qui se branche une adresse IP valide, ainsi que les paramètres nécessaires pour communiquer sur le réseau.

Ce chapitre pose les bases du protocole avant d'aborder, dans les deux chapitres suivants, sa mise en œuvre avancée chez DKTOYS : un second serveur en tolérance de panne, puis un relais pour desservir les VLAN distants d'un serveur DHCP central.

Le processus DORA

Un poste qui vient d'obtenir une adresse par DHCP (via un câble Ethernet ou une association Wi-Fi) ne connaît encore aucune adresse IP, y compris celle d'un éventuel serveur DHCP. Il commence donc par une diffusion (broadcast) sur son segment local. L'échange complet se déroule en quatre messages, retenus sous l'acronyme DORA :

ÉtapeMessageÉmetteur → destinataireRôle
1DHCPDISCOVERClient → diffusion (255.255.255.255)Le client cherche un serveur DHCP disponible sur le segment
2OFFERServeur → diffusion ou unicastLe serveur propose une adresse libre de son étendue, avec les options réseau
3REQUESTClient → diffusionLe client confirme l'offre choisie (utile s'il reçoit plusieurs offres de serveurs différents)
4ACKServeur → clientLe serveur confirme l'attribution et verrouille l'adresse pour la durée du bail

Le client diffuse sa demande en REQUEST plutôt que de répondre directement en unicast au serveur qui l'a offerte : cela permet aux autres serveurs DHCP éventuellement présents sur le même segment de voir que leur offre n'a pas été retenue et de libérer l'adresse qu'ils avaient réservée pour ce client.

Le bail et son cycle de vie

Une adresse distribuée par DHCP n'est jamais attribuée définitivement : elle est prêtée pour une durée déterminée, le bail (lease), au terme de laquelle le client doit la renouveler ou la restituer.

InstantNomComportement du client
50 % de la durée du bail (T1)RenouvellementLe client redemande directement au serveur qui la lui a attribuée (unicast) de prolonger le bail
87,5 % de la durée du bail (T2)RebindingSi le premier serveur ne répond pas, le client diffuse sa demande de renouvellement à tout serveur DHCP disponible
100 % de la durée du bailExpirationLe client abandonne l'adresse et reprend un cycle DORA complet

Cette mécanique explique pourquoi un poste débranché puis rebranché rapidement récupère souvent la même adresse (le bail n'a pas expiré et le serveur la lui réattribue), alors qu'un poste resté hors ligne plus longtemps obtient parfois une adresse différente si la première a été réattribuée entre-temps.

Les options DHCP transmises avec l'adresse

Une adresse IP seule ne suffit pas à faire fonctionner un poste : le serveur DHCP transmet en même temps un ensemble d'options, identifiées par un code, qui complètent la configuration réseau.

Option DHCPCodeContenu
Masque de sous-réseau001Masque associé à l'adresse attribuée
Routeur003Adresse de la passerelle par défaut
Serveurs DNS006Adresse(s) du ou des serveurs DNS
Nom de domaine015Suffixe DNS ajouté automatiquement
Durée du bail051Durée de validité de l'adresse, en secondes

Sur le réseau DKTOYS, chaque VLAN correspond à une étendue DHCP distincte, avec sa propre plage d'adresses, sa propre passerelle (l'interface du routeur ou du commutateur de niveau 3 qui dessert ce VLAN) et donc ses propres options 003 et 006, même si le serveur DHCP qui répond est unique.

Exclusions et réservations au sein d'une étendue

Une étendue DHCP ne distribue pas nécessairement la totalité de la plage d'adresses du sous-réseau. Deux mécanismes affinent cette distribution :

MécanismeRôleExemple chez DKTOYS
ExclusionRetire une sous-plage de la distribution, pour des équipements déjà en IP fixeLes adresses des commutateurs et du routeur de chaque VLAN, exclues de l'étendue correspondante
RéservationAttribue toujours la même adresse à un équipement identifié par son adresse MAC, tout en restant gérée par DHCPUne imprimante réseau de l'entrepôt, pour que son adresse ne change jamais malgré une gestion centralisée

La réservation combine les avantages des deux mondes : l'équipement conserve une adresse stable comme en IP fixe, mais celle-ci reste visible et modifiable depuis la console DHCP, sans intervention directe sur l'équipement lui-même.

Quand préférer une adresse statique à une adresse dynamique

Tous les équipements du réseau DKTOYS ne relèvent pas du DHCP de la même façon :

Type d'équipementMode d'adressage recommandéRaison
Poste de travail, terminal mobileDynamique (DHCP, sans réservation)Rotation fréquente du parc, aucune nécessité d'adresse stable
Imprimante, poste de supervisionDynamique avec réservationAdresse stable nécessaire, mais gestion centralisée préférable à une saisie manuelle sur chaque poste
Serveur (DHCP, DNS, applicatif), interface de routeur ou de commutateurStatique (IP fixe configurée localement)Ces équipements doivent rester joignables même si le service DHCP est interrompu ; un serveur DHCP ne peut par ailleurs pas dépendre de lui-même pour sa propre adresse

Cette répartition explique pourquoi, chez DKTOYS, les VLAN comportent systématiquement une petite plage d'adresses exclue en haut ou en bas de leur plan d'adressage, réservée aux équipements actifs et aux serveurs en IP fixe.

Quand une demande est refusée : le message DHCPNAK

L'échange DORA ne se termine pas toujours par un ACK. Un serveur peut répondre par un DHCPNAK (negative acknowledgment) lorsqu'un client redemande explicitement une adresse qui n'est plus valide pour lui — par exemple un poste qui a changé de VLAN (donc de sous-réseau) entre deux redémarrages, et qui tente de renouveler une adresse devenue incohérente avec le réseau sur lequel il se trouve désormais. Le client reçoit alors ce refus, abandonne l'adresse mémorisée et relance un cycle DORA complet depuis le début. Ce mécanisme protège l'intégrité du plan d'adressage : sans lui, un poste déplacé d'un VLAN à un autre pourrait continuer à utiliser une adresse appartenant à son ancien sous-réseau, rendant tout routage vers lui impossible.

Les autres messages du protocole

Au-delà des quatre messages DORA et du DHCPNAK, trois autres messages complètent le protocole et interviennent dans des situations plus ponctuelles :

MessageÉmetteurRôle
DHCPDECLINEClientLe client refuse l'adresse offerte, généralement parce qu'un test local (une requête ARP) révèle qu'elle est déjà utilisée par un autre poste sur le réseau
DHCPRELEASEClientLe client restitue volontairement son adresse avant l'expiration du bail, par exemple à l'extinction propre d'un poste
DHCPINFORMClientUn poste déjà configuré en IP fixe demande uniquement les options complémentaires (DNS, domaine…) sans demander d'adresse

Le DHCPDECLINE illustre un principe de prudence intégré au protocole : même après avoir reçu une offre du serveur, un client vérifie localement qu'aucun autre poste ne répond déjà sur cette adresse avant de l'accepter définitivement, ce qui limite (sans l'éliminer totalement) le risque de conflit d'adresses sur le réseau DKTOYS.

Le problème posé par plusieurs VLAN et un seul serveur

Le message DHCPDISCOVER du client est une diffusion, par nature limitée au segment local : elle ne franchit pas la frontière d'un VLAN. Or DKTOYS ne dispose que d'un serveur DHCP central, hébergé sur le VLAN Serveurs, distinct du VLAN Commercial, du VLAN Administration ou du VLAN Entrepôt où se trouvent les postes clients. Sans intervention, un poste du VLAN Commercial ne verrait donc jamais l'offre du serveur central : sa diffusion resterait cantonnée à son propre VLAN.

Deux réponses complémentaires seront apportées à ce constat dans la suite du cours :

  • un relais DHCP configuré sur chaque interface de VLAN du routeur ou du commutateur de niveau 3, qui capte les diffusions locales et les retransmet en unicast au serveur central (chapitre suivant : « Je mets en œuvre un relais DHCP ») ;
  • un second serveur DHCP, configuré en tolérance de panne avec le premier, pour que le service continue à fonctionner même si l'un des deux serveurs tombe (chapitre suivant : « Je configure un serveur DHCP en mode équilibrage de charge et tolérance de panne »).

Vocabulaire à maîtriser avant la suite du cours

Les deux chapitres suivants réutilisent sans les redéfinir plusieurs termes posés ici :

TermeDéfinition rapide
Étendue (scope)La plage d'adresses qu'un serveur DHCP peut distribuer pour un sous-réseau donné
Bail (lease)La durée pendant laquelle une adresse reste attribuée à un client avant renouvellement obligatoire
Relais (relay agent)L'équipement de couche 3 qui convertit une diffusion DHCP locale en requête unicast vers un serveur distant
giaddrLe champ qui identifie, dans une requête relayée, l'interface du relais à l'origine de la diffusion captée

Ce qu'il faut retenir

Le protocole DHCP automatise l'attribution d'une adresse IP et de ses paramètres associés (masque, passerelle, DNS) via un échange en quatre temps, DORA, puis maintient cette attribution par un système de bail renouvelé périodiquement (T1, T2) ou repris en cas d'expiration. Reposant sur des diffusions locales, il ne franchit pas nativement les frontières d'un VLAN : c'est le point de départ des deux chapitres suivants, qui montrent comment DKTOYS assure à la fois la disponibilité du service (tolérance de panne) et sa portée sur l'ensemble des VLAN du site (relais DHCP).

Note de production : aucun support dédié au protocole DHCP n'a été localisé dans les supports du dépôt pour ce chapitre ; le contenu s'appuie sur le cadrage pédagogique du module (data_module_3_maintenance_evolution_securisation.md) et sur la définition standard du protocole (RFC 2131).