Config DHCP / Iptables

Bonjour,

Merci d’avance pour l’attention que vous porterez à ce message et de votre participation. Voilà le blabla.

Je dispose d’un serveur web sous Debian intégré à un LAN derrière une box faisant office de serveur DHCP. J’utilise Iptables comme pare-feu. Iptables adopte une politique DROP par défaut et je n’ai pas de règles autorisant le trafic sur les ports DHCP (67 et 68).

J’ai remarque un truc que je ne comprends pas. Quand j’éteins la box, les machines du LAN dont le serveur ne sont plus connectées, elles n’ont plus alors d’adresse IP (?). Quand je rallume la box, une nouvelle transaction DHCP se fait. Normalement, comme iptables interdit les trafic sur les ports DHCP, la box ne devrait pas pouvoir attribuer au serveur web son adresse ip. Pourtant, Quand je rallume la box, le serveur se reconnecte sans problème au Lan avec la bonne adresse IP. Par quel miracle le serveur web retrouve-t-il son IP alors que les ports DHCP sont bloqués ?
Merci pour vos explications.

L’explication probable est que le client DHCP communique directement avec la couche ethernet, sans passer par la couche IP. Cela se justifie : lors de la négociation DHCP initiale (DHCPDISCOVER, DHCPOFFER…), l’interface réseau n’a pas encore d’adresse IP, masque de réseau, etc. donc ne peut pas encore communiquer normalement via la couche IP.

Oui, ce que tu dis est confirmé par l’article wikipédia. Lors de la première négociation qui à pour but d’attribuer une adresse IP (ainsi qu’un masque de sous-réseau et une passerelle), le DHCP utilise la couche liaison (couche 2 du modèle OSI).
Chose intéressante dans cet article, par rapport à mon problème:

[quote=“wikipédia”]Renouvellement du bail
[…] Cette fois, la transaction est effectuée par transmission IP classique, d’adresse à adresse.[/quote]
Au niveau de mon serveur, ces transactions sont bloquées par iptables. On le voit dans le fichier syslog dont voici un extrait:

Sep 13 06:25:22 tirou dhclient: DHCPREQUEST on eth0 to 192.168.1.1 port 67 Sep 13 06:25:22 tirou dhclient: send_packet: Operation not permitted
(Il y a des centaines de lignes comme celles-ci)

Donc, théoriquement, le serveur peut obtenir un bail (couche 2) mais pas le renouveler (couche 3 bloquée). Or:

Donc mon serveur, à l’expiration du bail, devrait se déconnecter du réseau. Pourtant rien de tel n’arrive. Ou alors le serveur est brièvement déconnecté le temps d’une réattribution d’IP via la couche liaison (couche 2) ?

Fais une capture des paquets DHCP sur l’interface ethernet et tu verras bien si à l’expiration du bail des paquets sortent. Ou bien si possible regarde dans les logs ou l’état des baux du serveur DHCP de la box pour voir de quand date l’attribution ou le renouvellement du bail. Ou alors tout simplement le client DHCP ne suit pas les règles et ne supprime pas l’adresse malgré l’expiration du bail.