Как работает dhcp в windows

Время на прочтение
10 мин

Количество просмотров 96K

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

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

Немного теории и решения интересных и не очень практических задач — под катом.

В современной локальной сети выдачей адресов обычно занимаются специализированные сервисы с поддержкой протоколов. Самым популярным из них является DHCP (Dynamic Host Configuration Protocol).

Zeroconf или зачем нам вообще какой-то DHCP

В принципе, специально для функционирования небольших сетей был создан стек технологий под названием Zeroconf. Он позволяет обойтись без каких-либо централизованных сервисов и серверов, включая, но не ограничиваясь выдачей IP-адресов. Им закрываются (ну, или почти закрываются) следующие вопросы:

Получение IP-адреса (Automatic Private IP Addressing или APIPA). Система сама назначает себе IP из сети 169.254.0.0/16 (кроме сеток /24 в начале и конце диапазона), основываясь на MAC-адресе и генераторе псевдослучайных чисел. Такая система позволяет избежать конфликтов, а адрес из этой сети называют link-local — в том числе и потому, что эти адреса не маршрутизируются.

Поиск по имени. Система анонсирует свое сетевое имя, и каждый компьютер работает с ним как с DNS, храня записи у себя в кэше. Apple использует технологию mDNS (Multicast DNS), а Microsoft — LLMNR (Link-local Multicast Name Resolution), упомянутую в статье «Домены, адреса и Windows: смешивать, но не взбалтывать».

Поиск сетевых сервисов. Например, принтеров. Пожалуй, самым известным протоколом является UPnP, который помимо прочего умеет сам открывать порты на роутерах. Протокол довольно сложен, в нем используется целый набор надстроек вроде использования http, в отличие от второго известного протокола — DNS-SD (DNS Service Discovery), который попросту использует SRV-записи, в том числе при работе mDNS.

При всех плюсах Zeroconf — без каких-либо сакральных знаний можно собрать рабочую сеть, просто соединив компьютеры на физическом уровне, — IT-специалистам он может даже мешать.

Немного раздражает, не так ли?

В системах Windows для отключения автонастройки на всех сетевых адаптерах необходимо создать параметр DWORD с именем IPAutoconfigurationEnabled в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters и поставить ему значение 0.

Разумеется, Zeroconf подходит разве что для небольших изолированных сетей (например, встретились с приятелем с ноутбуками, соединили их по Wi-Fi и давай играть Diablo II, не тратя время на какие-то сервера), да и выводить локальную сеть в интернет тоже хочется. Чтоб не мучаться со статическими настройками каждого компьютера, были созданы специальные протоколы, включая героя дня — DHCP.

DHCP и его прародители

Одна из первых реализаций протокола для выдачи IP-адресов появилась более 30 лет назад и называлась RARP (Reverse Address Resolution Protocol). Если немного упростить принцип его работы, то выглядело это так: клиент делал запрос на широковещательный адрес сети, сервер его принимал, находил в своей базе данных привязку MAC-адреса клиента и IP — и отправлял в ответ IP.

Схема работы RARP протокола.

И все вроде работало. Но у протокола были минусы: нужно было настраивать сервер в каждом сегменте локальной сети, регистрировать MAC-адреса на этом сервере, а передавать дополнительную информацию клиенту вообще не было возможности. Поэтому на смену ему был создан протокол BOOTP (Bootstrap Protocol).

Изначально он использовался для бездисковых рабочих станций, которым нужно было не только выдать IP-адрес, но и передать клиенту дополнительную информацию, такую, как адрес сервера TFTP и имя файла загрузки. В отличие от RARP, протокол уже поддерживал relay — небольшие сервисы, которые пересылали запросы «главному» серверу. Это сделало возможным использование одного сервера на несколько сетей одновременно. Вот только оставалась необходимость ручной настройки таблиц и ограничение по размеру для дополнительной информации. Как результат, на сцену вышел современный протокол DHCP, который является совместимым расширением BOOTP (DHCP-сервер поддерживает устаревших клиентов, но не наоборот).

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

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

