Два dhcp сервера в одной сети

Что такое DHCP и как это работает

Даже многие системные администраторы, годами работающие с сетевыми устройствами, не всегда могут дать чёткий и внятный ответ — что такое DHCP сервер. Знают что если он работает, то у компьютера появится IP-адрес — и то хорошо.

А ведь это очень важный момент! Этот протокол значительно облегчает жизнь системному администратору при настройке и управлении сетями.

Он работает как в обычных домашних сетях на бытовых WiFi-роутерах и модемах, так и в крупных корпоративных сетях и помогает компьютеру, ноутбуку или иному сетевому устройству быстро получить АйПи-адрес и идентифицироваться.

Давайте подробнее рассмотрим основные принципы работы DHCP сервера.

Что такое DHCP?

DHCP — Dynamic Host Configuration Protocol — это протокол динамической настройки узла прикладного уровня по модели OSI. Он разработан ещё в 1993 году, но до сих пор не только не потерял актуальности, но и наоборот — получил новую версию для работы с протоколом IPv6.

 Модель работы — «Клиент-сервер». При этом, у DHCP-сервера есть собственный метод обмена сообщениями между клиентом и сервером.

Протокол позволяет выполнить автоматическую настройку протокола IP версии 4, а так же и более новой версии 6, тем самым облегчив процесс настройки сети и исключив вероятность ошибки при ручном вводе данных.

Что делает DHCP-сервер?!

На ДХЦП-сервере системным администратором задаётся определённый диапазон IP-адресов, которые можно выдавать устройствам-клиентам при обращении. При этом дополнительно может настраиваться срок аренды адреса (lease time) в течение которого он закреплён за MAC-адресом компьютера и не может быть занят иным устройством.

У сервера есть три варианта распределения адресов в сети:

1 — Динамическое. Именно этот вариант работает на 95% серверов. Адрес выдаётся компьютеру на определённый срок (время аренды), по истечению которого АйПи будет считаться свободным и может быть назначен иному компьютеру в сети.

3 — Ручное. В этом случае администратором сервера составляется таблица соответствия IP и MAC-адресов устройств, согласно которой в дальнейшем они и будут получать сетевые параметры. Этот способ практически не используется. Если только в сетях с повышенным уровнем безопасности.

Как работает DHCP сервер

Работа сервера основывается на широковещательных сетевых запросах. Процедура «общения» клиента и сервера выглядить примерно так:

1. Клиент отправляет broadcast-сообщение «Мне нужен IP»
2. Сервер отвечает таким же сообщением «У меня есть адрес xxx.xxx.xxx.xxx. Устроит?»
3. Клиент — «Да устроит!»
4. Сервер — «ОК! Адрес xxx.xxx.xxx.xxx зарезервирован за тобой».
Для представленного «общения» используются следующие специальные широковещательные broadcast-запросы.

Вот, для наглядности, схема диалога клиента и сервера ДХЦП:

Диапазон IP-адресов, предназначенных для распределения между клиентами одной сети с помощью протокола DHCP, рассматривается как единый административный блок. Он называется «область действия» — scope.

Если сервер работает с несколькими подсетями, то при настройке службы DHCP, администратор должен создать отдельную область действия для каждой физической подсети.

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

Виды запросов сервера

Схема обмена сообщениями между клиентом и DHCP сервером:

DHCPDISCOVER — Это сообщение отправляется клиентом при подключении к сети для поиска активного DCHP сервера. При этом в качестве исходного IP используется 0.0.0.0, а в качестве адреса доставки — 255.255.255.255.

DHCPOFFER — Ответное сообщение DHCP-сервера на клиентский запрос DHCPDISCOVER, в котором предлагаются определённые сетевые настройки.

DHCPREQUEST — Broadcast-сообщение от клиента в ответ на DHCPOFFER, сообщающее о том, что он принял настройки.

DHCPACK — ответное послание клиенту после получения от него DHCPREQUEST, означающее завершение процесса общения. Оно подтверждает о том, что всё согласовано и ПК может работать в сети.

