Настройка сети в Windows Server 2019, за минуту

9.2 Процесс получения IP-адреса по DHCP. DHCP-клиент и DHCP-сервер

Привет, посетитель сайта 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-адрес не назначать, то в этих полях будут унылые нули.

Предлагаю пока не трогать эти поля, а изменить значения у полей Pool Name и Default Gateway. Мои настройки показаны ниже.

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-запросы они делают одинаковые, сам запрос показан ниже.

9.2.11 DHCP-сервер делает ARP запрос, чтобы проверить занятость IP-адреса

Тут мы видим, что наш первый сервер спрашивает всех соседей по канальной среде: у кого 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.

9.2.14 Сообщение DHCPOFFER от первого DHCP-сервера клиент уже получил, а от второго сервера OFFER еще в буфере коммутатора

На рисунке показано ниже, что сообщение DHCPOFFER широковещательное, хотя это бывает и не всегда так, тут учитывается два момента:

1. Клиент может сообщить DHCP-серверу о том, как он хочет получать ответ: broadcast или unicast.
2. Выбор способа доставки сообщения DHCPOFFER может зависеть от реализации самого сервера и некоторых значений в DHCP пакете.

2.15 Сообщение DHCPOFFER в Cisco Packet Tracer

В любом случае, для доставки DHCPOFFER у сервера есть возможность использовать на канальном уровне как broadcast, так и unicast, ведь мак-адрес клиента он уже изучил, когда получил сообщение DHCPDISCOVER. На рисунке показано, что клиент получил DHCPOFFER от первого сервера. DHCPOFFER второго сервера находится еще в буфере коммутатора, оба сервера предлагают клиенту адрес 192.168.0.4.

9.2.16 Внутренности пакета DHCPOFFER

Рисунок выше показывает, что при первом получении IP-адреса по DHCP в своем пакете сервер указывает свой IP-адрес, а в качестве адреса клиента используется 0.0.0.0. Поскольку это сообщение сформировано сервером, то порт источника 68, а порт назначения 67. Если сейчас заглянуть во внутренности пакета DHCPOFFER, то без всяких пояснений можно увидеть несколько интересных моментов.

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

Получив DHCPOFFER клиент не забирает себе IP-адрес, сперва он должен убедиться, что этот адрес еще никто не использует, для этого он делает ARP-запрос в сеть, в данном случае ему был предложен адрес 192.168.0.4, значит и спрашивать клиент будет: кто в сети использует адрес 192.168.0.4? Клиенты не используют ICMP для проверки, им это не надо, а вот серверам надо, в дальнейшем мы поймем – в каких ситуациях это действительно необходимо.

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

1. С каким сервером клиент захотел работать.
2. На какой IP-адрес клиент согласился.

В процессе написания я столкнулся с еще одной странностью в Cisco Packet Tracer: после ARP-запроса клиент получил IP-адрес и на этом всё закончилось. Поэтому дальше только словесное описание, а потом мы его дополним дампами из Wireshark.

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

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

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

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

9.2.5 Выводы

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

Возможно, эти записи вам покажутся интересными

Описание

DHCP-сервер — это сервер протоколов для сетей TCP / IP, который предоставляет IP-адреса другим компьютерам. DHCP-сервер для Windows также поддерживает протоколы TFTP, DNS и HTTP, что делает хороший пакет для простых и простых в установке сетей, например, для удаленной загрузки и других целей. DHCP-сервер работает во всех операционных системах Windows с Win32, начиная с Windows 95 до Windows 7. DHCP-сервер назначает IP-адреса клиентским компьютерам. Это очень часто используется в корпоративных сетях для сокращения усилий по настройке. Все IP-адреса всех компьютеров хранятся в базе данных, которая находится на сервере. Подробнее »Это очень простая и простая в использовании реализация DHCP-сервера для систем на базе Windows, поддерживающая все операционные системы Windows от Windows 98 до Windows 7. Данные конфигурации, а также клиентская« база данных »хранятся в файле INI. , Смотрите описание файла INI. DHCP-сервер работает мгновенно без установки в качестве службы или приложения. Посмотрите, как работает DHCP-сервер. Сервер HCP назначает IP-адреса нескольким клиентам. Скачайте сейчас бесплатно. Новая версия V2.1, V2.0, V1.9, V1.8, V1.7, V1.6, V1.5, V1 .4 DHCP-сервер является бесплатным программным обеспечением: его можно использовать и распространять как в учебных, так и в коммерческих целях абсолютно бесплатно. Там нет лицензионных отчислений или GNU-подобных ограничений «copyleft». Нет никаких требований, таких как сообщения об авторских правах или логотипы, связанные с использованием программного обеспечения. Программное обеспечение предоставляется «как есть», без каких-либо гарантий. Вы можете пожертвовать на мой счет PayPal все, что, по вашему мнению, стоит для вас.

