Avec la multiplication des réseaux, le nombre de machines à configurer augmente en permanence.
L'opération est longue, fastidieuse et propice aux erreurs. Le protocole DHCP sert à centraliser ce travail.


Par Erwan Barret
Illustrations : Dimitri Aumand
SVM Mac n° 138 - Avril 2002

Comment configurer toutes les machines d'une entreprise ou tous les abonnés d'un fournisseur d'accès en une fois et sans risque d'erreur ? Tout simplement en déléguant ce travail à un serveur DHCP (Dynamic Host Configuration Protocol). Chargé d'attribuer des adresses IP, il configure automatiquement les clients, pour peu qu'ils répondent eux aussi à ce protocole. Il leur attribue au moins une adresse IP et l'indispensable masque de sous-réseau, qui permet de faire la différence entre la partie de l'adresse IP qui désigne le réseau et celle qui caractérise la machine (voir SVM Mac n° 136 p. 118).

Mises à part ces informations minimales, un serveur DHCP est à même de fournir des renseignements très variés aux clients qui sont capables de les reconnaître. Si l'on trouve généralement l'adresse IP de la passerelle par défaut et des serveurs de noms de domaine (DNS), on peut voir apparaître aussi des données plus spécifiques. C'est le cas des adresses des serveurs WINS, utilisés avec les réseaux Windows, mais aussi des adresses des serveurs d'échange de mails (SMTP et POP3) ou encore des serveurs de groupes de discussion (NNTP), et même des serveurs de polices de caractères pour les postes exploitant le système d'interface X-Window. Extensible à volonté, la liste des paramètres que peut offrir un serveur DHCP est même appelée à s'allonger avec l'émergence des protocoles de communication.

La plupart des options s'appliquent à l'ensemble des clients DHCP, mais on peut aussi préciser celles qui concernent uniquement une ou des tranches d'adresses particulières. C'est une capacité très importante dans le cas des réseaux hétérogènes, où cohabitent, par exemple, des sous-réseaux de Macintosh et de PC. Quels que soient la plate-forme et l'environnement de travail, une machine peut donc s'insérer spontanément dans un réseau. L'avantage est évident pour les portables, mais il concerne aussi les postes fixes, dont l'administration se voit considérablement simplifiée.

Serveur spatio-temporel

