1 – Définition du protocole DHCP

DHCP signifie Dynamic Host Configuration Protocol. Il s’agit d’un protocole qui permet à un ordinateur
qui se connecte sur un réseau local d’obtenir dynamiquement et automatiquement sa configuration IP.
Le but principal étant la simplification de l’administration d’un réseau. On voit généralement le
protocole DHCP comme distribuant des adresses IP, mais il a été conçu au départ comme complément
au protocole BOOTP (Bootstrap Protocol) qui est utilisé par exemple lorsque l’on installe une machine à
travers un réseau (on peut effectivement installer complètement un ordinateur, et c’est beaucoup plus
rapide que de le faire en à la main). Cette dernière possibilité est très intéressante pour la
maintenance de gros parcs machines. Les versions actuelles des serveurs DHCP fonctionne
pour IPv4 (adresses IP sur 4 octets). Une spécification pour IPv6 (adresses IP sur 16 octets) est en
cours de développement par l’IETF.

2 – Références à DHCP
Les incontournables RFCs :

 RFC951 : Bootp

 RFC1497 : Options vendor extensions

 RFC1541 : Définition du protocole Dhcp

 RFC1542 : Interaction entre Bootp et Dhcp

 RFC2131 : Complément à la Rfc 1541

 RFC2132 : Complément aux options vendor extensions

3 – Fonctionnement
DHCP fonctionne sur le modèle client-serveur : un serveur, qui détient la politique d’attribution des
configurations IP, envoie une configuration donnée pour une durée donnée à un client donné
(typiquement, une machine qui vient de démarrer). Le serveur va servir de base pour toutes les
requêtes DHCP (il les reçoit et y répond), aussi doit-il avoir une configuration IP fixe. Dans un réseau,
on peut donc n’avoir qu’une seule machine avec adresse IP fixe : le serveur DHCP. Le protocole DHCP
s’appuie entièrement sur BOOTP : il en reprend le mécanisme de base (ordre des requêtes, mais aussi
le format des messages). DHCP est une extension de BOOTP.

Quand une machine vient de démarrer, elle n’a pas de configuration réseau (même pas de
configuration par défaut), et pourtant, elle doit arriver à émettre un message sur le réseau pour qu’on
lui donne une vraie configuration. La technique utilisée est le broadcast : pour trouver et dialoguer
avec un serveur DHCP, la machine va simplement émettre un paquet spécial, dit de broadcast, sur
l’adresse IP 255.255.255.255 et sur le réseau local. Ce paquet particulier va être reçu par toutes les
machines connectées au réseau (particularité du broadcast). Lorsque le serveur DHCP reçoit ce paquet,
il répond par un autre paquet de broadcast contenant toutes les informations requises pour la
configuration. Si le client accepte la configuration, il renvoit un paquet pour informer le serveur qu’il
garde les paramètres, sinon, il fait une nouvelle demande.
Les choses se passent de la même façon si le client a déjà une adresse IP (négociation et validation de
la configuration), sauf que le dialogue ne s’établit plus avec du broadcast.

4 – Les baux
Pour des raisons d’optimisation des ressources réseau, les adresses IP sont délivrées pour une durée
limitée. C’est ce qu’on appelle un bail (lease en anglais). Un client qui voit son bail arriver à terme peut
demander au serveur un renouvellement du bail. De même, lorsque le serveur verra un bail arrivé à
terme, il émettra un paquet pour demander au client s’il veut prolonger son bail. Si le serveur ne reçoit
pas de réponse valide, il rend disponible l’adresse IP. C’est toute la subtilité du DHCP  : on peut
optimiser l’attribution des adresses IP en jouant sur la durée des baux. Le problème est là  : si toutes
les adresses sont allouées et si aucune n’est libérée au bout d’un certain temps, plus aucune requête
ne pourra être satisfaite.

Sur un réseau où beaucoup d’ordinateurs se connectent et se déconnectent souvent (réseau d’école ou

de locaux commerciaux par exemple), il est intéressant de proposer des baux de courte durée. A
l’inverse, sur un réseau constitué en majorité de machines fixes, très peu souvent rebootées, des baux
de longues durées suffisent. N’oubliez pas que le DHCP marche principalement par broadcast, et que
cela peut bloquer de la bande passante sur des petits réseaux fortement sollicités.

5 – Dynamique ou pas ?
Un serveur DHCP est censé fournir des adresses dynamiques (un même ordinateur peut recevoir
successivement 2 adresses différentes), mais il peut fournir une adresse IP fixe à un client bien
particulier. Ceci ne doit être utilisé que de manière modérée, sinon, le serveur DHCP ne sert à peu près
plus à rien, mais cela peut se révéler utile pour fournir l’adresse IP au serveur TFTP qui va servir pour
le boot à distance des machines.

6 – Les requêtes et les messages DHCP

