Je vais répondre #2 :Non.
Lors de l'obtention d'une adresse IP, le démon dhcp crée un socket brut vers l'interface réseau et gère le protocole UDP lui-même. Ainsi les paquets UDP ne passent jamais par iptables.
La raison pour laquelle le démon dhcp doit implémenter UDP est que le noyau ne peut gérer UDP (en fait toute la suite TCP/IP) que lorsque l'interface a une adresse IP. Auparavant, les démons dhcp donnaient d'abord à une interface l'adresse IP 0.0.0.0 mais cela ne fonctionnait plus.
Ajout
$IPT -I INPUT -i $INTIF -p udp --dport 67:68 --sport 67:68 -j ACCEPT
rendra la mise à jour DHCPD plus rapide :) Cela fonctionnera à la fois côté INPUT et OUTPUT. Vous pouvez DROP dhcpd avec ebtables, pas avec iptables. DHCPD écoute à 0.0.0.0, pas dans IP
Mon observation récente, sur OpenWRT Kamikaze 7.09 =2.4.34 et udhcpc depuis busybox 1.4.2 :
J'ai une politique "ACCEPT" dans la chaîne OUTPUT, et dans le sens INPUT, à l'origine je m'appuyais sur cette règle fourre-tout classique :
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
pour autoriser les réponses DHCP (à mon udhcpc) sur l'interface WAN. C'est-à-dire que c'est là que le serveur DHCP en amont de mon FAI m'attribue une adresse IP.
Faites attention à la différence entre un échange DHCP initial (discover, offer, request, ack) et un renouvellement de bail DHCP (request, ack).
Après le démarrage, udhcpc commence par l'échange initial complet. Cet échange réussirait. Et un autre renouvellement ou deux réussiraient aussi - juste une demande et une reconnaissance. Le serveur DHCP de mon FAI demande généralement un temps de renouvellement d'environ une heure à 1,5 heure, ainsi mon client DHCP demande un renouvellement toutes les 30 à 45 minutes (ce comportement est basé sur le RFC).
Mais, vers le troisième ou le quatrième renouvellement, cela commençait à devenir intéressant. TCPdump afficherait environ trois tentatives de renouvellement, suivies d'un échange initial complet - cela dans un laps de temps de quelques minutes ou même quelques secondes. Comme si udhcpc n'aimait pas ce qu'il récupérait :-( et finirait par se contenter de l'échange complet. Après cela, un autre renouvellement dans une demi-heure réussirait... et l'histoire se répéterait à nouveau.
J'ai compris que c'était peut-être le suivi de connexion dans le noyau qui avait quelque chose de mal. Comme si l'entrée conntrack expirait au bout de deux heures environ et que les renouvellements DHCP ultérieurs échouaient car l'ACK du serveur n'atteignait pas réellement udhcpc à l'écoute sur le socket. Notez que tcpdump (libpcap) écoute sur l'interface brute et peut voir tous les paquets entrants, avant qu'ils ne soient soumis à iptables. Une fois que udhcpc abandonne les renouvellements et, désespéré, essaie de recommencer à zéro en utilisant un échange complet (en commençant par DISCOVER), le noyau établit une nouvelle entrée conntrack et peut comprendre les paquets associés pendant un certain temps...
Effectivement, une fois que j'ai ajouté quelque chose comme :
iptables -A INPUT -i $OUT_IF -p udp --sport 67 --dport 68 -j ACCEPT
les renouvellements semblent fonctionner pour toujours.
Les arguments suivants de la ligne de commande tcpdump peuvent vous être utiles :
tcpdump -vv -s 1500 -i eth0.1 port 67 or port 68
Remarque :le -vv demande la sortie détaillée du dissecteur. eth0.1 est mon port WAN (également une interface "NAT extérieure").
Un attribut intéressant dans les paquets ACK est le champ LT :=temps de bail suggéré / maximum accordé en secondes. Les requêtes DHCP sont envoyées du port 68 au port 67. Les réponses viennent du port 67 au port 68.