Требования к DHCP-клиенту и серверу во встраиваемом Linux

Встраиваемому устройству нужен DHCP-клиент, когда оно получает собственную конфигурацию IPv4 от существующей сети. DHCP-сервер нужен, когда устройство выдаёт настройки подключённому оборудованию или телефону для первоначальной настройки. Шлюз может выполнять обе роли на раздельно определённых интерфейсах. До выбора демона и добавления пакетов в образ Linux требования должны назвать эти интерфейсы, ответственных за конфигурацию и поведение при отказах.

Статья посвящена IPv4 DHCP во встраиваемых Linux-продуктах. Объявления маршрутизатора IPv6 и DHCPv6 требуют отдельного проектирования. Приведённые конфигурации и приёмочные проверки являются инженерными примерами, а не результатами внедрения Obeita.

Начните с топологии установки

Фраза «поддерживать DHCP» допускает несколько несовместимых трактовок. Датчик, подключённый к заводскому коммутатору, обычно является клиентом. Сервисная точка доступа может выдавать адреса только телефону техника. Маршрутизирующий шлюз может получать адрес WAN и обслуживать отдельную LAN. Мост может лишь передавать клиентские широковещательные сообщения существующему серверу; дополнительный сервер на таком мосту повлияет на весь широковещательный домен.

Роль продукта Выдача адресов Что зафиксировать
Конечное устройство заводской сети Клиент на восходящем интерфейсе ИТ-служба управляет подсетью, арендой и DNS
Локальная точка настройки Сервер на интерфейсе настройки Только локальный доступ или выход в Интернет
Маршрутизирующий шлюз Клиент WAN и сервер LAN Раздельные подсети и явная политика пересылки
Прозрачный мост Клиентов обслуживает существующий сетевой сервер Адрес управления и границы широковещания

Обозначайте физические порты наряду с именами Linux. Изменение платы, USB-адаптер или обновление драйвера может изменить порядок обнаружения. Сохраните в документации выпуска соответствие разъёма, MAC-адреса, принадлежности мосту/VLAN и сетевой роли.

Шлюз с DHCP-клиентом со стороны заводской сети и отдельным DHCP-сервером для телефона настройки.
Рисунок 1. Обе роли DHCP совместимы при явном разделении интерфейсов, подсетей и широковещательных доменов. Схема на английском.

Определите поведение клиента после первой аренды

Первичное выделение обычно включает Discover, Offer, Request и Acknowledgement. Далее действуют срок аренды, продление и повторная привязка; устройство не должно продолжать считать истёкшую аренду действительной. Эти переходы определены в RFC 2131. Приёмка должна проверять последующие переходы, а не завершаться успешным холодным запуском.

Определите видимые приложению состояния: канал недоступен, получение конфигурации, адрес действителен, локальная сеть доступна, целевой сервис доступен. Подтверждение DHCP устанавливает конфигурацию, но не проверяет DNS, Интернет или MQTT-сервис. Интерфейс и диагностический журнал должны различать эти состояния.

Ответственный за сеть должен решить, принимает ли клиент маршрут по умолчанию и DNS, какую идентификацию передаёт и поддерживает ли резервирование адреса. Зафиксируйте ожидаемые опции, включая маску, маршрутизатор и DNS-сервер, по RFC 2132. Не привязывайте продукт к конкретному адресу без согласования с ИТ-службой площадки.

Для нескольких интерфейсов задайте приоритет маршрутов и владельца настроек DNS. Два сетевых менеджера на одном интерфейсе могут перезаписывать адреса друг друга. Две действительные аренды на разных интерфейсах также могут установить нежелательный маршрут по умолчанию. Назначьте одного владельца конфигурации на интерфейс и проверьте совместную работу с менеджером сотовой связи, статическим сервисным портом и мостом контейнеров.

Ограничьте сервер разрешённым сегментом

Сервер настройки должен запускаться после назначения интерфейсу предусмотренного локального адреса. Ограничьте прослушиваемые интерфейсы и проверьте, что предложения не выходят в заводскую сеть. Прослушивание всех интерфейсов вместе со случайным мостом может создать нежелательный DHCP-сервер. Межсетевой экран является дополнительной границей, а не заменой правильного управления интерфейсами.

Разделяйте выдачу адресов, маршрутизацию, пересылку DNS и NAT. Полученный телефоном адрес не означает, что шлюз предоставляет Интернет. Для исключительно локальной настройки определите доступ приложения к устройству, когда телефон отмечает Wi-Fi как сеть без Интернета. Проверяйте документированный ручной способ даже при наличии captive portal.

