| DHCP (Dynamic Host Configuration Protocol) |
|
| 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.
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.
| 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.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.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-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…
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 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 M2) 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.
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.
Un Blog, des Blogs - Vous pouvez, vous aussi créer un blog !