Il firewall del tuo hotspot blocca DHCP prima del lease

Un nuovo telefono si unisce al tuo hotspot, non mostra alcun indirizzo e non ne ottiene mai uno. Il punto di accesso è a posto, il demone DHCP è in esecuzione e la regola del firewall che hai scritto sembra coerente con il piano degli indirizzi. In realtà esige che il client possieda già l’indirizzo che sta chiedendo. Il primo pacchetto DHCP non ha alcun indirizzo, quindi la regola non scatta mai.

Osserva un client che si unisce

Segui un’associazione dal lato del client. La radio si associa, il client invia una scoperta DHCP, il server offre, il client richiede, il server conferma, e solo allora il client ha un indirizzo utilizzabile per qualsiasi altra cosa.

Tutto ciò che precede quella conferma finale avviene mentre il client non può usare il gateway per il traffico ordinario. È proprio la finestra che la regola della sottorete dimentica.

Che cosa contiene davvero il primo pacchetto

RFC 2131 specifica che le diffusioni DHCP di un client prima di ottenere un indirizzo usano un indirizzo di origine zero. I messaggi dal client al server vanno alla porta UDP 67, e quelli dal server al client alla porta UDP 68. La scoperta arriva quindi con 0.0.0.0 come origine, e una regola che richiede un’origine all’interno della tua sottorete client semplicemente non corrisponde.

Non è una configurazione errata da parte del client. È il protocollo che funziona come previsto, nell’unica finestra in cui può farlo.

Quale percorso lo gestisce davvero

Se il punto di accesso stesso fornisce i lease, questa è una conversazione di servizio locale e, in un percorso locale filtrato per IP, riguarda la politica di input e output. Il traffico client inoltrato tramite la VPN è un’altra decisione, e il NAT per quel traffico è ancora un’altra. Confondere le tre è il modo in cui un’eccezione stretta diventa ampia.

Dove viene gestito il pacchetto dipende dal demone e dalla famiglia di firewall in uso. Le implementazioni a socket grezzi, le configurazioni a ponte e gli hook di filtraggio precedenti possono spostarlo o bloccarlo altrove del tutto. Conferma il binding dell’interfaccia del demone e gli hook attivi prima di aggiungere regole.

Una ricetta generica di input e output copiata da un forum non è prova che la tua implementazione attraversi quelle catene allo stesso modo.

La risposta non è sempre una diffusione

Anche un’eccezione che consente solo risposte in diffusione è sbagliata. La destinazione della risposta DHCP dipende dallo stato del client e dai campi del messaggio, e il protocollo specifica sia il caso di diffusione sia quello unicast. Se il tuo server risponde unicast a un indirizzo che sta per assegnare, una regola solo per la diffusione blocca il passo che completa il lavoro. Scrivi la regola in base allo scambio che il server configurato esegue davvero.

I rinnovi successivi del lease ripetono lo scambio in uno stato diverso, quindi lascia spazio anche a loro e non solo al primo collegamento.

Correggi in modo mirato, poi controlla il resto

Mantieni la politica esistente, trova l’autorizzazione DHCP mancante e limitala all’interfaccia rivolta al client, al protocollo e alle due porte. Dimostra che la richiesta raggiunge il servizio, poi dimostra che il servizio risponde. Sono due osservazioni diverse, e la configurazione del servizio o del pool può comunque essere errata dietro un filtraggio perfetto.

Svuotare una tabella non è un passo di configurazione DHCP. In iptables, flush elimina le regole dalla catena o dalla tabella selezionata, e svuotare la tabella NAT non crea una regola di traduzione. Impostare politiche ACCEPT ampie rimuove una protezione non legata al lease, ed è per questo che nessuna delle due appartiene a una correzione riutilizzabile per un hotspot.

Una volta che il client ha un lease, controlla DNS, inoltro e uscita VPN come attività separate. Un lease stabilisce l’indirizzamento locale e nulla di più.