DHCPRELEASE — Такое широковещательное сообщение отправляется клиентом если он прекращает использования сетевого адреса.

DHCPNAK — Этот ответ будет отправлен клиенту в случае, если невозможно удовлетворить параметры DHCPREQUEST.

DHCPDECLINE — Широковещательный ответ серверу в том случае, когда клиент обнаруживает, что присвоенный ему IP-адрес уже используется.

DHCPINFORM — Сообщение серверу в том случае, если у клиента DHCP прописан статический IP-адрес и он не нуждается в динамическом распределении.

Сообщения протокола DCHP имеют следующие поля:

Поле	Длина (байты)	Описание
op	1	Тип сообщения
htype	1	Тип адреса аппаратной части
hlen	1	Длина адреса аппаратной части
hops	1	Используемое количество агентов ретрансляции. Клиенты устанавливают значение на 0.
xid	4	ID  (уникальный идентификационный номер) транзакции используемой клиентом и серверов во время сессии
secs	2	Прошедшее время (в секундах) с момента запроса клиентом начала процесса
flags	2	Значение флагов
ciaddr	4	IP-адрес клиента (если имелся ранее).
yiaddr	4	IP-адрес, предложенный сервером клиенту
siaddr	4	IP-адрес сервера
giaddr	4	IP-адрес relay-агента (агента ретрансляции)
chaddr	16	Адрес аппаратной части клиента (в основном MAC).
sname	64	Имя сервера.
file	128	Название загрузочного файла.
options	изменяемая	Дополнительные опции

Как включить DHCP на сетевом адаптере

В операционной системе Windows 10 DHCP-клиент включен по умолчанию как служба, а на сетевом адаптере необходимо выставить автоматическое получение IP. Для этого нажимаем комбинацию клавиш Win+R чтобы открыть окно «Выполнить» и вводим команду ncpa.cpl.

Нажимаем на кнопку «ОК». Появится окно с сетевыми подключениями Виндовс 10.

На том адаптере, где хотим включить DHCP, кликаем правой кнопкой чтобы появилось контекстное меню. В меню — выбираем пункт «Свойства».

В следующем окне надо выбрать строчку «IP версии 4(TCP/IPv4)» и нажимаем на кнопку «Свойства» чтобы открыть параметры протокола:

Здесь необходимо поставить галочки на автоматическое получение адресов и нажать на кнопку «ОК».

В операционных системах семейства Linux все настройки прописаны в конфигурационных файлах. Например, в популярной Ubuntu это /etc/network/interfaces. Вот пример конфига, который позволяет включить DHCP на сетевом адаптере eth0:

Здесь:
auto eth0 — автоматическое включение сетевой карты eth0 при загрузке системы.
iface eth0 inet static — этой строчкой мы указываем системе, что интерфейс сетевой карты eth0 находится в диапазоне адресов с динамическим получением ip.

Если в системе работает менеджер соединение Network Manager, то можно включить DHCP на сетевом адаптере и в графическом интерфейсе:

 P.S.:
Отдельно стоит отметить что наличие работающего сервиса DHCP является признаком хорошего тона для любой локальной сети. Настройка сервера требует от администратора особых серьёзных знаний! В большинстве современных сетевых устройств (терминалов, роутеров и модемов) он вообще уже настроен по умолчанию и не требует дополнительной конфигурации.

Источник: https://set-os.ru/chto-takoe-dhcp/

Курс по основам компьютерных сетей на базе оборудования Cisco. Этот курс поможет вам подготовиться к экзаменам CCENT/CCNA, так как за его основу взят курс Cisco ICND1

Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем изучать основы работы компьютерных сетей. Продолжаем разбираться с протоколом DHCP в рамках подготовки к CCNA. На этот раз мы посмотрим на процесс получения IP-адреса по DHCP, а также разберемся с тем как и при помощи каких сообщений происходит взаимодействие между DHCP-сервером и DHCP-клиентом.

9.2.1 Введение

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

9.2.2 Упрощенный алгоритм взаимодействия DHCP-сервера и DHCP-клиента

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

