Hotspotisi palomuuri estää DHCP:n ennen vuokrausta

Uusi puhelin liittyy hotspotiisi, ei näytä osoitetta eikä koskaan saa sitä. Yhteyspiste on kunnossa, DHCP-taustaohjelma käy ja kirjoittamasi palomuurisääntö näyttää olevan osoitesuunnitelman mukainen. Itse asiassa se vaatii, että asiakkaalla on jo se osoite, jota se pyytää. Ensimmäisessä DHCP-paketissa ei ole lainkaan osoitetta, joten sääntö ei koskaan laukea.

Seuraa, miten asiakas liittyy

Seuraa yhtä liitosta asiakkaan puolelta. Radio liittyy, asiakas lähettää DHCP-löydöksen, palvelin tarjoaa, asiakas pyytää, palvelin kuittaa, ja vasta sitten asiakkaalla on osoite, jota voi käyttää mihinkään muuhun.

Kaikki ennen tuota lopullista kuittausta tapahtuu, kun asiakas ei voi käyttää yhdyskäytävää tavalliseen liikenteeseen. Juuri sen ikkunan aliverkkosääntö unohtaa.

Mitä ensimmäinen paketti oikeastaan sisältää

RFC 2131 määrittää, että asiakkaan DHCP-lähetykset ennen osoitteen saamista käyttävät lähdeosoitetta nolla. Viestit asiakkaalta palvelimelle menevät UDP-porttiin 67 ja palvelimelta asiakkaalle UDP-porttiin 68. Löydös saapuu siis lähteenään 0.0.0.0, eikä sääntö, joka vaatii lähteen asiakkaan aliverkon sisältä, yksinkertaisesti täsmää siihen.

Tämä ei ole asiakkaan puolen väärä kokoonpano. Tämä on protokolla, joka toimii suunnitellusti, ainoassa ikkunassa, jossa se voi.

Mikä reitti sitä oikeastaan käsittelee

Jos yhteyspiste itse jakaa vuokria, kyse on paikallisesta palvelukeskustelusta, ja IP-suodatetulla paikallisella reitillä se koskee tulo- ja lähtökäytäntöä. VPN:n kautta välitetty asiakasliikenne on eri päätös, ja sen liikenteen NAT on taas eri asia. Näiden kolmen sekoittaminen on se tapa, jolla kapeasta poikkeuksesta tulee laaja.

Missä pakettia käsitellään, riippuu taustaohjelmasta ja käytetystä palomuurin perheestä. Raakaliittymätoteutukset, sillä tehdyt järjestelyt ja aiemmat suodatuskoukut voivat siirtää tai estää sen aivan muualla. Vahvista taustaohjelman liitännän sidonta ja käytössä olevat koukut ennen sääntöjen lisäämistä.

Foorumilta kopioitu yleinen tulo- ja lähtöohje ei ole todiste siitä, että toteutuksesi kulkee samat ketjut samalla tavalla.

Vastaus ei ole aina lähetys

Myöskään poikkeus, joka sallii vain lähetysvastaukset, on väärä. DHCP-vastauksen kohde riippuu asiakkaan tilasta ja viestin kentistä, ja protokolla määrittelee sekä lähetys- että unicast-tapauksen. Jos palvelimesi vastaa unicastina osoitteeseen, jota se on juuri jakamassa, vain lähetykseen rajattu sääntö estää vaiheen, joka saattaa työn valmiiksi. Kirjoita sääntö sen vaihdon mukaan, jonka määritetty palvelin tosiasiassa suorittaa.

Myöhemmät vuokran uusinnat toistavat vaihdon eri tilassa, joten jätä niille tilaa eikä vain ensimmäiselle liitokselle.

Korjaa kapeasti ja tarkista sitten loput

Säilytä nykyinen käytäntö, etsi puuttuva DHCP-sallinta ja rajaa se asiakkaaseen päin olevaan liitäntään, protokollaan ja kahteen porttiin. Todista, että pyyntö saavuttaa palvelun, ja todista sitten, että palvelu vastaa. Ne ovat kaksi eri havaintoa, ja palvelun tai osoitealtaan kokoonpano voi olla yhä väärin täydellisen suodatuksen takana.

Taulun tyhjentäminen ei ole DHCP:n kokoonpanovaihe. Iptablesissa flush poistaa säännöt valitusta ketjusta tai taulusta, eikä NAT-taulun tyhjentäminen luo käännössääntöä. Laajojen ACCEPT-käytäntöjen asettaminen poistaa suojauksen, joka ei liity vuokraukseen, minkä vuoksi kumpikaan ei kuulu uudelleenkäytettävään hotspot-korjaukseen.

Kun asiakkaalla on vuokra, tarkista DNS, välitys ja VPN-lähtö erillisinä tehtävinä. Vuokra luo paikallisen osoitteistuksen eikä mitään sen enempää.