On pourrait croire qu’un seul aller-retour peut suffire à la bonne marche du protocole. En fait, il existe
plusieurs messages DHCP qui permettent de compléter une configuration, la renouveler… Ces
messages sont susceptibles d’être émis soit par le client pour le ou les serveurs, soit par le serveur
vers un client :
La valeur entre parenthèses est utilisées pour identifier ces requêtes dans les messages DHCP. Voir
les options DHCP.

La première requête émise par le client est un message DHCPDISCOVER. Le serveur répond par un
DHCPOFFER, en particulier pour soumettre une adresse IP au client. Le client établit sa configuration,
demande éventuellement d’autres paramètres, puis fait un DHCPREQUEST pour valider son adresse IP.
Le serveur répond simplement par un DHCPACK avec l’adresse IP pour confirmation de l’attribution.
Normalement, c’est suffisant pour qu’un client obtienne une configuration réseau efficace, mais cela
peut être plus ou moins long selon que le client accepte ou non l’adresse IP ou demande des infos
complémentaires…

Pour demander une nouvelle adresse, le chronogramme-type est le suivant :

Pour renouveler une adresse, le fonctionnement est le suivant (les 2 serveurs connaissent le client) :
7 – Les messages DHCP

7.1 – Dialogue avec le serveur

Les messages DHCP sont transmises via UDP. Bien que peu fiable, ce protocole suffit au transport des
paquets simples sur réseau local, et surtout il est très léger, donc intéressant pour les petits systèmes
(du genre le micro bout de programme qui fait la requête DHCP lorsque le PC se met en route). De
facto, DHCP fonctionne aussi en mode non connecté. Le client n’utilise que le port 68 pour envoyer et
recevoir ses messages  de la même façon, le serveur envoie et reçoit ses messages sur un seul port, le
port 67.

7.2 – Format de la trame BOOTP/DHCP

La trame DHCP est en fait la même que BOOTP, et a le format suivant (les chiffres entre parenthèses
indique la taille du champ en octets) :
  op : vaut 1 pour BOOTREQUEST (requête client), 2 pour BOOTREPLY (réponse serveur)

 htype : type de l’adresse hardware (adresse MAC, par exemple. Voir Rfc 1340)

 hlen : longueur de l’adresse hardware (en octet). C’est 6 pour une adresse MAC

 hops : peut être utilisé par des relais DHCP

 xid : nombre aléatoire choisi par le client et qui est utilisé pour reconnaître le client

 secs : le temps écoulé (en secondes) depuis que le client a commencé sa requête

 flags : flags divers

 ciaddr : adresse IP du client, lorsqu’il en a déjà une

 yiaddr : la (future ?) adresse IP du client

 siaddr : adresse IP du (prochain) serveur à utiliser

 giaddr : adresse IP du relais (passerelle par exemple) lorsque la connexion directe

client/serveur n’est pas possible
 chaddr : adresse hardware du client

 sname : champ optionnel. Nom du serveur

 file : nom du fichier à utiliser pour le boot

 options : Champs réservé pour les options (voir Rfc 2132). Dans une précédente RFC, la taille
de ce champ était limitée (limité à 64 octets par exemple pour la première version de
Bootp) ; maintenant, il n’y a plus de limitation. Dans tous les cas, un client DHCP doit être
prêt à recevoir au minimum 576 octets, mais la possibilité lui est offerte de demander au
serveur de restreindre la taille de ses messages.

7.3 – Passage d’options

Le passage de paramètres (nom de la machine…) se fait par l’intermédiaires d’options. Les options
sont documentées dans la RFC 2132. Elles portent toutes un numéro qui les identifie. Par exemple,
l’option 15 est celle qui permet de donner au client le nom de domaine du réseau. Il est bien entendu
possible d’envoyer plusieurs options dans le même message DHCP ; dans tous les cas, que l’on ne
transmette qu’une seule option utile ou plusieurs, on doit toujours finir la zone d’options par une
option 255 (end). Le format des options est le suivant :

Le numéro de l’option n’est codé que sur 1 octet, donc il ne peut y avoir que 256 options possibles.
L’octet 2 code la longueur du champ de données qui suit. Il ne tient donc pas compte des 2 octets de
code d’option et de longueur.

Certaines options ne comportent pas de données complémentaires, comme l’option 255. Dans ce cas,
il n’y a ni champ de longueur ni champ de données. Les messages DHCP vus dans le chapitre
précédent (DHCPACK…) sont tout simplement une option ! Il s’agit de l’option 53 qui comporte un
champ de données de longueur 1 contenant le numéro identifiant la requête (1 pour
DHCPDISCOVER…). Les 4 premiers octets du champ d’options doivent être initialisés respectivement
avec les valeurs 99, 130, 83 et 99 (valeurs en décimal). Cette séquence est appelée le «  magic
cookie » (gateau magique en français).

