Заштитни зид вашег хотспота блокира DHCP пре најма

Нови телефон се повезује са вашим хотспотом, не приказује адресу и никада је не добија. Приступна тачка је исправна, DHCP демон ради, а правило заштитног зида које сте написали изгледа усклађено са планом адреса. Оно што заправо чини јесте да тражи да клијент већ има адресу коју тражи. Први DHCP пакет уопште нема адресу, па се правило никада не активира.

Посматрајте како се клијент повезује

Пратите једну асоцијацију са стране клијента. Радио се асоцира, клијент шаље DHCP откривање, сервер нуди, клијент захтева, сервер потврђује и тек тада клијент има адресу употребљиву за било шта друго.

Све пре те коначне потврде одвија се док клијент не може да користи пролаз за обичан саобраћај. То је прозор који правило подмреже заборавља.

Шта први пакет заиста садржи

RFC 2131 прописује да DHCP емитовања клијента пре добијања адресе користе изворну адресу нулу. Поруке од клијента ка серверу иду на UDP порт 67, а од сервера ка клијенту на UDP порт 68. Откривање зато долази са 0.0.0.0 као извором, а правило које захтева извор унутар ваше клијентске подмреже се једноставно не поклапа с њим.

То није погрешна конфигурација на страни клијента. То је протокол који ради како је пројектован, у једином прозору у којем може.

Која путања то заиста обрађује

Ако сама приступна тачка даје најмове, то је локални разговор са сервисом и у локалној путањи филтрираној по IP-у тиче се политике улаза и излаза. Прослеђени клијентски саобраћај кроз VPN је друга одлука, а NAT за тај саобраћај је опет другачији. Мешање тих троје је начин на који уско изузеће постаје широко.

Где се пакет обрађује зависи од демона и породице заштитног зида која се користи. Имплементације са сировим сокетима, мостовни распореди и раније куке за филтрирање могу га преместити или блокирати негде сасвим другде. Потврдите везивање интерфејса демона и активне куке пре додавања правила.

Генерички рецепт за улаз и излаз копиран са форума није доказ да ваша имплементација пролази кроз те ланце на исти начин.

Одговор није увек емитовање

Изузеће које дозвољава само емитоване одговоре такође је погрешно. Одредиште DHCP одговора зависи од стања клијента и поља поруке, а протокол прописује и емитовани и уницаст случај. Ако ваш сервер одговара уницастом на адресу коју тек треба доделити, правило само за емитовање блокира корак који завршава посао. Напишите правило према размени коју конфигурисани сервер заиста обавља.

Каснија обнављања најма понављају размену у другом стању, па оставите места за њих, а не само за прво повезивање.

Поправите уско, па проверите остало

Задржите постојећу политику, пронађите недостајуће DHCP дозволе и ограничите га на интерфејс окренут клијенту, протокол и два порта. Докажите да захтев стиже до сервиса, затим докажите да сервис одговара. То су два различита запажања, а конфигурација сервиса или скупа адреса и даље може бити погрешна иза савршеног филтрирања.

Пражњење табеле није корак DHCP конфигурације. У iptables-у flush брише правила из одабраног ланца или табеле, а пражњење NAT табеле не ствара правило превођења. Постављање широких ACCEPT политика уклања заштиту која није повезана са најмом, због чега ниједно од тога не припада у вишекратно употребљиву поправку хотспота.

Кад клијент добије најам, проверите DNS, прослеђивање и VPN излаз као одвојене задатке. Најам успоставља локално адресирање и ништа више.