Основная информация по протоколу динамической конфигурации хостов DHCP
DHCP расшифровывается, как Dynamic Host Configuration Protocol — протокол динамической конфигурации хостов. Компьютеру, для того, чтобы он мог работать в сети нужно получить IP-адрес.
Есть два варианта назначения IP-адресов. Во-первых, IP-адреса можно назначать вручную, это удобно делать, когда в сети мало компьютеров, например, дома или в небольшой организации. Но если в вашей сети сотни или тысячи компьютеров назначить на каждый IP-адрес вручную практически невозможно. Для этого необходимы методы автоматического назначения IP-адресов. Как раз протокол DHCP предоставляет такую возможность. Это позволяет существенно снизить трудозатраты по настройке сетевых параметров в компьютерах в больших сетях.
С другой стороны, чтобы использовать протокол DHCP необходимо создать соответствующую инфраструктуру, создать в сети DHCP сервер и поддерживать его. Другой недостаток DHCP в том, что одному и тому же компьютеру в разное время DHCP сервер может назначать разные IP-адреса.
Работа протокола DHCP
DHCP работает по модели клиент-сервер. Клиент это компьютер, который получает IP-адрес автоматически. А сервер DHCP это компьютер, который раздает ip-адреса и следит за тем, чтобы один и тот же ip-адрес не был выдан двум клиентам, в противном случае они не смогут работать с сетью. Для того, чтобы получить ip-адрес, клиент и сервер обмениваются между собой сообщениями DHCP в режиме запрос-ответ.
Получение IP-адреса
Рассмотрим, как происходит получение IP-адреса по протоколу DHCP. Когда клиент включается, у него нет никакой информации о той сети в которой он находится. Его первая задача узнать, где находится DHCP сервер. Для этого он посылает сообщение DHCP DISCOVER.
Сервер, после того, как получил сообщение DHCP DISCOVER в ответ посылает сообщение DHCP OFFER. В сообщение DHCP сервер включает ip-адрес, который предлагает использовать клиенту.
Клиент в ответ посылает сообщение DHCP REQUEST с тем же самым ip-адресом.
На следующем шаге сервер посылает подтверждающее сообщение DHCP ACK, куда еще раз включается ip-адрес. После этого клиент может использовать ip-адрес для работы в сети. Проще всего запомнить процесс получения ip-адреса по протоколу DHCP по первым буквам DHCP сообщений DORA (Discover, Offer, Request, Ack).
Кроме тех сообщений, которые мы рассмотрели, есть и другие сообщения.
Зачем нужно четыре шага?
Зачем нужно 4 шага? Ведь на первый взгляд достаточно трёх шагов. Ответ на этот вопрос Вы узнаете из видео на 3:40 минуте.
Назначение адресов в DHCP
DHCP сервер может использовать 2 способа назначения адресов компьютерам.
Время аренды в DHCP
DHCP сервер выделяет IP-адрес компьютера на некоторое ограниченное время, которое называется временем аренды (lease time). Время аренды может быть разное от нескольких минут, до нескольких часов и даже суток в зависимость от потребности конкретной сети и конкретной организации.
Обновление аренды IP-адреса
После того, как время арены закончилось, ip-адрес освобождается и DHCP сервер может отдать его другому клиенту. Но что делать, если текущий клиент хочет использовать этот IP-адрес дальше? Для этого клиенту необходимо продлить аренду, обычно клиенты начинают это делать после того, как пройдет половина времени аренды, для продления аренды используется специальная сокращенная процедура получения IP-адреса. Так как клиент уже знает свой IP-адрес он сразу пересылает серверу сообщение DHCP request в котором указывает этот ip-адрес и если все нормально, то сервер в ответ высылает сообщение DHCP ACK, которое подтверждает, что клиент может использовать этот ip-адрес дальше.
Прекращение использования адреса
После того, как компьютер перестал работать с сетью, например при выключении, ему необходимо сказать об этом DHCP серверу, для этого используется сообщение DHCP Release. После получения такого сообщения DHCP сервер может отдать этот ip-адрес какому-нибудь другому компьютеру в сети.
Все современные операционные системы автоматически отправляют сообщения DHCP Release при выключении, никаких дополнительных действий от пользователя не требуется.
Если сообщение DHCP Release не будет отправлено, например в случае, когда компьютер выключен некорректно или произошел сбой в операционной системе, то DHCP сервер будет считать, что этот адрес занят пока не закончится время аренды и только после окончания времени аренды он может отдать этот ip-адрес другому компьютеру.
Конфигурационная информация
Компьютеру, для корректной работы в сети, обычно, нужен не только ip-адрес. Нужно знать маску подсетей и маршрутизатор по умолчанию. Также, хорошо узнать адреса серверов имен. DHCP позволяет передать эти и другие сведения о конфигурации сети с помощью опций. Опции включаются в пакет DHCP и передаются вместе с ip-адресом. Кроме маски подсети и маршрутизатора по умолчанию, обычно передается адрес DNS серверов, которые используются для разрешения имен, адреса серверов времени, какие-либо полезные локальные маршруты, а также другая конфигурационная информация.
Поиск DHCP сервера в сети
Если Вы используете DHCP для назначения ip-адресов своей сети, то при планировании сети необходимо обращать внимание на то, где расположен DHCP сервер. Он должен располагаться в той же самой подсети, что и клиенты, которые будут получать ip-адреса по протоколу DHCP.
Почему так происходит? Клиент DHCP при включении не знает, где находится DHCP сервер и отправляет запрос DHCP Discover на широковещательный адрес.
Его получают все компьютеры, которые находятся в данной подсети в том числе и DHCP сервер.
Чтобы решить эту проблему, используется DHCP Relay. Это специальная конфигурация маршрутизаторов или маршрутизирующих коммутаторов, которые позволяют им передавать широковещательный трафик, но не весь, а только тот, который относится к протоколу DHCP. Если наш маршрутизатор способен работать в режиме DHCP Relay, то он передаст сообщение DHCP Discover от клиента к DHCP серверу, который находится в другой сети.
И только в этом случае DHCP сервер может выдать ip-адрес клиенту, который находится за маршрутизатором.
Заключение
Протокол DHCP используется для автоматического назначения IP-адресов и другой конфигурационной информации. Протокол DHCP использует архитектуру клиент-сервер и работает в режиме запрос ответ. Чтобы получить IP-адрес используются 4 DHCP сообщения, сокращенно DORA. DHCP сервер выдает адреса на ограниченный срок (срок аренды). Чтобы DHCP сервер мог выдавать ip-адреса клиентам, он должен находиться с ними в одной подсети или необходимо использовать DHCP Relay на маршрутизаторах и коммутаторах.
ipconfig
Отображает все текущие значения конфигурации сети TCP/IP и обновляет параметры протокола DHCP и системы доменных имен (DNS). При использовании без параметров ipconfig отображает IP-адреса версии 4 (IPv4) и IPv6, маску подсети и шлюз по умолчанию для всех адаптеров.
Синтаксис
Параметры
Комментарии
Эта команда наиболее полезна на компьютерах, настроенных для автоматического получения IP-адреса. Это позволяет пользователям определить, какие значения конфигурации TCP/IP были настроены службой DHCP, автоматическим частным IP-адресом (APIPA) или альтернативной конфигурацией.
Для имен адаптеров ipconfig поддерживает использование подстановочного знака звездочки (*) для указания любого из адаптеров с именами, начинающимися с указанной строки или адаптеров, с именами, содержащими указанную строку. Например, Local* соответствует всем адаптерам, которые начинаются со строки Local и *Con* соответствуют всем адаптерам, содержащим строку Con.
Примеры
Чтобы отобразить основную конфигурацию TCP/IP для всех адаптеров, введите:
Чтобы отобразить полную конфигурацию TCP/IP для всех адаптеров, введите:
Чтобы обновить IP-адрес, назначенный DHCP только для адаптера локальной сети, введите:
Чтобы очистить кэш сопоставителя DNS при устранении неполадок с разрешением DNS-имен, введите:
Чтобы отобразить идентификатор класса DHCP для всех адаптеров с именами, начинающимися с Local, введите:
Чтобы задать идентификатор класса DHCP для ПРОВЕРЯЕМого адаптера локальной сети, введите:
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
Как устроен и работает протокол DHCP

