DHCP relay

Блог Traffic Inspector Next Generation Team03.08.20205385

Протокол DHCP (Dynamic Host Configuration Protocol) относится к числу основных служб, формирующих инфраструктуру сетей. Он применяется для автоматического выполнения конфигурации сетевых параметров. Любой специалист, занимающийся построением и обслуживанием компьютерных сетей, а также работой в них, должен иметь по крайней мере общее представление об этом протоколе и понимать, на каком уровне работает DHCP.

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

Разберем общий принцип работы протокола DHCP по ключевым моментам.

Получение настроек

Работа протокола DHCP осуществляется по принципу клиент-сервер. Для получения настроек используется схема DORA (Discover-Offer-Request-Acknowledge). Сам процесс состоит из следующих этапов:

• Обнаружение (Discover). После подключения клиента начинается процесс его инициализации в сети. Он находит подходящий DHCP-сервер путем отправки специального запроса DHCPDISCOVER на адрес 255.255.255.255. Учитывая отсутствие собственного IP, в таком запросе указывается 0.0.0.0 и MAC. Запрос поступает на все ПК в соответствующем сегменте сети. При этом ответ на него автоматически отправляется только DHCP-серверами.
• Предложение (Offer). Получив от клиента запрос, DHCP-сервер осуществляет его обработку и выполняет подбор сетевую конфигурацию. Эта конфигурация направляется клиенту в обратном сообщении DHCPOFFER, которое, как правило, передается на указанный MAC. Однако в некоторых случаях применяется широковещание. При нахождении нескольких серверов в пределах сети клиенту приходит соответствующее количество DHCPOFFER, из которых он выбирает один (обычно первый по времени получения).
• Запрос (Request). После получения DHCPOFFER клиент передает серверу специальное сообщение DHCPREQUEST, которое содержит запрос настроек. В этом запросе дублируется информация из DHCPDISCOVER, а также указывает IP-адрес избранного на предыдущем этапе DHCP-сервера.
• Подтверждение (Acknowledge). После получения DHCPREQUEST избранный DHCP-сервер выполняет фиксацию соответствующей привязки для клиента и направляет ему в ответ сообщение DHCPACK. В нем подтверждаются предоставленные автоматически настройки. Это сообщение передается на адрес MAC клиента, который был указан на предыдущем этапе. Получив DHCPACK, клиент проводит автоматическую проверку предоставленных настроек и применяет конфигурацию сети, полученную от сервера.

Полученный адрес может быть проверен клиентом путем отправки широковещательного запроса ARP. При обнаружении использования предоставленного IP другим устройством, серверу передается сообщение DHCPDECLINE. После этого начинается повторная инициализация.

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

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

В процессе обновления аренды клиент проходит два состояния:

• RENEWING — обновление адреса.
• REBINDING — обновление конфигурации.

Наступление состояния RENEWING предусмотрено на половине времени аренды (T1), а состояние REBINDING — после прохождения 87,5 этого периода (T2). Чтобы исключить синхронизацию различных клиентов, используется случайная величина отклонения при определении T1 и T2.

Рассмотрим, как работает протокол DHCP при обоих состояниях.

Работа при RENEWING

В этом состоянии клиентом запускается процесс обновления аренды. Для этого он направляет запрос DHCPREQUEST на собственный DHCP-сервер. При согласии сервера на продление клиенту возвращается ответ DHCPACK, в котором прописано новое время аренды и обновленные параметры. Клиент отмечает полученные значения, сбрасывает отсчет времени T1 и T2, после чего переходит в нормальное рабочее состояние.

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

Работа при REBINDING

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

Если до наступления T2 не поступает серверный ответ, сетевой протокол DHCP предусматривает перевод клиента в состояние REBINDING, после чего при помощи широковещания направляется запрос DHCPREQUEST с указанием текущего адреса. Такие запросы посылаются через определенное время.

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

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

Для отказа от аренды IP клиент передает серверу специальный запрос DHCPRELEASE. В ответ сервер помечает соответствующий IP-адрес свободным. При этом резервируется запись с клиентскими сетевыми параметрами. Это необходимо для того, чтобы возобновить действие адреса при поступлении такого запроса. При простом выключении клиент не прекращает аренду, а сохраняет локально все установленные настройки. Запрос DHCPRELEASE направляется клиентом только при возникновении потребности в отказе от аренды. Например, такая необходимость может возникнуть при переходе в новую подсеть. Кроме того, существует возможность отказа от аренды вручную. Для этого можно использовать команду ipconfig/release.

