Saya akan menjawab #2:Tidak.
Saat mendapatkan alamat IP, daemon dhcp membuat soket mentah ke antarmuka jaringan dan menangani protokol UDP itu sendiri. Dengan demikian paket UDP tidak pernah melewati iptables.
Alasan daemon dhcp harus mengimplementasikan UDP adalah karena kernel hanya dapat menangani UDP (sebenarnya semua suite TCP/IP) ketika antarmuka memiliki alamat IP. Daemon dhcp sebelumnya pertama-tama akan memberikan antarmuka alamat IP 0.0.0.0 tetapi itu tidak lagi berfungsi.
Menambahkan
$IPT -I INPUT -i $INTIF -p udp --dport 67:68 --sport 67:68 -j ACCEPT
akan membuat pembaruan DHCPD lebih cepat :) Ini akan bekerja di kedua sisi INPUT dan OUTPUT. Anda dapat DROP dhcpd dengan ebtables, bukan dengan iptables. DHCPD mendengarkan pada 0.0.0.0, bukan dalam IP
Pengamatan terakhir saya, pada OpenWRT Kamikaze 7.09 =2.4.34 dan udhcpc dari busybox 1.4.2 :
Saya memiliki kebijakan "TERIMA" di rantai OUTPUT, dan di arah INPUT, awalnya saya mengandalkan aturan penampung-semua klasik ini:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
untuk mengizinkan respons DHCP masuk (ke udhcpc saya) pada antarmuka WAN. Yaitu, di sinilah server DHCP hulu ISP saya memberikan Alamat IP kepada saya.
Perhatikan perbedaan antara pertukaran DHCP awal (temukan, tawarkan, minta, terima) dan perpanjangan sewa DHCP (permintaan, terima).
Setelah boot, udhcpc dimulai dengan pertukaran awal penuh. Pertukaran itu akan berhasil. Dan satu atau dua pembaruan lainnya juga akan berhasil - hanya permintaan dan pengakuan. Server DHCP ISP saya biasanya meminta waktu pembaruan sekitar satu jam hingga 1,5 jam, jadi klien DHCP saya meminta pembaruan setiap 30 hingga 45 menit (perilaku ini berdasarkan RFC).
Tapi, kira-kira pada pembaruan ketiga atau keempat, itu akan mulai menarik. TCPdump akan menampilkan sekitar tiga atau lebih upaya pembaruan, diikuti dengan pertukaran awal penuh - yang dalam rentang waktu hanya beberapa menit atau bahkan detik. Seolah udhcpc tidak menyukai apa yang didapatnya kembali :-( dan pada akhirnya akan puas dengan pertukaran penuh. Setelah itu, pembaruan lain dalam waktu setengah jam akan berhasil... dan ceritanya akan berulang lagi.
Saya menemukan, bahwa mungkin pelacakan koneksi di kernel yang salah. Seolah-olah entri conntrack kedaluwarsa setelah dua jam atau lebih, dan pembaruan DHCP yang lebih baru gagal karena ACK dari server tidak benar-benar berhasil mendengarkan udhcpc di soket. Perhatikan bahwa tcpdump (libpcap) mendengarkan pada antarmuka mentah dan dapat melihat semua paket masuk, sebelum tunduk pada iptables. Setelah udhcpc menghentikan perpanjangan dan, putus asa, mencoba untuk memulai dari awal menggunakan pertukaran penuh (dimulai dengan DISCOVER), kernel membuat entri conntrack baru dan dapat memahami paket terkait untuk beberapa waktu lagi...
Benar saja, setelah saya menambahkan sesuatu seperti:
iptables -A INPUT -i $OUT_IF -p udp --sport 67 --dport 68 -j ACCEPT
pembaruan tampaknya berfungsi selamanya.
Anda mungkin menemukan argumen cmdline tcpdump berikut berguna:
tcpdump -vv -s 1500 -i eth0.1 port 67 or port 68
Catatan:-vv meminta output disektor verbose. eth0.1 adalah port WAN saya (juga antarmuka "NAT di luar").
Atribut yang menarik dalam paket ACK adalah LT:field =saran / maksimum waktu sewa yang diberikan dalam hitungan detik. Permintaan DHCP dikirim dari port 68 ke port 67. Respons datang dari port 67 ke port 68.