Настройте bootpd и bootpc для успешного взаимодействия друг с другом.

Текущие bootpc и bootpd (из bootp) в Debian, похоже, не работают вместе в текущей среде ядра Linux. Кажется, есть проблема 🐔/🥚; bootpd отправляет ответы как однонаправленные UDP-пакеты на еще не настроенный IP-адрес. Ядро клиента затем отбрасывает их, не доставляя в сокет клиента bootpc, потому что этот IP-адрес еще не является действительным локальным адресом на хосте.

Как это вообще работало?

• Существует ли параметр ядра или другая модификация, которая может заставить ядро передать эти пакеты процессу bootpc?
• Существует ли конфигурация для bootpd, которая позволит использовать IP-адреса назначения, заполненные всеми единицами или всеми нулями, вместо еще не настроенного однонаправленного IP-адреса клиента?

У нас есть потенциальный клиент с большой инфраструктурой bootp, не использующей DHCP. Поддержка старого bootp является одним из их требований.

Детали проблемы

• bootpd отправляет свои ответные пакеты как однонаправленные пакеты на MAC-адрес клиента bootpc, используя значение IP-адреса назначения, соответствующее адресу, который также находится в полезной нагрузке, указывая клиенту настроить себя.
• Ядро затем отбрасывает эти пакеты, а не передает их процессу bootpc, который их запросил.
• bootpc корректно открыл сокет для прослушивания на 0.0.0.0:68 0.0.0.0:* (см. вывод netstat ниже)
• Я подтвердил этот анализ несколькими способами:
  • Я запустил tcpdump и вижу, что ответы доходят до сетевого интерфейса
  • Я использовал dropwatch и вижу, что пакеты отбрасываются с причиной IPINADDRERROR, что в основном означает “недействительный IP-адрес”
  • Я могу заставить bootpd использовать 0.0.0.0 как IP-адрес назначения, пропуская фактическую настройку IP; когда я это делаю, bootpc получает ответы и обрабатывает их. Однако это не помогает, потому что в этом случае клиент не получает IP-адрес
  • Я пытался добавить IP-адрес к интерфейсу во время того, как bootpc делает запросы. Как только я его добавляю, следующий ответ доходит до процесса.
• Я также попробовал опцию bootpc --serverbcast. Это не срабатывает по аналогичной причине:
  • bootpd отправляет ответы на широковещательный адрес подсети (например, 10.0.43.255)
  • Так как IP-адрес и маска подсети еще не настроены на интерфейсе, у ядра нет причин считать это действительным адресом для себя.

Вывод netstat, показывающий сокет для прослушивания bootpc:

$ sudo netstat -unlp
Активные интернет-соединения (только серверы)
Протокол Recv-Q Send-Q Локальный адрес           Удаленный адрес         Состояние       PID/Имя программы    
udp        0      0 0.0.0.0:68              0.0.0.0:*                           2295/bootpc         

Решение с обходом

Я нашел обходное решение, которое выглядит хакерским. В частности, я думаю, что оно использует непреднамеренное поведение, возможно, мы не можем рассчитывать на его работу в будущем:

• Модуль отслеживания соединений iptables имеет матч ctstate со значением DNAT.
• Это можно использовать для принятия пакетов, у которых адрес назначения не распознан
• Я не думаю, что это предназначено для сопоставления произвольных IP назначения:
  • Он может использоваться только с пакетами, которые были NAT’d тем же хостом
  • Я думаю, что его цель – сопоставлять пакеты, адреса которых были переписаны (что мы не делаем), но это “дешевая” реализация, которая игнорирует таблицу сопоставления NAT вместо проверки наличия записи, соответствующей этому пакету.
  • Я обеспокоен тем, что это может быть удалено или переписано, чтобы быть менее неразборчивым в будущем
  • Чтобы это заработало, мне нужно переназначить эти пакеты на их существующий порт назначения, просто чтобы получить данные о состоянии соединения NAT на пакет, иначе --ctstate DNAT не применяется к пакету.

Фон/должная осмотрительность

• Наша тестовая платформа использует Debian 12 на Linux 6.1.0.
• Наши тестовые хосты являются стандартными образами виртуальных машин UTM Debian 12 с полки
• bootpd имеет очень немного опций cli, ни одна из которых не касается ответов, портов или адресов. В руководстве не упоминаются “широковещательная” или “однонаправленная” передача, и упоминаний о “адресе” или “назначении” очень мало и они не актуальны.
• Наш фактический продукт – это Debian 12 на пользовательском ядре Linux 5.19.9 (и ведет себя так же)
• IP-соединение полностью работает между клиентом и сервером тестовой платформы
• bootpc отказывается отправлять запросы, если не выполняются следующие условия:
  • На интерфейсе нет маршрутизируемого IP-адреса (169.254/16 приемлемо)
  • Существует маршрут по умолчанию 0/0, указывающий на интерфейс, где ожидается сервер bootp
    • В противном случае он говорит сеть недоступна
    • Примечание: указание --dev <iface> в командной строке bootpc не помогает в этом случае
• Я все еще работаю над оценкой конфигурации bootptab, чтобы увидеть, есть ли какие-либо варианты, которые влияют на это. Не нашел хорошей ссылки на них, страница man bootptab очень кратка по этому поводу.

Альтернативное решение

Я смог заставить это работать с менее запутанным решением на iptables: я добавил правило NAT, которое сопоставляет UDP-порт 68 (bootpc) и перенаправляет IP-адрес назначения на 255.255.255.255 (и сохраняет тот же UDP-порт).

Это работает, но я считаю это хакерским. Очевидно, это не тот способ, как должен работать протокол, поэтому я бы предпочел “реальное” решение, если это возможно.