Tcpip

LE SERVICE DHCP
TCP/IP Projet
ABDELKARIM ELHALLOUMI OMAR SALIMI
Identification des applications
▸
À l’instar de l’OSI avec la notion de SAP, chaque unité protocolaire de
TCP-IP identifie le protocole ou l’application supérieure
▸
Numéro de port
▸
Identifiant de protocole
▸
Ethertype
ATM
LAN
HTTP
FTP
Telnet
DNS
SNMP
TCP
OSPF
UDP
IP
SLIP
PPP
DHCP-67
X.25
ICMP
FR
Service DHCP
▸
Sur les réseaux locaux de grande taille ou sur les
réseaux dont les utilisateurs changent fréquemment, le
service DHCP est très recommandé.
▸
▸
▸
De nouveaux utilisateurs peuvent se présenter travaillant sur
des ordinateurs portables et nécessitant une connexion.
D’autres peuvent disposer de nouvelles stations de travail
devant être connectées.
Plutôt que de faire attribuer des adresses IP par
l’administrateur réseau à chaque station de travail, il est plus
efficace que les adresses IP soient attribuées
automatiquement à l’aide du protocole DHCP.
Protocole DHCP
▸
DHCP : Dynamic Host Configuration Protocol
▸
▸
"Protocole de configuration Dynamique des clients«
DHCP est une extension du protocole BOOTP qui permet
à un client sans disque dur (terminal X, imprimante, etc.)
de démarrer et de configurer automatiquement TCP/IP.
Protocole DHCP
Permettre à un client d'obtenir dynamiquement une
adresse IP (et d'autres paramètres éventuellement)
auprès d'un serveur DHCP.
▸
Automatiser l’affectation des adresses IP, des
masques de sous-réseau, des paramètres de
passerelle et autres paramètres de réseau IP.
▸
▸
Remarques:
 Un réseau peut avoir plusieurs serveurs DHCP.

Le client ne désigne pas un serveur
Principe du DHCP
▸
Le serveur DHCP est contacté et une adresse est
demandée.
▸
Le serveur DHCP :
▸
choisit une adresse dans une plage d’adresses configurée
nommée pool
▸
les adresses qui ne sont plus utilisées sont automatiquement retournées
au pool pour être réattribuées.
▸
attribue temporairement une adresse au client DHCP pour une
durée définie nommée Bail.
Cinématique DHCP : demande d’@IP
L'obtention d'une adresse se fait en 4 phases :
1.
Demande de bail IP par le client.
2.
Offre de bail IP par un serveur.
3.
Sélection d'une offre par le client.
4.
Accusé de réception de bail IP par le serveur.
Cinématique DHCP : demande d’@IP
Serveur
DHCP
Demande de Bail IP
DHCPDISCOVER (UDP, broadcast)
▸
Client
Lorsqu’un périphérique, configuré pour le protocole DHCP, est mis sous
tension ou se connecte au réseau diffuse une demande d'adresse IP
(DhcpDiscover) avec :
1.
source
0.0.0.0
2.
destination
255.255.255.255
3.
Adresse MAC client
▸
Un client DHCP attend une offre pendant une seconde.
▸
En cas de non réponse il rediffuse sa demande quatre fois (à des intervalle
de 9, 13 et 16 secondes puis un intervalle aléatoire entre 0 et 1000
millisecondes).
▸
Après ces quatre tentatives, il renouvelle sa demande toutes les 5 minutes.
Cinématique DHCP : demande d’@IP
Lors du premier démarrage du client, il est dit être à l'état d'initialisation, et transmet un message
DHCPDISCOVER sur son sous-réseau physique local sur le port 67 UDP (User Datagram Protocol) (serveur
BootP). Puisque le client ne peut pas connaître le sous-réseau auquel il appartient, le message DHCPDISCOVER
est une diffusion pour tous les sous-réseaux (adresse IP de destination 255.255.255.255), avec l'adresse IP
source 0.0.0.0. L'adresse IP source est 0.0.0.0, puisque le client n'a pas d'adresse IP configurée. Si un serveur
DHCP existe sur ce sous- réseau local, qu'il est configuré et fonctionne correctement, le serveur DHCP entend la
diffusion et répond avec message DHCPOFFER. Si aucun serveur DHCP n'existe sur le sous-réseau local, un
agent relais DHCP/BootP doit être présent sur ce sous-réseau local pour transférer le message DHCPDISCOVER
à un sous-réseau qui contient un serveur DHCP.
Cet agent relais peut être un hôte dédié (par exemple Microsoft Windows Server) ou un routeur (par exemple, un
routeur Cisco configuré avec des déclarations auxiliaires IP au niveau de l'interface).
Cinématique DHCP : demande d’@IP
Serveur
DHCP
Offre de Bail IP
DHCPOFFER: IP (UDP, broadcast)
▸
Tous les serveurs reçoivent la demande.
▸
S'ils sont configurés pour répondre, ils diffusent des offres
(DhcpOffer) avec les informations suivantes :
1.
L'adresse MAC du client
2.
Une adresse IP
3.
Un masque de sous-réseau
4.
Une durée de bail (durée pendant laquelle l’IP ne sera pas
utilisée par un autre host)
5.
6.
Son adresse IP (du serveur)
Client
Cinématique DHCP : demande d’@IP
Un serveur DHCP qui reçoit un message DHCPDISCOVER peut répondre avec un message
DHCPOFFER sur le port 68 UDP (client BootP). Le client reçoit le message DHCPOFFER et passe
à l'état Sélection. Ce message DHCPOFFER contient les informations de configuration initiale pour
le client. Par exemple, le serveur DHCP renseigne le champ yiaddr du message DHCPOFFER avec
l'adresse IP demandée. Le masque de sous-réseau et la passerelle par défaut sont spécifiés dans
le champ d'options, et les options de masque de sous-réseau et de routeur, respectivement.
D'autres options communes dans le message DHCPOFFER sont la durée du bail de l'adresse IP, la
date de renouvellement, le serveur de noms de domaine et le serveur de noms NetBIOS (WINS). Le
serveur DHCP envoie le message DHCPOFFER à l'adresse de diffusion, mais inclut l'adresse
matérielle des clients dans le champ chaddr de l'offre, ainsi le client connaît la destination prévue. Si
le serveur DHCP n'est pas sur le sous-réseau local, le serveur DHCP renvoie le message
DHCPOFFER, comme paquet de monodiffusion, sur le port 67 UDP, à l'agent relais DHCP/BootP
qui lui avait envoyé le message DHCPDISCOVER. L'agent relais DHCP/BootP envoie alors par
diffusion ou monodiffusion le message DHCPOFFER sur le sous-réseau local sur le port 68 UDP,
selon l'indicateur de diffusion défini par le client BootP.
Cinématique DHCP : demande d’@IP
Serveur
DHCP
Sélection d'un Bail IP
DHCPREQUEST: IP (UDP, broadcast)
▸
Le client sélectionne une offre (en général la
première)
▸
Le client annonce par diffusion qu'il a accepté une
offre (DhcpRequest).
▸
Le message DhcpRequest comporte l'identification
du serveur sélectionné.
▸
Ce dernier sait que son offre a été retenue ;
▸
Tous les autres serveurs DHCP retirent leurs offres
Client
Cinématique DHCP : demande d’@IP
Après avoir reçu un message DHCPOFFER, le client répond avec un message DHCPREQUEST,
indiquant son intention d'accepter les paramètres du message DHCPOFFER et passe à l'état
Demande. Le client peut recevoir plusieurs messages DHCPOFFER, un de chaque serveur DHCP
qui a reçu le message DHCPDISCOVER initial. Le client choisit un message DHCPOFFER et
répond à ce serveur DHCP uniquement, implicitement refusant tous les autres messages
DHCPOFFER. Le client identifie le serveur sélectionné en renseignant le champ d'option Server
Identifier avec l'adresse IP du serveur DHCP. Le message DHCPREQUEST est également une
diffusion. Tous les serveurs DHCP qui ont envoyé un message DHCPOFFER voient donc le
message DHCPREQUEST, et chacun sait si son message DHCPOFFER a été accepté ou refusé.
Toutes les options de configuration supplémentaires demandées par le client sont incluses dans le
champ d'options du message DHCPREQUEST. Bien que le client ait reçu une adresse IP, il envoie
le message DHCPREQUEST avec l'adresse IP source 0.0.0.0. Le client n'a alors pas encore reçu la
confirmation qu'il peut utiliser l'adresse IP.
Cinématique DHCP : demande d’@IP
Serveur
DHCP
Accusé de réception
DHCPACK: IP (UDP, broadcast)
▸
Le serveur ainsi sélectionné envoi accusé de
réception au client (DhcpAck).
▸
Son message contient éventuellement d'autres
informations (serveur DNS, Passerelle, etc.)
Client
Cinématique DHCP : demande d’@IP
Une fois que le serveur reçoit le message DHCPREQUEST, il confirme avoir reçu la demande avec
un message DHCPACK, finalisant ainsi le processus d'initialisation. Le message DHCPACK a une
adresse IP source du serveur DHCP, et l'adresse de destination est à nouveau une diffusion et
contient tous les paramètres que le client a demandé dans le message DHCPREQUEST. Lorsque
le client reçoit le message DHCPACK, il passe à l'état Liaison, et est alors libre d'utiliser l'adresse IP
pour communiquer sur le réseau. En attendant, le serveur DHCP enregistre le bail dans sa base de
données et l'identifie de façon unique à l'aide de l'identificateur client ou chaddr, et de l'adresse IP
associée. Le client et le serveur utilisent tous les deux cette combinaison des identificateurs pour
faire référence au bail. L'identificateur client est l'adresse MAC du périphérique plus le type de
support.
Avant que le client DHCP commence à utiliser la nouvelle adresse, le client DHCP doit calculer les
paramètres temporels associés à l'adresse louée, qui sont la durée du bail (LT), la date de
renouvellement (T1) et la date de nouvelle liaison (T2). Par défaut, LT est de 72 heures. Vous
pouvez utiliser des durées de bail inférieures afin de conserver les adresses, si nécessaire.
Cinématique DHCP : demande d’@IP
Serveur
DHCP
Demande de Bail IP
DHCPDISCOVER (UDP, broadcast)
Offre de Bail IP
DHCPOFFER: IP (UDP, broadcast)
Sélection d'un Bail IP
DHCPREQUEST: IP (UDP, broadcast)
Accusé de réception
DHCPACK: IP (UDP, broadcast)
▸
Utilisation du mode non connecté via UDP et
N°Port 68
Client
Les options DHCP : RFC 2132
▸
▸
RFC 2132 précise les principaux paramètres
pouvant être affectés par DHCP, notamment :
1.
Un masque de sous-réseau
2.
L'adresse IP du serveur DNS et le nom de domaine dans lequel est situé la station
3.
Le nom de la station
4.
L'adresse IP du serveur WINS et le type de nœud Netbios
5.
Des paramètres IP, TCP, ARP tels que MTU, TTL, la durée du cache ARP,
6.
Des routes statiques par défaut ainsi que l’adresse du routeur par défaut
7.
Les serveurs de messagerie SMTP et POP
8.
Divers serveurs par défaut tels que Web, News, NTP, …
9.
Des paramètres relatifs au DHCP tel que le bail
10.
Les types de messages DHCP (Discover, Request, Release, …)
11.
…
Les options sont au nombre de 65 recensées à ce jour
Cinématique DHCP :Renouvellement du
bail
▸
L'affectation d'une adresse IP n'est pas permanente, elle est
accordée pour une durée limitée qui est le bail
▸
Une fois que le client obtient le bail, celui-ci doit être renouvelé
avant son expiration via un autre message DHCP REQUEST.
▸
▸
Le client doit donc renouveler ce bail
Deux modes de renouvellement possibles :
1.
Automatique (Time triggred)
2.
Manuel (utilisateur)
Cinématique DHCP : Renouvellement de
bail
▸
1ère demande de renouvellement

à 50% de l’utilisation du bail, le client envoie un message
DHCPREQUEST pour le renouvellement de son bail.

Si elle est accordée, le client continue avec un nouveau bail et
éventuellement de nouveaux paramètres (DhcpAck).

Si le serveur est absent, le bail reste donc valide pendant 50% de
la valeur initiale
Cinématique DHCP : Renouvellement de
bail
▸
2ème demande de renouvellement

à 87.5% du bail, si le serveur est indisponible, le client envoie un
message DHCPDISCOVER.

Cette fois la demande est adressée à tous les serveurs (diffusion).
1.
Un serveur peut répondre en proposant un nouveau bail (DhcpAck)
2.
Mais peut également répondre avec un message DhcpNack qui oblige le
client à se réinitialiser (reprise de la procédure d'obtention d'un bail)
Cinématique DHCP : Renouvellement de
bail
▸
Si le bail expire (ou message DhcpNack)
• À 100% du bail : reprise de la procédure, normale, d'obtention
d'un bail
Cinématique DHCP : Renouvellement de
bail
▸
Renouvellement manuel de bail
• L’utilisateur force manuellement le renouvellement du bail
-
ipconfig/renew : cette commande génère un DHCPREQUEST
-
ipconfig/release : cette commande annule le bail
Messages DHCP
▸
DHCPDISCOVER : Requête de Localisation des serveurs DHCP disponibles
▸
DHCPOFFER : Réponse d’un serveur à un paquet DHCPDISCOVER,
contenant les premiers paramètres DHCP
▸
DHCPREQUEST : Requête du client pour annoncer qu'il a accepté une offre
ou pour prolonger son bail
▸
DHCPACK : Réponse du serveur contenant des paramètres supplémentaires
en plus de l'adresse IP du client
▸
DHCPNAK : Réponse du serveur pour signaler au client que son bail est
expiré ou si le client annonce une mauvaise configuration réseau
▸
DHCPDECLINE : le client annonce au serveur que l'adresse est déjà utilisée
▸
DHCPRELEASE : le client libère son adresse IP
▸
DHCPINFORM : le client demande des paramètres locaux de configuration si
il a obtenu une adresse réseau grâce à d'autres moyens (ex. configuration
manuelle)
Messages DHCP
Routeur comme serveur DHCP
▸
Nous pouvons utiliser un routeur comme un serveur DHCP
▸
L’ exemple suivant montre une configuration de routeur Cisco
comme un serveur DHCP dans le réseau 192.168.1.0/24.
conf t
service dhcp
ip dhcp pool 192.168.1.0/24
network 192.168.1.0 255.255.255.0
default-router 192.168.1.1
dns-server 192.168.1.5 192.168.1.6
exit
ip dhcp excluded-address 192.168.1.1 192.168.1.199
ip dhcp excluded-address 192.168.1.241 192.168.1.255
▸
Avec les adresses exclus, uniquement les adresses IP entre
192.168.1.200-192.168.1.240 seront disponibles pour les clients.
Agent de relais DHCP
▸
Les trames brodcast ne traversent pas les routeurs.
▸
Sur un réseau segmenté par des routeurs il est donc impossible de
servir tous les segments avec le même serveur DHCP.
▸
1.
Il faut donc mettre un serveur DHCP sur chaque segment,
2.
Ou utiliser un agent de relais DHCP.
Un agent de relais DHCP relaye les messages DHCP échangés
entre un client et un serveur DHCP situés sur des sous-réseaux
différents.
▸
Il est généralement installé sur un routeur pour pouvoir diriger les messages
vers le serveur DHCP.
▸
L'agent doit connaître l'adresse du serveur DHCP mais ne peut pas être luimême client DHCP.
▸
Serveur DHCP et agent de relais ont des adresses ip statiques.
▸
Le dialogue traverse le routeur et se fait en unicast.
Agent de relais DHCP
1.
Le client envoie une trame de broadcast DhcpDiscover (1)
2.
l'agent de relais transfère la requête à la liste des serveurs DHCP
spécifiés lors du configuration de l'agent (2).
Le serveur retourne à l'agent une adresse (3)
3.
4.
L’agent diffuse la réponse sur le réseau ayant envoyé la requête d'origine
(4).
Serveur DHCP
Client
Agent de relais
Routeur
2
2
1
3
3
4
Routeur comme agent de relais
▸
Si les stations sont situées sur un autre réseau que le serveur DHCP, les requêtes
doivent transiter par le routeur (or routeur ne transmet pas les requêtes broadcast).
▸
On doit configurer le routeur Cisco comme agent de relais
▸
Il faut utiliser IP Helper address pour transformer le trafic broadcast qui arrive sur une
interface (DHCP Request) en trafic unicast sur une autre interface (celle de ton serveur
DHCP)
▸
Router# conf t
▸
Router(config)# int f0/1
▸
Router(config-int)# ip address 192.168.2.1 255.255.255.0
▸
Router(config-int)# ip helper-address 10.11.0.1
▸
Router(config-int)# ip helper-address @d’autres serveurs DHCP
▸
Router(config)# service DHCP
Serveur DHCP
10.11.0.1
Client
Routeur
.2
.1
192.168.2.0
.2
Analyse DHCP
Service DHCP
▸
Les adresses attribuées via le DHCP ne sont pas
affectées aux hôtes définitivement.
▸
Si l’hôte est mis hors tension ou retiré du réseau,
l’adresse est retournée au pool pour être réutilisée.
▸
▸
▸
utile pour les utilisateurs mobiles qui se connectent et se
déconnectent sur le réseau.
les utilisateurs peuvent librement se déplacer d’un endroit à un
autre et rétablir des connexions réseau.
L’hôte peut contenir une adresse IP une fois la connexion
matérielle établie, via un réseau local filaire ou sans fil.
Adressage Statique et Dynamique
▸
▸
L’adressage dynamique et l’adressage statique ont
chacun leur place dans la conception des réseaux.
De nombreux réseaux utilisent à la fois le protocole
DHCP et l’adressage statique.
▸
▸
Le protocole DHCP est utilisé pour les hôtes à utilisation
générale (par exemple, les périphériques d’utilisateur
final)
Les adresses fixes pour les périphériques réseau :
▸
▸
▸
▸
les passerelles,
les commutateurs,
les serveurs
et les imprimantes).
Recommandations DHCP
▸
▸
▸
Installez au moins un serveur DHCP par site pour
des questions de charge sur les liaisons WAN
Installez deux serveurs par site pour des besoins de
fiabilité surtout si le nombre de machines est grand
La durée de validité d’une adresse doit être limitée
dans le temps
▸
▸
12 à 24 heures pour un terminal
Une durée plus longue pour les équipements réseau
Simulation
Le serveur DHCP
1 – Où trouver un serveur DHCP ?
L’Internet Software Consortium développe un serveur DHCP pour le monde du logiciel libre. C’est le serveur DHCP le plus répandu, et celui qui « suit » au mieux les Rfcs. La
dernière version en date est la 3.0 et elle est encore en version bêta. Les versions antérieures marchent toutefois très bien, bien que l’ISC sortent beaucoup de patchs. L’une des
principales innovations de la version 3 est la possibilité de mettre à jour un DNS dynamiquement en fonction des adresses IP fournies par le serveur DHCP. Pour information, le
première draft sur le DNS dynamique date de mars 1996… Microsoft a bien entendu son propre serveur DHCP pour Windows. Seule la version pour Windows 2000 Server permet
de mettre à jour les DNS dynamiquement avec DHCP. Le reste de cette section traite de l’installation et de la configuration d’un serveur DHCP sous système Unix. L’exemple pris
est celui d’un serveur fourni par l’ISC.
2 – Compilation du serveur
La première étape de la réalisation d’un serveur DHCP est bien entendu sa compilation. Allez sur le site de l’ISC et téléchargez une version d’un serveur DHCP ou téléchargez
simplement ma version qui, bien que vieille, prend en charge la mise a jour de DNS. Copier le fichier dans un répertoire.
Décompressez l’archive : tar xzf dhcp-dhcp-2.0b1pl6.tar.gz
Déplacez-vous dans le répertoire (commande cd), et tapez : ./configure
Cela va générer les fichiers Makefile correspondant à votre système. Tapez ensuite make pour compiler le serveur et enfin make install pour installer le serveur.
Avant de faire le ./configure, il est hautement recommandé de lire le fichier README qui explique comment installer correctement le serveur. Par exemple, pour ma version, tapez
./configure –with-nsupdate pour compiler le serveur avec le support Dynamic DNS update. make install copiera les fichiers perl dans le répertoire /usr/local/DHCP-DNS-0.52mdn.
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.
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…
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;
}
}
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.
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).
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
{
...
}
}
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.
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.
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.
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.
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.
Configuration des clients
● Liste des tâches de configuration DHCP
Router#debug ip dhcp server packet
00:20:54: DHCPD: setting giaddr to 192.168.1.1.
!--- Router received DHCPDISCOVER/REQUEST/INRORM and setting Gateway IP address to 192.168.1.1 for forwarding.
00:20:54: DHCPD: BOOTREQUEST from 0063.6973.636f.2d30.3065.302e.3165.6632.2e63..
!--- BOOTREQUEST includes DHCPDISCOVER, DHCPREQUEST, and DHCPINFORM.
!--- 0063.6973.636f.2d30.3065.302e.3165.6632.2e63 indicates client identifier.
00:20:54: DHCPD: forwarding BOOTREPLY to client 00e0.1ef2.c441.
!--- BOOTREPLY includes DHCPOFFER and DHCPNAK.
!--- Client's MAC address is 00e0.1ef2.c441. 00:20:54: DHCPD: broadcasting BOOTREPLY to client 00e0.1ef2.c441.
!--- Router is forwarding DHCPOFFER or DHCPNAK broadcast on local LAN interface.
00:20:54: DHCPD: setting giaddr to 192.168.1.1.
!--- Router received DHCPDISCOVER/REQUEST/INFORM and set Gateway IP address to 192.168.1.1 for forwarding.
00:20:54: DHCPD: BOOTREQUEST from 0063.6973.636f.2d30.3065.302e.3165.6632.2e63..
!--- BOOTREQUEST includes DHCPDISCOVER, DHCPREQUEST, and DHCPINFORM.
!--- 0063.6973.636f.2d30.3065.302e.3165.6632.2e63 indicates client identifier.
00:20:54: DHCPD: forwarding BOOTREPLY to client 00e0.1ef2.c441.
!--- BOOTREPLY includes DHCPOFFER and DHCPNAK. !--- Client's MAC address is 00e0.1ef2.c441.
00:20:54: DHCPD: broadcasting BOOTREPLY to client 00e0.1ef2.c441.
!--- Router is forwarding DHCPOFFER or DHCPNAK broadcast on local LAN interface.
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.
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…
2 – Windows 95/98
9.2.1 – Configuration
Par le panneau de configuration, icône « réseau », cliquez sur « TCP/IP -> <votre carte réseau>. L’adresse IP doit être configurée dynamiquement, c’est d’ailleurs le choix par
défaut à l’installation.
9.2.2 – Vérification
Si vous avez un bail en cours de validité, la commande « winipcfg » vous affiche les choses suivantes:
ATTENTION! Windows 95 et 98 installent également le client PPP dont nous n’avons rien à faire… Ce client apparaît également dans la liste des interfaces réseau.
Vérifiez bien que vous pointez sur votre carte Ethernet et pas sur le client PPP…
Si vous cliquez sur le bouton « Plus d’info>> »:
Ici, c’est le bouton « Renouveler » qui sera votre seul secours en cas de problèmes. Notez que les rubriques « Bail obtenu » et « Expiration du bail » contiennent des valeurs
calculées par votre machine. Le serveur DHCP ne donne que la durée.
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.
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.
4 – Linux
4.1 – Configuration
Avec cet OS c’est beaucoup plus compliqué, parce qu’il y a beaucoup plus de configurations possibles. La configuration utilisée dans l’exposé est la suivante:
 Un portable Compaq équipé d’une carte réseau D-LINK PCMCIA
 MANDRAKE 8.2
 Eth0 et configurée avec DHClient.
