Файрвол хотспота блакуе 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 як асобныя задачы. Арэнда ўсталёўвае лакальную адрасацыю і нічога больш.