Видео

Интерфейс

DHCP — протокол автоматизации назначения IP-адреса клиенту. Он широко используется в современных сетях. В статье рассмотрим принципы работы, процесс DORA, основные опции и другие аспекты протокола.

Для чего нужен протокол DHCP

DHCP — протокол прикладного уровня модели TCP/IP, служит для назначения IP-адреса клиенту. Это следует из его названия — Dynamic Host Configuration Protocol. IP-адрес можно назначать вручную каждому клиенту, то есть компьютеру в локальной сети. Но в больших сетях это очень трудозатратно, к тому же, чем больше локальная сеть, тем выше возрастает вероятность ошибки при настройке. Поэтому для автоматизации назначения IP был создан протокол DHCP.

Впервые протокол был описан в 1993 году в документе RFC 1531, но с тех пор в описание вносились правки. На сегодняшний день основным документом, регламентирующим протокол, является RFC 2131. Помимо автоматизации процесса настройки IP, DHCP позволяет упростить диагностику подключения и переход из одной подсети в другую, оставляя уведомления для системного администратора в логах.

Принцип работы DHCP

Из вступления ясно, какие функции предоставляет DHCP, но по какому принципу он работает? Получение адреса проходит в четыре шага. Этот процесс называют DORA по первым буквам каждого шага: Discovery, Offer, Request, Acknowledgement.

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

Протокол DHCP, получение адреса IP — DORA

Discovery, или поиск

Изначально клиент находится в состоянии инициализации (INIT) и не имеет своего IP-адреса. Поэтому он отправляет широковещательное (broadcast) сообщение DHCPDISCOVER на все устройства в локальной сети. В той же локальной сети находится DHCP-сервер. DHCP-сервер — это, например, маршрутизатор или коммутатор, существуют также выделенные DHCP-серверы.

Не всегда одну сеть обслуживает один DHCP-сервер, нередко организации устанавливают сразу несколько. Какие порты использует DHCP? Сервер всегда слушает 67 порт, ожидает широковещательное сообщение от клиента, а после его получения отправляет ответное предложение — DHCPOFFER. Клиент принимает сообщение на 68 порту.

Offer, или предложение

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

Если имеются адреса, которые не должны быть назначены DHCP-сервером, область можно ограничить, указав только разрешенные адреса. Например, администратор может задать диапазон используемых IP-адресов от 192.0.0.10 до 192.0.0.40.

Бывает и так, что не все доступные адреса должны быть назначены клиентам. Например, администратор может исключить (exclude) диапазон 192.0.0.100 — 192.0.0.200 из используемой области. Такое ограничение называется исключением.

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

DHCPOFFER содержит IP из доступной области, который предлагается клиенту отправкой широковещательного (broadcast, «если вы тот, кто запрашивал IP-адрес, то доступен вот такой») или прямого (unicast, «вы запрашивали IP, предлагаю вот такой») сообщения. При этом, поскольку нужный клиент пока не имеет IP, для отправки прямого сообщения он идентифицируется по MAC-адресу.

Request, или запрос

Клиент получает DHCPOFFER, а затем отправляет на сервер сообщение DHCPREQUEST. Этим сообщением он принимает предлагаемый адрес и уведомляет DHCP-сервер об этом. Широковещательное сообщение почти полностью дублирует DHCPDISCOVER, но содержит в себе уникальный IP, выделенный сервером. Таким образом, клиент сообщает всем доступным DHCP-серверам «да, я беру этот адрес», а сервера помечают IP как занятый.

Acknowledgement, или подтверждение

Сервер получает от клиента DHCPREQUEST и окончательно подтверждает передачу IP-адреса клиенту сообщением DHCPACK. Это широковещательное или прямое сообщение утверждает не только владельца IP, но и срок, в течение которого клиент может использовать этот адрес.

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

Срок аренды

Когда DHCP-сервер выделяет IP из области, он оставляет запись о том, что этот адрес зарезервирован за клиентом с указанием срока действия IP. Этот срок действия называется срок аренды (lease time). Срок аренды может составлять от 24 часов до нескольких дней, недель или даже месяцев, он задается в настройках самого сервера.

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

