DHCP 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. 2 - Références - RFC951 : Bootp - RFC1497 : Options vendor extensions - RFC1541 : Définition du protocole Dhcp - RFC1542 : Interaction entre Bootp et Dhcp - RFC2131 : Complément à la Rfc 1541 - RFC2132 : Complément aux options vendor extensions 3 - Fonctionnement DHCP fonctionne sur le modèle client-serveur : un serveur, qui détient la politique d'attribution des configurations IP, envoie une configuration donnée pour une durée donnée à un client donné (typiquement, une machine qui vient de démarrer). Le serveur va servir de base pour toutes les requêtes DHCP (il les reçoit et y répond), aussi doit-il avoir une configuration IP fixe. Dans un réseau, on peut donc n'avoir qu'une seule machine avec adresse IP fixe : le serveur DHCP. Le protocole DHCP s'appuie entièrement sur BOOTP : il en reprend le mécanisme de base (ordre des requêtes, mais aussi le format des messages). DHCP est une extension de BOOTP. Quand une machine vient de démarrer, elle n'a pas de configuration réseau (même pas de configuration par défaut), et pourtant, elle doit arriver à émettre un message sur le réseau pour qu'on lui donne une vraie configuration. La technique utilisée est le broadcast : pour trouver et dialoguer avec un serveur DHCP, la machine va simplement émettre un paquet spécial, dit de broadcast, sur l'adresse IP 255.255.255.255 et sur le réseau local. Ce paquet particulier va être reçu par toutes les machines connectées au réseau (particularité du broadcast). Lorsque le serveur DHCP reçoit ce paquet, il répond par un autre paquet de broadcast contenant toutes les informations requises pour la configuration. Si le client accepte la configuration, il renvoit un paquet pour informer le serveur qu'il garde les paramètres, sinon, il fait une nouvelle demande. Les choses se passent de la même façon si le client a déjà une adresse IP (négociation et validation de la configuration), sauf que le dialogue ne s'établit plus avec du broadcast. 4 - Les baux Pour des raisons d'optimisation des ressources réseau, les adresses IP sont délivrées pour une durée limitée. C'est ce qu'on appelle un bail (lease en anglais). Un client qui voit son bail arriver à terme peut demander au serveur un renouvellement du bail. De même, lorsque le serveur verra un bail arrivé à terme, il émettra un paquet pour demander au client s'il veut prolonger son bail. Si le serveur ne reçoit pas de réponse valide, il rend disponible l'adresse IP. C'est toute la subtilité du DHCP : on peut optimiser l'attribution des adresses IP en jouant sur la durée des baux. Le problème est là : si toutes les adresses sont allouées et si aucune n'est libérée au bout d'un certain temps, plus aucune requête ne pourra être satisfaite. Sur un réseau où beaucoup d'ordinateurs se connectent et se déconnectent souvent (réseau d'école ou de locaux commerciaux par exemple), il est intéressant de proposer des baux de courte durée. A l'inverse, sur un réseau constitué en majorité de machines fixes, très peu souvent rebootées, des baux de longues durées suffisent. N'oubliez pas que le DHCP marche principalement par broadcast, et que cela peut bloquer de la
bande passante sur des petits réseaux fortement sollicités. 5 - Dynamique ou pas? Un serveur DHCP est censé fournir des adresses dynamiques (un même ordinateur peut recevoir successivement 2 adresses différentes), mais il peut fournir une adresse IP fixe à un client bien particulier. Ceci ne doit être utilisé que de manière modérée, sinon, le serveur DHCP ne sert à peu près plus à rien, mais cela peut se révéler utile pour fournir l'adresse IP au serveur TFTP qui va servir pour le boot à distance des machines. 6 - Les requêtes et les messages DHCP On pourrait croire qu'un seul aller-retour peut suffire à la bonne marche du protocole. En fait, il existe plusieurs messages DHCP qui permettent de compléter une configuration, la renouveler... Ces messages sont susceptibles d'être émis soit par le client pour le ou les serveurs, soit par le serveur vers un client : La valeur entre parenthèses est utilisées pour identifier ces requêtes dans les messages DHCP. Voir les options DHCP. La première requête émise par le client est un message DHCPDISCOVER. Le serveur répond par un DHCPOFFER, en particulier pour soumettre une adresse IP au client. Le client établit sa configuration, demande éventuellement d'autres paramètres, puis fait un DHCPREQUEST pour valider son adresse IP. Le serveur répond simplement par un DHCPACK avec l'adresse IP pour confirmation de l'attribution. Normalement, c'est suffisant pour qu'un client obtienne une configuration réseau efficace, mais cela peut être plus ou moins long selon que le client accepte ou non l'adresse IP ou demande des infos complémentaires... Pour demander une nouvelle adresse, le chronogramme-type est le suivant :
Pour renouveler une adresse, le fonctionnement est le suivant (les 2 serveurs connaissent le client) :
7 - Les messages DHCP 7.1 - Dialogue avec le serveur Les messages DHCP sont transmises via UDP. Bien que peu fiable, ce protocole suffit au transport des paquets simples sur réseau local, et surtout il est très léger, donc intéressant pour les petits systèmes (du genre le micro bout de programme qui fait la requête DHCP lorsque le PC se met en route). De facto, DHCP fonctionne en mode non connecté. Le client n'utilise que le port 68 pour envoyer et recevoir ses messages et 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) 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). 9 - Pour contrôler, réparer etc Quels sont les outils pour contrôler l'état du client DHCP sour Windows NT4/2000/Xp 9.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.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.
10 - Savoir "Sniffer" Un "sniffer" n'est pas un outil pour se "shooter", mais pour analyser les données qui se trimbalent sur le réseau. C'est un outil d'administrateur, qui est capable du meilleur comme du pire. Si vous voulez jouer avec, il en existe un tout à fait convenable et gratuit, aussi bien en version Linux que Windows, c'est Ethereal. Il nécessite l'installation de la librairie winpcap, 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.