私は答えます #2:いいえ
IP アドレスを取得すると、dhcp デーモンはネットワーク インターフェイスへの raw ソケットを作成し、UDP プロトコル自体を処理します。したがって、UDP パケットは iptables を通過しません。
dhcp デーモンが UDP を実装しなければならない理由は、インターフェイスに IP アドレスがある場合、カーネルが UDP (実際にはすべての TCP/IP スイート) しか処理できないためです。以前は、dhcp デーモンは最初にインターフェイスに 0.0.0.0 の IP アドレスを与えていましたが、それは機能しなくなりました。
追加
$IPT -I INPUT -i $INTIF -p udp --dport 67:68 --sport 67:68 -j ACCEPT
DHCPD の更新を高速化します:) INPUT と OUTPUT の両方で機能します。 iptables ではなく、ebtables を使用して dhcpd を削除できます。 IP 内ではなく、0.0.0.0 でリッスンする DHCPD
OpenWRT Kamikaze 7.09 =2.4.34 および busybox 1.4.2 の udhcpc に関する私の最近の観察:
OUTPUT チェーンには "ACCEPT" ポリシーがあり、INPUT 方向では、もともとこの古典的なキャッチオール ルールに依存していました。
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
WAN インターフェイスで (udhcpc への) DHCP 応答を許可します。つまり、これは、ISP のアップストリーム DHCP サーバーが IP アドレスを私に割り当てる場所です。
最初の DHCP 交換 (検出、提供、要求、確認) と DHCP リースの更新 (要求、確認) の違いに注意してください。
ブート後、udhcpc は完全な初期交換によって開始されます。この交換は成功します。そして、もう 1 つか 2 つの更新も成功します - 要求と承認だけです。私の ISP の DHCP サーバーは通常、約 1 時間から 1.5 時間の更新時間を要求するため、私の DHCP クライアントは 30 分から 45 分ごとに更新を要求します (この動作は RFC に基づいています)。
でも、3回目か4回目の更新くらいから面白くなってきました。 TCPdump では、約 3 回の更新試行が表示され、その後、最初の完全な交換が行われます。これは、わずか数分または数秒の間に発生します。あたかも udhcpc が返されたものを気に入らなかったかのように :-( そして、最終的には完全な交換に満足するでしょう。その後、30 分後に別の更新が成功し、話が再び繰り返されます。
おそらく、カーネルの接続追跡に問題があることがわかりました。 conntrack エントリが 2 時間ほど後に期限切れになり、サーバーからの ACK がソケットでリッスンしている udhcpc に実際に到達しないため、その後の DHCP 更新が失敗するかのように。 tcpdump (libpcap) は未加工のインターフェイスでリッスンし、着信するすべてのパケットを iptables の対象になる前に確認できることに注意してください。 udhcpc が更新を断念し、絶望的に完全な交換 (DISCOVER から開始) を使用して最初からやり直そうとすると、カーネルは新しい conntrack エントリを確立し、関連するパケットをもう少しの間理解できるようになります...
案の定、次のようなものを追加したら:
iptables -A INPUT -i $OUT_IF -p udp --sport 67 --dport 68 -j ACCEPT
更新は永久に機能するようです。
次の tcpdump コマンドライン引数が役立つ場合があります:
tcpdump -vv -s 1500 -i eth0.1 port 67 or port 68
注:-vv 詳細なディセクタ出力を要求します。 eth0.1 私のWANポートです（「NAT外部」インターフェースでもあります）。
ACK パケットの興味深い属性は LT です。フィールド =提案された秒数 / 許可された最大リース時間 (秒単位)。DHCP 要求はポート 68 からポート 67 に送信されます。応答はポート 67 からポート 68 に送信されます。