Схема общения клиента с сервером пересылки и сервером.

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

На нескольких собеседованиях меня спрашивали: «А какой транспорт и порт использует DHCP?» На всякий случай отвечаем: «Сервер UDP:67, клиент UDP:68».

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

• На практически любом маршрутизаторе, особенно SOHO.
• На системах Windows Server. О сервере и его настройке можно почитать в официальной документации.
• На системах *nix. Пожалуй, самое популярное ПО — ISC DHCP Server (dhcpd) и «комбайн» Dnsmasq.

Конкретных реализаций довольно много, но, например, на SOHO-маршрутизаторах настройки сервера ограничены. В первую очередь это касается дополнительных настроек, помимо классического «IP-адрес, маска, шлюз, сервер DNS». А как раз эти дополнительные опции и вызывают наибольший интерес в работе протокола. С полным списком можно ознакомиться в соответствующем RFC, я же разберу несколько интересных примеров.

Удивительные опции DHCP

В этом разделе я рассмотрю практическое применение опций DHCP на оборудовании MikroTik. Сразу обращу внимание на то, что не все опции задаются очевидно, формат параметров описан в wiki. Следует отметить также то, что опции клиент применяет, только когда сам их попросит. В некоторых серверах можно принудительно отправить настройки: например, в ISC DHCP Server за это отвечает директива dhcp-parameter-request-list, а в Dnsmasq —* *—dhcp-option-force. MikroTik и Windows такого не умеют.

Option 6 и Option 15. Начнем с простого. Настройка под номером 6 — это серверы DNS, назначаемые клиентам, 15 — суффикс DNS. Назначение суффикса DNS может быть полезным при работе с доменными ресурсами в недоменной сети, как я описывал в статье «Как мы сокращали персонал через Wi-Fi». Настройка MikroTik под спойлером.

#Добавляем опцию 15. содержимое — сконвертированный в HEX суффикс.

/ip dhcp-server option

add code=15 name=dns-suffix value=0x57687920616c6c207468697320736869743f

#создаем набор опций

/ip dhcp-server option sets

add name=dns option=dns-suffix

#Добавляем опцию к DHCP-серверу для клиентов.

/ip dhcp-server network

set [find comment="wi-fi client dhcp"] dhcp-option-set=dns

Знание, что сервер DNS — это тоже опция, недавно пригодилось мне, когда разным клиентам нужно было выдать разные серверы DNS. Решение вида «выдать один сервер и сделать разные правила dst-nat на 53 порт» не подходило по ряду причин. Часть конфигурации снова под спойлером.

#настройка опций, обратите внимание, что ip экранирован одинарными кавычками

/ip dhcp-server option

add code=6 name=google value="'8.8.8.8'"

add code=6 name=cloudflare value="'1.1.1.1'"

#настройка клиентов

/ip dhcp-server lease

add address=10.0.0.2 dhcp-option=google mac-address=11:11:11:11:11:11 server=dhcp

add address=10.0.0.3 dhcp-option=cloudflare mac-address=22:22:22:22:22:22 server=dhcp

Option 66 и Option 67. Эти настройки пришли еще с BOOTP и позволяют указать TFTP-сервер и образ для сетевой загрузки. Для небольшого филиала довольно удобно установить туда микротик и бездисковые рабочие станции и закинуть на маршрутизатор подготовленный образ какого-нибудь ThinStation. Пример настройки DHCP:

/ip dhcp-server option

add name="option66" code=66 value="s'192.168.88.1'"

add name="option67" code=67 value="'pxelinux.0'"

/ip dhcp-server option sets

add name="set-pxe" options=option66,option67