Notez que DHClient n’est pas le seul client possible. Vous pouvez parfaitement le remplacer par PUMP, DHCPXD ou par DHCPCD. Tous ces clients sont disponibles dans la
distribution Mandrake, qui installe d’ailleurs DHCPCD par défaut, et non pas celui que j’utilise.
 DHCPCD semble avoir la préférence du distributeur. Je n’ai jamais rencontré de problèmes avec, mais je ne l’utilise normalement pas pour la raison suivante: Son
paramétrage ne se fait que par la ligne de commande, ce qui oblige à aller modifier des scripts pas toujours faciles à trouver si l’on veut par exemple utiliser son
propre DNS à la place de celui proposé dans le bail.
 PUMP Fonctionne également sans problèmes, il dispose d’un fichier de configuration /etc/pump.conf dans le quel on peut par exemple spécifier très simplement que l’on
ne veut pas modifier le paramétrage du DNS avec l’information récupérée par DHCP. (Le ou les DNS sont inscrits dans le fichier /etc/resolv.conf).
 Je n’ai pas vraiment étudié DHCPXD qui fonctionne lui aussi sans difficultés. Il dispose d’un répertoire /etc/dhcpxd dans lequel vous trouverez quelques fichiers qui vous
donneront toutes les indications sur le bail en cours.
DHCLIENT a ma préférence. Il est écrit par ISC (les auteurs de BIND le fameux DNS et DHCPD lque nous utilisons ici, c’est dire qu’ils savent de quoi ils parlent :). Ce client cumule
à mon sens tous les avantages:
 Un fichier de configuration /etc/dhclient.conf, sans doute encore plus performant que celui de PUMP. Notez que ce fichier n’existe pas dans la distribution Mandrake, il vous
