O firewall do seu hotspot bloqueia DHCP antes da concessão

Um telefone novo entra no seu hotspot, não mostra endereço e nunca recebe um. O ponto de acesso está bem, o daemon DHCP está em execução e a regra de firewall que você escreveu parece coerente com o plano de endereços. O que ela faz na verdade é exigir que o cliente já tenha o endereço que está pedindo. O primeiro pacote DHCP não tem endereço algum, então a regra nunca é acionada.

Observe um cliente entrar

Acompanhe uma associação do lado do cliente. O rádio associa, o cliente envia uma descoberta DHCP, o servidor oferece, o cliente solicita, o servidor confirma, e só então o cliente tem um endereço utilizável para qualquer outra coisa.

Tudo antes dessa confirmação final acontece enquanto o cliente não pode usar o gateway para tráfego comum. Essa é a janela que a regra de sub-rede esquece.

O que o primeiro pacote realmente contém

RFC 2131 especifica que as difusões DHCP de um cliente antes de obter um endereço usam um endereço de origem zero. As mensagens do cliente para o servidor vão para a porta UDP 67, e as do servidor para o cliente para a porta UDP 68. Por isso a descoberta chega com 0.0.0.0 como origem, e uma regra que exija uma origem dentro da sua sub-rede de clientes simplesmente não corresponde a ela.

Isso não é uma configuração errada por parte do cliente. É o protocolo funcionando como projetado, na única janela em que pode.

Qual caminho realmente lida com isso

Se o próprio ponto de acesso fornece concessões, isso é uma conversa de serviço local e, num caminho local filtrado por IP, diz respeito à política de entrada e saída. O tráfego de cliente encaminhado pela VPN é outra decisão, e o NAT para esse tráfego é outra ainda. Confundir os três é como uma exceção estreita se torna ampla.

Onde o pacote é tratado depende do daemon e da família de firewall em uso. Implementações com sockets brutos, montagens em ponte e ganchos de filtragem anteriores podem movê-lo ou bloqueá-lo num lugar completamente diferente. Confirme a ligação de interface do daemon e os ganchos ativos antes de adicionar regras.

Uma receita genérica de entrada e saída copiada de um fórum não é prova de que a sua implementação percorre essas cadeias da mesma forma.

A resposta nem sempre é uma difusão

Uma exceção que só permite respostas de difusão também está errada. O destino da resposta DHCP depende do estado do cliente e dos campos da mensagem, e o protocolo especifica tanto o caso de difusão quanto o de unicast. Se o seu servidor responde por unicast a um endereço que está prestes a atribuir, uma regra só de difusão bloqueia o passo que termina o trabalho. Escreva a regra segundo a troca que o servidor configurado realmente executa.

As renovações posteriores da concessão repetem a troca num estado diferente, então deixe espaço para elas e não apenas para a primeira conexão.

Corrija de forma estreita e depois verifique o resto

Mantenha a política existente, encontre a permissão DHCP que falta e limite-a à interface voltada ao cliente, ao protocolo e às duas portas. Prove que a solicitação chega ao serviço e depois prove que o serviço responde. São duas observações diferentes, e a configuração do serviço ou do conjunto de endereços ainda pode estar errada atrás de uma filtragem perfeita.

Esvaziar uma tabela não é um passo de configuração de DHCP. No iptables, o flush exclui regras da cadeia ou tabela selecionada, e esvaziar a tabela NAT não cria uma regra de tradução. Definir políticas ACCEPT amplas remove proteção não relacionada à concessão, por isso nenhuma das duas pertence a uma correção reutilizável para hotspot.

Assim que o cliente tiver uma concessão, verifique DNS, encaminhamento e saída da VPN como tarefas separadas. Uma concessão estabelece o endereçamento local e nada além disso.