DHCP attribue les adresses par tranches (on parle aussi d'étendues), qui sont des intervalles d'adresses IP définis au moment de la configuration du serveur. Chaque sous-réseau desservi comporte au moins une tranche et, le cas échéant, des adresses fixes. Une tranche est tout simplement caractérisée par ses adresses extrêmes (192.168.1.30 à 192.168.1.45, par exemple), appelées bornes.

Comme le principal intérêt de DHCP est la configuration automatique d'un grand nombre de machines, les adresses fixes ménagées sur le réseau sont traitées séparément. Il s'agit d'une simple liste où figurent les adresses qu'il faut exclure des tranches d'adresses configurées, à commencer par celle du serveur DHCP lui-même. Mais le serveur n'est pas le seul concerné par l'adressage fixe : l'adresse de certains nœuds du réseau se doit d'être fixe. C'est le cas des imprimantes, mais aussi des serveurs Web ou DNS. Tous doivent être systématiquement présents à la même adresse pour pouvoir être accessibles en permanence.

Au-delà de l'aspect spatial du réseau représenté par les tranches, DHCP travaille également en fonction du temps. Un serveur DHCP fonctionne comme un standard téléphonique : quand une ligne est libérée, celle-ci doit être remise à disposition, il en va de même pour une adresse IP. Sur chaque serveur DHCP, on fixe donc tranche par tranche la durée de validité (ou bail) des adresses IP. On peut configurer les dates de demande de renouvellement, envoyées généralement à la moitié, aux trois quarts et aux sept huitièmes du bail. Si la requête se révèle infructueuse, un autre paramètre indique le temps pendant lequel la machine concernée pourra diffuser des demandes pour trouver un autre serveur DHCP.

Lors d'une demande d'adresse IP, toutes les machines
sont interrogées pour savoir qui est serveur DHCP,
et tous les serveurs répondent. Après acceptation du
futur client, le premier serveur DHCP à avoir répondu
fait connaître au client les informations requises.

Attention aux erreurs !

Bien que très fiable, le protocole DHCP n'est pas complètement abouti. Certaines contraintes seront corrigées à terme, mais d'autres restent liées à la nature même du protocole. Ainsi, pas question de créer des hiérarchies de réseaux DHCP, où un serveur mère distribuerait des adresses et des plages à des serveurs enfants. Pour fonctionner, ce protocole a besoin de repères fiables, dont le plus important est l'adresse IP fixe du serveur. Autre écueil, si évident qu'on l'oublie facilement : toute erreur de configuration se répercute sur l'ensemble des postes clients. Il convient donc d'être particulièrement attentif lors de la configuration d'un réseau. Le problème le plus fréquent est le chevauchement d'adresses. Il déclenche l'ouverture d'une alerte qui mentionne qu'un autre poste emploie déjà la même adresse IP. Ce tracas peut survenir sur une machine configurée en DHCP comme sur n'importe quel poste d'un réseau à adresses fixes. La cause est généralement identique, à savoir une erreur de configuration. Avec un seul serveur DHCP bien configuré, le souci est éliminé. Mais avec plusieurs serveurs sur un réseau, on ne peut même pas recouper les tranches d'adresses pour assurer un relais en cas de défaillance. En effet, comme l'attribution des baux d'un serveur à l'autre est irréalisable, il est impossible pour un serveur de savoir si une adresse a été libérée par un autre serveur DHCP. On finit donc toujours par se heurter à des chevauchements d'adresses IP. Conséquence directe : pas moyen de compter sur un véritable serveur de secours, qui prendrait entièrement la main sur le même réseau.

En effet, les serveurs DHCP ne peuvent échanger des copies de leur fichier leases, où sont enregistrés les baux accordés. Le palliatif généralement préconisé consiste à attribuer un serveur DHCP à chaque sous-réseau, et à partager les étendues de chacun des sous-réseaux entre les serveurs. En cas d'avarie sur l'un d'entre eux, on peut ainsi récupérer au moins une partie du service sur chacun des sous-réseaux. De manière générale, il faut éviter le recoupement d'étendues DHCP, même au détriment de la continuité du service lorsqu'un serveur tombe en panne.

Serveurs sourds-muets

Dans l'état actuel du protocole, un serveur DHCP ne peut pas non plus tirer parti d'autres types de services, qui seraient pourtant très utiles. Ainsi, l'alimentation d'un serveur DHCP par un service de répertoire, LDAP ou NetInfo (voir SVM Mac n° 137) fiabiliserait considérablement le protocole DHCP, en réduisant son rôle au minimum. Après récupération d'une demande d'adresse, le serveur DHCP interrogerait simplement un serveur LDAP pour connaître les informations à communiquer au poste client. En remplaçant aussi le fichier des baux, le serveur LDAP résoudrait du même coup le problème de la sauvegarde, puisque LDAP permet la réplication de serveurs, ainsi que celui des chevauchements d'adresses.

Le principal défaut de DHCP reste l'absence de toute communication entre serveurs DHCP d'un même réseau. S'il était au moins possible de croiser la consultation des fichiers de configuration, on pourrait résoudre beaucoup de dysfonctionnements côté serveur avant même qu'ils se manifestent côté client. On pourrait même prévoir des parades automatiques à la plupart des pannes. Autre souci similaire : un serveur ne peut détecter les adresses IP déjà attribuées manuellement à des machines du réseau. Lorsqu'on définit les tranches DHCP, l'exclusion des machines déjà configurées est donc primordiale.

Un serveur DHCP peut fournir beaucoup
plus que des informations TCP/IP basiques.
Dans Directory Setup, on peut demander à
ce que l'adresse du serveur NetInfo soit
distribuée par le serveur DHCP.

Avec quel équipement ?

Encore dépourvu d'adresse IP, le nouveau client DHCP doit en demander une par diffusion. Sa requête ne peut aboutir que sur un réseau local, dont un envoi en broadcast ne peut franchir les limites. Seule solution pour étendre les possibilités de DHCP à des sous-réseaux : utiliser des serveurs appropriés, appelés relais DHCP, qui sont en mesure de faire suivre une diffusion depuis et vers des sous-réseaux. Il peut donc faire suivre les requêtes des clients et les réponses du serveur d'un sous-réseau à l'autre.

Installé d'office sur Mac OS X Server, le serveur DHCP est absent de la version cliente. En revanche, on peut ajouter à Mac OS X un serveur porté depuis Linux ou FreeBSD. Un serveur DHCP purement logiciel est plus souple que son équivalent embarqué sur un routeur, qui ne permet généralement que de définir une fourchette d'adresses IP, l'adresse de la passerelle, celle des serveurs DNS, et parfois le nom de domaine. Sur une machine complète, on peut accéder à la totalité des informations susceptibles d'êtres envoyées à un client DHCP.

Concrètement, le protocole DHCP est mis en œuvre sur des équipements qu'on ne retrouve pas encore auprès du grand public, mais de plus en plus dans les PME. C'est le cas des routeurs employés pour raccorder un réseau local à une liaison câble ou ADSL. Pour une petite structure, un routeur d'entrée de gamme est une solution de rechange très économique : au lieu d'installer un serveur dédié, on prend un simple boîtier, qui remplit le même rôle qu'un serveur DHCP, pour un prix beaucoup plus avantageux et avec une configuration réduite au strict minimum.

Compliquer pour simplifier

Comme son proche parent BootP, DHCP exploite le protocole UDP pour obtenir une adresse IP en quatre étapes. En premier lieu, un client DHCP, dépourvu à l'origine des informations nécessaires à son fonctionnement en réseau, lance une diffusion (broadcast) pour faire appel à un serveur DHCP. Le retour de ces informations vers la machine toujours dépourvue d'adresse passe par le même biais.

En réponse à une demande, le serveur DHCP diffuse sa propre adresse, ainsi que l'adresse IP qu'il propose au client et le masque de sous-réseau correspondant. S'il n'y a qu'un serveur sur le réseau, le client répond pour valider le choix de l'adresse IP proposée. S'il y en a plusieurs, le premier est généralement sélectionné, et les autres dont les adresses ne sont pas retenues sont prévenus par cette même réponse. Enfin, le serveur accuse réception en renvoyant définitivement adresse IP, masque de sous-réseau et informations annexes, le cas échéant.

Quatre étapes, cela peut sembler bien compliqué pour une simple communication entre un client et un serveur, mais c'est un problème lié à la nature même de TCP/IP. On sait que deux machines ne peuvent communiquer via TCP/IP que si elles sont sur le même réseau, c'est-à-dire qu'elles possèdent des adresses IP dont la partie réseau est identique, et les parties hôtes différentes. Si l'une des deux machines est dépourvue d'adresse IP, elle ne peut qu'envoyer et recevoir des diffusions, employées pendant toute la phase d'initialisation d'un client DHCP. Ce n'est qu'à l'issue de cette phase que le nouveau client DHCP peut se servir de son adresse IP toute neuve pour des communications point à point.

Pour limiter la casse en cas de panne, on peut répartir les
adresses affectées à des sous-réseaux distincts sur plusieurs machines,
afin d'assurer au moins une partie du service sur chacun des sous-réseaux.