Le client DHCP a la possibilité d’imposer au serveur DHCP une taille maxi pour le champ d’options
(option 57). La conséquence d’une telle limitation est que le serveur peut manquer de place pour
envoyer toutes les options souhaitées. Pour répondre à ce problème, le serveur est autorisé à utiliser
les champs sname et file pour finir son envoi. Le client est averti de cet usage par un option 52 dans la
zone d’options.

8 – Le serveur DHCP

8.1 – Où trouver un serveur DHCP ?

L’Internet Software Consortium développe un serveur DHCP pour le monde du logiciel libre. C’est le
serveur DHCP le plus répandu, et celui qui « suit » au mieux les Rfcs. La dernière version en date est
la 3.0 et elle est encore en version bêta. Les versions antérieures marchent toutefois très bien, bien
que l’ISC sortent beaucoup de patchs. L’une des principales innovations de la version 3 est la
possibilité de mettre à jour un DNS dynamiquement en fonction des adresses IP fournies par le serveur
DHCP. Pour information, le première draft sur le DNS dynamique date de mars 1996… Microsoft a bien
entendu son propre serveur DHCP pour Windows. Seule la version pour Windows 2000 Server permet
de mettre à jour les DNS dynamiquement avec DHCP. Le reste de cette section traite de l’installation
et de la configuration d’un serveur DHCP sous système Unix. L’exemple pris est celui d’un serveur
fourni par l’ISC.

8.2 – Compilation du serveur

La première étape de la réalisation d’un serveur DHCP est bien entendu sa compilation. Allez sur le site
de l’ISC et téléchargez une version d’un serveur DHCP ou téléchargez simplement ma version qui, bien
que vieille, prend en charge la mise a jour de DNS. Copier le fichier dans un répertoire.
Décompressez l’archive : tar xzf dhcp-dhcp-2.0b1pl6.tar.gz

Déplacez-vous dans le répertoire (commande cd), et tapez : ./configure

Cela va générer les fichiers Makefile correspondant à votre système. Tapez ensuite make pour compiler
le serveur et enfin make install pour installer le serveur.

Avant de faire le ./configure, il est hautement recommandé de lire le fichier README qui explique
comment installer correctement le serveur. Par exemple, pour ma version, tapez ./configure –with-
nsupdate pour compiler le serveur avec le support Dynamic DNS update. make install copiera les
fichiers perl dans le répertoire /usr/local/DHCP-DNS-0.52mdn.

8.3 – Le fichier dhcpd.conf

Ce fichier est la base de la configuration du serveur. Par défaut, il se trouve dans le répertoire /etc/,
mais vous pouvez le mettre n’importe où. il est composé de plusieurs sections, chacune limitée par des
accolades { et } :

 des paramètres globaux qui s’appliquent à tout le fichier,

 shared-network,

 subnet,

 host,

 group.

Chaque section peut contenir des paramètres et des options. Une section group peut contenir des
sections host. Au début du fichier, on peut placer des paramètres globaux, comme par exemple la
durée des baux, les adresses des DNS… Chaque ligne du fichier de configuration doit se terminer par
un ;, sauf lorsqu’il y a une accolade. Les commentaires sont possibles en ajoutant un # en début de
ligne.

8.3.1 – Les paramètres globaux

Ils peuvent être un peu tout et n’importe quoi, pourvu qu’ils aient une signification applicable à toutes
les déclarations du fichier. Par exemple, on peut redéfinir la durée des baux (max-lease-time et
default-lease-time), empêcher le serveur de répondre à des requêtes venant d’hôtes non déclarés
(deny unknown-clients;), indiquer le nom de domaine que les machines doivent utiliser, les serveurs
DNS…

8.3.2 – shared-network

Ce paramètre est utilisé pour regrouper plusieurs zones subnet lorsque ceux-ci concerne le même
réseau physique. Les paramètres rentrés en début de zone seront utilisés pour le boot des clients
provenant des sous-réseaux déclarés, à moins de spécifier pour certains hôtes de ne pas booter (zone
host). Son utilisation se rapproche de celle de host ; il faut toutefois l’utiliser systématiquement que le
réseau est divisé en différents sous-réseaux administrés par le serveur DHCP. Syntaxe :

shared-network FOO-BAR

    {
    filename "boot";

    subnet 192.168.2.0 netmask 255.255.255.224

        {

        range 192.168.2.10 192.168.2.30;

        }

    subnet 192.168.2.32 netmask 255.255.255.224

        {

        range 192.168.2.40 192.168.2.50;

        }

    }

8.3.3 – subnet

subnet permet de définir les sous-réseaux sur lesquels le serveur DHCP doit intervenir. C’est la partie
la plus importante du fichier de configuration du serveur DHCP ; sans ça, votre serveur ne marchera
jamais.

La syntaxe exacte pour cette zone est comme suit :

