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

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

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

DHCP situation

9
задан Boann
19.11.2022 17:56 Количество просмотров материала 3669
Распечатать страницу

2 ответа

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

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

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

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

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

  1. обнаружение DHCP (DHCPDISCOVER) - Client Broadcast - " есть DHCP Сервер снаружи?"
  2. предложение DHCP (DHCPOFFER) - Server to Client - "Да, я здесь и доступен!"
  3. запрос DHCP (DHCPREQUEST) - Client to Server "потрясающе, могу ли я получить адрес, пожалуйста?"
  4. подтверждение DHCP (DHCPACK) - Server to client " конечно, вот IP, маска, шлюз, некоторые DNS / WINS-серверы, сервер времени и все остальное, настроенное для вашей области"

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

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

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

25
отвечен Fazer87 2022-11-21 01:44

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


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

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

RFC2131 указывает:

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

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

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

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

9
отвечен Oddthinking 2022-11-21 04:01

Постоянная ссылка на данную страницу: [ Скопировать ссылку | Сгенерировать QR-код ]

Ваш ответ

Опубликуйте как Гость или авторизуйтесь

Имя
Вверх