Din hotspot-firewall blokerer DHCP før udlejningen

En ny telefon forbinder til din hotspot, viser ingen adresse og får aldrig en. Adgangspunktet er i orden, DHCP-dæmonen kører, og den firewallregel, du skrev, ser ud til at stemme med adresseplanen. Hvad den faktisk gør, er at kræve, at klienten allerede har den adresse, den beder om. Den første DHCP-pakke har slet ingen adresse, så reglen udløses aldrig.

Følg en klient, der forbinder

Følg én association fra klientens side. Radioen associerer, klienten sender en DHCP-opdagelse, serveren tilbyder, klienten anmoder, serveren bekræfter, og først derefter har klienten en adresse, der kan bruges til noget andet.

Alt før den endelige bekræftelse sker, mens klienten ikke kan bruge gatewayen til almindelig trafik. Det er det vindue, undernetreglen glemmer.

Hvad den første pakke egentlig indeholder

RFC 2131 fastslår, at en klients DHCP-udsendelser før den får en adresse, bruger kildeadressen nul. Meddelelser fra klient til server går til UDP-port 67, og fra server til klient til UDP-port 68. Opdagelsen ankommer derfor med 0.0.0.0 som kilde, og en regel, der kræver en kilde inde i dit klientundernet, matcher den simpelthen ikke.

Det er ikke en forkert konfiguration hos klienten. Det er protokollen, der virker som designet, i det eneste vindue, hvor den kan.

Hvilken vej håndterer det egentlig

Hvis adgangspunktet selv udleverer lejemål, er dette en lokal service-samtale, og i en IP-filtreret lokal vej handler det om input- og outputpolitik. Videresendt klienttrafik gennem VPN er en anden beslutning, og NAT for den trafik er igen noget andet. At blande de tre er, hvordan en snæver undtagelse bliver bred.

Hvor pakken håndteres, afhænger af dæmonen og den anvendte firewallfamilie. Rå-socket-implementeringer, broopsætninger og tidligere filtreringskroge kan flytte eller blokere den helt andre steder. Bekræft dæmonens interface-binding og de aktive kroge, før du tilføjer regler.

En generisk opskrift på ind- og udgående trafik kopieret fra et forum er ikke bevis for, at din implementering gennemløber de kæder på samme måde.

Svaret er ikke altid en udsendelse

En undtagelse, der kun tillader udsendte svar, er også forkert. DHCP-svarets destination afhænger af klientens tilstand og meddelelsens felter, og protokollen angiver både udsendelses- og unicast-tilfælde. Hvis din server svarer unicast til en adresse, den er ved at tildele, blokerer en regel kun for udsendelse det trin, der gør arbejdet færdigt. Skriv reglen mod den udveksling, den konfigurerede server faktisk udfører.

Senere fornyelser af lejemålet gentager udvekslingen i en anden tilstand, så giv plads til dem og ikke kun til den første forbindelse.

Ret snævert, og kontroller så resten

Behold den eksisterende politik, find den manglende DHCP-tilladelse, og afgræns den til det klientvendte interface, protokollen og de to porte. Bevis, at anmodningen når tjenesten, og bevis derefter, at tjenesten svarer. Det er to forskellige observationer, og service- eller puljekonfiguration kan stadig være forkert bag perfekt filtrering.

At tømme en tabel er ikke et DHCP-konfigurationstrin. I iptables sletter flush regler fra den valgte kæde eller tabel, og tømning af NAT-tabellen opretter ikke en oversættelsesregel. Brede ACCEPT-politikker fjerner beskyttelse, der ikke har med udlejning at gøre, og derfor hører ingen af de to hjemme i en genbrugelig hotspot-rettelse.

Når klienten har et lejemål, skal du kontrollere DNS, videresendelse og VPN-udgang som separate opgaver. Et lejemål etablerer lokal adressering og intet derudover.