Jo hotspot-firewall blokket DHCP foar de hier

In nije telefoan ferbynt him mei jo hotspot, lit gjin adres sjen en krijt der nea ien. It tagongspunt is yn oarder, de DHCP-daemon draait, en de firewall-regel dy't jo skreaun hawwe liket oerien te kommen mei it adresplan. Wat er eins docht, is easke dat de kliïnt it adres dat er oanfreget al hat. It earste DHCP-pakket hat hielendal gjin adres, dat de regel wurdt nea aktivearre.

Sjoch hoe't in kliïnt him ferbynt

Folgje ien assosjaasje fan 'e kliïntkant. De radio assosjearret, de kliïnt stjoert in DHCP-ûntdekking, de tsjinner biedt oan, de kliïnt freget, de tsjinner befêstiget, en pas dan hat de kliïnt in adres dat foar wat oars brûkber is.

Alles foar dy lêste befêstiging bart wylst de kliïnt de gateway net foar gewoan ferkear brûke kin. Dat is it finster dat de subnet-regel ferjit.

Wat it earste pakket eins befettet

RFC 2131 bepaalt dat DHCP-útstjoerings fan in kliïnt foardat er in adres krijt in boarneadres fan nul brûke. Berjochten fan kliïnt nei tsjinner gean nei UDP-poarte 67, en fan tsjinner nei kliïnt nei UDP-poarte 68. De ûntdekking komt dus mei 0.0.0.0 as boarne, en in regel dy't in boarne binnen jo kliïnt-subnet easket, past der gewoan net op.

Dat is gjin ferkearde konfiguraasje fan 'e kliïnt. Dat is it protokol dat wurket sa't it ûntwurpen is, yn it ienige finster dêr't it kin.

Hokker paad behannelt it eins

As it tagongspunt sels hieren úttsjinnet, is dit in lokale tsjinstpetear, en yn in IP-filtern lokale paad giet it om ynfier- en útfierbelied. Trochstjoerd kliïntferkear fia de VPN is in oare beslissing, en NAT foar dat ferkear is wer oars. It trochinoar heljen fan dy trije is hoe't in smelle útsûndering in brede wurdt.

Wêr't it pakket behannele wurdt, hinget ôf fan 'e daemon en de firewalfamylje dy't brûkt wurdt. Rau-socket-ymplemintaasjes, brêge-opstellings en eardere filterheakken kinne it hielendal earne oars ferpleatse of blokkearje. Befêstigje de ynterfacebining fan 'e daemon en de aktyf heakken foardat jo regels tafoegje.

In generysk resept foar yn- en útfier kopiearre fan in forum is gjin bewiis dat jo ymplemintaasje deselde keatlingen itselde paad trochrint.

It antwurd is net altyd in útstjoering

In útsûndering dy't allinnich útstjoerde antwurden tastiet, is ek ferkeard. De bestimming fan it DHCP-antwurd hinget ôf fan 'e tastân fan 'e kliïnt en de fjilden fan it berjocht, en it protokol beskriuwt sawol it útstjoer- as it unicast-gefal. As jo tsjinner unicast antwurdet op in adres dat er krekt tawize sil, blokkearret in regel allinnich foar útstjoering de stap dy't it wurk dien makket. Skriuw de regel tsjin de útwikseling oan dy't de konfigurearre tsjinner eins docht.

Lettere hierfernijings werhelje de útwikseling yn in oare tastân, dus lit romte foar har en net allinnich foar de earste ferbining.

Reparearje smel, kontrolearje dan de rest

Hâld it besteande belied, fyn de ûntbrekkende DHCP-tastimming en behein dy ta de ynterface nei de kliïnt, it protokol en de twa poarten. Bewiis dat it fersyk de tsjinst berikt, bewiis dan dat de tsjinst antwurdet. Dat binne twa ferskillende waarnimmings, en tsjinst- of poelkonfiguraasje kin efter perfekte filtering noch altyd ferkeard wêze.

In tabel leegje is gjin DHCP-konfiguraasjestap. Yn iptables smyt flush regels fuort út 'e keazen keatling of tabel, en it leegjen fan 'e NAT-tabel makket gjin oersettingsregel. It ynstellen fan brede ACCEPT-belieds ferwideret beskerming dy't neat mei hierjen te meitsjen hat, en dêrom heart gjin fan beide yn in werbrûkbere hotspot-reparaasje.

Sadree't de kliïnt in hier hat, kontrolearje DNS, trochstjoering en VPN-útgong as aparte taken. In hier fêstiget lokale adressearring en neat mear.