Какие настройки выдает DHCP сервер

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

  • Главная
  • Как устроен и работает протокол DHCP

Как устроен и работает протокол DHCP

  • Автор: Уваров А.С.
  • 12.07.2019

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

DHCP — это клиент-серверный протокол, использующий в качестве транспорта UDP, порт сервера — 67, порт клиента — 68. Так как для работы протокола используется широковещание (broadcast), то его действие ограничено текущей подсетью (широковещательным доменом). Для взаимодействия с клиентами расположенными в иных широковещательных доменах могут использоваться агенты ретрансляции (DHCP Relay), о них мы поговорим позже.

Основная задача протокола — получение клиентом IP-адреса, поля для иных сетевых настроек не предусмотрены, дополнительные сетевые параметры передаются протоколом DHCР в виде опций, например: опция 1 — маска сети, опция 3 — адрес маршрутизатора (основной шлюз), опция 6 — адреса серверов имен (DNS).

Получение адреса

Рассмотрим процесс получения IP-адреса, он достаточно прост и состоит из четырех этапов, которые в упрощенном виде показаны на следующей схеме:

Начинает этот процесс клиент, отправляя широковещательное сообщение Обнаружения DHCP (DHCP DISCOVER), в качестве обязательных полей передается номер транзакции — xid, MAC-адрес устройства — chaddr, также в опциях передается последний присвоенный клиенту IP-адрес, однако данная опция может быть проигнорирована сервером.

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

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

Обратим внимание на опцию 55 (Parameter Request List) — это список опции запрашиваемых клиентом. Именно так, опции всегда запрашиваются клиентом. С непониманием этого момента связаны ситуации, когда администратор добавил на сервере нужные ему опции, но клиенты их «почему-то» не получают. Ниже показан состав данной опции для Linux и Windows клиентов:

Можно увидеть, что Linux-клиент запрашивает опцию 42 — сервера времени (NTP), а Windows нет, поэтому даже если вы укажете ее на сервере, то Windows-клиенты не будут ее использовать. А что радует, так это что оба клиента запрашивают обе опции для получения маршрутов: предусмотренную стандартом 121 и введенную Microsoft 249.

Запрос обнаружения рассылается для всех узлов сети, но отвечают на него только DHCP-сервера, формируя сообщение Предложения DHCP (DHCP OFFER), которое содержит предлагаемую сервером сетевую конфигурацию. Если серверов несколько, то предложений клиент получит несколько. Из предложенных конфигураций клиент выбирает одну, как правило полученную первой. Предлагаемый клиенту адрес содержится в специальном поле yiaddr, а поле siaddr передается адрес DHCP-сервера.

Так как MAC-адрес отправителя известен, то сервер направляет ответ непосредственно клиенту (unicast), хотя в некоторых случаях может ответить и широковещательным пакетом. Например, DHCP-сервера dnsmasq и Mikrotik отвечает непосредственно клиенту (юникастом), в то время как DHCP Windows Server отвечает широковещательным пакетом. По большому счету это не имеет особого значения, просто вы должны знать, что это вполне допустимые режимы работы DHCP-сервера и не являются признаком неправильной работы.

В структуре ответа мы также отметили цветом вышеописанные опции, также обратите внимание, что в данном случае ответ был отправлен широковещательным пакетом (Windows Server). Ниже показана структура ответа dnsmasq:

Здесь видно, что сервер ответил непосредственно клиенту (отправив фрейм на его MAC-адрес), не прибегая к широковещательной рассылке.

Остальные сетевые параметры передаются в виде опций, в нашем случае это опции 1, 3 и 6 (маска, шлюз, DNS):

Приняв предложение клиент официально запрашивает у сервера данную конфигурацию, для чего отправляет широковещательно Запрос DHCP (DHCP REQUEST), он полностью повторяет по структуре сообщение обнаружения (Discover), только добавляет к нему опцию 54 с адресом сервера, конфигурацию которого клиент принял. Опция 50 содержит предложенный сервером IP-адрес. Несмотря на то, что MAC-адрес DHCP-сервера известен, запрос (Request) рассылается широковещательно, это нужно для того, чтобы остальные DHCP-сервера понимали, что их предложение отвергнуто.

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