subnet numero_sous-reseau netmask netmask

    {

    [ paramètres globaux... ]

    [ déclarations... ]

    }

numero_sous-reseau et netmask sont donnés sous format adresse IP pointées. Un exemple se trouve
juste au dessus, dans la partie décrivant la zone shared-network.

On peut bien entendu commencer la zone par des paramètres globaux qui ne seront appliqués que
pour les ordinateurs de ce sous-réseau. Par exemple, le nom de domaine à appliquer sur ce sous-
réseau (option domain-name). Ensuite, on peut ajouter des déclarations d’hôtes. Le paramètre global
indispensable est :

range [ dynamic-bootp ] adresse_inferieure [ adresse_superieure ] qui définit la zone d’adresses IP

(limitée par adresse_inferieure et adresse_superieure) que le DHCP peut distribuer. Plusieurs range
peuvent se suivre. On peut ne pas spécifier d’adresse supérieure, cela revient à ne considérer qu’une
seule adresse IP distribuable (celle indiquée, bien sûr). dynamic-bootp doit être mis pour indiquer que
le DHCP doit répondre aux requêtes BOOTP en donnant une adresse de cette plage.

8.3.4 – host
Ce mot permet de déclarer des machines que le DHCP doit connaître et leur appliquer une
configuration particulière. Vous n’êtes pas obligé d’utiliser cette zone, mais elle est par exemple
indispensable lorsque vous avez déclaré deny unknown-clients; en début de fichier pour empêcher le
serveur DHCP de répondre à des requêtes provenant d’hôtes non déclarés.

host est utilisé de la façon suivante :

host nom

    {

    paramètres...

    }

Un hôte peut être reconnu de deux façons : en utilisant son nom (le nom qui suit le mot clé host) ou
en utilisant son adresse hardware (ethernet ou token-ring). Dans ce dernier cas, il faut ajouter une
ligne dans la déclaration host : hardware ethernet|token-ring adresse-hardware;. Il est fortement
recommandé d’authentifier les ordinateurs à partir de leur adresse hardware plutôt que leur nom,
surtout qu’il sont supposés ne pas posséder de véritable nom Internet et que l’on peut redéfinir ce
nom.

Un point important : c’est dans une déclaration host que l’on décide d’attribuer une adresse fixe ou
non à un hôte. Il suffit alors d’utiliser une ligne comme celle-ci : fixed-address 192.168.2.4;.
ATTENTION ! Toute adresse IP attribuée de manière fixe ne doit pas faire partie des zones d’adresses
IP déclarées avec range… (zone subnet).

8.3.5 – group

Cette zone est simplement utilisée pour rassembler plusieurs déclarations (de toute sorte, y compris
d’autres déclarations group) pour leur appliquer des différents paramètres. Exemple :

group

    {

    option domain-name "bar.org";

    option routers 192.168.1.254;

    host foo1

        {

        ...

        }

    host foo2

        {

        ...
        }

  }

8.3.6 – Les options

Les paramètres qui doivent commencer avec option sont les options définies dans la  RFC 2132. Il y en
a environ 60 définies dans la RFC, mais le serveur peut en gérer jusqu’à 254 (les options 0 et 255 sont
réservées). Pour trouver les options possibles et leur nom, vous pouvez consulter le fichier
common/tables.c des sources du serveur. ATTENTION ! les noms des options peut varier d’une version
de serveur à une autre.

Le format des valeurs des options est donné dans ce même fichier au début («  format codes: »). Les
options plus utiles sont les suivantes :

 subnet-mask (option 1) qui indique le masque de sous-réseau pour la configuration IP,

 routers (option 3) qui indique les routeurs à utiliser,

 domain-name-servers (option 6) qui indique les DNS à utiliser. On peut aussi bien donner le
nom que l’adresse IP (!)
 host-name (option 12) qui indique au client quel nom d’hôte il doit prendre,

 domain-name (option 15) qui fournit au client le nom du domaine arpa dans lequel il se trouve,

 broadcast-address (option 28) qui indique l’adresse de broadcast en vigueur sur le réseau,

 dhcp-lease-time (option 51) qui indique au client la durée de validité du bail.

 D’autres options (60 en particulier) permettent de personnaliser les messages DHCP circulant
sur le réseau.

8.3.7 – Exemple de fichier dhcpd.conf

 max-lease-time 240;

 default-lease-time 240;

 deny unknown-clients;

 option domain-name « bar.com »;

 option domain-name-servers foo1.bar.com, foo2.bar.com;

subnet 192.168.1.0 netmask 255.255.255.0

    {

    range 192.168.1.2 192.168.1.100;

    range 192.168.1.110 192.168.1.254;

    option broadcast-address 192.168.1.255;

    }