Option 121 и Option 249. Используются для передачи клиенту дополнительных маршрутов, что может быть в ряде случаев удобнее, чем прописывать маршруты на шлюзе по умолчанию. Настройки практически идентичные, разве что клиенты Windows предпочитают вторую. Для настройки параметра маршруты надо перевести в шестнадцатеричный вид, собрав в одну строку маску сети назначения, адрес сети и шлюз. Также, по RFC, необходимо добавить и маршрут по умолчанию. Вариант настройки — под спойлером.

/ip dhcp-server option

add code=121 name=classless value=0x0A0000c0a8580200c0a85801

Подробнее можно прочитать в статье «Mikrotik, DHCP Classless Route».

Option 252. Автоматическая настройка прокси-сервера. Если по каким-то причинам в организации используется непрозрачный прокси, то удобно будет настроить его у клиентов через специальный файл wpad (pac). Пример настройки такого файла разобран в материале «Proxy Auto Configuration (PAC)». К сожалению, в MiroTik нет встроенного веб-сервера для размещения этого файла. Можно использовать для этого пакет hotspot или возможности metarouter, но лучше разместить файл где-либо еще.

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

После настройки DHCP-Relay на маршрутизаторе в информации о клиентах появятся поля Agent Circuit ID и Agent Remote ID, где первое — идентификатор порта коммутатора, а второе — идентификатор самого коммутатора.

Выдача адресов с option 82.

Информация выдается в шестнадцатиричном формате. Для удобства восприятия при анализе журнала DHCP можно использовать скрипты. Например, решение для решения от Microsoft опубликовано в галерее скриптов Technet под названием «Декорирование DHCP опции 82».

Также опция Option 82 активно используется в системе биллинга провайдеров и при защите сети от посторонних вмешательств. Об этом чуть подробнее.

Добавим сети надежности и безопасности

Ввиду простоты протокола и присутствия широковещательных запросов есть эффективные атаки на инфраструктуру — в основном типа MITM («человек посередине»). Атаки производятся посредством поднятия своего DHCP-сервера или релея: ведь если контролировать выдачу сетевых настроек, можно запросто перенаправить трафик на скомпрометированный шлюз. Для облегчения атаки используется DHCP starvation (представляясь клиентом или релеем, злоумышленник заставляет «родной» DHCP-сервер исчерпать свои IP-адреса). Подробнее про реализацию атаки можно почитать в статье «Атакуем DHCP», методом же защиты является DHCP Snooping.

Это функция коммутатора, которая позволяет «привязать» DHCP-сервер к определенному порту. Ответы DHCP на других портах будут заблокированы. В некоторых коммутаторах можно настроить и работу с Option 82 при ее обнаружении в пакете (что говорит о присутствии релея): отбросить, заменить, оставить без изменения.

В коммутаторах MikroTik включение DHCP Snooping производится в настройках бриджа:

#Включаем dhcp-snooping и option 82

/interface bridge

add name=bridge

set [find where name="bridge"] dhcp-snooping=yes add-dhcp-option82=yes

#ставим настраиваем доверенный порт

/interface bridge port

add bridge=bridge interface=ether1

add bridge=bridge interface=ether2 trusted=yes

Настройка в других коммутаторах происходит аналогичным образом.

Стоит отметить, что не все модели MikroTik имеют полную аппаратную поддержку DHCP Snooping — она есть только у CRS3xx.

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

Красивая коммутационная — залог здоровья.

К другим методам защиты можно отнести Port Security («привязка» определенного MAC-адреса к порту маршрутизатора, при обнаружении трафика с других адресов порт будет блокироваться), Анализ трафика на количество DHCP-запросов и ответов или ограничение их количества, ну и, конечно, различные системы IPS\IDS.

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

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

Разберем более практичные варианты.

В системах Windows Server начиная с 2012 система резервирования DHCP работает «из коробки», в режиме балансировки нагрузки (active-active) или в режиме отказоустойчивости (active-passive). С подробным описанием технологии и настройками можно ознакомиться в официальной документации. Отмечу, что отказоустойчивость настраивается на уровне зоны, поэтому разные зоны могут работать в разном режиме.

