|
|
Dhcp
par Sylvain et Christian
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 - Discussion autour de la
documentation
12 - Suivi du document
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.
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)
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.
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.
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.
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) :
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.
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é 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.
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.
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.
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-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.
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.
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.
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;
}
}
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.
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).
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
{
...
}
}
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.
-
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.
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.
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.
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.
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.
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 M2) trois PC dont un sur lequel sont
installés trois systèmes, je n'ai plus de place...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Pas de réponse au ping, on peut continuer tranquille...
Le serveur DHCP vient de proposer une configuration au 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.
Pas besoin de regarder de près ce qu'il se passe dans les broadcasts ARP que
le client fait par la suite.
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.
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.
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 :
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.
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.
Vous pouvez poser toutes vos questions,
vos remarques et vos expériences à propos de DHCP. Pour cela,
rendez-vous sur le
Forum "TCP-IP".
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.
|
|