Следующий пример dnsmasq обслуживает выделенный сегмент без объявления маршрутизатора по умолчанию и DNS-сервера. Предполагаются отдельно заданный адрес br-setup 192.168.77.1/24, отсутствие связи с другим DHCP-сегментом и существующий доступный для записи каталог аренды. Сверьте опции с руководством dnsmasq установленной версии. Это исходная лабораторная настройка, а не полная конфигурация сети и безопасности.

# Dedicated local commissioning interface only
interface=br-setup
bind-interfaces
port=0
dhcp-range=192.168.77.20,192.168.77.60,255.255.255.0,10m
dhcp-option=3
dhcp-option=6
dhcp-leasefile=/data/dhcp/setup.leases

Если требуется маршрутизация в Интернет, опишите её отдельно и задайте правильные опции маршрутизатора/DNS. При динамическом создании интерфейсов проверяйте запуск и перезапуск демона, не предполагая сохранения правильной привязки. Убедитесь, что нижестоящая подсеть не пересекается с внешней; предусмотрите контролируемую процедуру изменения при конфликте.

Определите конфликты, исчерпание пула и постоянство идентичности

Размер пула должен учитывать одновременных клиентов, старые неистёкшие аренды и частую смену подключений при настройке. Телефоны могут использовать частные Wi-Fi-адреса, поэтому одно устройство не обязательно сохраняет единственный MAC постоянно. Ограничьте злоупотребляющий трафик запросов и определите сообщение монтажнику при заполненном пуле.

Решите, сохраняются ли аренды сервера после перезагрузки. Потеря базы не обязательно немедленно вызывает коллизию, но меняет доступные сведения для безопасного повторного использования адресов. Сохраняйте её по принятой политике и проверяйте перезапуск с остающимися в сети клиентами. Не стирайте все настройки устройства ради устранения одной проблемы DHCP.

Повторяющиеся IPv4-адреса требуют заметной ошибки и политики восстановления. RFC 5227 описывает обнаружение конфликтов с помощью ARP. Проверьте реализацию используемого клиентского/серверного стека и захватите конфликтующий трафик. Успешный ping может скрывать другой узел, периодически отвечающий за тот же адрес.

Используйте приёмочную матрицу отказов

Воздействие Наблюдение Предлагаемый критерий
Сервер отсутствует при старте, затем возвращается Повторы, CPU, состояние приложения Ограниченные ресурсы; автоматическое получение в согласованный срок
Короткая аренда; блокировать продление, затем все ответы Продление, перепривязка, истечение Приложение не использует истёкшую аренду; после восстановления перезагрузка не нужна
DHCP меняет маршрутизатор или DNS Маршруты, резолвер, текущие соединения Новая конфигурация применена, соединения восстановлены по политике приложения
Перезапуск сервера с активными клиентами База аренды и повторная выдача Нет одинаковых адресов в проверенной группе
Пул исчерпан или конфликтует статический узел Журнал и ответ монтажнику Конкретная ошибка; определённое восстановление без повреждения прочих настроек
WAN и точка настройки работают вместе Захват с обоих интерфейсов Предложения настройки ограничены нужным сегментом

Выбирайте временные пороги по потребностям установки и поддерживаемым срокам аренды. Для каждого результата указывайте срок аренды, версию прошивки, конфигурацию демона, модель маршрутизатора и ОС клиента. Сервер проверяйте с поддерживаемыми семействами телефонов и ноутбуков; один успешный ноутбук недостаточен для доказательства мобильного сценария.

Ищите первый отсутствующий переход

В разрешённой лаборатории захватывайте по одному интерфейсу. Ниже приведены диагностические примеры; имена интерфейсов и доступные утилиты зависят от образа:

ip -br link
ip -4 address show dev eth0
ip -4 route show
tcpdump -ni eth0 -vv 'udp port 67 or udp port 68 or arp'

Нет Discover — проверьте интерфейс, процесс и управление конфигурацией. Discover без Offer указывает на VLAN, сервер, ретранслятор или фильтрацию. Подтверждение без пригодного адреса — на клиентский обработчик или интеграцию сетевого менеджера. Если адрес действителен, но имена не разрешаются, проверяйте DNS; при исправном DNS и отказе сервиса переходите к приложению. Сохраняйте временные метки и ID транзакций, обезличивайте идентификаторы клиентов перед передачей захвата за пределы проекта.

Преобразуйте топологию в объём поставки

Услуга подключения устройств Obeita помогает определить роли интерфейсов и сетевую приёмку. Завершённый проект шлюза RK3528 показывает разные Ethernet-тракты и предлагаемые роли LAN/WAN, но не доказывает испытанный DHCP в вашей сети.

Для оценки предоставьте схему разъёмов/VLAN, состав клиентов, ограничения DHCP площадки, требования локальной настройки и текущий образ. Согласуйте ответственного за настройки, сообщения ошибок, захват и матрицу испытаний до включения «DHCP поддерживается» в акт сдачи.

Похожие записи