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