После получения адреса из области, клиент берет его в аренду на время, называемое T. Клиент переходит в связанное (BOUND) состояние и продолжает нормальную работу, пока не наступит время половины срока аренды — T1.

По наступлении T1 клиент инициализирует процедуру получения нового IP или обновления адреса — состояние RENEWING. Процесс повторного получения происходит по упрощенной схеме: клиент прямым сообщением запрашивает (DHCPREQUEST), а сервер подтверждает (DHCPACK) запрос. Время аренды начинает отсчитываться заново.

Если подтверждение (DHCPACK) от сервера не поступает, клиент снова запрашивает адрес, но только когда истекает половина T1. Если запрос адреса остается без ответа второй раз, клиент отправляет еще одно сообщение, когда истекает половина от T1/2 (25% от полного срока аренды). Следующий запрос будет отправлен после истечения еще половины оставшегося времени, потом еще половины. И так далее, пока не наступит T2, которое равняется 87,5%, или 7/8 от всего времени аренды. После T2 все попытки продлить аренду IP будут широковещательными. Это значит, что, если первый сервер по какой-то причине недоступен, на запрос адреса сможет ответить любой другой, и работа не будет прервана.

Три подхода к распределению адресов

Сервер назначает IP одним из трех основных способов.

Статическое распределение (static allocation). Почти как ввод адреса на каждом компьютере вручную. Отличие в том, что системный администратор задает нужные соответствия IP для MAC-адресов клиентов на самом DHCP-сервере. IP останется за клиентом, даже если тот выйдет из сети, отключится, перейдет в новую сеть и т.п.

Автоматическое распределение (automatic allocation). Сервер закрепляет IP из области за каждым клиентом навсегда. Срок аренды не ограничен.

Динамическое распределение (dynamic allocation). DHCP-сервер назначает адрес из области на определенное время, называемое сроком аренды. Такой подход полезен, если число доступных IP ограничено. IP назначается каждому клиенту при подключении к сети и возвращается в область, как только клиент его освобождает. В таком случае IP может отличаться при каждом подключении, но обычно назначается прежний.

Особые DHCP сообщения

Кроме DORA — четырех сообщений для получения адреса — DHCP использует и другие. Давайте рассмотрим каждое.

DHCPNAK. Нередко в источниках можно встретить написание DHCPNACK, что является неправильным, так как RFC 2131 регламентирует именно NAK. DHCPNAK отправляется сервером вместо окончательного подтверждения. Такой отказ может быть отправлен клиенту, если аренда запрашиваемого IP истекла или клиент перешел в новую подсеть.

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

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

Опции DHCP

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

• Option 1 — маска подсети IP;
• Option 3 — основной шлюз;
• Option 6 — адрес сервера DNS (основной и резервный);
• Option 51 определяет, на какой срок IP-адрес предоставляется в аренду клиенту;
• Option 55 — список запрашиваемых опций. Клиент всегда запрашивает опции для правильной конфигурации. Отправляя сообщение с Option 55, клиент выставляет список запрашиваемых числовых кодов опций в порядке предпочтения. DHCP-сервер старается отправить ответ с опциями в том же порядке.

Option 82 — ретрансляция DHCP-сервера

Option 82 — информация об агенте ретрансляции (relay agent information). Благодаря ретранслятору клиент и сервер могут общаться, находясь в разных подсетях. По умолчанию широковещательные сообщения не могут выходить за пределы текущего широковещательного домена (подсети). Внимательный читатель скажет, что выше мы писали, как клиент отправляет широковещательное сообщение DHCPDISCOVER всем доступным DHCP-серверам. А что если в сети нет DHCP?

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

Значит ли это, что широковещательные сообщения каким-то образом выходят за пределы подсети? Не совсем. За пределы подсети выходят только широковещательные DHCP-сообщения. Это становится возможным благодаря агенту ретрансляции. Обычно в его роли выступает маршрутизатор или сервер. Ретранслятор получает сообщения от клиента в своей подсети, направляют его на DHCP-сервер, который тем же образом — через ретранслятор — отправляет ответ. Так ретранслятор выступает в качестве посредника между подсетями.

Опции DHCP для загрузки PXE

Протокол DHCP позволяет загрузку компьютера без использования носителя данных. Такая загрузка происходит с сетевой карты и называется PXE (Preboot eXecution Environment). Для конфигурации сетевой загрузки LEGACY BIOS PXE используются DHCP-опции 43, 60, 66 и 67.

