Как клиенты DHCP знают, какой из нескольких DHCPOFFERS принять?

Question

Представьте, что у нас есть сеть, как на картинке. Шесть хостов в одной сети уровня 2, без VLAN. Предполагается, что сеть будет разделена на две подсети с одним DHCP-сервером в каждой. Серверы DHCP имеют фиксированные IP-адреса, поэтому они, очевидно, знают, к какой подсети они принадлежат.

Затем подключаются новые клиенты. Они ничего не знают о том, в какой подсети они должны находиться, и отправляют свой DHCPDISCOVER в широковещательную рассылку Ethernet 255.255.255.255, поэтому она отправляется на оба DHCP-сервера. Оба сервера отвечают предложением. Теперь вот мой вопрос: как клиент узнает, какой DHCPOFFER он должен принять?

Answer 1

Самый простой ответ - первым пришел, первым обслужен.

Если у вас было несколько VLAN, и 10.10.10.0/24 находились в другой VLAN, отличной от 10.10.20.0/24 - широковещательная передача не пересекает VLAN.

Если DHCP-сервер находился в отдельной VLAN для клиентов, iphelper на интерфейсе маршрутизации между vlans направил бы широковещательную рассылку в правильное местоположение.

В вашем сценарии, где у вас есть две отдельные сети в одной VLAN (или их отсутствие), обслуживающие разные подсети - это гонка.

DHCP обслуживает с использованием следующих транзакций:

1. Обнаружение DHCP (DHCPDISCOVER) - Широковещательная рассылка - «Есть ли там DHCP-сервер?"
2. Предложение DHCP (DHCPOFFER) - сервер клиенту - «Да, я здесь и доступен!"
3. Запрос DHCP (DHCPREQUEST) - клиент-сервер "Отлично, могу ли я иметь адрес, пожалуйста?"
4. Подтверждение DHCP (DHCPACK) - сервер-клиент «Конечно, вот IP-адрес, маска, шлюз, некоторые DNS/WINS-серверы, сервер времени и все остальное, настроенное для вашей области»

Все это происходит на UDP-портах 67 для сервера и 68 для клиента.

Как только шаг 2 будет достигнут - клиент перестанет "слушать" ответы других DHCP-серверов - он счастлив иметь дело с первым сервером, чтобы уделить ему некоторое внимание.

В качестве примечания: на самом деле существует хорошо известная серия атак DoS (отказ в обслуживании), которые злоупотребляют этим правом. Злоумышленник подключает устройство, которое отвечает и отправляет пакеты DHCPOFFER, а затем не отправляет DHCPACK при запросе ... снова и снова. Существует также еще одна DoS-атака, когда "поддельные" DHCP-серверы предлагают адреса, которые нельзя маршрутизировать или которые конфликтуют с другими IP-адресами, которые прослушиваются для связи с сетями.

Answer 2

Существующий ответ от @ Fazer87 в целом верен на практике, и я рекомендую отклонить его и принять его. Этот ответ исследует мелкую деталь немного точнее.

---

Оба DHCP-сервера могут ответить сообщением DHCPOffer.

Клиент DHCP может принимать их по принципу «первым пришел - первым обслужен». Однако такой подход не требуется.

RFC2131 определяет:

Клиент получает одно или несколько сообщений DHCPOFFER от одного или нескольких серверов. Клиент может выбрать ожидание нескольких ответов. Клиент выбирает один сервер для запроса параметров конфигурации на основе параметров конфигурации, предлагаемых в сообщениях DHCPOFFER.

Таким образом, если второй DHCP-сервер предлагал более длительное резервирование IP-адреса или предлагал сервер времени, где другой не имел, или, возможно, имел настраиваемое поле, которое клиент запрограммировал на предпочтение, он может принять второе предложение.

Как правило, подход «первым пришел - первым обслужен» даст вам предложение, которое не прошло через несколько переходов между устройствами (ретрансляции BOOTP), поэтому это хороший протокол, которым нужно следовать, если у вас нет причин для беспокойства.

Я был в одном проекте, где пользовательское устройство предпочло бы DHCPOffer, который включал сервер TFTP, где можно было найти обновленную прошивку.