Firewall vašeg hotspot-a blokira DHCP prije najma

Novi telefon se pridružuje vašem hotspotu, ne pokazuje adresu i nikada je ne dobija. Pristupna tačka je ispravna, DHCP daemon radi, a pravilo firewall-a koje ste napisali izgleda usklađeno s planom adresa. Ono što zapravo radi 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.

Gledajte kako se klijent pridružuje

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

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

Šta prvi paket zapravo sadrži

RFC 2131 propisuje da DHCP emitovanja klijenta prije dobijanja adrese koriste izvornu adresu nulu. Poruke od klijenta prema serveru idu na UDP port 67, a od servera 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 jednostavno se 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 zapravo obrađuje

Ako sama pristupna tač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 firewall-a 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/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 dozvoljava samo emitovane odgovore također je pogrešno. Odredište DHCP odgovora zavisi od stanja klijenta i polja poruke, a protokol propisuje i emitovane i unicast slučajeve. Ako vaš server odgovara unicast na adresu koju tek treba dodijeliti, pravilo samo za emitovanje blokira korak koji završava posao. Napišite pravilo prema razmjeni koju konfigurisani server zaista obavlja.

Kasnija obnavljanja najma ponavljaju razmjenu u drugom stanju, pa ostavite mjesta za njih, a ne samo za prvo pridruživanje.

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 iptables-u 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 hotspot-a.

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