• Option 43 зарезервирована для обмена информацией производителей;
• Option 60 — классовый идентификатор; здесь указывается, например, PXE клиент;
• Option 66 и 67 необходимы для указания имени сервера PXE и имени файла загрузки соответственно.

Взаимодействие DHCP и DNS

Как мы упоминали выше, Option 6 — это сервер DNS. Давайте рассмотрим подробнее взаимодействие двух протоколов.

DNS (система доменных имен) отвечает за соответствие доменных имен и IP-адресов. Доменное имя — это не только адрес в интернете, например, selectel.ru, но также имя компьютера в локальной сети, например, Director PC. DNS проводит соединительную линию между IP и буквенно-числовым доменным именем компьютера или веб-сайта. DHCP занимается выделением и назначением IP из области. Очевидно, что два протокола должны тесно взаимодействовать между собой.

В статье мы уже говорили, что DHCP-сервер имеет область IP-адресов, которые допускается распределять между клиентами в сети. DNS-сервер занимается тем, что сопоставляет IP-адреса и доменные имена. Это не только имена сайтов, но и имена компьютеров в сети, (например, NetworkServer PC).

Если вы хотите создать свою локальную сеть на базе Linux, потому что это бесплатно и вы не хотите связываться Windows, то вы можете столкнуться с проблемой взаимодействия DNS и DHCP. Linux не имеет Active Directory, как в Windows, позволяющей тесно связать DHCP и DNS, избегая необходимости обращаться к клиенту каждый раз по IP. Однако способы организовать такую связь существуют и для свободной системы.

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

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

Настроить данное взаимодействие можно в четыре шага при помощи пакета dnsmasq, доступного в стандартных репозиториях Ubuntu и Debian. Мы не будем давать детальную инструкцию по осуществлению, а лишь кратко опишем каждый шаг.

Шаг 1 — конфигурация сети

В первую очередь необходимо определиться с компьютером, который будет выполнять роль сервера. Важно выбрать тот компьютер (Ubuntu Server или Ubuntu Desktop), который вы не планируете выключать слишком часто. Если после полной настройки вы решите выключить компьютер, то вся сеть тоже выключится.

Выбранному компьютеру необходимо назначить статический IP. Делается это редактированием конфигурационного файла в директории /etc/network/interfaces.

Шаг 2 — установка dnsmasq

Установите пакет dnsmasq командой из терминала:

sudo apt-get install dnsmasq -y

А затем откройте файл конфигурации /etc/dnsmasq.conf. Файл конфигурации dnsmasq очень большой, но он содержит комментарии с объяснениями того, за что отвечает каждая настройка. Чтобы добавить требуемые настройки, откройте файл и удалите решетку (#), означающую комментарий, в начале нужных строк.

Шаг 3 — настройка фаервола

Для изменения настроек фаервола можно использовать Ubuntu Uncomplicated Firewall. Используйте следующие команды:

sudo ufw allow bootps

sudo ufw allow 53/udp

sudo ufw allow 53/tcp

Шаг 4 — изменение настроек роутера

Зайдите в настройки вашего роутера из браузера, отключите DHCP для локальной сети, измените все настройки DNS так, чтобы они указывали на ваш только что настроенный сервер. Последнее действие — перезапуск сети на сервере. Для этого вы можете просто перезагрузить компьютер или использовать команды:

sudo service dnsmasq restart

sudo service network-manager restart

Недостатки протокола DHCP

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

Еще одна брешь в безопасности — в том, что DHCP использует UDP-протокол. UDP — протокол обмена датаграммами без установления соединения, а значит, и без шифрования. Передаваемая по UDP информация не защищена и может быть «подслушана», что также может быть использовано злоумышленниками.

Третий недостаток — вновь ненадежность UDP, но другого рода. UDP не обеспечивает гарантию доставки информации. Этот протокол допускает потери и ошибки, которые могут сказаться и на работе DHCP, в частности при PXE-загрузке.

Заключение

Мы рассмотрели основные принципы работы DHCP-серверов. Несмотря на недостатки и частые доработки, протокол DHCP широко используется в современных сетях. Также изучили процесс DORA, основные опции и другие аспекты протокола. Надеемся, эта статья оказалась вам полезна.

Используемые источники:

• https://zametkinapolyah.ru/kompyuternye-seti/9-2-process-polucheniya-ip-adresa-po-dhcp-dhcp-klient-i-dhcp-server.html
• https://8d9.ru/program/free-dhcp-server
• https://selectel.ru/blog/dhcp-protocol/