Eldveggur hotspotsins þíns lokar DHCP fyrir leiguna

Nýr sími tengist hotspotinu þínu, sýnir ekkert vistfang og fær aldrei neitt. Aðgangspunkturinn er í lagi, DHCP-púkinn keyrir og eldveggsreglan sem þú skrifaðir virðist samræmast vistfangaskipulaginu. Það sem hún gerir í raun er að krefjast þess að biðlarinn hafi þegar vistfangið sem hann biður um. Fyrsti DHCP-pakki hefur ekkert vistfang, svo reglan verkar aldrei.

Fylgstu með biðlara tengjast

Fylgdu einni samtengingu frá hlið biðlarans. Þráðlaust tækið tengist, biðlarinn sendir DHCP-uppgötvun, netþjónninn býður, biðlarinn biður, netþjónninn staðfestir og aðeins þá hefur biðlarinn vistfang sem nýtist fyrir eitthvað annað.

Allt sem gerist fyrir þá lokastöðfestingu gerist á meðan biðlarinn getur ekki notað gáttina fyrir venjulega umferð. Það er glugginn sem undirnetsreglan gleymir.

Hvað fyrsti pakkinn inniheldur í raun

RFC 2131 tilgreinir að DHCP-útvarp biðlara fyrir vistfang noti núll upprunavistfang. Skilaboð frá biðlara til netþjóns fara á UDP-gátt 67 og frá netþjóni til biðlara á UDP-gátt 68. Uppgötvunin kemur því með 0.0.0.0 sem uppruna, og regla sem krefst uppruna innan undirnets biðlarans passar einfaldlega ekki við hana.

Þetta er ekki rangstilltur biðlari. Þetta er prótókollinn að virka eins og hann var hannaður, í eina glugganum þar sem hann getur.

Hvaða leið sér í raun um það

Ef aðgangspunkturinn sjálfur veitir leigur er þetta staðbundið þjónustusamtal, og á staðbundinni leið sem er síað eftir IP varðar það stefnu fyrir inntak og úttak. Biðlaraumferð sem er framsend í gegnum VPN er önnur ákvörðun, og NAT fyrir þá umferð er enn önnur. Að rugla þessum þremur er leiðin sem þröng undantekning verður breið.

Hvar pakkinn er meðhöndlaður fer eftir púkanum og eldveggsfjölskyldunni sem er notuð. Hráar sokk-útfærslur, brúarfyrirkomulag og fyrri síukrókar geta fært eða lokað honum alveg annars staðar. Staðfestu tengingu viðmóts púkans og virka króka áður en þú bætir við reglum.

Almenn uppskrift fyrir inntak og úttak sem er afrituð af vefspjalli er ekki sönnun þess að útfærslan þín fari sömu keðjurnar á sama hátt.

Svarið er ekki alltaf útvarp

Undantekning sem leyfir aðeins útvarpssvör er líka röng. Áfangastaður DHCP-svars fer eftir stöðu biðlarans og sviðum skilaboðanna, og prótókollinn tilgreinir bæði útvarps- og einstakasts-tilvikið. Ef netþjónninn þinn svarar með einstakasti á vistfang sem hann er að fara að úthluta, lokar regla sem er aðeins fyrir útvarp skrefinu sem klárar verkið. Skrifaðu regluna miðað við skiptin sem stillti netþjónninn framkvæmir í raun.

Seinni endurnýjanir leigu endurtaka skiptin í annarri stöðu, svo skildu eftir pláss fyrir þær og ekki bara fyrir fyrstu tengingu.

Lagaðu þröngt og athugaðu svo restina

Haltu núverandi stefnu, finndu DHCP-heimildina sem vantar og takmarkaðu hana við viðmótið sem snýr að biðlaranum, prótókollinn og gáttirnar tvær. Sannaðu að beiðnin nái til þjónustunnar og sannaðu svo að þjónustan svari. Þetta eru tvær ólíkar athuganir, og stilling þjónustu eða vistfangasafns getur enn verið röng bak við fullkomna síun.

Að tæma töflu er ekki skref í DHCP-stillingu. Í iptables eyðir flush reglum úr valdri keðju eða töflu, og tæming NAT-töflunnar býr ekki til þýðingarreglu. Að setja breiðar ACCEPT-stefnur fjarlægir vernd sem tengist ekki leigunni, og þess vegna á hvorugt heima í endurnýtanlegri viðgerð á hotspoti.

Þegar biðlarinn hefur leigu skaltu athuga DNS, framsendingu og VPN-útgang sem aðskilin verkefni. Leiga setur staðbundið vistfang og ekkert meira.