Файрвол вашої точки доступу блокує 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 як окремі завдання. Оренда встановлює локальну адресацію і нічого понад це.