Požarni zid vašega hotspota blokira DHCP pred najemom

Nov telefon se poveže z vašim hotspotom, ne pokaže naslova in ga nikoli ne dobi. Dostopna točka je v redu, daemon DHCP teče, pravilo požarnega zidu, ki ste ga napisali, pa je videti skladno z načrtom naslovov. V resnici zahteva, da ima odjemalec naslov, ki ga zahteva, že v lasti. Prvi paket DHCP sploh nima naslova, zato pravilo nikoli ne deluje.

Opazujte, kako se odjemalec poveže

Sledite eni povezavi z odjemalčeve strani. Radio se poveže, odjemalec pošlje odkrivanje DHCP, strežnik ponudi, odjemalec zahteva, strežnik potrdi, in šele nato ima odjemalec naslov, uporaben za karkoli drugega.

Vse pred to končno potrditvijo se dogaja, medtem ko odjemalec ne more uporabljati prehoda za običajen promet. To je okno, ki ga pravilo podomrežja pozabi.

Kaj prvi paket v resnici vsebuje

RFC 2131 določa, da oddajanja DHCP odjemalca pred pridobitvijo naslova uporabljajo ničelni izvorni naslov. Sporočila od odjemalca do strežnika gredo na vrata UDP 67, od strežnika do odjemalca pa na vrata UDP 68. Zato odkrivanje prispe z 0.0.0.0 kot virom, in pravilo, ki zahteva vir znotraj vašega odjemalskega podomrežja, se z njim preprosto ne ujema.

To ni napačna konfiguracija na odjemalčevi strani. To je protokol, ki deluje tako, kot je zasnovan, v edinem oknu, kjer lahko.

Katera pot to v resnici obravnava

Če dostopna točka sama dodeljuje najeme, je to pogovor lokalne storitve, in na lokalni poti, filtrirani po IP, se tiče politike vhoda in izhoda. Posredovani odjemalski promet skozi VPN je druga odločitev, NAT za ta promet pa spet druga. Mešanje teh treh je način, kako ozka izjema postane široka.

Kje se paket obravnava, je odvisno od daemona in uporabljene družine požarnega zidu. Izvedbe s surovimi vtičnicami, mostne postavitve in zgodnejše kaveljčke filtriranja ga lahko premaknejo ali blokirajo povsem drugje. Pred dodajanjem pravil potrdite vezavo vmesnika daemona in dejavne kaveljčke.

Splošen recept za vhod in izhod, kopiran s foruma, ni dokaz, da vaša izvedba prehaja te verige na enak način.

Odgovor ni vedno oddajanje

Tudi izjema, ki dovoljuje samo oddajane odgovore, je napačna. Cilj odgovora DHCP je odvisen od stanja odjemalca in polj sporočila, protokol pa določa tako oddajni kot enonaslovni primer. Če vaš strežnik odgovarja enonaslovno na naslov, ki ga bo pravkar dodelil, pravilo samo za oddajanje blokira korak, ki delo dokonča. Pravilo napišite glede na izmenjavo, ki jo konfigurirani strežnik v resnici izvede.

Poznejše podaljšanje najema ponovi izmenjavo v drugem stanju, zato pustite prostor tudi zanj in ne le za prvo povezavo.

Popravite ozko, nato preverite ostalo

Obdržite obstoječo politiko, poiščite manjkajoče dovoljenje DHCP in ga omejite na vmesnik, obrnjen k odjemalcu, protokol in dve vrati. Dokažite, da zahteva doseže storitev, nato dokažite, da storitev odgovori. To sta dve različni opažanji, in konfiguracija storitve ali bazena naslovov je lahko še vedno napačna za brezhibnim filtriranjem.

Praznjenje tabele ni korak konfiguracije DHCP. V iptables flush izbriše pravila iz izbranega zaporedja ali tabele, praznjenje tabele NAT pa ne ustvari pravila za prevajanje. Nastavljanje širokih politik ACCEPT odstrani zaščito, ki ni povezana z najemom, zato nobeno od tega ne sodi v ponovno uporabno popravilo hotspota.

Ko ima odjemalec najem, preverite DNS, posredovanje in izhod VPN kot ločene naloge. Najem vzpostavi lokalno naslavljanje in nič več.