Tenemos la mejor respuesta que hemos encontrado por todo internet. Queremos que te resulte de mucha utilidad y si quieres compartir alguna mejora siéntete libre de hacerlo..
Solución:
Voy a responder #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 de dhcp le daban primero a una interfaz la dirección IP de 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, en 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 de 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, reconocer) y una renovación de arrendamiento de DHCP (solicitar, reconocer).
Después del arranque, udhcpc comienza con el intercambio inicial completo. Ese intercambio tendría éxito. 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 quedara 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 usando un intercambio completo (comenzando con DISCOVER), el kernel establece una nueva entrada de control y puede comprender los paquetes relacionados por 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 tcpdump cmdline:
tcpdump -vv -s 1500 -i eth0.1 port 67 or port 68
Nota la -vv pide la salida detallada del disector. eth0.1 es mi puerto WAN (también una interfaz “NAT externa”).
Un interesante attribute en los paquetes ACK está el LT: campo = sugerido / máximo tiempo de concesión concedido 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.
Puedes añadir valor a nuestro contenido participando con tu experiencia en los comentarios.