Hotspot-brannmuren din blokkerer DHCP før leieavtalen

En ny telefon kobler seg til hotspoten din, viser ingen adresse og får aldri en. Aksesspunktet er i orden, DHCP-demonen kjører, og brannmurregelen du skrev ser ut til å stemme med adresseplanen. Det den faktisk gjør, er å kreve at klienten allerede har adressen den ber om. Den første DHCP-pakken har ingen adresse i det hele tatt, så regelen utløses aldri.

Følg med når en klient kobler seg til

Følg én assosiasjon fra klientsiden. Radioen assosierer, klienten sender en DHCP-oppdagelse, serveren tilbyr, klienten ber om, serveren bekrefter, og først da har klienten en adresse som kan brukes til noe annet.

Alt før den endelige bekreftelsen skjer mens klienten ikke kan bruke gatewayen til vanlig trafikk. Det er vinduet undernettregelen glemmer.

Hva den første pakken faktisk inneholder

RFC 2131 fastslår at en klients DHCP-kringkastinger før den får en adresse bruker kildeadressen null. Meldinger fra klient til server går til UDP-port 67, og fra server til klient til UDP-port 68. Oppdagelsen ankommer derfor med 0.0.0.0 som kilde, og en regel som krever en kilde innenfor klientundernettet ditt, treffer den rett og slett ikke.

Dette er ikke feil konfigurasjon på klientsiden. Det er protokollen som virker som designet, i det eneste vinduet der den kan.

Hvilken vei som faktisk håndterer det

Hvis aksesspunktet selv deler ut leier, er dette en lokal tjenestesamtale, og i en IP-filtrert lokal vei gjelder det inngangs- og utgangspolicy. Videreformidlet klienttrafikk gjennom VPN er en annen beslutning, og NAT for den trafikken er igjen noe annet. Å blande de tre er hvordan et smalt unntak blir bredt.

Hvor pakken håndteres avhenger av demonen og brannmurfamilien som brukes. Rå-socket-implementasjoner, brooppsett og tidligere filtreringskroker kan flytte eller blokkere den helt andre steder. Bekreft demonens grensesnittbinding og de aktive krokene før du legger til regler.

En generisk oppskrift for inn- og utdata kopiert fra et forum er ikke bevis for at implementasjonen din går gjennom de kjedene på samme måte.

Svaret er ikke alltid en kringkasting

Et unntak som bare tillater kringkastede svar, er også feil. Destinasjonen for DHCP-svaret avhenger av klientens tilstand og meldingens felt, og protokollen angir både kringkastings- og unicast-tilfellet. Hvis serveren din svarer med unicast til en adresse den er i ferd med å tildele, blokkerer en regel kun for kringkasting trinnet som fullfører jobben. Skriv regelen mot utvekslingen den konfigurerte serveren faktisk utfører.

Senere fornyelser av leien gjentar utvekslingen i en annen tilstand, så gi plass til dem og ikke bare til den første tilkoblingen.

Rett smalt, og kontroller deretter resten

Behold den eksisterende policyen, finn DHCP-tillatelsen som mangler, og begrens den til grensesnittet mot klienten, protokollen og de to portene. Bevis at forespørselen når tjenesten, og bevis deretter at tjenesten svarer. Det er to forskjellige observasjoner, og tjeneste- eller pool-konfigurasjon kan fortsatt være feil bak perfekt filtrering.

Å tømme en tabell er ikke et DHCP-konfigurasjonstrinn. I iptables sletter flush regler fra den valgte kjeden eller tabellen, og tømming av NAT-tabellen oppretter ikke en oversettelsesregel. Brede ACCEPT-policyer fjerner beskyttelse som ikke har med utleie å gjøre, og derfor hører ingen av dem hjemme i en gjenbrukbar hotspot-rettelse.

Når klienten har en leie, kontroller DNS, videresending og VPN-utgang som separate oppgaver. En leie etablerer lokal adressering og ingenting utover det.