Je hotspot-firewall blokkeert DHCP vóór de lease

Een nieuwe telefoon verbindt met je hotspot, toont geen adres en krijgt er nooit een. Het accesspoint is in orde, de DHCP-daemon draait, en de firewallregel die je schreef lijkt te kloppen met het adresplan. Wat die regel feitelijk doet, is eisen dat de client het adres dat hij aanvraagt al bezit. Het eerste DHCP-pakket heeft helemaal geen adres, dus de regel grijpt nooit in.

Kijk hoe een client verbindt

Volg één associatie vanaf de kant van de client. De radio associeert, de client stuurt een DHCP-discovery, de server biedt aan, de client vraagt aan, de server bevestigt, en pas dan heeft de client een adres dat voor iets anders bruikbaar is.

Alles vóór die laatste bevestiging gebeurt terwijl de client de gateway niet voor gewoon verkeer kan gebruiken. Dat is het venster dat de subnetregel vergeet.

Wat het eerste pakket werkelijk bevat

RFC 2131 bepaalt dat DHCP-broadcasts van een client vóór het verkrijgen van een adres een bronadres van nul gebruiken. Berichten van client naar server gaan naar UDP-poort 67, en van server naar client naar UDP-poort 68. De discovery komt dus met 0.0.0.0 als bron aan, en een regel die een bron binnen je clientsubnet eist, matcht daar simpelweg niet mee.

Dat is geen verkeerde configuratie aan de kant van de client. Dat is het protocol dat werkt zoals het is ontworpen, in het enige venster waarin dat kan.

Welk pad het werkelijk afhandelt

Als het accesspoint zelf leases uitgeeft, is dit een lokaal servicegesprek, en in een IP-gefilterd lokaal pad gaat het om in- en uitvoerbeleid. Doorgegeven clientverkeer via de VPN is een andere beslissing, en NAT voor dat verkeer is weer iets anders. Die drie door elkaar halen is hoe een smalle uitzondering breed wordt.

Waar het pakket wordt afgehandeld hangt af van de daemon en de gebruikte firewallfamilie. Raw-socket-implementaties, bridge-opstellingen en eerdere filterhaken kunnen het heel ergens anders verplaatsen of blokkeren. Bevestig de interfacebinding van de daemon en de actieve haken voordat je regels toevoegt.

Een algemeen recept voor in- en uitvoer dat van een forum is gekopieerd, is geen bewijs dat jouw implementatie die ketens op dezelfde manier doorloopt.

Het antwoord is niet altijd een broadcast

Een uitzondering die alleen broadcast-antwoorden toestaat, is ook onjuist. De bestemming van het DHCP-antwoord hangt af van de toestand van de client en de velden van het bericht, en het protocol schrijft zowel het broadcast- als het unicastgeval voor. Als je server per unicast antwoordt op een adres dat hij op het punt staat toe te wijzen, blokkeert een regel alleen voor broadcast de stap die het werk afmaakt. Schrijf de regel naar de uitwisseling die de geconfigureerde server werkelijk uitvoert.

Latere leasevernieuwingen herhalen de uitwisseling in een andere toestand, dus laat daar ruimte voor en niet alleen voor de eerste verbinding.

Repareer smal en controleer daarna de rest

Behoud het bestaande beleid, zoek de ontbrekende DHCP-toestemming en beperk die tot de interface aan de clientzijde, het protocol en de twee poorten. Bewijs dat het verzoek de dienst bereikt en bewijs daarna dat de dienst antwoordt. Dat zijn twee verschillende waarnemingen, en dienst- of poolconfiguratie kan achter perfecte filtering nog steeds fout zijn.

Een tabel leegmaken is geen DHCP-configuratiestap. In iptables verwijdert flush regels uit de gekozen keten of tabel, en het leegmaken van de NAT-tabel maakt geen vertaalregel aan. Brede ACCEPT-beleidsregels verwijderen bescherming die niets met leasen te maken heeft, en daarom hoort geen van beide in een herbruikbare hotspotoplossing.

Zodra de client een lease heeft, controleer je DNS, doorsturen en VPN-uitgang als afzonderlijke taken. Een lease stelt lokale adressering in en niets meer dan dat.