Получив запрос сервер направляет клиенту в ответ Подтверждение DHCP (DHCP ACK), которое отправляется на MAC-адрес клиента (хотя может и широковещательно) и получив которое клиент должен настроить свой сетевой адаптер согласно указанного адреса и опций.

По структуре сообщение подтверждения (Ask) практически не отличается от предложения (Offer), за исключением того, что поле siaddr с адресом DHCP-сервера не заполняется, но его адрес передается в опции 54.

Получив адрес клиент может проверить его на предмет использования при помощи широковещательного ARP-запроса (в большинстве реализаций так и происходит) и если будет обнаружено, что выделенный адрес уже используется (скажем, назначен вручную), то клиент посылает широковещательное сообщение Отказа DHCP (DHCP DECLINE) и начинает процесс получения адреса заново. Сервер, получив сообщение отказа, должен пометить указанный адрес как недоступный и уведомить администратора о возможной проблеме в конфигурации (например, записью в логе).

Также клиент может самостоятельно отказаться от выданного адреса, отправив серверу сообщение Освобождения DHCP (DHCP RELEASE), в отличии от других сообщений, освобождение направляется юникастом серверу, выдавшему адрес. Получив такое сообщение сервер помечает адрес как доступный, но на всякий случай оставляет запись о клиенте, если он захочет получить адрес повторно. Это поведение не является обязательным, но реализовано в большинстве DHCP-серверов.

Обновление адреса

IP-адрес выдается клиенту на определенное время, называемое сроком аренды, его значение зависит от настроек сервера и может варьироваться в широких пределах, например, для DHCP-сервера Windows стандартный срок аренды — 8 дней.

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

Сразу после получения адреса клиент переходит в нормальное состояние (BOUND), при этом устанавливаются два момента времени T1 — равный половине времен аренды и T2 — равный 7/8 срока. По достижении времени T1 клиент переходит в состояние Обновления адреса (RENEWING), при котором он пытается обновить свой IP-адрес.

Для этого он отправляет сообщение запроса (Request), в котором указывает текущий IP-адрес. Если сервер подтверждает аренду, то отвечает сообщением подтверждения (Ask), клиент сбрасывает счетчики T1 и T2 и начинает отсчет срока аренды заново.

Читать еще:  Как посмотреть параметры видеокарты на Windows 7

Обратите внимание, что на сообщение запроса ответит только тот сервер, у которого имеется запись для этого клиента, если такой записи нет — запрос будет проигнорирован.

Данные о сроке аренды и времени обновления адреса и обновлении конфигурации передаются сервером в опциях 51, 58 и 59:

Если сервер не ответил клиенту, то он берет промежуток времени до окончания состояния обновления и делит его пополам, в это время будет отправлен повторный запрос, при его отсутствии промежуток времени снова будет поделен пополам, потом снова пополам, при этом полученный промежуток времени не может быть меньше 60 сек. Таким образом, чем ближе окончание срока обновления, тем чаще будут делаться запросы.

После наступления момента времени T2, если клиенту не удалось обновить адрес, он переходит в состояние обновления Обновления конфигурации (REBINDING). В этом случае он посылает сообщение Обнаружения DHCP, теперь клиенту может ответить любой DHCP-сервер, а не только тот, который выдал IP-адрес. Если ответа от сервера не было, то оставшееся время также делится пополам и запрос повторяется. Все это время клиент может продолжать пользоваться уже полученной сетевой конфигурацией и нормально работать.

Если же до окончания срока аренды ответ так и не был получен, то клиент прекращает все сетевые операции и переходит в состояние Инициализации (INIT). В последствии, при получении предложений (Offer) от различных серверов клиент предпочтет выбрать предложение от сервера, который выдавал ему адрес прошлый раз и продолжит пользоваться старым адресом.

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

Если сеть клиента корректна, но запрашиваемый адрес занят, то сервер также ответит сообщением отмены (Nak) и клиент начнет получение адреса повторно.