group
    {

    option routers 192.168.2.101;

    host foo3

        {

        hardware ethernet 00:c0:c3:11:90:23;

        option host-name pc3;

        }

    host foo4

        {

        hardware ethernet 00:c0:c3:cc:0a:8f;

        fixed-address 192.168.1.105;

        }

    }

host foo5

    {

    hardware ethernet 00:c0:c3:2a:34:f5;

    server-name "bootp.bar.com";

    filename "boot";

    }

Explications :

Les cinq premières lignes définissent les paramètres globaux. Les 2 premiers concernent les baux
(leases). La ligne suivante dit au serveur de ne pas répondre aux requêtes DHCP venant d’hôtes qu’il
ne connaît pas (i.e. non définis dans dhcpd.conf). On définit enfin les paramètres du domaine du
réseau (nom de domaine et serveurs DNS).

On définit ensuite le sous-réseau sur lequel le serveur DHCP est censé intervenir : c’est la ligne
« subnet… ». Dans ce sous-réseau, on dit au serveur de ne fournir des adresses IP que dans les plages
d’adresses définies par les lignes « range… ». la dernière ligne de la section définit l’adresse de
broadcast à utiliser sur le sous-réseau.

On crée ensuite un groupe dont le but est uniquement de fournir des adresses de passerelles à des
machines bien déterminées (par leur adresse MAC). On remarque que foo4.bar.com obtiendra une
adresse IP fixe.
foo5, enfin, sera une machine qui bootera à travers le réseau, en se connectant au serveur TFTP
bootp.bar.com, et booter avec le fichier boot.

8.4 – Lancer le démon dhcpd

Pour lancer le serveur, il faut d’abord être root sur le système. Il suffit ensuite de taper la commande
suivante :

dhcpd -lf fichier_de_leases -cf fichier_de_config adpateur1 adapteur2…

le serveur DHCP va alors se lancer sur les adaptateurs réseau adapteur1, adapteur2…, en trouvant sa
configuration dans le fichier fichier_de_config et en utilisant le fichier fichier_de_leases pour stocker
ses baux. Sans tous les arguments, le serveur DHCP va aller chercher ses fichiers dans des
emplacements déterminés au moment de la compilation, dans le fichier includes/dhcpd.h et utiliser
eth0 comme interface par défaut. Vous pouvez bien entendu modifier tout ça.

8.5 – Exécuter le démon à chaque démarrage (pour Linux)

Pour lancer le démon au démarrage de votre machine, il faut d’abord placer un script shell de
lancement du démon dans le répertoire /etc/rc.d/init.d/. Ce script va en fait gérer le démarrage et
l’arrêt de dhcpd. Ce fichier n’est hélas par fourni avec les archives de l’ISC. Vous pouvez le créer vous
même en vous inspirant des autres scripts figurant dans le répertoire ou simplement reprendre:

# Source networking configuration.

. /etc/sysconfig/network

# Check that networking is up.

[ ${NETWORKING} = "no" ] && exit 0

[ -f /usr/sbin/dhcpd ] || exit 0

[ -f /etc/dhcpd.conf ] || exit 0

[ -f /var/dhcpd/dhcpd.leases ] || touch /var/dhcpd/dhcpd.leases

# See how we were called.

case "$1" in

start)

# Start daemons.

echo -n "Starting dhcpd: "

daemon /usr/sbin/dhcpd -lf /var/dhcpd/dhcpd.leases -cf /etc/dhcpd.conf eth0

touch /var/lock/subsys/dhcpd

;;
stop)

# Stop daemons.

echo -n "Shutting down dhcpd: "

killproc dhcpd

echo

rm -f /var/lock/subsys/dhcpd

;;

restart)

$0 stop

$0 start

;;

status)

status dhcpd

;;

*)

echo "Usage: dhcpd {start|stop|restart|status}"

exit 1

esac

exit 0

Faites un chmod 755 dhcpd pour mettre les bons droits.

Il faut maintenant dire à GNU/Linux d’exécuter ce script au démarrage. Cela se fait en créant des liens
symboliques dans les répertoires /etc/rc.d/rcx.d/ avec x un entier correspondant au runlevel auquel le
démon doit être lancé. Faites simplement chkconfig –add dhcpd, cela va créer les liens symboliques
pour vous.

Vous pouvez maintenant redémarrer votre ordinateur, le serveur DHCP sera lancé automatiquement.

ATTENTION ! Il se peut que linuxconf prenne le contrôle du serveur DHCP. Si vous voulez garder
indéprendante la gestion de votre serveur DHCP (comme c’est par exemple le cas pour moi car j’ai
modifié la script /etc/rc.d/init.d/dhcpd), désactivez la prise en charge de dhcpd dans linuxconf.

8.6 – Documentation
La commande make install a dû installer sur votre système les manuels du serveur. Pour y accéder,
tapez simplement :

 man dhcpd pour connaître le fonctionnement du démon dhcpd,

  man dhcpd.conf pour savoir comment écrire et configurer le fichier dhcpd.conf,

 man dhcpd.leases pour avoir des informations sur les baux du serveur DHCP.

