El firewall de tu hotspot bloquea DHCP antes de la concesión

Un teléfono nuevo se une a tu hotspot, no muestra ninguna dirección y nunca obtiene una. El punto de acceso está bien, el demonio DHCP se ejecuta y la regla de firewall que escribiste parece coherente con el plan de direcciones. Lo que hace en realidad es exigir que el cliente ya tenga la dirección que solicita. El primer paquete DHCP no tiene ninguna dirección, así que la regla nunca se activa.

Observa cómo se une un cliente

Sigue una asociación desde el lado del cliente. La radio se asocia, el cliente envía un descubrimiento DHCP, el servidor ofrece, el cliente solicita, el servidor confirma y solo entonces el cliente tiene una dirección utilizable para cualquier otra cosa.

Todo lo anterior a esa confirmación final ocurre mientras el cliente no puede usar la puerta de enlace para el tráfico normal. Esa es la ventana que olvida la regla de subred.

Qué contiene realmente el primer paquete

RFC 2131 especifica que las difusiones DHCP de un cliente antes de obtener una dirección usan una dirección de origen cero. Los mensajes de cliente a servidor van al puerto UDP 67, y los de servidor a cliente al puerto UDP 68. Por eso el descubrimiento llega con 0.0.0.0 como origen, y una regla que exija un origen dentro de tu subred de clientes simplemente no coincide con él.

Eso no es una mala configuración por parte del cliente. Es el protocolo funcionando como se diseñó, en la única ventana en la que puede hacerlo.

Qué ruta lo gestiona realmente

Si el propio punto de acceso sirve concesiones, esto es una conversación de servicio local y, en una ruta local filtrada por IP, afecta a la política de entrada y salida. El tráfico de cliente reenviado por la VPN es otra decisión, y el NAT para ese tráfico es otra distinta. Confundir las tres es como una excepción estrecha se convierte en amplia.

Dónde se gestiona el paquete depende del demonio y de la familia de firewall en uso. Las implementaciones con sockets crudos, los montajes de puente y los enganches de filtrado anteriores pueden moverlo o bloquearlo en un lugar completamente distinto. Confirma la vinculación de interfaz del demonio y los enganches activos antes de añadir reglas.

Una receta genérica de entrada/salida copiada de un foro no es prueba de que tu implementación recorra esas cadenas de la misma manera.

La respuesta no siempre es una difusión

Una excepción que solo permite respuestas de difusión también es incorrecta. El destino de la respuesta DHCP depende del estado del cliente y de los campos del mensaje, y el protocolo especifica tanto el caso de difusión como el de unidifusión. Si tu servidor responde por unidifusión a una dirección que está a punto de asignar, una regla solo de difusión bloquea el paso que termina el trabajo. Escribe la regla según el intercambio que realiza realmente el servidor configurado.

Las renovaciones posteriores de la concesión repiten el intercambio en otro estado, así que deja espacio para ellas y no solo para la primera unión.

Corrige de forma estrecha y luego revisa el resto

Mantén la política existente, encuentra el permiso DHCP que falta y limítalo a la interfaz orientada al cliente, al protocolo y a los dos puertos. Demuestra que la solicitud llega al servicio y luego demuestra que el servicio responde. Son dos observaciones distintas, y la configuración del servicio o del grupo de direcciones todavía puede estar mal detrás de un filtrado perfecto.

Vaciar una tabla no es un paso de configuración de DHCP. En iptables, flush elimina reglas de la cadena o tabla seleccionada, y vaciar la tabla NAT no crea una regla de traducción. Establecer políticas ACCEPT amplias elimina protección no relacionada con la concesión, por lo que ninguna de las dos pertenece a una corrección reutilizable para un hotspot.

Una vez que el cliente tiene una concesión, comprueba DNS, reenvío y salida de la VPN como tareas separadas. Una concesión establece el direccionamiento local y nada más.