Firewall-i i hotspot-it tënd bllokon DHCP para qirasë

Një telefon i ri lidhet me hotspot-in tënd, nuk shfaq asnjë adresë dhe nuk e merr kurrë. Pika e aksesit është në rregull, daemoni DHCP po punon, dhe rregulli i firewall-it që shkruajte duket në përputhje me planin e adresave. Në fakt ai kërkon që klienti ta ketë tashmë adresën që po kërkon. Paketa e parë DHCP nuk ka fare adresë, prandaj rregulli nuk aktivizohet kurrë.

Vëzhgo si lidhet një klient

Ndiq një asociim nga ana e klientit. Radioja asociohet, klienti dërgon zbulimin DHCP, serveri ofron, klienti kërkon, serveri konfirmon, dhe vetëm atëherë klienti ka një adresë të përdorshme për çdo gjë tjetër.

Gjithçka para asaj konfirmimi përfundimtar ndodh ndërsa klienti nuk mund të përdorë portën hyrëse për trafikun e zakonshëm. Ai është dritarja që rregulli i nënrrjetit harron.

Çfarë përmban në të vërtetë paketa e parë

RFC 2131 specifikon që transmetimet DHCP të një klienti përpara se të marrë një adresë përdorin një adresë burimi zero. Mesazhet nga klienti te serveri shkojnë në portën UDP 67, dhe ato nga serveri te klienti në portën UDP 68. Prandaj zbulimi arrin me 0.0.0.0 si burim, dhe një rregull që kërkon një burim brenda nënrrjetit të klientit tënd thjesht nuk përputhet me të.

Ky nuk është konfigurim i gabuar nga ana e klientit. Ky është protokolli që punon siç është projektuar, në dritaren e vetme ku kjo është e mundur.

Cila rrugë e trajton në të vërtetë

Nëse pika e aksesit vetë ofron qira, ky është një bisedë shërbimi lokal, dhe në një rrugë lokale të filtruar nga IP ka të bëjë me politikën e hyrjes dhe daljes. Trafiku i klientit i përcjellë përmes VPN është një vendim tjetër, dhe NAT-i për atë trafik është përsëri diçka tjetër. Përzierja e të treve është mënyra se si një përjashtim i ngushtë bëhet i gjerë.

Ku trajtohet paketa varet nga daemoni dhe familja e firewall-it që përdoret. Implementimet me socket të papërpunuar, rregullimet me urë dhe grepat e mëparshëm të filtrimit mund ta zhvendosin ose bllokojnë atë diku krejt tjetër. Konfirmo lidhjen e ndërfaqes së daemonit dhe grepat aktivë përpara se të shtosh rregulla.

Një recetë e përgjithshme për hyrje dhe dalje e kopjuar nga një forum nuk është provë që implementimi yt i kalon ato zinxhirë në të njëjtën mënyrë.

Përgjigjja nuk është gjithmonë transmetim

Një përjashtim që lejon vetëm përgjigje transmetimi është gjithashtu i gabuar. Destinacioni i përgjigjes DHCP varet nga gjendja e klientit dhe fushat e mesazhit, dhe protokolli specifikon si rastin e transmetimit ashtu edhe atë të një-adresës. Nëse serveri yt përgjigjet me një-adresë ndaj një adrese që është gati për të caktuar, një rregull vetëm për transmetim bllokon hapin që e përfundon punën. Shkruaj rregullin sipas shkëmbimit që serveri i konfiguruar kryen në të vërtetë.

Rinovimet e mëvonshme të qirasë përsëritin shkëmbimin në një gjendje tjetër, prandaj lëri vend edhe për to, e jo vetëm për lidhjen e parë.

Rregullo ngushtë, pastaj kontrollo pjesën tjetër

Mbaj politikën ekzistuese, gjej lejen DHCP që mungon dhe kufizoje atë në ndërfaqen përballë klientit, protokollin dhe dy portat. Vërteto që kërkesa arrin te shërbimi, pastaj vërteto që shërbimi përgjigjet. Këto janë dy vëzhgime të ndryshme, dhe konfigurimi i shërbimit ose i grupit të adresave mund të jetë ende i gabuar pas filtrimit të përsosur.

Zbrazja e një tabele nuk është hap i konfigurimit DHCP. Në iptables, flush fshin rregullat nga zinxhiri ose tabela e zgjedhur, dhe zbrazja e tabelës NAT nuk krijon një rregull përkthimi. Vendosja e politikave të gjera ACCEPT heq mbrojtjen që nuk lidhet me qiranë, prandaj asnjëra prej tyre nuk i përket një rregullimi të ripërdorshëm për hotspot.

Pasi klienti të ketë një qira, kontrollo DNS, përcjelljen dhe daljen përmes VPN si detyra të veçanta. Qiraja vendos adresimin lokal dhe asgjë më shumë.