Получение дополнительной информации

Если клиент имеет статически назначенный IP-адрес, но хочет получить дополнительные параметры, скажем адрес серверов имен или статические маршруты, то он отправляет специальное широковещательное сообщение Информации DHCP (DHCP INFORM), в ответ сервера отправляют сообщение подтверждения (Ask) без выделения IP-адреса.

Объяснение работы DHCP сервера с примерами

В этом руководстве объясняются основные понятия DHCP-сервера, в том числе о том, как DHCP-сервер назначает автоматический IP-адрес через четыре состояния (обнаружение DHCP, предложение DHCP, запрос DHCP и подтверждение DHCP). Узнайте, что такое DHCP-сервер и как он работает в сети.

Компьютеры в сетях IP нуждаются в некой важной информации, прежде чем смогут общаться с другими хостами. Эта информация включает в себя IP-адрес и префикс маршрута и маршрутизации по-умолчанию. Настройка IP-адресации в большой сети на основе TCP / IP может быть кошмаром, особенно если машины часто перемещаются из одной сети в другую. DHCP устраняет ручную задачу сетевым администратором. Протокол конфигурации динамического хоста (DHCP) может помочь с рабочей нагрузкой при настройке систем в сети путем автоматического назначения адресов системам при загрузке. Он также предоставляет центральную базу данных устройств, которые подключены к сети и устраняет дублирование назначений ресурсов.

DHCP-сервер может иметь три метода распределения IP-адресов:

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

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

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

Среди этих трех методов, статический и динамический — самая популярная реализация.

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

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

DHCP discover

Клиентские компьютеры передают сообщения в физической подсети для обнаружения доступных DHCP-серверов. Этот клиент-компьютеры создает пакет протокола udp (User Datagram Protocol) с назначением широковещательной передачи по умолчанию 255.255.255.255 или определенным адресом широковещательной передачи подсети, если он настроен.

DHCP offer

Когда DHCP-сервер получает запрос аренды IP от клиента, он резервирует IP-адрес для клиента и расширяет предложение аренды IP, отправив сообщение DHCPOFFER клиенту. Это сообщение содержит MAC-адрес клиента, IP-адрес, который предлагает сервер, маску подсети, Продолжительность аренды и IP-адрес DHCP-сервера, делающего предложение.

DHCP request

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

DHCP acknowledgement

Когда DHCP-сервер получает сообщение DHCPREQUEST от клиента, процесс настройки переходит в свою заключительную фазу.

Фаза подтверждения включает отправку пакета DHCPACK клиенту. Этот пакет включает Продолжительность аренды и любую другую информацию о конфигурации, которую клиент мог бы запросить. На этом этапе процесс настройки IP завершен.

Администрирование #04. DHCP.

Прошу прощение за долгое отсутствие. Я поняла, что в моём man’е по DHCP написано прискорбно мало и решила полностью его переписать.

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

Для начала, что делает DHCP (Dynamic Host Configuration Protocol – протокол динамической настройки узла). С помощью этой штуки сетевые устройства могут получать IP-адрес и другие сетевые настройки автоматически. Работает этот протокол по клиент-серверной модели. В самом общем случае это выглядит так:

Клиент-всем: Дайте мне кто-нибудь настройки!

Сервер-клиенту: Держи, я тут сервер, вот настройки: «настройки». Тебе норм?

Читать еще:  File record segment is unreadable что делать

Клиент-серверу: Ага, «настройки» подходят, ништяк.

Сервер-клиенту: Пометил у себя, «настройки» записаны на твоё имя.

Клиент /сам с собой/ уф, применил «настройки», кажись пошел трафик.

