Sinu hotspoti tulemüür blokeerib DHCP enne rendilepingu andmist

Uus telefon liitub sinu hotspotiga, ei näita aadressi ega saa seda kunagi. Juurdepääsupunkt on korras, DHCP-deemon töötab ja kirjutatud tulemüürireegel näib aadressiplaaniga kooskõlas olevat. Tegelikult nõuab see, et kliendil oleks juba see aadress, mida ta küsib. Esimesel DHCP-paketil pole üldse aadressi, seega reegel ei rakendu kunagi.

Vaata, kuidas klient liitub

Jälgi üht seost kliendi poolelt. Raadio seostub, klient saadab DHCP-avastuse, server pakub, klient küsib, server kinnitab ja alles siis on kliendil aadress, mida saab millegi muu jaoks kasutada.

Kõik enne seda lõplikku kinnitust toimub ajal, mil klient ei saa lüüsi tavaliikluseks kasutada. See on aken, mille alamvõrgu reegel unustab.

Mida esimene pakett tegelikult sisaldab

RFC 2131 sätestab, et kliendi DHCP-ringhäälingud enne aadressi saamist kasutavad allikaaadressi null. Kliendilt serverile suunduvad sõnumid UDP-pordile 67 ja serverilt kliendile UDP-pordile 68. Avastus saabub seega allikaga 0.0.0.0, ja reegel, mis nõuab allikat sinu kliendi alamvõrgus, lihtsalt ei sobi sellega.

See pole kliendi poolne vale seadistus. See on protokoll, mis töötab nii, nagu on kavandatud, ainsas aknas, kus see võimalik on.

Milline tee seda tegelikult käsitleb

Kui juurdepääsupunkt ise rendilepinguid jagab, on see kohalik teenusekõnelus ja IP-filtreeritud kohalikul teel puudutab see sisend- ja väljundpoliitikat. VPN-i kaudu edastatud kliendiliiklus on teine otsus ja selle liikluse NAT on jälle midagi muud. Nende kolme segamine on viis, kuidas kitsast erandist saab lai.

Kus paketti käsitletakse, sõltub deemonist ja kasutatavast tulemüüriperekonnast. Toorsoketi rakendused, sillasätted ja varasemad filtreerimiskonksud võivad selle hoopis mujale liigutada või blokeerida. Kinnita deemoni liidese sidumine ja aktiivsed konksud enne reeglite lisamist.

Foorumist kopeeritud üldine sisend- ja väljundiretsept ei ole tõestus, et sinu rakendus läbib neid ahelaid samamoodi.

Vastus ei ole alati ringhääling

Ka erand, mis lubab ainult ringhäälingu vastuseid, on vale. DHCP-vastuse sihtkoht sõltub kliendi olekust ja sõnumi väljadest ning protokoll määratleb nii ringhäälingu kui ka üksiksaate juhtumi. Kui sinu server vastab üksiksaatena aadressile, mille ta just jagab, blokeerib ainult ringhäälingu reegel sammu, mis töö lõpetab. Kirjuta reegel lähtudes vahetusest, mida seadistatud server tegelikult teeb.

Hiljemad rendilepingu uuendused kordavad vahetust teises olekus, seega jäta nende jaoks ruumi, mitte ainult esimese liitumise jaoks.

Paranda kitsalt, siis kontrolli ülejäänut

Hoia olemasolev poliitika, leia puuduv DHCP-luba ja piira see kliendi poole suunatud liidese, protokolli ja kahe pordiga. Tõesta, et päring jõuab teenuseni, seejärel tõesta, et teenus vastab. Need on kaks eri vaatlust ja teenuse või aadressibasseini seadistus võib täiusliku filtreerimise taga ikkagi vale olla.

Tabeli tühjendamine ei ole DHCP seadistamise samm. Iptablesis kustutab flush valitud ahelast või tabelist reeglid ja NAT-tabeli tühjendamine ei loo tõlkereeglit. Laiade ACCEPT-poliitikate seadmine eemaldab rendileandmisega mitteseotud kaitse, mistõttu ei kuulu kumbki korduvkasutatavasse hotspoti parandusse.

Kui kliendil on rendileping, kontrolli DNS-i, edastamist ja VPN-i väljundit eraldi ülesannetena. Rendileping loob kohaliku adresseerimise ega midagi enamat.