Ich antworte Nr. 2:Nein.
Beim Abrufen einer IP-Adresse erstellt der dhcp-Daemon einen Raw-Socket zur Netzwerkschnittstelle und verarbeitet das UDP-Protokoll selbst. Daher gehen die UDP-Pakete niemals durch iptables.
Der Grund, warum der dhcp-Daemon UDP implementieren muss, ist, dass der Kernel nur mit UDP (eigentlich der gesamten TCP/IP-Suite) umgehen kann, wenn die Schnittstelle eine IP-Adresse hat. Früher haben DHCP-Daemons einer Schnittstelle zunächst die IP-Adresse 0.0.0.0 gegeben, aber das funktioniert nicht mehr.
Hinzufügen
$IPT -I INPUT -i $INTIF -p udp --dport 67:68 --sport 67:68 -j ACCEPT
soll das DHCPD-Update schneller machen :) Es soll sowohl auf der INPUT- als auch auf der OUTPUT-Seite funktionieren. Sie können dhcpd mit ebtables DROPEN, nicht mit iptables. DHCPD hört auf 0.0.0.0, nicht innerhalb von IP
Meine letzte Beobachtung, auf OpenWRT Kamikaze 7.09 =2.4.34 und udhcpc von busybox 1.4.2 :
Ich habe eine "ACCEPT"-Richtlinie in der OUTPUT-Kette und in der INPUT-Richtung habe ich mich ursprünglich auf diese klassische Auffangregel verlassen:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
um die DHCP-Antworten (an meinen udhcpc) auf der WAN-Schnittstelle zuzulassen. Das heißt, hier weist mir der Upstream-DHCP-Server meines ISP eine IP-Adresse zu.
Beachten Sie den Unterschied zwischen einem anfänglichen DHCP-Austausch (Discover, Offer, Request, ack) und einer DHCP-Lease-Erneuerung (Request, ack).
Nach dem Booten beginnt udhcpc mit dem vollständigen anfänglichen Austausch. Dieser Austausch würde erfolgreich sein. Und eine weitere Verlängerung oder zwei würden auch gelingen – nur eine Bitte und Bestätigung. Der DHCP-Server meines Internetdienstanbieters fragt normalerweise nach einer Erneuerungszeit von etwa einer Stunde bis 1,5 Stunden, daher fragt mein DHCP-Client alle 30 bis 45 Minuten nach einer Erneuerung (dieses Verhalten basiert auf dem RFC).
Aber ungefähr bei der dritten oder vierten Verlängerung würde es interessant werden. TCPdump würde ungefähr drei Erneuerungsversuche anzeigen, gefolgt von einem vollständigen anfänglichen Austausch – und das innerhalb einer Zeitspanne von nur wenigen Minuten oder sogar Sekunden. Als ob udhcpc nicht gefallen würde, was es zurückbekommt :-( und sich letztendlich mit dem vollen Austausch zufrieden geben würde. Danach würde eine weitere Erneuerung in einer halben Stunde gelingen ... und die Geschichte würde sich erneut wiederholen.
Ich habe herausgefunden, dass vielleicht die Verbindungsverfolgung im Kernel etwas falsch macht. Als ob der conntrack-Eintrag nach etwa zwei Stunden abläuft und die späteren DHCP-Erneuerungen fehlschlagen, weil das ACK vom Server es nicht wirklich zum udhcpc schafft, der den Socket überwacht. Beachten Sie, dass tcpdump (libpcap) auf der Raw-Schnittstelle lauscht und alle eingehenden Pakete sehen kann, bevor sie iptables unterliegen. Sobald udhcpc die Verlängerung aufgibt und verzweifelt versucht, mit einem vollständigen Austausch (beginnend mit DISCOVER) von vorne zu beginnen, erstellt der Kernel einen neuen Conntrack-Eintrag und kann verwandte Pakete noch einige Zeit verstehen ...
Sicher genug, sobald ich so etwas hinzugefügt habe:
iptables -A INPUT -i $OUT_IF -p udp --sport 67 --dport 68 -j ACCEPT
die Erneuerungen scheinen ewig zu funktionieren.
Möglicherweise finden Sie die folgenden tcpdump-cmdline-Argumente nützlich:
tcpdump -vv -s 1500 -i eth0.1 port 67 or port 68
Hinweis:der -vv fragt nach der ausführlichen Ausgabe des Dissektors. eth0.1 ist mein WAN-Port (auch eine "NAT-externe" Schnittstelle).
Ein interessantes Attribut in den ACK-Paketen ist das LT:-Feld =vorgeschlagene / maximal gewährte Lease-Zeit in Sekunden. DHCP-Anfragen werden von Port 68 an Port 67 gesendet. Antworten kommen von Port 67 an Port 68.