Еще раз – это упрощение. На каждом этапе могут возникнуть свои нюансы и мы часть из них разберем. Пока о том, зачем это нужно: ведь есть статическое назначение адресов (и других настроек). На сегодняшний день, на мой взгляд, причина «во-первых» — это то, что для присвоения статических настроек надо хоть что-то знать о сетях, то есть – домохозяйка с роутером пролетает. Ну и причина «во-вторых», которая на самом деле наиболее важна – это автоматизация и централизация сетевой настройки. Круто, когда у вас 5 компов и в сети статика. Потом их станет 15 и появится файлик с адресами. Потом их становится 100… и в один непрекрасный момент срочно понадобится сменить DNS сервер или шлюз по умолчанию. И если на DHCP вы правите это в одном месте и настройки распространяются автоматом, то тут вы будете ходить и править сто компов руками (вас в процессе четвертуют скорее всего). К тому же, DHCP ведет за вас свой виртуальный «файлик» и не выдаст случайно одинаковые адреса разным хостам. В-третьих, это возможность выдавать адрес «на время», например, на неделю или на час. Вы же не будете каждому посетителю своего интернет-кафе прописывать адрес вручную и записывать в файлик. А так, адрес выдался автоматом, через час освободился и может быть выдан другому.

Для работы сервера выделяется некоторый пул (pool) – диапазон адресов, которые DHCP-сервер может раздавать клиентам.

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

Как видно из примера диалога выше, общение клиента и сервера разбито на несколько этапов-сообщений. В DHCP есть следующие типы сообщений: DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK, DHCPNAK, DHCPDECLINE, DHCPRELEASE, DHCPINFORM. Клиент и сервер общаются по протоколу UDP (у сервера порт 67, у клиента 68).

Эти сообщения выглядят в общем случае так: в шапке всякая важная мура из разряда кому, от кого, идентификаторы и всё такое, а в конце пачка опций. Вот эти опции и есть те настройки которые клиент запрашивает, а сервер выдаёт. Кому интересны подробности (а они правда интересны и важны), почитайте rfc2131.

На первом этапе клиент рассылает всем в локальной сети широковещательное сообщение на MAC-адрес FF:FF:FF:FF:FF:FF.

Отступление: Если у вас есть специальный сервер перенаправления запросов DHCP-relay, то сообщение может уйти и за пределы локальной сети.

Это сообщение DHCPDISCOVER. Тут возникает один нюанс: бывает так, что клиент «чистенький» — у него не было адреса, а бывает так, что у него был какой-то IP адрес и он говорит «неплохо бы повторить, если можно, бро». Во втором случае в список опций добавляется «requested IP address» с желаемым IP. Из важного в DHCPDISCOVER указывается ID транзакции (он будет одинаковым для всей цепочки обмена сообщениями) и идентификатор клиента (он должен быть уникальным в локальной сети, так что чаще всего это MAC).

В ответ все DHCP-серверы, до которых дошел запрос, присылают свои предложения DHCPOFFER тоже широковещательно на MAC-адрес FF:FF:FF:FF:FF:FF. Это происходит в том случае, если желаемый IP НЕ указан (о том, что происходит, когда указан – будет ниже). Клиент из них выбирает наиболее приглянувшееся (чаще всего по принципу «кто раньше прислал – того и тапки»). Сервер же, прежде чем прислать адрес, проверяет (протокол не обязывает, но настоятельно рекомендует), что адрес ещё не занят. В этом сообщении указывается уже предлагаемый IP, предлагаемые параметры и известен адрес-идентификатор сервера.

Подробнее про то, как выглядят остальные сообщения DHCP в Wireshark можно посмотреть в посте из соседней лиги. Или запустить wireshark дома.

Клиент, когда выбрал предложение, посылает DHCPREQUEST тоже широковещательно на MAC-адрес FF:FF:FF:FF:FF:FF, но с идентификатором сервера в соответствующем поле.

Сервер, если ничего криминально не случилось и адрес всё ещё свободен, посылает клиенту (всё так же широковещательно на MAC-адрес FF:FF:FF:FF:FF:FF) DHCPACK с настройками и помечает у себя адрес выданным. Уникальный идентификатор клиента и выданный IP-адрес однозначно идентифицируют DHCP-lease – так называемую аренду IP адреса. Если же адрес в процессе успел стать занятым, то клиенту посылается DHCPNACK с отказом и всё идёт заново.

