DHCP - Cloudfront.net

DHCP (Dynamic Host Configuration
Protocol)
1 - Définition
2 - Références
3 - Fonctionnement
4 - Les baux
5 - Dynamique ou pas ?
6 - Les requêtes et les messages DHCP
7 - Les messages DHCP
7.1 - Dialogue avec le serveur
7.2 - Format de la trame BOOTP/DHCP
7.3 - Passage d'options
8 - Le serveur Dhcp
8.1 - Où trouver un serveur DHCP ?
8.2 - Compilation du serveur
8.3 - Le fichier dhcpd.conf
8.3.1 - Les paramètres globaux
8.3.2 - shared-network
8.3.3 - subnet
8.3.4 - host
8.3.5 - group
8.3.6 - Les options
8.3.7 - Exemple de fichier dhcpd.conf
8.4 - Lancer le démon dhcpd
8.5 - Exécuter le démon à chaque démarrage (pour Linux)
8.6 - Documentation
9 - Configuration des clients
9.1 - Tout pour contrôler, réparer etc
9.2 - Windows 95/98
9.2.1 - Configuration
9.2.2 - Vérification
9.3 - Windows NT4/2000/XP
9.3.1 - Configuration
9.3.2 - Vérification
9.4 - Linux
9.4.1 - Configuration
9.4.2 - Vérifiez l'état de votre connexion
9.4.3 - Particularités du client DHClient
10 - Savoir "Sniffer"
10.1 - En-têtes de trames
10.2 - Détail des trames
10.2.1 - Le DHCP Discover
10.2.2 - Un petit ping...
10.2.3 - Offre d'un nouveau bail
10.2.4 - Demande du Bail de la part du client
10.2.5 - Le serveur est d'accord
10.3 - Notes supplémentaires
10.3.1 - Duplication d'adresse
10.3.2 - Pas de réponse
10.4 - Renouvellement d'un bail en cours de validité
10.4.1 - Quand ça se passe bien...
10.4.2 - Et quand ça se passe mal
11 - Suivi du document
1 - Définition
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 comment 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
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
Spécifications et API Java : dhcp.org
Le site de l'ISC : http://www.isc.org
Le site de Microsoft : BOOTP, DHCP, DNS servers (en anglais)
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
- ile : nom du fichier à utiliser pour le boot
- options : Champs réservé 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. L'une des principales innovations 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 versionqui,
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-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-DNS0.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...
Voir un exemple
.
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 sousré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 : fixedaddress 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 -> . 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 Mandriva (anciennement 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 Mandriva, 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 - En-tê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.
11 - Suivi du document
En juin 2003, par
Christian, Ajout des chapitres 9 et 10 apportant les clients et des analyses de trames.
En septembre 2000, par Sylvain, création du document.
En Juin 2005, par Christophe Bruggeman, Ajout de quelques modification.
www.misfu.com