Brannmuren til hotspotten din blokkerer DHCP før leigeavtalen

Ein ny telefon koplar seg til hotspotten din, viser inga adresse og får aldri ei. Aksesspunktet er i orden, DHCP-demonen køyrer, og brannmurregelen du skreiv ser ut til å stemme med adresseplanen. Det han faktisk gjer, er å krevje at klienten allereie har adressa han ber om. Den første DHCP-pakken har inga adresse i det heile, så regelen slår aldri inn.

Fylg med når ein klient koplar seg til

Fylg éin assosiasjon frå klientsida. Radioen assosierer, klienten sender ei DHCP-oppdaging, tenaren tilbyr, klienten ber om, tenaren stadfestar, og først då har klienten ei adresse som kan brukast til noko anna.

Alt før den siste stadfestinga skjer medan klienten ikkje kan bruke gatewayen til vanleg trafikk. Det er vindauget undernettregelen gløymer.

Kva den første pakken faktisk inneheld

RFC 2131 fastset at DHCP-kringkastingar frå ein klient før han får ei adresse brukar kjeldeadressa null. Meldingar frå klient til tenar går til UDP-port 67, og frå tenar til klient til UDP-port 68. Oppdaginga kjem derfor med 0.0.0.0 som kjelde, og ein regel som krev ei kjelde innanfor klientundernettet ditt, treff henne rett og slett ikkje.

Dette er ikkje feil konfigurasjon på klientsida. Det er protokollen som verkar som designa, i det einaste vindauget der han kan.

Kva veg som faktisk handterer det

Viss aksesspunktet sjølv deler ut leiger, er dette ein lokal tenestesamtale, og i ein IP-filtrert lokal veg gjeld det inngangs- og utgangspolicy. Vidaresend klienttrafikk gjennom VPN er eit anna vedtak, og NAT for den trafikken er igjen noko anna. Å blande dei tre er korleis eit smalt unntak blir breitt.

Kvar pakken blir handtert avheng av demonen og brannmurfamilien som blir brukt. Rå-socket-implementasjonar, bruoppsett og tidlegare filtreringskrokar kan flytte eller blokkere han heilt andre stader. Stadfest grensesnittbindinga til demonen og dei aktive krokane før du legg til reglar.

Ei generell oppskrift for inn- og utdata kopiert frå eit forum er ikkje prov på at implementasjonen din går gjennom dei kjedene på same måte.

Svaret er ikkje alltid ei kringkasting

Eit unntak som berre tillèt kringkasta svar, er også feil. Destinasjonen for DHCP-svaret avheng av tilstanden til klienten og felta i meldinga, og protokollen angir både kringkastings- og unicast-tilfellet. Viss tenaren din svarar med unicast til ei adresse han er i ferd med å dele ut, blokkerer ein regel berre for kringkasting trinnet som fullfører jobben. Skriv regelen mot utvekslinga den konfigurerte tenaren faktisk utfører.

Seinare fornyingar av leiga gjer utvekslinga om att i ein annan tilstand, så gi plass til dei og ikkje berre til den første tilkoplinga.

Rett smalt, og kontroller deretter resten

Behald den eksisterande policyen, finn DHCP-tillatinga som manglar, og avgrens henne til grensesnittet mot klienten, protokollen og dei to portane. Prov at førespurnaden når tenesta, og prov deretter at tenesta svarar. Det er to ulike observasjonar, og teneste- eller pool-konfigurasjon kan framleis vere feil bak perfekt filtrering.

Å tømme ein tabell er ikkje eit DHCP-konfigurasjonstrinn. I iptables slettar flush reglar frå den valde kjeda eller tabellen, og tømming av NAT-tabellen lagar ikkje ein omsetjingsregel. Breie ACCEPT-policyar fjernar vern som ikkje har med utleige å gjere, og derfor høyrer ingen av dei heime i ei gjenbrukbar hotspot-retting.

Når klienten har ei leige, kontroller DNS, vidaresending og VPN-utgang som separate oppgåver. Ei leige etablerer lokal adressering og ingenting utover det.