Клиент получает сообщение DHCPACK с настройками, может сделать финальную проверку на занятость адреса и применяет эти параметры. С этого момента клиент сконфигурирован (и у вас пишется в винде «сеть1: подключено»).

Общая схема еще раз:

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

Вернёмся к DHCPDISCOVER и ситуации, когда мы просим выдать адрес, который у нас уже когда-то был. Rfc говорит нам, что в этом случае сервер сразу присылает DHCPACK (если адрес не помечен за кем-то другим) или DHCPNACK (если вы прошатались в отпуске месяц и адрес ушел к другому). Причем проверка на конфликты (пинг на всякий случай) ложится на клиента.

На самом деле, сколько ни ловила, так такую ситуацию и не поймала. У меня на DHCPDISCOVER с предпочитаемым IP в ответ приходил «Неправильный» DFCPOFFER на конкретный адрес. Подозреваю, что это ловился ipconfig /renew.

Если клиент обнаруживает, что с адресом что-то не в порядке, он посылает серверу DHCPDECLINE.

Немного о времени аренды IP-адреса. Это время в секундах, оно относительно, а потому не требует синхронизации времени между сервером и клиентом. То есть «забрать адрес через 3600 секунд» и без разницы, что у вас локаль Камчатки, а у сервера Москвы. Время аренды надо выбирать сообразно задачам – чтоб и адреса не кончались и слишком большой нагрузки на сервер не было. Интернет-кафе – час, дома – месяц, на работе – неделя, например. А еще есть время, через которое IP-адрес можно перезапросить, не отдавая его. Оно должно быть меньше времени аденды, тогда никто не захапает ваш адрес, пока ваш комп онлайн.

Теперь об опциях. Чаще всего, это DNS сервер, шлюз по умолчанию, ntp-сервер. А может быть куча всего – на это даже отдельный rfc2132 есть. У нас, например, такие.

Бывает еще такая вещь, как резервации (reservations). Это не когда индейцев ограничивают, а когда адрес добавляют к резервированию. Некоторые lease’ы запоминаются (админ указывает, какие именно). То есть, пара MAC-IP становится постоянной. Это позволяет получить статические адреса внутри пула, которые клиенты тем не менее получают по DHCP.

Протокол DHCP (FAQ для системного администратора)

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

Что такое DHCP? И почему рекомендуется использовать его? Представьте, что вы работаете администратором в крупной компании с 500 настольными компьютерами, и вам на каждом необходимо установить IP адрес, маску подсети, шлюз по умолчанию, DNS сервера и другие сетевые настройки. Как можно это выполнить?

Читать еще:  Как удалить защитник Windows 10 навсегда

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

Для того, чтобы решить эти проблемы, вы можете задействовать в вашей сети протокол Dynamic Host Configuration Protocol (DHCP).

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

DHCP сервер может легко и полностью автоматически предоставлять IP-адреса клиентам, поэтому вам не нужно настраивать и устанавливать какие-либо параметры на стороне клиента, все, что вам нужно, это настроить сервер DHCP, настроить параметры области (scope) и некоторые другие параметры протокола TCP / IP. Вы можете предоставить своим клиентам IP-адреса из выбранного вами диапазона IP-адресов.

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

Как работает DHCP?

Не вдаваясь в техническую информацию (процесс DORA), скажу, клиент DHCP запрашивает у сервера DHCP на некоторое время IP адрес, время, на которое клиент DHCP получил динамический IP адрес, называется временем аренды (lease): аренда означает, что клиент арендовал IP-адрес у сервера DHCP на определенное время, и если клиент хочет продолжить использовать конкретного IP-адреса, ему необходимо продлить (renew) аренду.

Разберем этот процесс более подробно. Служба DHCP работает с использованием процесса DORA (Discover, Offer, Request and Acknowledgment — его можно отследить с помощью утилиты Network Monitor):

1) DHCPDISCOVER — клиент шлет широковещательный пакет DHCPDISCOVER, пытаясь найти сервер DHCP в сети, в случаях, когда сервер DHCP не нашелся в той же подсети, что и клиент, нужно настраивать на сетевых устройствах (маршрутизаторах) DHCP Relay Agent, в целях передачи пакета DHCPDISCOVER на сервер DHCP.