Особенности работы DHCP

Сетевой протокол DHCP работает посредством UDP. Обмен данными между клиентом и сервером осуществляется через порты 67 UDP и UDP 68. Для передачи информации от клиента к серверу DHCP протокол задействует порт 67 UDP, а в обратном направлении — 68 UDP.

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

При расположении в разных широковещательных доменах общение клиентов и серверов производится через специальный ретранслятор DHCP relay agent. Он выполняет функцию посредника, который обеспечивает обмен сообщениями между клиентом и сервером в формате адресных пакетов. Таким ретранслятором может служить маршрутизатор или специальный сервер, например, Windows Server.

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

Предоставлено SendPulseНазадДалее

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

Перед началом я хотел бы вам напомнить, что ознакомиться с опубликованными материалами первой части курса можно по ссылке: «Основы взаимодействия в компьютерных сетях».

9.3.1 Введение

Здесь мы рассмотрим структуру DHCP пакета и поговорим о их назначении DHCP-сообщений. В частности будут рассмотрены такие виды DHCP сообщений как: DHCPDISCOVER, DHCPOFFER, DHCPREQUEST и DHCPACK. Дам небольшое пояснение по поводу того, что я буду подразумевать под словом DHCP-пакет, а что под DHCP-сообщением. Под первым я буду понимать физическую сущность со строгой структурой, а под вторым я буду понимать логический смысл, который несет в себе физическая сущность, пакет всего один, а сообщений много и они разные.

9.3.2 Общая структура DHCP пакета, назначение его полей и их размер

Мы довольно наглядно рассмотрели процесс получения IP-адреса по DHCP в Cisco Packet Tracer, но хотелось бы понимать то, как устроены пакеты DHCP, которыми обменивается клиент и сервер. Тут у меня для вас две новости:

1. Начну с хорошей. При обмене различными сообщениями и клиент, и сервер используют пакеты с одинаковой структурой, а это означает, что поля в различных DHCP-сообщениях имеют одинаковые названия и одинаковый размер, за исключением поля Options, о котором мы говорили, в записи про DHCP протокол, но в них указываются разные значения.
2. Вторая новость не то что бы плохая, но всё же. Различного рода сообщений в DHCP много и не со всеми вы будете сталкиваться и не все вам будут нужны, но если столкнетесь, то придется почитать RFC, чтобы понять, как это должно работать, а потом заглянуть в дамп, чтобы увидеть, как это работает по факту.

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

9.3.1 Структура DHCP-пакета, поля и их размер

Сама по себе картинка нам еще ничего не дает, кроме названия полей в DHCP-пакета, также мы видим, что пакет разбивается на строки (иначе, машинные слова), каждая строка 32-а бита. Крайний левый бит в слове имеет нулевой порядковый номер, а крайний правый бит 31-ый. Размер всех полей в битах кратен числу 8.

Давайте теперь поговорим более подробно о каждом поле DHCP пакета. Для их описания я подготовил таблицу.

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

9.3.3 Сообщение DHCPDISCOVER или как клиент ищет DHCP сервер?

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

9.3.2 Как инкапсулируется и передается по сети сообщение DHCPDISCOVER

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

В заголовке IP-пакета в качестве адреса источника клиент использовал 0.0.0.0, а IP-адрес назначения опять широковещательный – 255.255.255.255. DHCP упаковывается на транспортном уровне в UDP, поскольку сообщение DHSPDISCOVER генерирует клиент, он в качестве порта источника использует значение 68, а в качестве порта назначения 67. Ну и наконец мы видим, что Wireshark смог определить, что это сообщение DHCPDISCOVER. Попробуем определить и мы.

9.3.3 Формат сообщения DHCPDISCOVER

Для этого заглянем внутрь DHCP-пакета и проанализируем значения его полей. В самом верху мы видим тип сообщения Boot Request (это поле opcode), значение 1 говорит нам о том, что это клиент что-то посылает серверу. Следующих два поля сообщают нам, что на канальном уровне используется Ethernet и указана длина аппаратного адреса. Поле Hops имеет значение 0, а значит клиент считает, что он находится с сервером в одной канальной среде. Когда клиент начал общение с сервером, он сгенерировал уникальный Transaction ID, по которому можно будет отличить этот процесс получения IP-адреса от какого-нибудь другого. Поле Second Elapsed никому не интересно, тут обычно стоит 0.

