Jūsu hotspot ugunsmūris bloķē DHCP pirms nomas

Jauns tālrunis pievienojas jūsu hotspot, nerāda adresi un nekad to nesaņem. Piekļuves punkts ir kārtībā, DHCP dēmons darbojas, un jūsu rakstītais ugunsmūra noteikums izskatās saskaņots ar adrešu plānu. Taču patiesībā tas prasa, lai klientam jau būtu tā adrese, kuru tas pieprasa. Pirmajā DHCP paketē adreses vispār nav, tāpēc noteikums nekad neiedarbojas.

Novērojiet, kā klienta pievienojas

Izsekojiet vienu asociāciju no klienta puses. Radio asociējas, klients sūta DHCP atklāšanu, serveris piedāvā, klients pieprasa, serveris apstiprina, un tikai tad klientam ir adrese, kas izmantojama kam citam.

Viss pirms šī galīgā apstiprinājuma notiek, kamēr klients nevar izmantot vārteju parastam trafikam. Tieši šo logu apakštīkla noteikums aizmirst.

Ko pirmajā paketē patiešām ir

RFC 2131 nosaka, ka klienta DHCP apraides pirms adreses iegūšanas izmanto nulles avota adresi. Ziņojumi no klienta uz serveri iet uz UDP 67 portu, bet no servera uz klientu – uz UDP 68 portu. Tāpēc atklāšana ierodas ar 0.0.0.0 kā avotu, un noteikums, kas pieprasa avotu jūsu klienta apakštīklā, tam vienkārši neatbilst.

Tā nav klienta puses nepareiza konfigurācija. Tas ir protokols, kas darbojas tā, kā projektēts, vienīgajā logā, kur tas ir iespējams.

Kurš ceļš to patiešām apstrādā

Ja piekļuves punkts pats izsniedz nomas, tā ir vietēja servisa saruna, un IP filtrētā vietējā ceļā tas attiecas uz ievades un izvades politiku. VPN pārsūtītais klienta trafiks ir cits lēmums, un NAT šim trafikam ir vēl kas cits. Šo trīs sajaukšana ir veids, kā šaurs izņēmums kļūst plašs.

Kur pakete tiek apstrādāta, ir atkarīgs no dēmona un izmantotās ugunsmūra saimes. Neapstrādātu ligzdu realizācijas, tilta izkārtojumi un agrāki filtrēšanas āķi var to pārvietot vai bloķēt pavisam citur. Pirms noteikumu pievienošanas apstipriniet dēmona saskarnes piesaisti un aktīvos āķus.

Vispārīga ievades un izvades recepte, kas nokopēta no foruma, nav pierādījums, ka jūsu realizācija šķērso šīs ķēdes tāpat.

Atbilde ne vienmēr ir apraide

Arī izņēmums, kas atļauj tikai apraides atbildes, ir nepareizs. DHCP atbildes galamērķis ir atkarīgs no klienta stāvokļa un ziņojuma laukiem, un protokols nosaka gan apraides, gan vienam adresātam adresētu gadījumu. Ja jūsu serveris atbild vienam adresātam uz adresi, kuru tas taisās piešķirt, noteikums tikai apraidei bloķē soli, kas pabeidz darbu. Rakstiet noteikumu atbilstoši apmaiņai, ko konfigurētais serveris patiešām veic.

Vēlākas nomas atjaunošanas atkārto apmaiņu citā stāvoklī, tāpēc atstājiet tām vietu, nevis tikai pirmajai pievienošanai.

Labojiet šauri, pēc tam pārbaudiet pārējo

Saglabājiet esošo politiku, atrodiet trūkstošo DHCP atļauju un ierobežojiet to ar saskarni, kas vērsta pret klientu, protokolu un diviem portiem. Pierādiet, ka pieprasījums sasniedz servisu, pēc tam pierādiet, ka serviss atbild. Tie ir divi dažādi novērojumi, un servisa vai adrešu baseina konfigurācija joprojām var būt nepareiza aiz perfektas filtrēšanas.

Tabulas iztīrīšana nav DHCP konfigurācijas solis. iptables flush dzēš noteikumus no izvēlētās ķēdes vai tabulas, un NAT tabulas iztīrīšana neizveido tulkošanas noteikumu. Platu ACCEPT politiku iestatīšana noņem aizsardzību, kas nav saistīta ar nomu, tāpēc neviens no tiem nepieder pie atkārtoti lietojama hotspot labojuma.

Kad klientam ir noma, pārbaudiet DNS, pārsūtīšanu un VPN izeju kā atsevišķus uzdevumus. Noma nosaka vietējo adresāciju un neko vairāk.