Первое и важное условие нормальной работы DHCP-сервера заключается в том, что он должен находиться в одной подсети/канальной среде с клиентом, иначе ничего работать не будет. В дальнейшем мы убедимся, что это не всегда так и если сервер и клиент находятся в разных подсетях, то им необходим посредник, который называется DHCP Relay Agent. Ну а теперь перейдем к алгоритму взаимодействия между клиентом и сервером по DHCP.

1. Как и в любой порядочной схеме клиент-сервер, взаимодействие по DHCP инициирует клиент. Когда клиент просыпается и осознает, что сетевые настройки нужно получить по DHCP, он формирует специальное широковещательное сообщение, называемое DHCPDISCOVER, этим сообщением он пытается найти DHCP-сервер в своей сети. Вы же помните, что широковещательные сообщения в протоколе Ethernet не выходят за пределы канальной среды?
2. Если в канальной среде с клиентом находится сервер, то он получит DHCPDISCOVER, если сервера нет, то, возможно, это сообщение получит DHCP Relay Agent и перешлет его серверу, если нет и его, то клиент обломится.
3. Но представим, что сервер есть и сообщение он получил. В ответ на DHCPDISCOVER сервер сформирует сообщение, называемое DHCP-предложением или на древнерусском DHCPOFFER. В сообщение DHCPOFFER содержится IP-адрес, который сервер хочет предложить клиенту и другая информация, которая может пригодиться. Сообщение DHCPOFFER может быть отправлено сервером как broadcast, так и unicast, ведь мак-адрес клиента сервер уже изучил. От чего это зависит мы увидим чуть позже.
4. В нашей сети может быть несколько DHCP-серверов, и они все могут получить DHCPDISCOVER от клиента и направить ему DHCPOFFER. Естественно, клиент их все получит и обычно выберет первое неконфликтное предложение от одного единственного сервера. В ответ на выбранный DHCPOFFER клиент сформирует сообщение DHCPREQUEST, из которого будет понятно, с каким сервером он станет дальше дружить. DHCPREQUEST – широковещательное сообщение, это сделано специально, чтобы все сервера в сети видели, какие параметры выбрал клиент и с кем он дальше решил работать.
5. Все серверы получают DHCPREQUEST, но только выбранный сервер продолжит взаимодействие с клиентом, на DHCPREQUEST сервер ответит сообщением DHCPACK, которое служит подтверждением или, если хотите, официальным разрешением от сервера на использование клиентом выбранного IP-адреса.
6. Как только клиент получил сообщение DHCPACK, он переходит в рабочее состояние и смело пользуется IP-адресом.

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

9.2.1 DHCP сообщения, которыми обмениваются клиент и сервер, когда клиент пытается получить IP-адрес

На этой схеме показаны DHCP пакеты, которыми будут обмениваться устройство в тот момент, когда клиент пытается получить IP-адрес от сервера в первый раз, на схеме не показаны сообщения, которые могут возникать при различного рода конфликтах. В общем, это идеальный случай, его вы будете встречать чаще всего.

9.2.3 DHCP-клиент и DHCP-сервер, базовая настройка

Теперь нам нужно закрепить полученные знания о взаимодействие между DHCP-сервером и DHCP-клиентом на практике, для этого мы расчехлим Cisco Packet Tracer и соберем простую схему, которая показана ниже.

9.2.2 Схема сети для демонстрации взаимодействия между DHCP-клиентом и сервером

Вокруг этой схемы мы и будем плясать, в центре схемы находится обычный L2 коммутатор, в его настройки мы не лезем, поэтому можно смело утверждать, что все устройства в нашей сети находятся в одной канальной среде.

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

Также на схеме есть два DHCP-сервера, которые уже подключены к коммутатору и три клиента, из которых пока подключен только один.

Перед началом настройки схемы не забудьте переключить Cisco Packet Tracer в режим симуляции. Роутеру и двум серверам нужно будет назначить статический IP-адрес, так как здесь адреса ни при каких сбоях не должны измениться, роутер для клиентов является основным шлюзом, а DHCP-сервера источником настроек. Клиент должен получать настройки динамически.