Флаги – отдельная тема, сейчас мы их пропустим. У клиента еще нет и не было IP-адреса, клиент не знает IP-адрес сервера, клиент ничего не знает по DHCP Relay Agent, клиент сам себе не может выдать IP-адрес, поэтом следующих четыре поля имеют значения 0.0.0.0. В поле Client MAC Address клиент сообщает свой мак-адрес серверу. А вот поле Client Hardware Address Padding различается для машин с Windows и Linux, сейчас вы видите значение для Windows, это поле мы обсудим позже.

Далее клиент сообщает серверу о том, что ему не нужно сообщать hostname сервера и не надо давать ссылку на Boot-файл. Ну а поле Magic Cookie сообщает о том, что начались DHCP опции и нам нужно обратить внимание на следующий рисунок.

9.3.4 DHCP опции, которые передает клиент серверу в сообщение DHCPDISCOVER

Во-первых, стоит сразу отметить, что количество опции, да и сами опции, которые будут в сообщение DHCPDISCOVER зависят от настроек клиента. Первая опция имеет код 53, так клиент сообщает всем в сети, что данное сообщение является сообщением DHCPDISCOVER. Опция с кодом 61 используется клиентом, чтобы сообщить свой мак-адрес. В опции с кодом 50 клиент сообщает, что хотел бы получить от сервера IP-адрес 192.168.0.100. Опция с кодом 12 используется клиентом, чтобы сообщить свой hostname.

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

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

9.3.4 Сообщение DHCPOFFER или как сервер предлагает клиенту IP-адрес?

Перейдем к сообщение DHCPOFFER, которым сервер отвечает на запрос DHCPDISCOVER от клиента, тут самый первый вопрос, который у вас должен возникнуть: а как сервер отправляет сообщение DHCPOFFER – broadcast или unicast. Правильным будет ответ: сервер может передавать сообщение DHCPOFFER как широковещательно, так и адресно, вот что написано в RFC протокола DHCP.

Если поле giaddr в сообщении DHCP от клиента отлично от 0, сервер передает все отклики на сообщения в порт DHCP server транслятору BOOTP, адрес которого указан в поле giaddr. Если giaddr = 0, а поле ciaddr отлично от нуля, сервер передает сообщения DHCPOFFER и DHCPACK по индивидуальному адресу ciaddr. Если giaddr = 0, ciaddr = 0 и установлен флаг broadcast, сервер передает сообщения DHCPOFFER и DHCPACK по широковещательному адресу 0xffffffff. Если флаг broadcast не установлен, а giaddr и ciaddr имеют значение 0, сервер передает сообщения DHCPOFFER и DHCPACK по индивидуальному аппаратному адресу клиента и yiaddr. Во всех случаях, когда giaddr = 0, сервер отправляет сообщения DHCPNAK по широковещательному адресу 0xffffffff.

9.3.5 DHCPOFFER — сообщение, которое отправляет сервер в ответ на DHCPDISCOVER

Если посмотреть на дамп протокола IP, то можно будет увидеть, что сервер не просто направил клиенту DHCPOFFER юникастом, но и более того, в поле IP-адрес назначения был подставлен IP-адрес, который был запрошен клиентом в сообщение DHCPDISCOVER. Главным образом такое поведение DHCP-сервера связано с тем, какие флаги были получены им от клиента. Обратите внимание, что в сообщение DHCPOFFER сервер еще не использует предлагаемый IP-адрес в поле Client IP Address, там еще находятся унылые нули. В поле Your IP Address сервер предлагает клиенту тот IP-адрес, который он у него запросил, естественно, перед тем как его предложить, сервер убедился в том, что этот адрес свободен. Как видим, сообщение DHCPOFFER по своему содержимому не сильно отличается от DHCPDISCOVER, теперь давайте посмотрим на опции, которые сервер предложил клиенту.

9.3.6 DHCP опции в сообщение DHCPOFFER

Во-первых, опции в сообщение DHCPOFFER, как и в любых других сообщениях, начинаются с Magic Cookie, а заканчиваются 255 опцией. Во-вторых, сервер не знал всех опций, которые у него попросил клиент, поэтому выдал то, что смог. После Magic Cookie сервер сообщает, что этот пакет несете в себе сообщение DHCPOFFER. Следующим шагом он сообщает клиенту свой идентификатор. А вот опция с кодом 51 несет в себе очень важную информацию о времени аренды IP-адреса, об этом времени у нас будет отдельный разговор.

Еще из полезного сервер предложил в качестве опций клиенту IP-адрес шлюза по умолчанию, маску подсети и адрес DNS-сервера.