Получение адреса
Рассмотрим процесс получения IP-адреса, он достаточно прост и состоит из четырех этапов, которые в упрощенном виде показаны на следующей схеме:
Все это можно увидеть, если заглянуть внутрь DHCP-пакета:
В данном случае это запрос обнаружения (Discover), цветом мы отметили упоминавшиеся выше поля и опции. Вроде бы все просто, но есть некоторые моменты, которые обычно обходятся молчанием, но способны вызвать определенные затруднения от неверного их понимания.
Запрос обнаружения рассылается для всех узлов сети, но отвечают на него только DHCP-сервера, формируя сообщение Предложения DHCP (DHCP OFFER), которое содержит предлагаемую сервером сетевую конфигурацию. Если серверов несколько, то предложений клиент получит несколько. Из предложенных конфигураций клиент выбирает одну, как правило полученную первой. Предлагаемый клиенту адрес содержится в специальном поле yiaddr, а поле siaddr передается адрес DHCP-сервера.
Так как MAC-адрес отправителя известен, то сервер направляет ответ непосредственно клиенту (unicast), хотя в некоторых случаях может ответить и широковещательным пакетом. Например, DHCP-сервера dnsmasq и Mikrotik отвечает непосредственно клиенту (юникастом), в то время как DHCP Windows Server отвечает широковещательным пакетом. По большому счету это не имеет особого значения, просто вы должны знать, что это вполне допустимые режимы работы DHCP-сервера и не являются признаком неправильной работы.
В структуре ответа мы также отметили цветом вышеописанные опции, также обратите внимание, что в данном случае ответ был отправлен широковещательным пакетом (Windows Server). Ниже показана структура ответа dnsmasq:
Здесь видно, что сервер ответил непосредственно клиенту (отправив фрейм на его MAC-адрес), не прибегая к широковещательной рассылке.
Остальные сетевые параметры передаются в виде опций, в нашем случае это опции 1, 3 и 6 (маска, шлюз, DNS):
Приняв предложение клиент официально запрашивает у сервера данную конфигурацию, для чего отправляет широковещательно Запрос DHCP (DHCP REQUEST), он полностью повторяет по структуре сообщение обнаружения (Discover), только добавляет к нему опцию 54 с адресом сервера, конфигурацию которого клиент принял. Опция 50 содержит предложенный сервером IP-адрес. Несмотря на то, что MAC-адрес DHCP-сервера известен, запрос (Request) рассылается широковещательно, это нужно для того, чтобы остальные DHCP-сервера понимали, что их предложение отвергнуто.
Выше показана структура запроса, можете сравнить его с пакетом обнаружения, обратите внимание на заполненное значение опции 54.
Получив запрос сервер направляет клиенту в ответ Подтверждение DHCP (DHCP ACK), которое отправляется на MAC-адрес клиента (хотя может и широковещательно) и получив которое клиент должен настроить свой сетевой адаптер согласно указанного адреса и опций.
По структуре сообщение подтверждения (Ask) практически не отличается от предложения (Offer), за исключением того, что поле siaddr с адресом DHCP-сервера не заполняется, но его адрес передается в опции 54.
Получив адрес клиент может проверить его на предмет использования при помощи широковещательного ARP-запроса (в большинстве реализаций так и происходит) и если будет обнаружено, что выделенный адрес уже используется (скажем, назначен вручную), то клиент посылает широковещательное сообщение Отказа DHCP (DHCP DECLINE) и начинает процесс получения адреса заново. Сервер, получив сообщение отказа, должен пометить указанный адрес как недоступный и уведомить администратора о возможной проблеме в конфигурации (например, записью в логе).
Также клиент может самостоятельно отказаться от выданного адреса, отправив серверу сообщение Освобождения DHCP (DHCP RELEASE), в отличии от других сообщений, освобождение направляется юникастом серверу, выдавшему адрес. Получив такое сообщение сервер помечает адрес как доступный, но на всякий случай оставляет запись о клиенте, если он захочет получить адрес повторно. Это поведение не является обязательным, но реализовано в большинстве DHCP-серверов.
Обновление адреса
В зависимости от срока прошедшего с момента получения адреса клиент может находится в одном из нескольких состояний.
Для этого он отправляет сообщение запроса (Request), в котором указывает текущий IP-адрес. Если сервер подтверждает аренду, то отвечает сообщением подтверждения (Ask), клиент сбрасывает счетчики T1 и T2 и начинает отсчет срока аренды заново.
Данные о сроке аренды и времени обновления адреса и обновлении конфигурации передаются сервером в опциях 51, 58 и 59:
Если сервер не ответил клиенту, то он берет промежуток времени до окончания состояния обновления и делит его пополам, в это время будет отправлен повторный запрос, при его отсутствии промежуток времени снова будет поделен пополам, потом снова пополам, при этом полученный промежуток времени не может быть меньше 60 сек. Таким образом, чем ближе окончание срока обновления, тем чаще будут делаться запросы.
После наступления момента времени T2, если клиенту не удалось обновить адрес, он переходит в состояние обновления Обновления конфигурации (REBINDING). В этом случае он посылает сообщение Обнаружения DHCP, теперь клиенту может ответить любой DHCP-сервер, а не только тот, который выдал IP-адрес. Если ответа от сервера не было, то оставшееся время также делится пополам и запрос повторяется. Все это время клиент может продолжать пользоваться уже полученной сетевой конфигурацией и нормально работать.
Если же до окончания срока аренды ответ так и не был получен, то клиент прекращает все сетевые операции и переходит в состояние Инициализации (INIT). В последствии, при получении предложений (Offer) от различных серверов клиент предпочтет выбрать предложение от сервера, который выдавал ему адрес прошлый раз и продолжит пользоваться старым адресом.
Также при обновлении могут быть иные сценарии развития событий. Скажем, клиент был включен в другую подсеть. В этом случае при получении запроса DHCP (клиент не знает, что он в другой подсети и пытается продлить аренду) сервер определяет неподходящий адрес в запросе и отвечает ему сообщением Отмены DHCP (DHCP NAK), после чего клиент должен начать процедуру получения адреса заново.
Если сеть клиента корректна, но запрашиваемый адрес занят, то сервер также ответит сообщением отмены (Nak) и клиент начнет получение адреса повторно.
Получение дополнительной информации
Если клиент имеет статически назначенный IP-адрес, но хочет получить дополнительные параметры, скажем адрес серверов имен или статические маршруты, то он отправляет специальное широковещательное сообщение Информации DHCP (DHCP INFORM), в ответ сервера отправляют сообщение подтверждения (Ask) без выделения IP-адреса.
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал:
Принципы работы протокола DHCP
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.255.
Бывает и так, что не все доступные адреса должны быть назначены клиентам. Например, администратор может исключить (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 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.
Взаимодействие 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 командой из терминала:
А затем откройте файл конфигурации /etc/dnsmasq.conf. Файл конфигурации dnsmasq очень большой, но он содержит комментарии с объяснениями того, за что отвечает каждая настройка. Чтобы добавить требуемые настройки, откройте файл и удалите решетку (#), означающую комментарий, в начале нужных строк.
Шаг 3 — настройка фаервола
Для изменения настроек фаервола можно использовать Ubuntu Uncomplicated Firewall. Используйте следующие команды:
Шаг 4 — изменение настроек роутера
Зайдите в настройки вашего роутера из браузера, отключите DHCP для локальной сети, измените все настройки DNS так, чтобы они указывали на ваш только что настроенный сервер. Последнее действие — перезапуск сети на сервере. Для этого вы можете просто перезагрузить компьютер или использовать команды:
Недостатки протокола DHCP
DHCP имеет свои уязвимости. Основная заключается в четырех шагах, необходимых для получения IP. Процесс DORA подразумевает рассылку сообщений широковещательного типа, когда первый откликнувшийся DHCP-сервер получает возможность предложить IP из своей области. Если злоумышленник сможет использовать свой сервер, который даст самый быстрый ответ клиенту, то у него откроется возможность получить контроль над действиями пользователя в сети и нанести существенный ущерб.
Еще одна брешь в безопасности — в том, что DHCP использует UDP-протокол. UDP — протокол обмена датаграммами без установления соединения, а значит, и без шифрования. Передаваемая по UDP информация не защищена и может быть «подслушана», что также может быть использовано злоумышленниками.
Третий недостаток — вновь ненадежность UDP, но другого рода. UDP не обеспечивает гарантию доставки информации. Этот протокол допускает потери и ошибки, которые могут сказаться и на работе DHCP, в частности при PXE-загрузке.
Заключение
Мы рассмотрели основные принципы работы DHCP-серверов. Несмотря на недостатки и частые доработки, протокол DHCP широко используется в современных сетях. Также изучили процесс DORA, основные опции и другие аспекты протокола. Надеемся, эта статья оказалась вам полезна.











