Imaginons un serveur isc dhcpd configuré de la sorte (centos 6.4) :
...
subnet 192.168.0.0 netmask 255.255.255.0 {
option domain-name-servers 192.168.0.1;
option routers 192.168.0.254;
authoritative;
deny client-updates;
deny
pool {
allow unknown-clients;
range 192.168.0.100 192.168.0.200;
}
host monposte.be-root.com {
option domain-name-servers 192.168.0.2;
hardware ethernet xx:xx:xx:xx:xx:xx;
fixed-address 192.168.0.10;
}
}
Symptômes :
Sur la machine monposte :
si l’on boote sur un livecd (ubuntu), nous obtenons comme paramètres via le dhcp 192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.2 (les paramètres sont donc ceux attendus)
si l’on boote sur windows 7, nous obtenons comme paramètres via le dhcp 192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.1 (le serveur dns n’est pas celui déclaré dans la section host. Il s’agit du dns déclaré dans la section subnet).
Si sous windows 7, nous effectuons un ipconfig /renew alors les parametres sont 192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.2. Cependant, au redémarrage suivant, les paramètres sont de nouveau 192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.1.
Analyse :
Si l’on sniffe l’echange entre le poste windows 7 et le serveur dhcp, on remarque :
-1 requête DHCP Request de la part du client
-1 réponse DHCP ACK de la part du serveur DHCP lui fournissant les paramètres 192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.2 (donc corrects).
-1 requête DHCP Inform de la part du client précisant sont adresse 192.168.0.10 et demandant les paramètres subnet mask/domain name/ router/ domain name server/…/private-proxy autodiscovery
-1 réponse DHCP ACK de la part du serveur dhcp lui fournissant la passerelle 192.168.0.254 et le dns 192.168.0.1 (donc erronés).
– …
A priori, tant que le client ne reçoit pas de réponses valides pour la recherche automatique de proxy, il continue a faire des requêtes DHCPInform toutes les 100 secondes.
La norme concernant les requêtes DCHP Inform stipule :
The server SHOULD check the network address in a DHCPINFORM message for consistency, but MUST NOT check for an existing lease.
Ainsi, le serveur dhcpd n’utilise pas les informations de son fichier de leases pour répondre avec les même paramètres que ceux envoyés lors du DHCP Request mais parcours le fichier de configuration.
Comme l’adresse ip indiquée dans la requête DHCP Inform fait partie du subnet 192.168.0.0, il répond avec les paramètres globaux de la zone.
Résolution :
On peut contourner de problème de plusieurs façons :
- Virer le paramètre authoritative dans le subnet. Le serveur ne répondra plus aux requêtes DHCP Inform … (moyen)
- Supprimer les déclarations globales de serveurs dns et les mettre par hôte/pool. (long et pas très pratique).
- Si l’on n’utilise pas la fonctionnalité de découverte automatique de proxy (wpad) : sur le client Windows7, lancer l’éditeur de base de registres.
Sous HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\Identifiant-de-l-interface , créer une clé nommée UseInform de type DWORD. Initialiser à la valeur 0.
Ainsi le client Windows 7 ne fera plus de requêtes DHCP Inform et donc conservera les informations retournées par lors de la première transaction DHCP Request.
