Firewall ya hotspot yako inazuia DHCP kabla ya kukodisha

Simu mpya inajiunga na hotspot yako, haionyeshi anwani na haipati kamwe. Kituo cha ufikiaji kiko sawa, daemon ya DHCP inaendesha, na kanuni ya firewall uliyoandika inaonekana kupatana na mpango wa anwani. Lakini inachofanya kwa kweli ni kudai kwamba mteja awe tayari ana anwani anayoiomba. Pakiti ya kwanza ya DHCP haina anwani kabisa, kwa hiyo kanuni haitumiki kamwe.

Tazama mteja anajiunga

Fuatilia muunganisho mmoja kutoka upande wa mteja. Redio inaunganisha, mteja anatuma utambuzi wa DHCP, seva inatoa, mteja anaomba, seva inathibitisha, na hapo ndipo mteja anapokuwa na anwani inayoweza kutumika kwa kitu kingine chochote.

Kila kitu kabla ya uthibitisho huo wa mwisho hutokea wakati mteja hawezi kutumia lango kwa trafiki ya kawaida. Hilo ndilo dirisha ambalo kanuni ya subnet inalisahau.

Pakiti ya kwanza ina nini kwa kweli

RFC 2131 inabainisha kwamba matangazo ya DHCP ya mteja kabla ya kupata anwani hutumia anwani ya chanzo sifuri. Ujumbe kutoka mteja kwenda seva huenda kwenye lango la UDP 67, na kutoka seva kwenda mteja kwenye lango la UDP 68. Kwa hiyo utambuzi unafika ukiwa na 0.0.0.0 kama chanzo, na kanuni inayodai chanzo ndani ya subnet ya mteja wako hailingani nayo kabisa.

Hii si usanidi mbaya kwa upande wa mteja. Hii ni itifaki ikifanya kazi kama ilivyoundwa, katika dirisha pekee ambalo inaweza.

Ni njia gani inayoshughulikia hili kwa kweli

Ikiwa kituo cha ufikiaji chenyewe kinatoa ukodishaji, hii ni mazungumzo ya huduma ya ndani, na katika njia ya ndani iliyochujwa kwa IP inahusika na sera ya kuingiza na kutoa. Trafiki ya mteja inayopitishwa kupitia VPN ni uamuzi mwingine, na NAT kwa trafiki hiyo ni tofauti tena. Kuchanganya hivi vitatu ndiyo njia ambayo ubaguzi mwembamba unakuwa mpana.

Mahali pakiti inashughulikiwa kunategemea daemon na familia ya firewall inayotumika. Utekelezaji wa soketi mbichi, mipangilio ya daraja na ndoano za uchujaji za awali zinaweza kuihamisha au kuizuia mahali pengine kabisa. Thibitisha ufungaji wa kiolesura cha daemon na ndoano zinazofanya kazi kabla ya kuongeza kanuni.

Mapishi ya jumla ya kuingiza na kutoa yaliyonakiliwa kutoka jukwaa si uthibitisho kwamba utekelezaji wako unapita katika minyororo hiyo kwa njia ile ile.

Jibu si kila mara tangazo

Ubaguzi unaoruhusu majibu ya matangazo pekee pia si sahihi. Mahali jibu la DHCP linakwenda kunategemea hali ya mteja na sehemu za ujumbe, na itifaki inabainisha hali zote mbili, tangazo na anwani moja. Ikiwa seva yako inajibu kwa anwani moja kwa anwani ambayo iko karibu kuitoa, kanuni ya tangazo pekee inazuia hatua inayokamilisha kazi. Andika kanuni kulingana na mabadilishano ambayo seva iliyosanidiwa inafanya kwa kweli.

Usasishaji wa ukodishaji wa baadaye unarudia mabadilishano katika hali nyingine, kwa hiyo acha nafasi kwa ajili yao na si kwa muunganisho wa kwanza pekee.

Rekebisha kwa ufinyu, kisha angalia mengine

Weka sera iliyopo, pata ruhusa ya DHCP inayokosekana na uipunguze kwa kiolesura kinachoelekea mteja, itifaki na lango mbili. Thibitisha kwamba ombi linafika kwa huduma, kisha thibitisha kwamba huduma inajibu. Haya ni maonjo mawili tofauti, na usanidi wa huduma au bwawa la anwani bado unaweza kuwa mbaya nyuma ya uchujaji kamili.

Kufuta jedwali si hatua ya usanidi wa DHCP. Katika iptables, flush hufuta kanuni kutoka mnyororo au jedwali lililochaguliwa, na kufuta jedwali la NAT hakuundui kanuni ya tafsiri. Kuweka sera pana za ACCEPT huondoa ulinzi usiohusiana na ukodishaji, ndiyo sababu hakuna mojawapo inayostahili kuwa katika marekebisho ya hotspot yanayoweza kutumika tena.

Mteja akiwa na ukodishaji, angalia DNS, upelekaji na utokeaji wa VPN kama kazi tofauti. Ukodishaji huweka anwani za ndani na hakuna zaidi ya hapo.