9.2.3.1 Настройка протокола DHCP на сервере и клиенте в Cisco Packet Tracer

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

9.2.3 Настройки протокола IP на DHCP сервере

Серверу я не стал давать адрес шлюза по умолчанию, так как серверу не нужен доступ в Интернет, где найти IP настройки для устройств в Cisco Packet Tracer, вы уже должны знать, показывал и не один раз. Следующим пунктом нашей программы будет настройка DHCP на сервере. Для этого перейдите на вкладку Services и в левом меню выберете DHCP.

9.2.4 Настройки DHCP на сервере

Обратите внимание, здесь уже заполнены поля Start IP Address и Subnet Mask, мы же еще помним, что и клиент, и сервер должны находиться в одной канальной среде, чтобы было всё гуд. Когда мы назначили IP-адрес на интерфейс сервера, Cisco Packet Tracer сам назначил значения в эти поля за нас, если IP-адрес не назначать, то в этих полях будут унылые нули.

9.2.5 Продолжаем настраивать DHCP сервер

Все изменения я выделил, для начала был включен DHCP при помощи чекбокса, затем я дал имя новому пулу IP-адресов, который сервер будет использовать для выдачи клиентам, а также была указана дополнительная опция в виде адреса шлюза по умолчанию.

Чтобы пул был добавлен, следует нажать кнопку Add, после чего внизу у нас появится два пула IP-адресов: один – этот тот, что создали мы, второй – это тот, что был создан Cisco Packet Tracer автоматически.

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

Итак, что мы сделали, чтобы настроить DHCP-сервер, а сделали мы следующее:

1. Настроили IP-адрес на интерфейсе сервера.
2. Создали пул IP-адресов, из которого сервер будет выдавать настройки клиенту.
3. Дали этому пулу имя, так как пулов у DHCP-сервера может быть несколько.
4. Указали начальный IP-адрес пула (поле Start IP Address), это означает, что сервер будет пытаться выдавать IP-адреса, начиная с 192.168.0.1 (а не с 192.168.0.0, ведь сервер понимает, что это номер сети, а также он немного в курсе о том, что в 21 веке мы все используем маску подсети переменной длины, а про классовые сети мы все уже забыли).
5. Также мы дали указание серверу выдавать две опции: маску подсети и IP-адрес шлюза по умолчанию.

Собственно, это всё, что нам сейчас необходимо. Сейчас мы сконфигурировали DHCP-сервер в режиме автоматической выдачи динамических IP-адресов, для нас этот режим самый интересный.

9.2.3.2 Настройки DHCP на клиенте

Настройка DHCP на клиенте гораздо проще, нужно только поставить галочку напротив «Получать IP-адрес по DHCP» и забыть про утомительный ручной труд.

9.2.6 Настройка протокола DHCP на клиенте

Фразы «Гибкая настройка» и Cisco Packet Tracer плохо совместимы, в реальных операционных системах вы сможете задать: какие параметры рабочая станция должна получить по DHCP, а какие параметры вы можете ввести своими руками. Но это нам сейчас не интересно, нам важно разобраться с тем, как клиент получает IP-адрес от DHCP сервера и это мы сделаем. Настройка протокола DHCP на клиенте на этом закончена.

9.2.4 Как клиент получает IP-адрес по DHCP

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

9.2.7 Клиент сформировал сообщение DHCPDISCOVER

На зеленый пакет, сформированный сервером, не обращайте внимание. Нас интересует желтый пакет, который сформировал клиент, это и есть DHCPDISCOVER, давайте на него посмотрим.

9.2.8 Сообщение DHCPDISCOVER в Cisco Packet Tracer

Здесь сразу видно, что пртокол DHCP работает на прикладном уровне моделей OSI 7 и TCP/IP. Также тут видно, что клиент еще не разу не получал IP-адрес от сервера и даже не знает, где этот сервер находится. На транспортном уровне протокол DHCP инкапсулируется в UDP дейтаграммы, когда клиент делает запрос серверу, то в качестве порта источника он выбирает 68 порт, а в качестве порта назначения используется 67 порт.