Настройка отказоустойчивости DHCP-сервера в Windows.

В ISC DHCP Server для настройки отказоустойчивости используется директива failover peer, синхронизацию данных предлагается делать самостоятельно — например, при помощи rsync. Подробнее можно почитать в материале «Два DHCP сервера на Centos7…»

Если же делать отказоустойчивое решение на базе MikroTik, то без хитростей не обойтись. Один из вариантов решения задачи был озвучен на MUM RU 18, а затем и опубликован в блоге автора. Если вкратце: настраиваются два сервера, но с разным параметром Delay Threshold (задержка ответа). Тогда выдавать адрес будет сервер с меньшей задержкой, а с большей задержкой — только при выходе из строя первого. Синхронизацию информации опять же приходится делать скриптами.

Лично я в свое время изрядно потрепал себе нервов, когда в сети «случайно» появился роутер, подключенный в локальную сеть и WAN, и LAN интерфейсами.

Расскажите, а вам приходилось сталкиваться с проказами DHCP?

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.

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

Какой IP-адрес может быть у устройства

IP-адрес устройства может быть статическим или динамическим.

Статический адрес присваивается на постоянной основе, а динамический выдается на время (например, на одну сессию). Для автоматической выдачи динамических адресов используется прокол DHCP.

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

В первом случае пользователь с правами администратора сети делает настройку сетевого адаптера вручную — задает ему статический адрес. Во втором — динамический IP присваивается автоматически через протокол DHCP.

Что такое Dynamic Host Configuration Protocol (DHCP)

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

• D – Discovery (обнаружение);
• O – Offer (предложение);
• R – Request (запрос);
• A – Acknowledge (подтверждение).

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

1. Discovery (обнаружение). На первом этапе сервер проверяет, в сети ли устройство. Технически этот процесс выглядит, как отправка отдельного запроса на универсальный адрес 255.255.255.255. Поскольку на этапе обнаружения у нового пользователя отсутствует свой IP, с его стороны отправляется MAC-адрес (уникальный идентификатор устройства) и IP 0.0.0.0.

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

3. Request (запрос). На третьем этапе подключения по DHCP отправляется запрос на подключение с устройства клиента. После того как клиент получил предложение со стороны сетевого адаптера, он отправляет запрос на присоединение к сети. Запрос включает в себя MAC-адрес клиента и IP, который отправил сервер на предыдущем этапе.

4. Acknowledge (подтверждение). На четвертом этапе сервер подтверждает подключение устройства. Он отправляет по MAC-адресу клиента сообщения с данными параметров, с помощью которых устройство будет авторизовано в сети. После успешной автоматической проверки соответствия всех настроек, соединение становится активным. С этого момента устройство может обмениваться данными с сервером.

Особенности протокола

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

Как работает протокол DHCP при обновлении арендных IP-адресов

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

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

• изменение адреса,
• изменение настроек подключения.

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

Если по запросу на обновление адреса от сервера не приходит ответная информация, то система продолжает отправлять запросы. Если пройдет 87,5% времени аренды IP-адреса, но он так и не обновится, система заново выполнит алгоритм подключения по принципу DORA с самого первого этапа. Это поможет избежать ситуации, когда под одним адресом одновременно синхронизируются два клиента.

Как включить DHCP на Windows 10

По умолчанию протокол DHCP уже включен на Windows. Однако, если по какой-то причине он отключился, вы можете настроить его заново по инструкции. Ниже мы расскажем, как это сделать на Windows 10.

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.254.

Бывает и так, что не все доступные адреса должны быть назначены клиентам. Например, администратор может исключить (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 из своей области. Если злоумышленник сможет использовать свой сервер, который даст самый быстрый ответ клиенту, то у него откроется возможность получить контроль над действиями пользователя в сети и нанести существенный ущерб.

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

Заключение

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

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

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

Если вы попытаетесь выполнить эту задачу вручную, вы потратите немало времени, проведя за каждым ПК по 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

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-адреса.