Cette doc n’est toutefois ni très simple ni complète. Les options ne sont par exemple pas détaillées. La
meilleure documentation est finalement de loin la RFC qui pour une fois a la bonne idée d’être claire et
concise.

9 – Configuration des clients

Vous devez aller dans la configuration TCP/IP, enlever tout ce qu’il y a concernant l’IP, le masque de
sous réseau, DNS, passerelle et juste dire que vous voulez une configuration dynamique (DHCP).
Relancez vos services réseaux, la méthode la plus simple et la plus bestiale étant le «  reboot », et
voilà. Une fois le système remonté, vous devez avoir hérité d’une configuration automatique.

9.1 – Tout pour contrôler, réparer etc

Dans cette partie nous verrons, suivant le système employé,

 Windows 95/98

 Windows NT4/2000/Xp

 Linux (Mandrake 9)

quels sont les outils pour contrôler l’état du client DHCP. Je demande aux utilisateurs de  Be/OS, de
MAC/OS et de tous ceux que j’oublie, de bien vouloir m’excuser de ne pas leur apporter mon soutien.
J’ai déjà dans mon petit bureau (4 M 2) trois PC dont un sur lequel sont installés trois systèmes, je n’ai
plus de place…

9.2 – Windows 95/98

9.2.1 – Configuration

Par le panneau de configuration, icône « réseau », cliquez sur « TCP/IP -> <votre carte réseau>.
L’adresse IP doit être configurée dynamiquement, c’est d’ailleurs le choix par défaut à l’installation.

9.2.2 – Vérification

Si vous avez un bail en cours de validité, la commande « winipcfg » vous affiche les choses suivantes:
ATTENTION! Windows 95 et 98 installent également le client PPP dont nous n’avons rien à faire… Ce
client apparaît également dans la liste des interfaces réseau.
Vérifiez bien que vous pointez sur votre carte Ethernet et pas sur le client PPP…

Si vous cliquez sur le bouton « Plus d’info>> »:

Ici, c’est le bouton « Renouveler » qui sera votre seul secours en cas de problèmes. Notez que les
rubriques « Bail obtenu » et « Expiration du bail » contiennent des valeurs calculées par votre
machine. Le serveur DHCP ne donne que la durée.
9.3 – Windows NT4/2000/XP
9.3.1 – Configuration

La configuration se fait dans le panneau de configuration, icône « réseau », onglet « protocoles », puis
« propriétés » de TCP/IP. Là, vous avez indiqué que la carte doit recevoir une adresse IP
dynamiquement.

9.3.2 – Vérification

Tapez dans une console, la commande « ipconfig »

Votre adresse doit être affichée. Si vous voulez tous les détails, utilisez la commande « ipconfig /all »:

La commande « ipconfig » permet également:

 De résilier le bail: « ipconfig /release »

  De renouveler le bail: « ipconfig /renew »

C’est cette commande qui est à utiliser pour essayer de récupérer une adresse IP lorsque vous avez
des problèmes.

Notes.

 Les rubriques « Bail obtenu » et « Expiration du bail » contiennent des valeurs calculées par
votre machine. Le serveur DHCP ne donne que la durée.
 La commande en mode graphique « winipcfg » n’existe pas nativement sous Windows NT  mais
vous pouvez la récupérer dans le kit de ressources techniques (téléchargeable sur le site MS
en cherchant bien :-). N’essayez pas d’utiliser celle de Windows 95/98, les dll winsock32
utilisées ici ne sont pas compatibles.

9.4 – Linux
9.4.1 – Configuration

Avec cet OS c’est beaucoup plus compliqué, parce qu’il y a beaucoup plus de configurations possibles.
La configuration utilisée dans l’exposé est  la suivante:

 Un portable Compaq équipé d’une carte réseau D-LINK PCMCIA

 MANDRAKE 8.2

 Eth0  et configurée avec  DHClient.

Notez que DHClient n’est pas le seul client possible. Vous pouvez parfaitement le remplacer par PUMP,
DHCPXD ou par DHCPCD. Tous ces clients sont disponibles dans la distribution Mandrake, qui installe
d’ailleurs DHCPCD par défaut, et non pas celui que j’utilise.

 DHCPCD semble avoir la préférence du distributeur. Je n’ai jamais rencontré de problèmes

avec, mais je ne l’utilise normalement pas pour la raison suivante: Son paramétrage ne se
fait que par la ligne de commande, ce qui oblige à aller modifier des scripts pas toujours
faciles à trouver si l’on veut par exemple utiliser son propre DNS à la place de celui proposé
dans le bail.
 PUMP Fonctionne également sans problèmes, il dispose d’un fichier de configuration
