O teu cortafocos do hotspot bloquea DHCP antes da concesión

Un teléfono novo únese ao teu hotspot, non mostra ningún enderezo e nunca obtén un. O punto de acceso está ben, o daemon DHCP está en execución e a regra de cortafocos que escribiches parece coherente co plan de enderezos. O que fai en realidade é esixir que o cliente xa teña o enderezo que solicita. O primeiro paquete DHCP non ten ningún enderezo, así que a regra nunca se activa.

Observa como se une un cliente

Segue unha asociación desde o lado do cliente. A radio asóciase, o cliente envía un descubrimento DHCP, o servidor ofrece, o cliente solicita, o servidor confirma e só entón o cliente ten un enderezo utilizábel para calquera outra cousa.

Todo o anterior a esa confirmación final ocorre mentres o cliente non pode usar a porta de enlace para o tráfico normal. Esa é a xanela que esquece a regra de subrede.

Que contén realmente o primeiro paquete

RFC 2131 especifica que as difusións DHCP dun cliente antes de obter un enderezo usan un enderezo de orixe cero. As mensaxes de cliente a servidor van ao porto UDP 67, e as de servidor a cliente ao porto UDP 68. Por iso o descubrimento chega con 0.0.0.0 como orixe, e unha regra que esixa unha orixe dentro da túa subrede de clientes simplemente non coincide con el.

Isto non é unha mala configuración por parte do cliente. É o protocolo funcionando como se deseñou, na única xanela na que pode facelo.

Que ruta o xestiona realmente

Se o propio punto de acceso serve concesións, isto é unha conversa de servizo local e, nunha ruta local filtrada por IP, afecta á política de entrada e saída. O tráfico de cliente reenviado pola VPN é outra decisión, e o NAT para ese tráfico é outra distinta. Confundir as tres é como unha excepción estreita se converte en ampla.

Onde se xestiona o paquete depende do daemon e da familia de cortafocos en uso. As implementacións con sockets crueis, as montaxes de ponte e os enganches de filtrado anteriores poden movelo ou bloquealo nun lugar completamente distinto. Confirma a vinculación de interface do daemon e os enganches activos antes de engadir regras.

Unha receita xenérica de entrada e saída copiada dun foro non é proba de que a túa implementación percorra esas cadeas do mesmo xeito.

A resposta non sempre é unha difusión

Unha excepción que só permite respostas de difusión tamén é incorrecta. O destino da resposta DHCP depende do estado do cliente e dos campos da mensaxe, e o protocolo especifica tanto o caso de difusión como o de unicast. Se o teu servidor responde por unicast a un enderezo que está a piques de asignar, unha regra só de difusión bloquea o paso que remata o traballo. Escribe a regra segundo o intercambio que realiza realmente o servidor configurado.

As renovacións posteriores da concesión repiten o intercambio noutro estado, así que deixa espazo para elas e non só para a primeira unión.

Corrixe de forma estreita e logo revisa o resto

Mantén a política existente, atopa o permiso DHCP que falta e limítao á interface orientada ao cliente, ao protocolo e aos dous portos. Demostra que a solicitude chega ao servizo e logo demostra que o servizo responde. Son dúas observacións distintas, e a configuración do servizo ou do conxunto de enderezos aínda pode estar mal detrás dun filtrado perfecto.

Baleirar unha táboa non é un paso de configuración de DHCP. En iptables, flush elimina regras da cadea ou táboa seleccionada, e baleirar a táboa NAT non crea unha regra de tradución. Establecer políticas ACCEPT amplas elimina protección non relacionada coa concesión, polo que ningunha das dúas pertence a unha corrección reutilizábel para un hotspot.

Unha vez que o cliente ten unha concesión, comproba DNS, reenvío e saída da VPN como tarefas separadas. Unha concesión establece o enderezamento local e nada máis.