2) DHCPOFFER — сервер DHCP шлет широковещательный пакет DHCPOFFER для клиента, который включает предложение использовать уникальный IP адрес.

3) DHCPREQUEST — клиент шлет широковещательный пакет DHCPREQUEST на сервер DHCP с ответом, и «просит» у сервера выдать в аренду предложенный уникальный адрес.

4) DHCPACK — сервер DHCP шлет клиенту широковещательный пакет DHCPACK, в этот пакете сервером утверждается запрос клиента на использование IP-адреса, а также сообщаются и другие детали, такие, как сервера DNS, шлюз по умолчанию, и т.д. Если сервер не может предоставить запрашиваемый адрес или по каким-то причинам адрес недействителен, сервер посылает пакет DHCPNACK.

Примечание: Служба DHCP использует порт 67/UDP на сервере DHCP, и 68/UDP на клиентах DHCP.

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

В некоторых случаях можно обнаружить еще некоторые типы DHCP-сообщений:

1) DHCPDECLINE — Если клиент определяет, что IP-адрес, который предлагает ему сервер DHCP, уже используется, клиент сгенерирует новый запрос на другой адрес (в шаге DHCPREQUEST).

2) DHCPRELEASE — Это сообщение обычно используется, когда клиент освобождает IP- адрес.

3) DHCPRENEW — Это пакет с просьба обновить и продолжить аренду выданного адреса.

4) DHCPINFORM — DHCPINFORM это пакет, который клиент посылает на сервер DHCP для того, чтобы получить более подробную информацию с сервера, например DHCPINFORM можно отправить в целях установления местонахождения другого DHCP сервера в сети.

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

В случае получения DHCPNACK, клиенту необходимо перезапустить процесс получения в аренду адреса.

Области DHCP, исключения и резервации

Область (scope) DHCP – это целый диапазон IP адресов, которые вы настроили на сервере DHCP, в качестве диапазона адресов, предназначены для выдачи среди клиентов.

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

Вы также можете создавать более одной области на одном DHCP-сервере, но в этом случае рекомендуется проверить, что ваши области не пересекаются и не дублируют друг друга. В процессе создания таких областей вы можете индивидуально настроить на клиентах параметры TCP / IP, такие как маска подсети, времени аренды, маршрутизатор (шлюз по умолчанию), DNS-сервера и т.д, поэтому получая свой адрес из той или иной области, клиенты получают также и другие параметры области.

В некоторых случаях, Вам будет необходимо предотвратить получение клиентами некоторых адресов, например, если ваша область DHCP имеет диапазон от 10.0.0.1 до 10.0.0.100, а IP-адреса Ваших серверов находятся в диапазоне 10.0.0.1-10.0.0.10, Вам понадобится возможность исключить эти IP адреса из области, которая выдается DHC-сервером. Такая возможность называется исключением (exclude).

Резервация(reservation) – используется в случаях, когда Вы планируете представить конкретный динамический IP-адрес определенному клиенту DHCP. Например, в своей области DHCP, вы хотите выделить для конкретного клиента уникальный адрес, который будет закреплен за ним, для этого Вы можете легко создать для него резервацию, используя уникальный идентификатор — MAC-адрес (Media Access Control — представляет собой уникальный шестнадцатеричный физический адрес сетевого адаптера).

Active Directory и сервер DHCP

Для корректной работы вашего Microsoft Windows DHCP – сервера в среде Active Directory, Вам необходимо сначала авторизовать свой DHCP – сервер в AD.

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

DHCP Relay Agent

DHCP Relay Agent – это тип хоста (обычно маршрутизатор или сервер), которые принимает широковещательные трансляции DHCP / BOOTP от клиентов в подсетях, не имеющих локальных серверов DHCP.

DHCP Relay Agent пересылает пакеты от клиентов и серверов DHCP, которые находятся в различных физических подсетях, позволяя им работать по протоколу DHCP, т.е. выполняет функции посредника

В заключение

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

Ссылка на основную публикацию
Adblock
detector