Jou hotspot-firewall blokkeer DHCP voor die huur

’n Nuwe selfoon sluit by jou hotspot aan, wys geen adres nie en kry nooit een nie. Die toegangspunt is reg, die DHCP-daemon loop, en die firewall-reël wat jy geskryf het lyk in ooreenstemming met die adresplan. Wat dit eintlik doen, is om te eis dat die kliënt reeds die adres het waarvoor hy vra. Die eerste DHCP-pakket het glad geen adres nie, so die reël werk nooit.

Kyk hoe ’n kliënt aansluit

Volg een assosiasie van die kliënt se kant. Die radio assosieer, die kliënt stuur ’n DHCP-ontdekking, die bediener bied aan, die kliënt versoek, die bediener bevestig, en eers dan het die kliënt ’n adres wat vir iets anders bruikbaar is.

Alles voor daardie finale bevestiging gebeur terwyl die kliënt nie die gateway vir gewone verkeer kan gebruik nie. Dit is die venster wat die subnet-reël vergeet.

Wat die eerste pakket werklik bevat

RFC 2131 bepaal dat ’n kliënt se DHCP-uitsendings voordat hy ’n adres kry, ’n bronadres van nul gebruik. Boodskappe van kliënt na bediener gaan na UDP-poort 67, en boodskappe van bediener na kliënt gaan na UDP-poort 68. Die ontdekking kom dus met 0.0.0.0 as bron, en ’n reël wat ’n bron binne jou kliënt-subnet vereis, pas eenvoudig nie daarop nie.

Dit is nie ’n verkeerde instelling aan die kliënt se kant nie. Dit is die protokol wat werk soos dit ontwerp is, in die enigste venster waar dit kan.

Watter pad dit werklik hanteer

As die toegangspunt self huurkontrakte bedien, is dit ’n plaaslike diensgesprek, en in ’n IP-gefilterde plaaslike pad raak dit invoer- en uitsetbeleid. Oorgedraagde kliëntverkeer deur die VPN is ’n ander besluit, en NAT vir daardie verkeer is weer anders. Om die drie te verwar, is hoe ’n smal uitsondering ’n breë een word.

Waar die pakket hanteer word, hang af van die daemon en die firewall-familie wat gebruik word. Rou-sok-implementerings, brugreëlings en vroeëre filterhake kan dit heeltemal elders skuif of blokkeer. Bevestig die daemon se koppelvlakbinding en die hake wat in werking is voordat jy reëls byvoeg.

’n Algemene invoer/uitset-resep wat van ’n forum gekopieer is, is nie bewys dat jou implementering dieselfde deur daardie kettings gaan nie.

Die antwoord is nie altyd ’n uitsending nie

’n Uitsondering wat slegs uitsendings-antwoorde toelaat, is ook verkeerd. Die bestemming van die DHCP-antwoord hang af van die kliënt se toestand en die boodskapvelde, en die protokol spesifiseer beide uitsending- en unicast-gevalle. As jou bediener unicast antwoord na ’n adres wat hy op die punt is om toe te wys, blokkeer ’n slegs-uitsending-reël die stap wat die taak voltooi. Skryf die reël teen die uitruiling wat die gekonfigureerde bediener werklik doen.

Latere huurhernuwings herhaal die uitruiling in ’n ander toestand, so laat ruimte daarvoor eerder as net vir die eerste aansluiting.

Maak dit smal reg, kyk dan na die res

Hou die bestaande beleid, vind die ontbrekende DHCP-toelating en beperk dit tot die kliëntgerigte koppelvlak, die protokol en die twee poorte. Bewys dat die versoek die diens bereik, bewys dan dat die diens antwoord. Dit is twee verskillende waarnemings, en diens- of poelkonfigurasie kan steeds verkeerd wees agter perfekte filtering.

Om ’n tabel te leegmaak is nie ’n DHCP-konfigurasiestap nie. In iptables verwyder flush reëls uit die gekose ketting of tabel, en om die NAT-tabel te leegmaak skep nie ’n omreël nie. Om breë ACCEPT-beleide te stel, verwyder beskerming wat nie met hure verband hou nie, en daarom hoort nie een van die twee in ’n herbruikbare hotspot-regmaak nie.

Sodra die kliënt ’n huur het, kyk na DNS, deurstuur en VPN-uitgang as afsonderlike take. ’n Huur vestig plaaslike adressering en niks verder nie.