/etc/pump.conf dans le quel on peut par exemple spécifier très simplement que l’on ne veut
pas modifier le paramétrage du DNS avec l’information récupérée par DHCP. (Le ou les DNS
sont inscrits dans le fichier /etc/resolv.conf).
 Je n’ai pas vraiment étudié DHCPXD qui fonctionne lui aussi sans difficultés. Il dispose d’un
répertoire /etc/dhcpxd dans lequel vous trouverez quelques fichiers qui vous donneront
toutes les indications sur le bail en cours.

DHCLIENT a ma préférence. Il est écrit par ISC (les auteurs de BIND le fameux DNS et DHCPD lque
nous utilisons ici, c’est dire qu’ils savent de quoi ils parlent :). Ce client cumule à mon sens tous les
avantages:
  Un fichier de configuration /etc/dhclient.conf, sans doute encore plus performant que celui de
PUMP. Notez que ce fichier n’existe pas dans la distribution Mandrake, il vous faudra
éventuellement le créer si vous ne voulez pas vous contenter du fonctionnement par défaut.
 Des scripts optionnels exécutés automatiquement avant l’obtention du bail et après l’obtention
du bail, avec à disposition des variables contenant toutes les informations recueillies par le
client auprès du serveur. Très pratique par exemple pour vous envoyer par mail l’adresse
courante de votre machine si celle-ci change; dans le cas par exemple où vous avez besoin
de vous y connecter à distance par telnet ou ssh.
 Il tient un historique des baux obtenus dans le fichier /var/lib/dhcp/dhclient.leases

Son seul inconvénient est sa richesse. Il n’est pas le plus facile à mettre en oeuvre.

9.4.2 – Vérifiez l’état de votre connexion

Dans /etc/sysconfig/network-scripts, il y a un fichier intitulé : ifcfg-eth0. Il doit contenir au moins ces

lignes :

DEVICE="eth0"

BOOTPROTO="dhcp"

IPADDR=""

NETMASK=""

ONBOOT="yes"

C’est assez parlant pour ne pas nécessiter d’explications particulières.

La commande « ifconfig eth0 » devrait vous donner quelque chose comme ceci :

Si rien n’apparaît, c’est que votre interface n’est pas activée. Essayez alors ifup eth0 :
Cette commande affiche l’état de Eth0, mais elle ne donne pas toutes les informations que l’on obtient
sous Windows avec winipcfg ou ipconfig. Si vous voulez tout savoir, il faut aller dans le répertoire
« /var/lib/dhcp » et regarder le fichier dhclient.leases. Celui-ci contient l’historique des dialogues
DHCP :

lease

    {

    interface "eth0";

    fixed-address 192.168.0.8;

    option subnet-mask 255.255.255.0;

    option routers 192.168.0.253;

    option dhcp-lease-time 3600;

    option dhcp-message-type 5;

    option domain-name-servers 192.168.0.253;

    option dhcp-server-identifier 192.168.0.253;

    option domain-name "maison.mrs";

    renew 2 2002/12/10 08:49:42;

    rebind 2 2002/12/10 09:14:05;

    expire 2 2002/12/10 09:21:35;

    }

Notez que ce fichier peut être beaucoup plus long. Cherchez dedans le dernier bail obtenu. Constatez
que vous avez bien la trace de toutes les informations que notre serveur DHCP est capable d’envoyer à
ses clients.

9.4.3 – Particularités du client DHClient

Grâce aux informations conservées dans ce fichier dhclient.leases, ce client adopte un comportement
un peu particulier, que l’on ne retrouve pas dans celui de Microsoft, par exemple.

Lorsqu’un hôte a obtenu un premier bail de la part du DHCP, l’adresse du serveur DHCP est conservée
et, même après extinction et redémarrage de l’hôte au bout d’un temps bien supérieur à la durée de
son bail, le client commencera par envoyer directement un DHCP request au serveur qu’il connaît.
Cette particularité peut dérouter lorsque l’on espionne les dialogues DHCP sur le réseau.

10 – Savoir « Sniffer »
Un « sniffer » n’est pas un outil pour se « shooter », mais pour analyser les données qui se trimbalent
sur le réseau. C’est un outil d’administrateur, qui est capable du meilleur comme du pire. Si vous
voulez jouer avec, il en existe un tout à fait convenable et gratuit, aussi bien en version Linux que
Windows, c’est Ethereal. Il nécessite l’installation de la librairie libpcap, disponible elle aussi sous Linux
comme sous Windows.

Nous allons juste ici analyser une capture de trames correspondant au dialogue DHCP, et constater
que, lorsque ça va bien, ça se passe comme c’est dit dans les livres, ce qui est un peu réconfortant.

La manipulation est faite avec un client sous Windows XP.

10.1 – Entêtes de trames