Клиент не знает IP-адрес сервера, да и своего у него еще нет, поэтому на сетевом уровне в качестве IP-адреса источника он использует IP-адрес 0.0.0.0, а в качестве IP-адреса назначения используется 255.255.255.255. Мы видим, что это широковещательный запрос.

На канальном уровне клиент указывает свой мак-адрес в качестве источника и широковещательный мак-адрес в качестве назначения. Ниже показана структура пакета DHCPDISCOVER, но с ней мы будем разбираться на примере дампа Wireshark.

9.2.9 Структура пакета DHCPDISCOVER в Cisco Packet Tracer

А сейчас продолжим разбираться и посмотрим, что будет, когда запрос DHCPDISCOVER дойдет до серверов.

9.2.10 Запрос DHCPDISCOVER дошел до всех участников канальной среды

Здесь мы видим, что DHCPDISCOVER, посланный клиентом, дошел до всех участников канальной среды, что и не мудрено, ведь он широковещательный, но этот запрос оказался интересным только двум нашим DHCP-серверам. Когда сервер получил DHCPDISCOVER он понял, что в сети появился клиент, которому нужно выдать IP-адрес, сервер смотрит на пул IP-адресов, который у него есть и ищет свободный адрес, обычно это процесс упорядоченный и клиенту будет выдан первый свободный адрес из пула.

Но тут всё не так просто, дело в том, что компьютерная сеть – это то место, где изменения происходят очень быстро, поэтому прежде чем сформировать DHCPOFFER, сервер должен убедиться, что в сети еще не появился какой-нибудь негодяй, который уже начал использовать IP-адрес, который сервер решил выдать этому клиенту, а может случиться так, что другой сервер выдал  выбранный адрес клиенту чуть раньше, это надо проверить.

Поскольку у нас канальная среда Ethernet, то для проверки будет идеальным протокол ARP, он позволяет опросить все устройства в канальной среде. Вы же знаете, что при помощи ARP-запроса машины узнают мак-адреса по известному IP-адресу. И дело тут в том, что серверу известен IP-адрес, который он хочет выдать клиенту, он его и использует в ARP-запросе и кричит на всю канальную среду: кто использует IP-адрес такой-то?

ARP-запрос – это зеленый пакет, на котором нет значка паузы. Наши сервера настроены одинаково, базы данных у них сейчас одинаковые, поэтому и ARP-запросы они делают одинаковые, сам запрос показан ниже.

Тут мы видим, что наш первый сервер спрашивает всех соседей по канальной среде: у кого IP-адрес 192.168.0.1, я сервер с IP-адресом 192.168.0.2? Но, как мы помним, адрес 192.168.0.1 мы настроили на роутере, он уже занят. И ничего страшного, что этот адрес занят нашим маршрутизатором, маршрутизатор получит ARP-запрос и любезно на него ответит своим ARP-ответом, получив ответ, наши сервера поймут, что адрес 192.168.0.1 занят и нужно искать следующий адрес для выдачи.

В зависимости от реализации, после ARP-запроса, сервер может еще попробовать и попинговать IP-адрес 192.168.0.1, чтобы окончательно убедиться в том, что он занят. Такие проверки будут продолжаться до тех пор, пока DHCP-сервера не доберутся до IP-адрес 192.168.0.4 в своем пуле, ведь это первый адрес, который еще не используется в нашей сети, для этого адреса будет сформирован ARP-запрос, на который никто не ответит.

9.2.13 ARP-запрос от DHCP сервера, на который никто не ответит

Тут опять же, всё зависит от конкретного DHCP-сервера, ARP-запрос может быть повторен, а после него сервер может еще и попробовать опросить адрес по ICMP, все это нужно, чтобы убедиться, что адрес еще никто не занял, а только после этого формировать сообщение DHCPOFFER.

Источник: https://zametkinapolyah.ru/kompyuternye-seti/9-2-process-polucheniya-ip-adresa-po-dhcp-dhcp-klient-i-dhcp-server.html