dhcp

Les différents messages dhcp

Quand on débug du dhcp, on doit souvent analyser les messages dhcp et certains peuvent être trop vite mal compris. Finissons-en avec les rumeurs, voici les faits (tout simplement tirés de la RFC2131)

Le serveur dhcp fournit 2 services distintcts :

- il attribue des adresses ip

- il envoie des paramètres de configuration

DHCPDISCOVER : le client envoie un broadcast pour localiser les serveurs dhcp disponible

DHCPOFFER : le serveur donne au client un nombre variable de paramètres de configuration (ip, dns, passerelle, etc.)

DHCPREQUEST : Le client accepte les paramètres de configuration d'un serveur dhcp (et décline toute autre offre) ou le client reconfirme les paramètres de configuration (en cas de reboot ou pour étendre le bail)

DHCPACK : le serveur confirme au client l'attribution des paramètres

DHCPNACK : le réseau demandé par le client est incorrect ou le bail est expiré

DHCPDECLINE : le client indique qu'il refuse l'adresse ip car il a détecté qu'elle est déjà utilisée sur son propre réseau

DHCPRELEASE : le client indique au serveur qu'il n'a plus besoin de l'adresse et que le bail peut être libéré

DHCPINFORM : le client demande au serveur des paramètres (le client a déjà une adresse ip)

Un dialogue normal d'attribution d'ip se déroule donc ainsi :

Le client envoie un DHCPDISCOVER sur le réseau

Via un DHCPOFFER, le serveur propose une adresse ip au client

Avec DHCPREQUEST, le client confirme qu'il peut prendre l'adresse ip proposée

Le serveur conclue le dialogue avec un DHCPACK

dhcpd.conf

Un dhcp célèbre est le ISC Dhcp.

La configuration se fait grâce au fichier dhcpd.conf

On utilise généralement les objets suivants :

Un shared-network indique un même réseau physique. Dans un même réseau physique, on ne pourra pas choisir un subnet particulier. Le shared-network contient un paramétrage commun à tous les subnets définis dans ce shared-network.

Un subnet définit un sous-réseau, donc à l'aide d'une adresse ip et d'un masque.

Un pool peut être mis à l'intérieur d'un subnet pour gérer les classes. Les classes permettent d'analyser les DHCPDISCOVER et d'agir de manière différente suivant les paramètres figurant dans le DHCPDISCOVER. Les fabricants de "hosts" mettent en général un identifiant pour savoir quel type d'appareil fait la requête dhcp.

Un host est utilisé pour attribuer une ip statique à un hôte que l'on suppose connu. Généralement on utilise l'adresse mac, en théorie unique au monde, pour reconnaître l'hôte en question.

Pour que le dhcp puisse communiquer avec les clients, il y a deux solutions. Soit le dhcp est sur le même brin niveau 2 (même réseau physique ou même vlan) et il récupère les requêtes par ce biais. Soit le dhcp est distant et il faut utiliser un équipement qui fera "relais dhcp".

Comment le dhcp va choisir l'adresse ip à offrir à un hôte ?

L'hôte doit lui donner un indice concernant le réseau sur lequel il se trouve. En général, le serveur dhcp n'est pas sur le même réseau physique que les clients. Il faut donc passer un "relay agent" qui va transmettre le paquet dhcp du client vers le serveur.

Le relay agent va se substituer au client. Il y aura donc - au niveau ip - un dialogue entre le relay agent et le serveur dhcp.

Le serveur dhcp recevra dans le champ giaddr l'adresse ip du relay agent. Le dhcp va examiner cette ip et voir si elle correspond à un des subnets. Si c'est le cas, le dhcp affectera soit une ip fixe (si l'hôte qui se présente figure dans une directive host) ou une ip dynamique (si un range est défini).

Si le dhcp trouve un hôte dans un subnet. Il sort ensuite de ce subnet pour remonter d'un niveau afin de prendre les options complémentaires. Ca peut donc être des options d'un shared-network ou les options globales.

Il y a une hierarchie dans  l'évaluation :

directive host

directive subclass

directive class

directive subnet

directive pool

directive shared-network