Dynamic Host Configuration Protocol (DHCP) — сетевой протокол, предназначенный для автоматической конфигурации параметров сети на сетевых узлах. DHCP является одной из ключевых служб сетевой инфраструктуры и каждый, кто имеет отношение к компьютерным сетям, должен хотя бы в общих чертах представлять принципы его работы.
Для начала давайте вспомним, что требуется компьютеру для работы в сети. К примеру, так выглядит консоль настроек сети в Windows.
Как видите, для начала работы компьютеру нужен IP-адрес, маска подсети и шлюз по умолчанию, а также хотя-бы один DNS-сервер. Сама процедура настройки несложная, при наличии опыта на один компьютер потребуется не больше минуты. Но если настроить надо не один, а несколько сотен устройств, да еще и территориально расположенных в разных местах? Вручную это сделать практически нереально, поэтому в корпоративных сетях для централизованного управления сетевыми настройками используются DHCP-сервера.
С помощью DHCP решаются две основные проблемы:
• Автоматизация. При наличии в сети DHCP-сервера не требуется производить настройки на каждом новом клиенте. Достаточно один раз настроить DHCP-сервер и дальнейшая настройка IP-адресов и прочих сетевых параметров производится автоматически;
• Централизованное управление. DHCP-сервер осуществляет контроль за выданными адресами, предотвращает их дублирование, а также своевременно освобождает неиспользуемые IP-адреса.
Подробно протокол DHCP описан в документе RFC 2131, мы же не будем вдаваться в детали, а рассмотрим только основные моменты. Начнем с процедуры получения настроек.
Получение настроек
DHCP работает по схеме клиент-сервер. Процесс получения настроек происходит в несколько этапов и описывается схемой DORA (Discover-Offer-Request-Acknowledge):
Discover (Обнаружение)
Клиент DHCP подключается к сети и приступает к инициализации (состояние INIT). Первым делом он ищет в сети подходящий DHCP-сервер, для чего отправляет запрос DHCPDISCOVER на широковещательный адрес 255.255.255.255. В качестве своего адреса клиент указывает 0.0.0.0, поскольку своего адреса у него еще нет. Также в запросе клиент указывает свой MAC-адрес. Запрос доставляется всем компьютерам, находящимся в данном сегменте сети, но отвечают на него только DHCP-сервера.
Offer (Предложение)
DHCP-сервер, получивший запрос DHCPDISCOVER, анализирует его содержимое, выбирает подходящую конфигурацию сети и отправляют ее в сообщении DHCPOFFER. Обычно DHCPOFFER отправляется на MAC-адрес клиента, указанный в DHCPDISCOVER, хотя иногда может использоваться широковещание. Если в сети находятся несколько DHCP-серверов, то клиент получает несколько ответов DHCPOFFER и выбирает из них один, как правило полученный первым.
Request (Запрос)
Получив ответ сервера, клиент отвечает сообщением DHCPREQUEST, в котором ″официально″ запрашивает у сервера предоставленные настройки. В сообщении DHCPREQUEST содержится та же информация, что и в DHCPDISCOVER, а также IP-адрес выбранного DHCP-сервера. DHCPREQUEST отправляется на широковещательный адрес и те DHCP-сервера, чей адрес отсутствует в сообщении, понимают что их предложение отвергнуто.
Acknowledge (Подтверждение)
DHCP-сервер, адрес которого указан в DHCPREQUEST, получает сообщение и понимает, что его выбрали. Он фиксирует привязку для клиента и отвечает сообщением DHCPACK, подтверждая выданные клиенту настройки. DHCPACK отправляется на MAC-адрес клиента, указанный в DHCPREQUEST. Клиент получает сообщение DHCPACK, проверяет настройки и применяет конфигурацию (состояние BOUND), которая была получена в сообщении DHCPOFFER.
Клиент может проверить полученный от DHCP-сервера адрес, например с помощью широковещательного ARP-запроса. Если обнаружится, что предложенный адрес уже используется в сети, то клиент отправляет серверу сообщение DHCPDECLINE и начинает процедуру инициализации заново. Сообщение DHCPDECLINE передается в широковещательном режиме, поскольку клиент отвергает предложенный ему IP-адрес. DHCP-сервер, получив сообщение DHCPDECLINE, должен пометить IP-адрес как недоступный, а также уведомить администратора о возможных проблемах в конфигурации.
Это стандартная схема получения настроек, но возможны еще несколько вариантов развития событий.
У клиента уже есть назначенный ранее адрес
Если у клиента имеется выданный ранее сетевой адрес и он хочет его использовать, то можно пропустить некоторые этапы. В этом случае клиент передает широковещательное сообщение DHCPREQUEST, указывая в сообщении имеющийся у него адрес. DHCP-cервер, получивший запрос, проверяет корректность сети и адреса и в случае успешной проверки посылает клиенту подтверждение DHCPACK. Клиент получает подтверждение и применяет настройки.
Если DHCP-сервер обнаруживает, что клиент находится в неподходящей сети, он отвечает отказом DHCPNACK. Если сеть корректна, то проверяется наличие записи для этого клиента и доступность запрошенного адреса. Если адрес по какой либо причине не подходит (например занят), то сервер отвечает отказом DHCPNACK. Получив отказ, клиент больше не может пользоваться сохраненным сетевым адресом и должен запросить новый адрес, начав полную процедуру инициализации.
Если же на сервере нет записи для этого клиента, то он считает, что адрес был выдан другим DHCP-сервером и просто оставляет запрос без ответа. Такое поведение позволяет находиться в одной сети нескольким независимым DHCP-серверам.
У клиента есть адрес, полученный другим способом
Если у клиента уже есть адрес, назначенный любым другим способом (например вручную), то он может запросить у DHCP-сервера только конкретные параметры конфигурации (например адреса DNS-серверов) с помощью сообщения DHCPINFORM. Сообщение передается на адрес сервера (если он известен) либо широковещанием на адрес 255.255.255.255. DHCP-сервер, получивший сообщение DHCPINFORM, отвечает сообщением DHCPACK с требуемыми параметрами конфигурации, но без проверки аренды и выделения сетевого адреса. Сообщение передается клиенту напрямую. Клиент принимает ответ и применяет полученные настройки.
Если клиент не получает от сервера сообщения DHCPACK в течение разумного срока ожидания, то он должен выдать пользователю сообщение о проблеме и приступить к работе в сети, используя параметры, рекомендованные в RFC 1122.
Примечание. Вообще процедура получения адреса может кардинально отличаться в зависимости от настроек DHCP-сервера. Например сервер может выдать клиенту адрес, отличающийся от запрошенного, предложить адрес из другой подсети и даже вообще отказать в предоставлении адреса. Более того, DHCP-сервер вовсе не должен отвечать на каждый поступивший к нему запрос. Это позволяет контролировать доступ к сети, например можно выдавать адреса только клиентам, прошедшим определенную проверку.
Обновление адреса
IP-адрес выдается клиенту на определенное время, которое называется временем аренды (lease time). Время аренды зависит от настроек сервера и может варьироваться от нескольких минут до недель и даже месяцев. По прошествии половины срока клиент пробует обновить аренду. Если сразу обновить аренду не удается, то клиент будет пытаться сделать это снова вплоть до окончания срока. В том случае, если все попытки окажутся неудачными, по окончании срока клиент будет искать другой DHCP-сервер.
В процессе обновления клиент проходит два состояния — обновление адреса (RENEWING) и обновление конфигурации (REBINDING). Первое состояние наступает на примерно половине срока аренды адреса (T1), второе – по истечении 87.5% (или 7/8) полного срока аренды (T2). Для предотвращения синхронизации разных клиентов при расчете значений T1 и T2 к ним добавляется случайное отклонение.
Обновление адреса (RENEWING)
Это состояние означает, что клиент может начать процесс обновления аренды. Для обновления клиент посылает запрос DHCPREQUEST, но не широковещательный, а адресованный своему DHCP-серверу. Сервер получает запрос, после чего возможно два варианта:
• Сервер соглашается продлить аренду. Для подтверждения продления аренды он посылает клиенту сообщение DHCPACK с указанием нового срока аренды и тех параметров, которые могли измениться с момента создания или последнего продления аренды;
• Сервер отказывается продлевать аренду. В этом случае он шлет клиенту сообщение об отказе DHCPNACK.
В зависимости от полученого ответа клиент:
• В случае положительного ответа DHCPACK отмечает новый срок истечения аренды и все измененные параметры, полученные от сервера, сбрасывает таймеры T1 и T2 и переходит в нормальное (BOUND) состояние.
• Получив отрицательный ответ DHCPNACK немедленно переходит в состояние инициализации (INIT) и начинает процедуру получения аренды заново.
Обновление конфигурации (REBINDING)
Если клиент сразу не получает ответ от сервера на запрос обновления аренды, то он ожидает ответ в течение времени (T2 — t)/2 сек (но не меньше 60 сек), где t — время отправки последнего сообщения DHCPREQUEST, затем отправляет сообщение повторно. Пока сервер не ответит, клиент остается в состоянии RENEWING и регулярно шлет запрос DHCPREQUEST на сервер. В течение этого времени он сохраняет свой текущий адрес и продолжает нормально работать.
Если ответ от сервера не поступил к моменту T2, клиент переходит в состояние REBINDING и передает уже широковещательное сообщение DHCPREQUEST со своим текущим адресом. В этом случае срок повтора запросов DHCPREQUEST рассчитывается аналогично предыдущему случаю, только вместо T2 используется полное время окончания срока аренды.
В том случае, если срок аренды завершается до получения клиентом ответа от сервера, клиент должен прекратить все сетевые операции и перейти в состояние инициализации (INIT). Если DHCP-сервер все-таки ответит после завершения аренды, то клиент может возобновить работу с прежним адресом.
Освобождение адреса
Клиент может явно отказаться от аренды сетевого адреса, передав серверу сообщение DHCPRELEASE. При получении этого сообщения сервер помечает адрес как свободный, но сохраняет запись с параметрами клиента в базе на тот случай, если клиент захочет использовать адрес повторно. Стоит уточнить, что клиент не освобождает аренду при обычном выключении, все настройки сохраняются локально. Клиент передает DHCPRELEASE только при явной необходимости отказаться от аренды, например при перемещении в другую подсеть. Также освободить аренду можно вручную, например с помощью команды ipconfig /release.
Еще из важного
Для своей работы DHCP использует протокол UDP. Сообщения от клиента к серверу передаются по порту 67 UDP, а сообщения от сервера клиенту — на порт UDP 68.
Также надо знать, что по умолчанию сообщения DHCP ограничены текущей подсетью. Дело в том, что для своей работы DHCP использует широковещание (broadcast), а маршрутизаторы не пропускают широковещательный трафик за пределы широковещательного домена.
Примечание. Широковещательный домен (broadcast domain) — область сети, в которой все узлы могут общаться между собой с помощью широковещания, без участия маршрутизатора. Обычно широковещательному домену соответствует физическая или логическая подсеть.
Так вот, если DHCP-сервер и клиенты находятся в разных широковещательных доменах и не могут общаться напрямую, то для их взаимодействия требуется специальный DHCP ретранслятор (DHCP relay agent). Ретранслятор является как бы посредником между клиентом и сервером, он обрабатывает стандартный широковещательный DHCP-запрос и отправляет его на сервер в виде адресного (unicast) пакета, а полученный от сервера ответ переправляет DHCP-клиенту. В роли ретранслятора могут выступать как маршрутизаторы, так и специальные серверы. К примеру в Windows Server для этого есть специальная серверная роль.
Для корректной работы DHCP необходимо проверить, что брандмауэр не блокирует нужные порты, а если DHCP-сервер и клиенты находятся в различных подсетях, то убедиться в наличии DHCP relay.
На этом пожалуй закончим теоретическую часть. В следующей статье речь пойдет о настройке DHCP-сервера на базе Windows Server 2016.
Спасибо за статью.