Odpovím #2:Ne.
Při získávání IP adresy démon dhcp vytvoří nezpracovaný soket pro síťové rozhraní a sám zpracovává protokol UDP. Pakety UDP tedy nikdy neprocházejí přes iptables.
Důvod, proč musí démon dhcp implementovat UDP, je ten, že jádro dokáže zpracovat UDP (ve skutečnosti celou sadu TCP/IP), když má rozhraní IP adresu. Dříve dhcp démoni nejprve přidělovali rozhraní IP adresu 0.0.0.0, ale to již nefunguje.
Přidávání
$IPT -I INPUT -i $INTIF -p udp --dport 67:68 --sport 67:68 -j ACCEPT
bude aktualizace DHCPD rychlejší :) Bude fungovat na obou stranách INPUT a OUTPUT. Můžete DROP dhcpd s ebtables, ne s iptables. DHCPD naslouchá na 0.0.0.0, nikoli v rámci IP
Moje nedávné pozorování na OpenWRT Kamikaze 7.09 =2.4.34 a udhcpc z busybox 1.4.2:
V řetězci OUTPUT mám zásadu „ACCEPT“ a ve směru INPUT jsem původně spoléhal na toto klasické pravidlo catch-all:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
abych povolil odpovědi DHCP v (mému udhcpc) na rozhraní WAN. To je místo, kde mi předřazený DHCP server mého ISP přiděluje IP adresu.
Pamatujte na rozdíl mezi počáteční výměnou DHCP (objevit, nabídnout, požadavek, potvrzení) a obnovením pronájmu DHCP (požadavek, potvrzení).
Po spuštění se udhcpc spustí úplnou počáteční výměnou. Tato výměna by byla úspěšná. A další obnovení nebo dvě by také uspěly - jen žádost a potvrzení. Server DHCP mého ISP obvykle požaduje dobu obnovení přibližně hodinu až 1,5 hodiny, takže můj klient DHCP žádá o obnovení každých 30 až 45 minut (toto chování je založeno na RFC).
Ale asi při třetím nebo čtvrtém obnovení by to začalo být zajímavé. TCPdump by ukázal asi tři pokusy o obnovení, po nichž by následovala úplná počáteční výměna - to v časovém rozpětí pouhých několika minut nebo dokonce sekund. Jako by se udhcpc nelíbilo, co dostal zpět :-( a nakonec by se spokojilo s úplnou výměnou. Poté by se povedlo další obnovení za půl hodiny... a příběh by se opakoval znovu.
Přišel jsem na to, že je možná chyba ve sledování připojení v jádře. Jako kdyby platnost položky conntrack vypršela přibližně po dvou hodinách a pozdější obnovení DHCP selžou, protože ACK ze serveru se ve skutečnosti nedostane do udhcpc naslouchajícího na soketu. Všimněte si, že tcpdump (libpcap) naslouchá na nezpracovaném rozhraní a může vidět všechny příchozí pakety, než budou podrobeny iptables. Jakmile se udhcpc vzdá obnovování a v zoufalství se pokusí začít znovu od nuly pomocí úplné výměny (počínaje příkazem DISCOVER), jádro vytvoří nový záznam conntrack a může ještě nějakou dobu rozumět souvisejícím paketům...
Jistě, jednou jsem přidal něco jako:
iptables -A INPUT -i $OUT_IF -p udp --sport 67 --dport 68 -j ACCEPT
Zdá se, že obnovení fungují navždy.
Následující argumenty cmdline tcpdump mohou být užitečné:
tcpdump -vv -s 1500 -i eth0.1 port 67 or port 68
Poznámka:-vv požádá o podrobný výstup disektoru. eth0.1 je můj WAN port (také rozhraní "NAT mimo").
Zajímavým atributem v ACK paketech je LT:pole =navrhovaná / maximální přidělená doba pronájmu v sekundách. Požadavky DHCP jsou odesílány z portu 68 na port 67. Odpovědi přicházejí z portu 67 na port 68.