Contestaré #2:No.
Al obtener una dirección IP, el demonio dhcp crea un conector sin procesar para la interfaz de red y maneja el protocolo UDP. Por lo tanto, los paquetes UDP nunca pasan por iptables.
La razón por la que el demonio dhcp tiene que implementar UDP es que el kernel solo puede manejar UDP (de hecho, todo el paquete TCP/IP) cuando la interfaz tiene una dirección IP. Anteriormente, los demonios dhcp le daban primero a una interfaz la dirección IP 0.0.0.0, pero eso ya no funciona.
Agregando
$IPT -I INPUT -i $INTIF -p udp --dport 67:68 --sport 67:68 -j ACCEPT
hará que la actualización de DHCPD sea más rápida :) Funcionará tanto en la ENTRADA como en la SALIDA. Puede DROP dhcpd con ebtables, no con iptables. DHCPD escuchando en 0.0.0.0, no dentro de IP
Mi observación reciente, sobre OpenWRT Kamikaze 7.09 =2.4.34 y udhcpc de busybox 1.4.2:
Tengo una política de "ACEPTAR" en la cadena de SALIDA, y en la dirección de ENTRADA, originalmente me basé en esta regla general clásica:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
para permitir las respuestas DHCP (a mi udhcpc) en la interfaz WAN. Es decir, aquí es donde el servidor DHCP ascendente de mi ISP me asigna una dirección IP.
Tenga en cuenta la diferencia entre un intercambio de DHCP inicial (descubrir, ofrecer, solicitar, confirmar) y una renovación de arrendamiento de DHCP (solicitar, confirmar).
Después del arranque, udhcpc comienza con el intercambio inicial completo. Ese intercambio se realizará correctamente. Y otra renovación o dos también tendrían éxito, solo una solicitud y reconocimiento. El servidor DHCP de mi ISP generalmente solicita un tiempo de renovación de aproximadamente una hora a 1,5 horas, por lo que mi cliente DHCP solicita una renovación cada 30 a 45 minutos (este comportamiento se basa en el RFC).
Pero, alrededor de la tercera o cuarta renovación, comenzaría a ponerse interesante. TCPdump mostraría alrededor de tres o más intentos de renovación, seguidos de un intercambio inicial completo, eso dentro de un período de tiempo de solo unos minutos o incluso segundos. Como si a udhcpc no le gustara lo que recibió :-( y finalmente quedaría satisfecho con el intercambio completo. Después de eso, otra renovación en media hora tendría éxito... y la historia se repetiría nuevamente.
Me di cuenta de que quizás sea el seguimiento de la conexión en el kernel el que tiene algo mal. Como si la entrada de conntrack caduca después de dos horas más o menos, y las renovaciones posteriores de DHCP fallan porque el ACK del servidor en realidad no llega a udhcpc escuchando en el socket. Tenga en cuenta que tcpdump (libpcap) escucha en la interfaz sin procesar y puede ver todos los paquetes que ingresan, antes de que estén sujetos a iptables. Una vez que udhcpc renuncia a las renovaciones y, desesperado, intenta comenzar de cero utilizando un intercambio completo (comenzando con DISCOVER), el núcleo establece una nueva entrada de control y puede comprender los paquetes relacionados durante más tiempo...
Efectivamente, una vez que agregué algo como:
iptables -A INPUT -i $OUT_IF -p udp --sport 67 --dport 68 -j ACCEPT
las renovaciones parecen funcionar para siempre.
Puede encontrar útiles los siguientes argumentos de tcpdump cmdline:
tcpdump -vv -s 1500 -i eth0.1 port 67 or port 68
Nota:el -vv pide la salida detallada del disector. eth0.1 es mi puerto WAN (también una interfaz "NAT externa").
Un atributo interesante en los paquetes ACK es el LT:campo =sugerido / tiempo de concesión máximo otorgado en segundos. Las solicitudes de DHCP se envían desde el puerto 68 al puerto 67. Las respuestas provienen del puerto 67 al puerto 68.