Протокол динамической конфигурации хоста ( DHCP ) — это протокол управления сетью , используемый в сетях Интернет-протокола (IP) для автоматического назначения IP-адресов и других параметров связи устройствам, подключенным к сети с использованием архитектуры клиент-сервер . [1]
Технология устраняет необходимость индивидуальной настройки сетевых устройств вручную и состоит из двух сетевых компонентов: централизованно установленного сетевого DHCP- сервера и клиентских экземпляров стека протоколов на каждом компьютере или устройстве. При подключении к сети и периодически после этого клиент запрашивает набор параметров у сервера с помощью DHCP.
DHCP может быть реализован в сетях самого разного размера — от жилых сетей до крупных университетских сетей и региональных сетей интернет-провайдеров. [2] Многие маршрутизаторы и домашние шлюзы имеют функцию DHCP-сервера. Большинство маршрутизаторов домашних сетей получают уникальный IP-адрес в сети интернет-провайдера. В локальной сети DHCP-сервер назначает каждому устройству локальный IP-адрес.
Службы DHCP существуют для сетей, использующих Интернет-протокол версии 4 (IPv4), а также версии 6 ( IPv6 ). Версия протокола DHCP IPv6 обычно называется DHCPv6 .
Протокол разрешения обратного адреса (RARP) был определен в 1984 году [3] для настройки простых устройств, таких как бездисковые рабочие станции , с подходящим IP-адресом. Действуя на уровне канала передачи данных , он затруднял реализацию на многих серверных платформах. Требовалось, чтобы сервер присутствовал на каждом отдельном сетевом канале. На смену RARP пришел протокол Bootstrap (BOOTP), определенный в сентябре 1985 года. [4] Это ввело концепцию агента ретрансляции, который позволил пересылать пакеты BOOTP по сетям, позволяя одному центральному серверу BOOTP обслуживать хосты во многих IP-подсетях.
DHCP был впервые определен в октябре 1993 года. [5] [6] Он основан на BOOTP, но может динамически выделять IP-адреса из пула и возвращать их, когда они больше не используются. Его также можно использовать для доставки широкого спектра дополнительных параметров конфигурации IP-клиентам, включая параметры, специфичные для платформы. [7]
Четыре года спустя были добавлены тип сообщения DHCPINFORM (используемый для WPAD ) и другие небольшие изменения. Это определение с 1997 года [8] остается основой стандарта для сетей IPv4.
DHCPv6 был первоначально определен в 2003 году. [9] После обновлений многих последующих RFC его определение было заменено в 2018 году, [10] где теперь были объединены делегирование префиксов и автоконфигурация адресов без сохранения состояния .
Интернет-протокол (IP) определяет, как устройства взаимодействуют внутри и между локальными сетями в Интернете. DHCP-сервер может управлять настройками IP для устройств в своей локальной сети, например, автоматически и динамически назначая IP-адреса этим устройствам. [11]
DHCP работает по модели клиент-сервер . Когда компьютер или другое устройство подключается к сети, клиентское программное обеспечение DHCP отправляет широковещательный запрос DHCP, запрашивая необходимую информацию. Любой DHCP-сервер в сети может обслуживать запрос. DHCP-сервер управляет пулом IP-адресов и информацией о параметрах конфигурации клиента, таких как шлюз по умолчанию , имя домена , серверы имен и серверы времени . При получении запроса DHCP сервер DHCP может ответить конкретной информацией для каждого клиента, предварительно настроенной администратором, или конкретным адресом и любой другой информацией, действительной для всей сети и на период времени, на который выделено (аренда ) ) действует. Клиент DHCP обычно запрашивает эту информацию сразу после загрузки , а затем периодически до истечения срока действия информации. Когда DHCP-клиент обновляет назначение, он первоначально запрашивает те же значения параметров, но DHCP-сервер может назначить новый адрес на основе политик назначения, установленных администраторами.
В больших сетях, состоящих из нескольких каналов, один DHCP-сервер может обслуживать всю сеть при помощи агентов ретрансляции DHCP, расположенных на соединяющихся маршрутизаторах. Такие агенты ретранслируют сообщения между DHCP-клиентами и DHCP-серверами, расположенными в разных подсетях.
В зависимости от реализации DHCP-сервер может иметь три метода выделения IP-адресов:
Службы DHCP используются для Интернет-протокола версии 4 (IPv4) и IPv6 . Детали протоколов IPv4 и IPv6 различаются настолько, что их можно считать отдельными протоколами. [12] Для работы IPv6 устройства могут альтернативно использовать автоконфигурацию адреса без отслеживания состояния . Хосты IPv6 также могут использовать адресацию локального канала для выполнения операций, ограниченных каналом локальной сети.
DHCP использует модель обслуживания без установления соединения с использованием протокола пользовательских дейтаграмм (UDP). Он реализован с двумя номерами портов UDP для своих операций, которые такие же, как и для протокола начальной загрузки ( BOOTP ). Сервер прослушивает UDP-порт номер 67, а клиент прослушивает UDP-порт номер 68.
Операции DHCP делятся на четыре фазы: обнаружение сервера, предложение аренды IP, запрос аренды IP и подтверждение аренды IP. Эти этапы часто обозначаются сокращением DORA (открытие, предложение, запрос и подтверждение).
Работа DHCP начинается с широковещательной рассылки запроса клиентами. Если клиент и сервер находятся в разных широковещательных доменах , можно использовать DHCP-помощник или агент DHCP-ретрансляции. Клиенты, запрашивающие продление существующей аренды, могут связываться напрямую через одноадресную рассылку UDP , поскольку на тот момент у клиента уже есть установленный IP-адрес. Кроме того, существует флаг BROADCAST (1 бит в 2-байтовом поле флагов, где все остальные биты зарезервированы и поэтому установлены в 0), который клиент может использовать, чтобы указать, каким способом (широковещательным или одноадресным) он может получить DHCPOFFER: 0x8000 для широковещательной передачи, 0x0000 для одноадресной рассылки. [8] Обычно DHCPOFFER отправляется посредством одноадресной рассылки. Для тех хостов, которые не могут принимать одноадресные пакеты до настройки IP-адресов, этот флаг можно использовать для решения этой проблемы.
Клиент DHCP передает сообщение DHCPDISCOVER в подсети сети, используя адрес назначения 255.255.255.255 (ограниченная широковещательная рассылка) или широковещательный адрес конкретной подсети (направленная широковещательная рассылка). Клиент DHCP может также запросить IP-адрес в DHCPDISCOVER, который сервер может принять во внимание при выборе адреса для предложения.
Например, если для HTYPE установлено значение 1, чтобы указать, что используемой средой является Ethernet , для HLEN установлено значение 6, поскольку длина адреса Ethernet (MAC-адрес) составляет 6 октетов. CHADDR устанавливается на MAC-адрес, используемый клиентом. Некоторые параметры также установлены.
Когда DHCP-сервер получает от клиента сообщение DHCPDISCOVER, которое представляет собой запрос на аренду IP-адреса, DHCP-сервер резервирует IP-адрес для клиента и делает предложение аренды, отправляя клиенту сообщение DHCPOFFER. Это сообщение содержит идентификатор клиента клиента (традиционно MAC-адрес), IP-адрес, предлагаемый сервером, маску подсети, продолжительность аренды и IP-адрес DHCP-сервера, делающего предложение. DHCP-сервер также может учитывать MAC-адрес аппаратного уровня на нижележащем транспортном уровне: согласно текущим RFC, MAC-адрес транспортного уровня может использоваться, если в пакете DHCP не указан идентификатор клиента.
DHCP-сервер определяет конфигурацию на основе аппаратного адреса клиента, указанного в поле CHADDR (аппаратный адрес клиента). В следующем примере сервер ( 192.168.1.1 ) указывает IP-адрес клиента в поле YIADDR (ваш IP-адрес).
В ответ на предложение DHCP клиент отвечает сообщением DHCPREQUEST, транслируемым на сервер, [a] запрашивающим предложенный адрес. Клиент может получать предложения DHCP от нескольких серверов, но он будет принимать только одно предложение DHCP. Прежде чем запросить IP-адрес, клиент отправит широковещательный запрос ARP , чтобы определить, есть ли в сети другой хост с предложенным IP-адресом. Если ответа нет, этот адрес не конфликтует с адресом другого хоста, поэтому его можно использовать бесплатно.
Клиент должен отправить опцию идентификации сервера в сообщении DHCPREQUEST, указав сервер, предложение которого выбрал клиент. [8] : Раздел 3.1, пункт 3. Когда другие DHCP-серверы получают это сообщение, они отзывают все предложения, которые они сделали клиенту, и возвращают предложенный им IP-адрес в пул доступных адресов.
Когда DHCP-сервер получает сообщение DHCPREQUEST от клиента, процесс настройки переходит в заключительную фазу. Фаза подтверждения включает отправку пакета DHCPACK клиенту. Этот пакет включает в себя продолжительность аренды и любую другую информацию о конфигурации, которую мог запросить клиент. На этом процесс настройки IP завершен.
Протокол ожидает, что DHCP-клиент настроит свой сетевой интерфейс с согласованными параметрами.
После того, как клиент получит IP-адрес, он должен проверить вновь полученный адрес [8] : сек. 2.2 (например, с протоколом разрешения адресов ARP ), чтобы предотвратить конфликты адресов, вызванные перекрытием пулов адресов DHCP-серверов. Если этот зонд обнаружит другой компьютер, использующий этот адрес, компьютер должен отправить широковещательную рассылку DHCPDECLINE на сервер.
Клиент DHCP может запросить больше информации, чем сервер отправил с исходным DHCPOFFER. Клиент также может запросить повторные данные для конкретного приложения. Например, браузеры используют DHCP Inform для получения настроек веб-прокси через WPAD .
Клиент отправляет запрос DHCP-серверу на выдачу информации DHCP, и клиент деактивирует свой IP-адрес. Поскольку клиентские устройства обычно не знают, когда пользователи могут отключить их от сети, протокол не требует отправки DHCP Release .
DHCP-сервер может предоставлять клиенту дополнительные параметры конфигурации. В RFC 2132 описаны доступные параметры DHCP, определенные Управлением по присвоению номеров в Интернете (IANA) — ПАРАМЕТРЫ DHCP и BOOTP. [13]
Клиент DHCP может выбирать, манипулировать и перезаписывать параметры, предоставляемые DHCP-сервером. В Unix-подобных системах такое уточнение на уровне клиента обычно происходит в соответствии со значениями в файле конфигурации /etc/dhclient.conf .
Опции представляют собой строки октетов различной длины. Это называется кодированием типа-длины-значения . Первый октет — это код опции, второй октет — количество следующих октетов, а остальные октеты зависят от кода. Например, опция типа сообщения DHCP для предложения будет выглядеть как 0x35, 0x01, 0x02, где 0x35 — это код 53 для «типа сообщения DHCP», 0x01 означает, что за ним следует один октет, а 0x02 — это значение «предложения».
В следующих таблицах перечислены доступные параметры DHCP. [14] [13]
В этой таблице перечислены типы сообщений DHCP, описанные в RFC 2132, RFC 3203, [15] RFC 4388, [16] RFC 6926 [17] и RFC 7724. [18] Эти коды представляют собой значение в расширении DHCP 53, показанном на рисунке. таблицу выше.
Существует возможность определить производителя и функциональные возможности DHCP-клиента. Информация представляет собой строку символов или октетов переменной длины , значение которой определяется поставщиком DHCP-клиента. Одним из методов, с помощью которого DHCP-клиент может сообщить серверу, что он использует определенный тип оборудования или встроенного ПО, является установка в своих запросах DHCP значения, называемого идентификатором класса поставщика (VCI) (опция 60).
Значение, присвоенное этому параметру, дает DHCP-серверу подсказку о любой необходимой дополнительной информации, которая требуется этому клиенту в ответе DHCP. Некоторые типы телеприставок настраивают VCI для информирования DHCP-сервера о типе оборудования и функциях устройства. Например, точка беспроводного доступа кампуса Арубы предоставляет значение «ArubaAP» в качестве опции 60 в своем сообщении DHCPDISCOVER . [19] Затем DHCP-сервер может дополнить свой DHCPOFFER IP-адресом беспроводного контроллера Aruba в опции 43, чтобы точка доступа знала, где зарегистрироваться.
Установка VCI клиентом позволяет DHCP-серверу различать клиентские машины и соответствующим образом обрабатывать запросы от них.
Опция информации агента ретрансляции (опция 82) определяет контейнер для прикрепления дополнительных опций к запросам DHCP, передаваемым между ретранслятором DHCP и сервером DHCP. [20]
В небольших сетях, где управляется только одна IP-подсеть, DHCP-клиенты напрямую взаимодействуют с DHCP-серверами. Однако DHCP-серверы также могут предоставлять IP-адреса для нескольких подсетей. В этом случае DHCP-клиент, который еще не получил IP-адрес, не может напрямую взаимодействовать с DHCP-сервером, находящимся не в той же подсети, поскольку широковещательная рассылка клиента может быть получена только в его собственной подсети.
Чтобы разрешить клиентам DHCP в подсетях, которые не обслуживаются напрямую серверами DHCP, взаимодействовать с серверами DHCP, в этих подсетях можно установить агенты ретрансляции DHCP. Агент ретрансляции DHCP работает на сетевом устройстве и может осуществлять маршрутизацию между подсетью клиента и подсетью DHCP-сервера. Клиент DHCP осуществляет широковещательную передачу по локальному каналу; агент ретрансляции получает широковещательную рассылку и передает ее на один или несколько DHCP-серверов с использованием одноадресной рассылки . IP-адреса DHCP-серверов настраиваются вручную в агенте ретрансляции. Агент ретрансляции сохраняет свой собственный IP-адрес с интерфейса, на котором он получил широковещательную рассылку клиента, в поле GIADDR пакета DHCP. DHCP-сервер использует значение GIADDR для определения подсети, а затем и соответствующего пула адресов, из которого можно выделить IP-адрес. Когда DHCP-сервер отвечает клиенту, он отправляет ответ на адрес GIADDR, опять же используя одноадресную рассылку. Затем агент ретрансляции повторно передает ответ по локальной сети, используя одноадресную рассылку (в большинстве случаев) на вновь зарезервированный IP-адрес, в кадре Ethernet , направленном на MAC-адрес клиента. Клиент должен принять пакет как свой собственный, даже если этот IP-адрес еще не установлен на интерфейсе. [8] : 25 Непосредственно после обработки пакета клиент устанавливает IP-адрес на своем интерфейсе и сразу после этого готов к регулярному IP-соединению.
Если реализация стека IP клиента не принимает одноадресные пакеты, когда у него еще нет IP-адреса, клиент может установить бит широковещания в поле FLAGS при отправке пакета DHCPDISCOVER. Агент ретрансляции будет использовать широковещательный IP-адрес 255.255.255.255 (и MAC-адрес клиента) для информирования клиента о DHCPOFFER сервера.
Для связи между агентом ретрансляции и DHCP-сервером обычно используется UDP-порт источника и назначения 67.
Клиент DHCP может получать эти сообщения от сервера: [8] : Раздел 4.4.
Клиент перемещается по состояниям DHCP в зависимости от того, как сервер реагирует на сообщения, которые отправляет клиент.
DHCP обеспечивает надежность несколькими способами: периодическое обновление, перепривязка, [8] : Раздел 4.4.5 и аварийное переключение. DHCP-клиентам предоставляются аренды на определенный период времени. Клиенты начинают пытаться продлить аренду после истечения половины срока аренды. [8] : Раздел 4.4.5, параграф 3. Они делают это, отправляя одноадресное сообщение DHCPREQUEST на DHCP-сервер, который предоставил первоначальную аренду. Если этот сервер не работает или недоступен, он не сможет ответить на DHCPREQUEST . Однако в этом случае клиент время от времени повторяет DHCPREQUEST , [8] : Раздел 4.4.5, Параграф 8 [b] , поэтому, если DHCP-сервер снова заработает или станет доступным, DHCP-клиент сможет связаться с ним и продлить аренду.
Если DHCP-сервер недоступен в течение длительного периода времени, [8] : Раздел 4.4.5, Параграф 5, DHCP-клиент попытается повторно привязаться, передавая свой DHCPREQUEST , а не отправляя его в одноадресной рассылке. Поскольку оно широковещательное , сообщение DHCPREQUEST достигнет всех доступных DHCP-серверов. Если какой-либо другой DHCP-сервер сможет продлить аренду, он сделает это в данный момент.
Чтобы перепривязка работала, когда клиент успешно связывается с резервным DHCP-сервером, этот сервер должен иметь точную информацию о привязке клиента. Поддержание точной информации о привязке между двумя серверами является сложной проблемой; если оба сервера могут обновлять одну и ту же базу данных аренды, должен быть механизм, позволяющий избежать конфликтов между обновлениями на независимых серверах. Предложение по внедрению отказоустойчивых DHCP-серверов было представлено Рабочей группе по проектированию Интернета, но так и не было формализовано. [28] [с]
Если перепривязка не удалась, срок аренды в конечном итоге истечет. По истечении срока аренды клиент должен прекратить использовать IP-адрес, предоставленный ему в рамках аренды. [8] : Раздел 4.4.5, Параграф 9. В это время он перезапустит процесс DHCP с самого начала, отправив широковещательное DHCPDISCOVER
сообщение. Поскольку срок его аренды истек, он примет любой предложенный ему IP-адрес. Как только он получит новый IP-адрес (предположительно от другого DHCP-сервера), он снова сможет использовать сеть. Однако, поскольку его IP-адрес изменился, все текущие соединения будут разорваны.
Базовая методология DHCP была разработана для сетей, основанных на интернет-протоколе версии 4 (IPv4). С момента разработки и развертывания сетей IPv6 DHCP также использовался для назначения параметров в таких сетях, несмотря на присущие IPv6 возможности автоконфигурации адресов без сохранения состояния . Версия протокола IPv6 обозначается как DHCPv6 . [29]
Базовый DHCP не включает никакого механизма аутентификации. [30] : сек. 7 Из-за этого он уязвим для различных атак. Эти атаки делятся на три основные категории: [8] : сек. 7
Поскольку у клиента нет возможности проверить личность DHCP-сервера, в сетях могут работать неавторизованные DHCP-серверы (обычно называемые « мошенническими DHCP »), предоставляющие DHCP-клиентам неверную информацию. [31] Это может служить либо атакой типа «отказ в обслуживании», не позволяющей клиенту получить доступ к сетевому подключению, [32] либо атакой «человек посередине» . [33] Поскольку DHCP-сервер предоставляет DHCP-клиенту IP-адреса серверов, например IP-адрес одного или нескольких DNS-серверов, [8] : сек. 7 злоумышленник может убедить DHCP-клиента выполнить поиск DNS через свой собственный DNS-сервер и, следовательно, может предоставить свои собственные ответы на DNS-запросы от клиента. [34] Это, в свою очередь, позволяет злоумышленнику перенаправлять сетевой трафик через себя, позволяя ему подслушивать соединения между клиентом и сетевыми серверами, с которыми он контактирует, или просто заменять эти сетевые серверы своими собственными. [34]
Поскольку DHCP-сервер не имеет безопасного механизма аутентификации клиента, клиенты могут получить несанкционированный доступ к IP-адресам, предоставив учетные данные, такие как идентификаторы клиентов, которые принадлежат другим DHCP-клиентам. [31] Это также позволяет DHCP-клиентам исчерпать хранилище IP-адресов DHCP-сервера — предоставляя новые учетные данные каждый раз, когда он запрашивает адрес, клиент может использовать все доступные IP-адреса в определенном сетевом канале, не позволяя другим DHCP-клиентам получение услуги. [31]
DHCP предоставляет некоторые механизмы для решения этих проблем. Расширение протокола Relay Agent Information Option [30] (обычно называемое в отрасли по фактическому номеру Option 82 [35] [36] ) позволяет сетевым операторам прикреплять теги к сообщениям DHCP по мере того, как эти сообщения поступают в доверенную сеть сетевого оператора. . Этот тег затем используется в качестве токена авторизации для управления доступом клиента к сетевым ресурсам. Поскольку клиент не имеет доступа к сети выше агента ретрансляции, отсутствие аутентификации не мешает оператору DHCP-сервера полагаться на токен авторизации. [30] : сек. 7
Другое расширение, Аутентификация сообщений DHCP [37] (RFC 3118), обеспечивает механизм аутентификации сообщений DHCP. По состоянию на 2002 год это расширение не получило широкого распространения из-за проблем с управлением ключами для большого количества клиентов DHCP. [38] В книге о технологиях DSL, вышедшей в 2007 году, отмечается, что:
[T]было выявлено множество уязвимостей безопасности, противоречащих мерам безопасности, предложенным RFC 3118. Этот факт в сочетании с введением 802.1x замедлил развертывание и скорость использования аутентифицированного DHCP, и он никогда не получил широкого распространения. [39]
В книге 2010 года отмечается, что:
[T]было очень мало реализаций DHCP-аутентификации. Проблемы управления ключами и задержки обработки из-за хэш-вычислений были сочтены слишком тяжелой ценой за предполагаемые преимущества. [40]
Архитектурные предложения 2008 года включают аутентификацию запросов DHCP с использованием 802.1x или PANA (оба из которых передают EAP ). [41] IETF было сделано предложение включить EAP в сам DHCP, так называемый EAPoDHCP ; [42] похоже, это не продвинулось дальше уровня проекта IETF, последний из которых датируется 2010 годом. [43]
{{cite journal}}
: Требуется цитировать журнал |journal=
( помощь )