9.3.5 Сообщение DHCPREQUEST или как клиент делает запрос на получение IP-адреса?

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

ПРИМЕЧАНИЕ: здесь мы пропускаем все проверки на занятость/свободность IP-адреса, это мы обсудили при прошлом разговоре и сейчас считаем, что они есть и в результате этих проверок IP-адрес свободен.

Давайте посмотрим, как выглядит сообщение DHCPREQUEST в дампе Wireshark.

9.3.7 Сообщение DHCPREQUEST или как клиент делает запрос на получение IP-адреса

Сразу бросается в глаза то, что DHCPREQUEST отправляется не адресно, а широковещательно, тут дело в том, что клиент должен сообщить всем серверам о том, какой адрес он хочет получить и с каким сервером он хочет продолжать взаимодействие. Все поля сверху, за исключением поля Message Type, имеют точно такие же значения, как и в сообщение DHCPDISCOVER, а вот поля опций изменились, давайте на них и посмотрим.

Показываю в виде дампа, так как не удалось вывести все опции в одном скрине. Опция 53 сообщает нам о том, что это сообщение у нас DHCPREQUEST. Далее идут знакомые нам уже опции, а вот на опции с кодом 54 мы остановимся (DHCP Server Identifier), этой опцией клиент сообщает все серверам о том, с кем из них он намерен продолжать сотрудничать. Опцией 81 клиент сообщает серверу свое имя, а вдруг пригодится. А в опции 55 клиент пытается упрекнуть сервера, мол, смотри, сколько я у тебя опций запрашивал и что ты мне выдал, ты точно не сможешь дать мне все то, о чем я тебя прошу?

3.6 Сообщение DHCPACK или как сервер назначает IP-адрес клиенту?

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

9.3.8 Сообщение DHCPACK или как сервер подтверждает выдачу IP-адреса клиенту

Обычно сообщение DHCPACK сервер старается выслать клиенту адресно, не прибегая к широковещанию, хотя иногда бывают и исключения. Главным требованием к содержимому сообщения DHCPACK должна быть непротиворечивость тому, что было отправлено в сообщение DHCPOFFER. Пожалуй, это всё, что следовало сказать про DHCPACK.

3.7 Выводы

Итак, на этот раз мы подробно разобрали структуру DHCP-пакета и разобрались с содержимым самых часто используемых сообщений в протоколе DHCP и с тем, как они отправляются, еще раз напомню: сообщение DHCPDISCOVER отправляется как broadcast клиентом, этим сообщением он ищет сервер; когда сервер получает DHCPDISCOVER, он формирует сообщение DHCPOFFER, которое может быть отправлено как unicast, так и broadcast (в большей степени это зависит от того, как будет удобно клиенту), в этом сообщение сервер предлагает клиенту IP-адрес; в ответ на DHCPOFFER клиент формирует DHCPREQUEST – сообщение, которым клиент дает согласие на получение предложенного IP-адреса, сообщение исключительно широковещательное; в завершении сервер резервирует IP-адрес и отправляет сообщение DHCPACK, это сообщение служит квитанцией о выдаче адреса.

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

В этой статье мы выполним настройку DHCP сервера на Mikrotik. Узнаем, как сделать привязку IP клиента к MAC-адресу и повысить безопасность сети используя связку DHCP + ARP с подробным описанием.

Освоить MikroTik вы можете с помощью онлайн-курса «Настройка оборудования MikroTik». В курсе изучаются все темы из официальной программы MTCNA. Автор – официальный тренер MikroTik. Материал подходит и тем, кто уже давно работает с оборудованием MikroTik, и тем, кто еще не держал его в руках. В состав входят 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.

Содержание

Надеюсь, данная статья была вам полезна. Если возникли вопросы пишите в комментарии.

Освоить MikroTik вы можете с помощью онлайн-курса «Настройка оборудования MikroTik». В курсе изучаются все темы из официальной программы MTCNA. Автор – официальный тренер MikroTik. Материал подходит и тем, кто уже давно работает с оборудованием MikroTik, и тем, кто еще не держал его в руках. В состав входят 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.

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

• https://www.smart-soft.ru/blog/printsipy_raboty_protokola_dhcp/
• https://zametkinapolyah.ru/kompyuternye-seti/9-3-struktura-format-i-naznachenie-dhcp-paketov-soobshhenij-dhcpdiscover-dhcpoffer-dhcprequest-i-dhcpack.html
• https://smartadm.ru/mikrotik-nastrojka-dhcp-server/