1 – Notre client se réveille, il n’a pas d’IP et utilise 0.0.0.0 pour faire un « broadcast général
(255.255.255.255) ». C’est le DHCP Discover. 
2 – Notre serveur DHCP, qui a l’intention d’offrir à ce client l’IP 192.168.0.9, fait un ping sur cette
adresse, histoire de voir si elle est réellement disponible sur le réseau. 
3 – Comme il ne reçoit pas de réponse à son ping, il offre cette adresse au client.  
4 – Le client fait alors un DHCP Request 
5 – Le serveur accepte 
6 – Le client fait un broadcast ARP pour vérifier de son côté que l’IP 192.168.0.9 n’est pas dupliquée
sur le réseau. 
7 – idem 
8 – idem 
9 – Là, commence le verbiage propre aux réseaux Microsoft…

Note à propos du ping.

Ce ping fait « perdre » une seconde au processus d’attribution d’un bail. En effet, le serveur attend
pendant une seconde une éventuelle réponse. Si vous êtes absolument sûr de votre réseau, vous
pouvez désactiver ce ping dans le fichier de configuration de DHCPd, mais je ne vous le conseille pas.

10.2 – Détail des trames

Ce qui suit représente l’interprétation exhaustive des trames par le « sniffer ». Il est évident qu’en
lecture directe sur le réseau, on ne verrait qu’une suite d’octets difficilement interprétable par l’esprit
humain.

La lecture en est certes un peu fastidieuse, mais elle est riche d’enseignements… Les points les plus
importants sont marqués en gras.

10.2.1 – Le DHCP Discover

10.2.2 – Un petit ping…

Pas de réponse au ping, on peut continuer tranquille…

10.2.3 – Offre d’un nouveau bail

Le serveur DHCP vient de proposer une configuration au client.

10.2.4 – Demande du Bail de la part du client

Il faut aussi, maintenant que le client fasse une demande explicite pour ce bail. N’oublions pas qu’il
pourrait y avoir plusieurs DHCP qui répondent, il faut donc qu’il y ait une confirmation au serveur
choisi par le client.
C’est presque fini, il ne reste plus au serveur qu’à confirmer l’attribution de ce bail.

10.2.5 – Le serveur est d’accord

Pas besoin de regarder de près ce qu’il se passe dans les broadcasts ARP que le client fait par la suite.

10.3 – Notes supplémentaires

10.3.1 – Duplication d’adresse

Que se serait-il passé, si l’adresse proposée par le serveur (ici 192.168.0.9) avait été déjà utilisée par
un autre noeud du réseau ?

Je ne vous assommerai pas encore une fois avec un sniff, croyez-moi sur parole, j’ai fait la manip pour
vérifier.

Dans ce cas, le serveur recevra un « echo reply » de la part du noeud utilisant cette IP et ne répondra
pas au Discover. Le client, ne recevant pas de réponse, enverra un nouveau discover et le serveur lui
proposera une autre IP.

10.3.2 – Pas de réponse

Et si le client qui a pris l’IP 192.168.0.9 ne répond pas aux pings ?

Ce sera la catastrophe annoncée. Le bail sera alloué et il y aura une duplication de l’IP sur le réseau.
Mais les broadcast ARP fait par le client qui a reçu l’IP dupliquée mettra à jour cette duplication et la
configuration échouera.

Cette situation ne devrait pas se produire sur un réseau proprement configuré. Elle ne devrait
apparaître que s’il y a un utilisateur malveillant sur le réseau, qui force une configuration statique
quand il ne le faut pas et qui bloque volontairement les échos ICMP.

Pour ceux qui n’ont pas peur de se plonger dans les Rfcs, vous trouverez celle qui traite du protocole
Dhcp la RFC 2131.

10.4 – Renouvellement d’un bail en cours de validité

Lorsque la durée du bail est inférieure à  » l’uptime » du client, autrement dit, si votre client reste
connecté plus longtemps que la durée de validité de son bail, il va devoir le renouveler.

Pour visualiser cette procédure, nous faisons un petit test, en diminuant la durée de vie du bail à
quatre minutes, et nous sniffons :

10.4.1 – Quand ça se passe bien…

Ca semble suffisamment parlant, au bout d’environ 120 secondes, soit 50% de la durée de vie du bail,
le client essaye de le renouveler. Ca se passe bien, puisque le serveur répond toute de suite et ça
repart pour 4 minutes. Inutile de regarder le détail des trames.
10.4.2 – Et quand ça se passe mal

Nous allons faire la même chose, mais en simulant une panne de serveur DHCP :

Mais elle aurait pu mal finir, si ça avait été une bonne, vraie, grosse panne du serveur. En effet, une
fois le bail expiré, le client perd bel et bien son IP et est éjecté de fait du réseau… Du temps où les
câblés Wanadoo fonctionnaient sur ce système, ils n’ont pas manqué d’assister quelques fois à ce
désolant spectacle.