Защитната стена на хотспота ви блокира 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 като отделни задачи. Наемът установява локална адресация и нищо повече.