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

2478
Michael Niemand

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

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

DHCP situation

16
Сравните [этот вопрос] (https://superuser.com/q/1287263/432690) и ответы там. Kamil Maciorowski 5 лет назад 0
Вот еще один [связанный вопрос] (https://superuser.com/q/1367891/326546). kasperd 5 лет назад 0
«Ethernet-широковещание 255.255.255.255» - это широковещательный IP-адрес для локальной сети, а не адрес Ethernet. Исходные сообщения DHCP DISCOVER также могут использовать широковещательный адрес Ethernet ff: ff: ff: ff: ff: ff, но на самом деле это не одно и то же. ilkkachu 5 лет назад 1

2 ответа на вопрос

26
Fazer87

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

Если у вас было несколько 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-адресами, которые прослушиваются для связи с сетями.

И поэтому короткий ответ на вопрос «Но тогда как мне запустить несколько подсетей в одном сегменте уровня 2?» это "** Вы не делаете. **" (Да, есть способы, но это не то, что вы обычно должны делать. Один домен уровня 2 = одна подсеть.) grawity 5 лет назад 16
Спасибо вам, ребята, что действительно сошлись со мной. Мне всегда было интересно, как это возможно, но это просто не так. Итак, вот что нужно сделать: есть ли маршрутизатор / коммутатор 3-го уровня между подсетями или сегментом с VLAN, я прав? Michael Niemand 5 лет назад 0
В общем, да, вам нужны VLAN или физическая сегментация. Совместное использование домена L2 было бы выполнимо * только *, если бы оба ваших DHCP-сервера были ограничены обработкой «известных» клиентов (например, с помощью списка «статической аренды» с разрешенными MAC-адресами). grawity 5 лет назад 4
Я думаю, что вы могли бы дать каждому DHCP-серверу белый список MAC-адресов и контролировать, какой клиент получает адрес с какого сервера таким образом. Darren 5 лет назад 3
@ Grawity, вы можете легко запустить несколько IP-подсетей в одном сегменте уровня 2, если подсети равны, и вам все равно, какой клиент получает адрес, из какой подсети. У вас просто есть один DHCP-сервер, который выдает адреса из обоих блоков, и один маршрутизатор, который действует как шлюз для обоих блоков (с адресом в каждом). Готово. Сказать «ты не» - это просто неправильно. ilkkachu 5 лет назад 0
Как говорится в [ответе от странного мышления] (https://superuser.com/a/1370324/600133), клиент может полностью прослушивать несколько DHCPOFFER, прежде чем решить, что делать. Там нет ничего, чтобы заставить его остановиться в первую очередь. Я предполагаю, что вы хотели упростить, основываясь на том, что делают наиболее распространенные реализации, но если вы это сделаете, по крайней мере, укажите свои предположения. ilkkachu 5 лет назад 0
@ilkkachu: Да, я делаю это в своей сети. Я сделал это с одним сервером DHCP и с двумя. Это все еще не то, что вы должны делать. grawity 5 лет назад 0
@ Grawity, я до сих пор не вижу твоих аргументов, почему кто-то даже "не должен" делать это. ilkkachu 5 лет назад 0
9
Oddthinking

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

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

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

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

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

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

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

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

... или если один сервер предложил адрес, который клиент уже использовал ранее и хотел сохранить ilkkachu 5 лет назад 0
@ilkkachu: Да, в теории, но для этого есть более эффективные механизмы (как обновление резервирования до истечения срока его действия со старым сервером DHCP, так и отправка DHCPDiscovery, запрашивающего старый IP-адрес), поэтому на практике это вряд ли будет полезным. Oddthinking 5 лет назад 0

Похожие вопросы