faudra éventuellement le créer si vous ne voulez pas vous contenter du fonctionnement par défaut.
 Des scripts optionnels exécutés automatiquement avant l’obtention du bail et après l’obtention du bail, avec à disposition des variables contenant toutes les informations
recueillies par le client auprès du serveur. Très pratique par exemple pour vous envoyer par mail l’adresse courante de votre machine si celle-ci change; dans le cas par
exemple où vous avez besoin de vous y connecter à distance par telnet ou ssh.
 Il tient un historique des baux obtenus dans le fichier /var/lib/dhcp/dhclient.leases
Son seul inconvénient est sa richesse. Il n’est pas le plus facile à mettre en oeuvre.
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.
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.
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.
1 – Entêtes de trames
1 – Notre client se réveille, il n’a pas d’IP et utilise 0.0.0.0 pour faire un « broadcast général (255.255.255.255) ». C’est le DHCP Discover.
2 – Notre serveur DHCP, qui a l’intention d’offrir à ce client l’IP 192.168.0.9, fait un ping sur cette adresse, histoire de voir si elle est réellement disponible sur le réseau.
3 – Comme il ne reçoit pas de réponse à son ping, il offre cette adresse au client.
4 – Le client fait alors un DHCP Request
5 – Le serveur accepte
6 – Le client fait un broadcast ARP pour vérifier de son côté que l’IP 192.168.0.9 n’est pas dupliquée sur le réseau.
7 – idem
8 – idem
9 – Là, commence le verbiage propre aux réseaux Microsoft…
Note à propos du ping.
Ce ping fait « perdre » une seconde au processus d’attribution d’un bail. En effet, le serveur attend pendant une seconde une éventuelle réponse. Si vous êtes absolument sûr de
votre réseau, vous pouvez désactiver ce ping dans le fichier de configuration de DHCPd, mais je ne vous le conseille pas.
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.
2.1 – Le DHCP Discover
2.2 – Un petit ping…
Pas de réponse au ping, on peut continuer tranquille…
2.3 – Offre d’un nouveau bail
Le serveur DHCP vient de proposer une configuration au client.
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.
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.
3 – Notes supplémentaires
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.
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.
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.
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.
Présentation et dépannage de DHCP à l'aide des tracés de l'analyseur de réseau Décodage du tracé de l'analyseur de réseau d'un client et d'un
serveur DHCP sur un même segment LAN Le tracé de l'analyseur de réseau ci-dessous est composé de six trames.
Ces six trames illustrent un scénario de travail pour DHCP, où le client et le serveur DHCP résident sur le même segment physique ou logique. En
cas de dépannage de DHCP, il est important que le tracé de l'analyseur de réseau corresponde aux tracés ci-dessous. Quelques différences
peuvent exister par rapport aux tracés ci-dessous, mais le flux de paquets général doit être identique. Le tracé de paquets correspond aux
considérations précédentes sur le fonctionnement de DHCP.