Zaštitni zid vašeg hotspota blokira DHCP prije najma

Novi telefon se priključuje vašem hotspotu, ne prikazuje adresu i nikada je ne dobija. Pristupna točka je ispravna, DHCP daemon radi, a pravilo zaštitnog zida koje ste napisali izgleda usklađeno s planom adresa. Ono što zaista čini jeste da traži da klijent već ima adresu koju traži. Prvi DHCP paket uopće nema adresu, pa se pravilo nikada ne aktivira.

Posmatrajte kako se klijent priključuje

Pratite jednu asocijaciju sa strane klijenta. Radio se asocira, klijent šalje DHCP otkrivanje, poslužitelj nudi, klijent zahtijeva, poslužitelj potvrđuje i tek tada klijent ima adresu upotrebljivu za bilo šta drugo.

Sve prije te konačne potvrde odvija se dok klijent ne može koristiti prolaz za običan saobraćaj. To je prozor koji pravilo podmreže zaboravlja.

Šta prvi paket zaista sadrži

RFC 2131 propisuje da DHCP emitovanja klijenta prije dobijanja adrese koriste izvornu adresu nulu. Poruke od klijenta prema poslužitelju idu na UDP port 67, a od poslužitelja prema klijentu na UDP port 68. Otkrivanje zato dolazi s 0.0.0.0 kao izvorom, a pravilo koje zahtijeva izvor unutar vaše klijentske podmreže se jednostavno ne poklapa s njim.

To nije pogrešna konfiguracija na strani klijenta. To je protokol koji radi kako je projektovan, u jedinom prozoru u kojem može.

Koja putanja to zaista obrađuje

Ako sama pristupna točka daje najmove, to je lokalni razgovor sa servisom i u lokalnoj putanji filtriranoj po IP-u tiče se politike ulaza i izlaza. Proslijeđeni klijentski saobraćaj kroz VPN je druga odluka, a NAT za taj saobraćaj je opet drugačiji. Miješanje tih troje je način na koji usko izuzeće postaje široko.

Gdje se paket obrađuje zavisi od daemona i porodice zaštitnog zida koja se koristi. Implementacije sa sirovim socketima, mostovni rasporedi i ranije kuke za filtriranje mogu ga premjestiti ili blokirati negdje sasvim drugdje. Potvrdite vezivanje interfejsa daemona i aktivne kuke prije dodavanja pravila.

Generički recept za ulaz i izlaz kopiran s foruma nije dokaz da vaša implementacija prolazi kroz te lance na isti način.

Odgovor nije uvijek emitovanje

Izuzeće koje dopušta samo emitovane odgovore također je pogrešno. Odredište DHCP odgovora zavisi od stanja klijenta i polja poruke, a protokol propisuje i emitovani i unicast slučaj. Ako vaš poslužitelj odgovara unicastom na adresu koju tek treba dodijeliti, pravilo samo za emitovanje blokira korak koji završava posao. Napišite pravilo prema razmjeni koju konfigurisani poslužitelj zaista obavlja.

Kasnija obnavljanja najma ponavljaju razmjenu u drugom stanju, pa ostavite mjesta za njih, a ne samo za prvo priključenje.

Popravite usko, pa provjerite ostalo

Zadržite postojeću politiku, pronađite nedostajuće DHCP dopuštenje i ograničite ga na interfejs okrenut klijentu, protokol i dva porta. Dokažite da zahtjev stiže do servisa, zatim dokažite da servis odgovara. To su dva različita zapažanja, a konfiguracija servisa ili skupa adresa i dalje može biti pogrešna iza savršenog filtriranja.

Pražnjenje tabele nije korak DHCP konfiguracije. U iptablesu flush briše pravila iz odabranog lanca ili tabele, a pražnjenje NAT tabele ne stvara pravilo prevođenja. Postavljanje širokih ACCEPT politika uklanja zaštitu koja nije povezana s najmom, zbog čega nijedno od toga ne pripada u višekratno upotrebljivu popravku hotspota.

Kad klijent dobije najam, provjerite DNS, prosljeđivanje i VPN izlaz kao odvojene zadatke. Najam uspostavlja lokalno adresiranje i ništa više.