Posté par gouttegd .
En réponse au message Configuration DHCP.
Évalué à 2.
Dernière modification le 25 mars 2015 à 17:01.
Par contre cette histoire de ne "rien" répondre est la plus importantes ....
Peut-être pas tant que ça.
Il ne me paraît pas normal que les machines « tombent » simplement parce que ton serveur leur envoie une réponse négative.
A priori, ce qui se passe est que ces machines se souviennent de l’ancienne adresse IP que leur avait attribué le serveur légitime, et envoient donc directement un message DHCPREQUEST pour demander que l’on leur ré-attribue cette adresse. Ton serveur refuse (DHCPNAK), ce qui est normal (l’adresse demandée n’est pas dans la plage d’adresse qu’il est configuré pour distribuer). Mais à ce moment-là, au lieu de « tomber », les clients devraient se rabattre automatiquement sur un cycle DHCP « complet » (DHCPDISCOVERY → DHCPOFFER → DHCPREQUEST → DHCPACK), qui devrait leur permettre de recevoir une bonne configuration de la part du serveur DHCP légitime.
Si malgré tout les machines « tombent », je dirais qu’il se passe le scénario suivant :
1 Le client envoie un DHCPREQUEST avec l’ancienne IP (correcte).
2 Ton serveur répond DHCKNAK.
3 Le client envoie un DHCPDISCOVER.
4 Ton serveur répond un DHCPOFFER avec une adresse IP incorrecte (valable sur ton réseau local, mais pas sur le réseau entreprise).
5 Le serveur DHCP légitime du réseau entreprise envoie DHCPACK (en réponse au DHCPREQUEST du 1), mais il est trop tard.1
6 Le client envoie un DHCPREQUEST avec l’adresse IP reçue en 4.
7 Ton serveur renvoie DHCPACK ; le client se retrouve configurée avec une IP incorrecte, donnant l’impression qu’il est « tombé » du point de vue du réseau entreprise.
8 Le serveur DHCP légitime envoie un DHCPOFFER en réponse au DHCPDISCOVER du 3, mais encore une fois, trop tard.1
En supposant que c’est bien ce qui se passe, il n’est pas particulièrement gênant que ton serveur réponde DHCKNAK en 2. Tout au plus, cela oblige le client à renvoyer un DHCPDISCOVER dont il pourrait autrement se passer. Le vrai problème, c’est que ton serveur ne devrait pas envoyer de DHCPOFFER en 4. Et pour ça, configurer ton serveur comme dans l’exemple que tu donnes (pour ne répondre positivement qu’à des machines précises) devrait être suffisant.
1 L’ordre exact d’arrivée des messages du serveur DHCP légitime peut être un peu différent, mais ce qui est sûr c’est qu’ils arrivent après la bataille.
[^] # Re: Configuration basée sur l'adresse MAC
Posté par gouttegd . En réponse au message Configuration DHCP. Évalué à 2. Dernière modification le 25 mars 2015 à 17:01.
Peut-être pas tant que ça.
Il ne me paraît pas normal que les machines « tombent » simplement parce que ton serveur leur envoie une réponse négative.
A priori, ce qui se passe est que ces machines se souviennent de l’ancienne adresse IP que leur avait attribué le serveur légitime, et envoient donc directement un message DHCPREQUEST pour demander que l’on leur ré-attribue cette adresse. Ton serveur refuse (DHCPNAK), ce qui est normal (l’adresse demandée n’est pas dans la plage d’adresse qu’il est configuré pour distribuer). Mais à ce moment-là, au lieu de « tomber », les clients devraient se rabattre automatiquement sur un cycle DHCP « complet » (DHCPDISCOVERY → DHCPOFFER → DHCPREQUEST → DHCPACK), qui devrait leur permettre de recevoir une bonne configuration de la part du serveur DHCP légitime.
Si malgré tout les machines « tombent », je dirais qu’il se passe le scénario suivant :
1 Le client envoie un DHCPREQUEST avec l’ancienne IP (correcte).
2 Ton serveur répond DHCKNAK.
3 Le client envoie un DHCPDISCOVER.
4 Ton serveur répond un DHCPOFFER avec une adresse IP incorrecte (valable sur ton réseau local, mais pas sur le réseau entreprise).
5 Le serveur DHCP légitime du réseau entreprise envoie DHCPACK (en réponse au DHCPREQUEST du 1), mais il est trop tard.1
6 Le client envoie un DHCPREQUEST avec l’adresse IP reçue en 4.
7 Ton serveur renvoie DHCPACK ; le client se retrouve configurée avec une IP incorrecte, donnant l’impression qu’il est « tombé » du point de vue du réseau entreprise.
8 Le serveur DHCP légitime envoie un DHCPOFFER en réponse au DHCPDISCOVER du 3, mais encore une fois, trop tard.1
En supposant que c’est bien ce qui se passe, il n’est pas particulièrement gênant que ton serveur réponde DHCKNAK en 2. Tout au plus, cela oblige le client à renvoyer un DHCPDISCOVER dont il pourrait autrement se passer. Le vrai problème, c’est que ton serveur ne devrait pas envoyer de DHCPOFFER en 4. Et pour ça, configurer ton serveur comme dans l’exemple que tu donnes (pour ne répondre positivement qu’à des machines précises) devrait être suffisant.
1 L’ordre exact d’arrivée des messages du serveur DHCP légitime peut être un peu différent, mais ce qui est sûr c’est qu’ils arrivent après la bataille.