Zure hotspotaren suebakiak DHCP blokeatzen du maizterra eman aurretik

Telefono berri bat zure hotspotera konektatzen da, ez du helbiderik erakusten eta ez du inoiz lortzen. Sarbide-puntua ondo dago, DHCP daemona martxan dago, eta idatzi duzun suebaki araua helbide-planarekin bat datorrela dirudi. Benetan egiten duena eskatzen duen helbidea bezeroak jada duela eskatzea da. Lehen DHCP paketeak ez du helbiderik, beraz arauak ez du inoiz eragiten.

Begira nola konektatzen den bezero bat

Jarraitu asoziazio bat bezeroaren aldetik. Irratiak asoziatzen du, bezeroak DHCP aurkikuntza bidaltzen du, zerbitzariak eskaintzen du, bezeroak eskatzen du, zerbitzariak baieztatzen du, eta orduan soilik du bezeroak beste ezeretarako erabil daitekeen helbidea.

Azken baieztapen horren aurretiko guztia bezeroak trafiko arrunterako ate-bidea erabili ezin duenean gertatzen da. Azpisareko arauak ahazten duen leihoa da hori.

Zer dagoen benetan lehen paketean

RFC 2131 arauak zehazten du bezeroaren DHCP difusioek, helbidea lortu aurretik, zero jatorri-helbidea erabiltzen dutela. Bezerotik zerbitzarirako mezuak UDP 67 portura joaten dira, eta zerbitzaritik bezerorakoak UDP 68 portura. Beraz, aurkikuntza 0.0.0.0 jatorriarekin iristen da, eta zure bezeroaren azpisarearen barruko jatorria eskatzen duen arauak ez du harekin bat egiten.

Hori ez da bezeroaren aldetik konfigurazio oker bat. Protokoloa diseinatu zen bezala ari da lanean, hori egin dezakeen leiho bakarrean.

Zein bide arduratzen da horretaz benetan

Sarbide-puntuak berak maizterrak ematen baditu, tokiko zerbitzu elkarrizketa da, eta IPz iragazitako bide lokalean sarrera eta irteera politikari dagokio. VPN bidez birbidalitako bezero trafikoa beste erabaki bat da, eta trafiko horretarako NAT are beste bat. Hirurak nahastea da salbuespen estu bat zabal bihurtzeko modua.

Paketea non kudeatzen den daemonaren eta erabilitako suebaki familiaren araberakoa da. Socket gordineko inplementazioek, zubi antolamenduek eta aurreko iragazketa kakoek erabat beste leku batean mugitu edo blokea dezakete. Egiaztatu daemonaren interfaze lotura eta martxan dauden kakoak arauak gehitu aurretik.

Forotik kopiatutako sarrera eta irteera errezeta orokor bat ez da zure inplementazioak kate horiek era berean zeharkatzen dituen froga.

Erantzuna ez da beti difusioa

Difusio-erantzunak soilik uzten dituen salbuespena ere okerra da. DHCP erantzunaren helmuga bezeroaren egoeraren eta mezuaren eremuen araberakoa da, eta protokoloak bai difusio kasua bai unicast kasua zehazten ditu. Zure zerbitzariak esleitzeko zorian dagoen helbide batera unicast bidez erantzuten badu, difusio hutseko arauak lana amaitzen duen urratsa blokeatzen du. Idatzi araua konfiguratutako zerbitzariak benetan egiten duen trukaren arabera.

Geroagoko maizter berritzeek trukea beste egoera batean errepikatzen dute, beraz utzi horientzako tokia, ez soilik lehen konexiorako.

Zuzendu estuki, gero gainerakoa egiaztatu

Mantendu lehendik dagoen politika, aurkitu falta den DHCP baimena eta mugatu bezeroaren aldera dagoen interfazera, protokolora eta bi portuetara. Frogatu eskaerak zerbitzura iristen dela, gero frogatu zerbitzuak erantzuten duela. Bi behaketa desberdin dira, eta zerbitzuaren edo helbide multzoaren konfigurazioa oraindik oker egon daiteke iragazketa perfektuaren atzean.

Taula bat hustea ez da DHCP konfigurazio urratsa. iptables-en, flush-ek hautatutako kate edo taulatik arauak ezabatzen ditu, eta NAT taula husteak ez du itzulpen-arau bat sortzen. ACCEPT politika zabalak ezartzeak maizterketarekin zerikusirik ez duen babesa kentzen du, eta horregatik ez batak ez besteak ez du tokirik hotspot konponketa berrerabilgarri batean.

Bezeroak maizterra duenean, egiaztatu DNS, birbidaltzea eta VPN irteera zeregin bereizi gisa. Maizterrak tokiko helbideratzea ezartzen du eta ez beste ezer.