Протокол динамического конфигурирования сервера

Протокол динамической конфигурации хоста ( DHCP ) - это протокол управления сетью, используемый в сетях Интернет-протокола (IP) , посредством которого DHCP- сервер динамически назначает IP-адрес и другие параметры конфигурации сети каждому устройству в сети, чтобы они могли связываться с другим IP-адресом. сети. ^[1] DHCP-сервер позволяет компьютерам автоматически запрашивать IP-адреса и параметры сети у поставщика услуг Интернета (ISP), что снижает потребность в сетевом администраторе или пользователе.чтобы вручную назначить IP-адреса всем сетевым устройствам. ^[1] При отсутствии DHCP-сервера компьютеру или другому устройству в сети необходимо вручную назначить IP-адрес или назначить себе адрес APIPA , последний из которых не позволит ему общаться за пределами своей локальной подсети. .

DHCP может быть реализован в сетях размером от домашних сетей до крупных кампусных сетей и региональных сетей Интернет-провайдеров. ^[2] маршрутизатор или шлюз может быть включен , чтобы выступать в качестве сервера DHCP. Большинство маршрутизаторов домашних сетей получают глобальный уникальный IP-адрес в сети Интернет-провайдера. В локальной сети DHCP-сервер назначает локальный IP-адрес каждому устройству, подключенному к сети.

История [ править ]

В 1984 году был введен протокол обратного разрешения адресов (RARP), определенный в RFC 903 , чтобы позволить простым устройствам, таким как бездисковые рабочие станции, динамически получать подходящий IP-адрес. Однако, поскольку он действовал на уровне канала передачи данных, это затрудняло реализацию на многих серверных платформах, а также требовало наличия сервера на каждом отдельном сетевом канале. RARP был заменен протоколом начальной загрузки ( BOOTP ), определенным в RFC 951 в сентябре 1985 года. В нем была представлена ​​концепция агента ретрансляции , который позволял пересылать пакеты BOOTP по сетям, позволяя одному центральному серверу BOOTP обслуживать хосты во многих IP-подсетях. ^[3]

DHCP основан на BOOTP, но может динамически выделять IP-адреса из пула и восстанавливать их, когда они больше не используются. Его также можно использовать для доставки широкого спектра дополнительных параметров конфигурации IP-клиентам, включая параметры для конкретной платформы. ^[4] Протокол DHCP был впервые определен в RFC 1531 в октябре 1993 года; но из-за ошибок в редакционном процессе он был почти сразу переиздан как RFC 1541 .

Четыре года спустя тип сообщения DHCPINFORM ^[5] и другие небольшие изменения были добавлены в RFC 2131 ; который с 2014 года ^{[Обновить]}остается стандартом для сетей IPv4.

DHCPv6 был первоначально описан в RFC 3315 в 2003 году, но он был обновлен во многих последующих RFC. ^[6] RFC 3633 добавил механизм DHCPv6 для делегирования префикса , а автоконфигурация адреса без сохранения состояния была добавлена RFC 3736 .

Обзор [ править ]

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

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

В больших сетях, состоящих из нескольких каналов, один DHCP-сервер может обслуживать всю сеть при помощи агентов ретрансляции DHCP, расположенных на соединяющихся маршрутизаторах. Такие агенты ретранслируют сообщения между DHCP-клиентами и DHCP-серверами, расположенными в разных подсетях.

В зависимости от реализации DHCP-сервер может иметь три метода выделения IP-адресов:

Динамическое размещение

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

Автоматическое распределение

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

Ручное распределение

Также обычно называется статическим распределением и резервированием . DHCP-сервер выдает частный IP-адрес, зависящий от идентификатора клиента каждого клиента (или, как правило, MAC-адреса клиента ), на основе предварительно заданного администратором сопоставления. Эта функция по-разному называется статическим назначением DHCP с помощью DD-WRT , фиксированным адресом в документации dhcpd, резервированием адреса с помощью Netgear, резервированием DHCP или статическим DHCP от Cisco и Linksys , а также резервированием IP-адреса или привязкой MAC / IP-адреса.различными другими производителями маршрутизаторов. Если не найдено совпадение для идентификатора клиента (если он указан) или MAC-адреса (если идентификатор клиента не указан), сервер может или не может вернуться к динамическому или автоматическому распределению.

DHCP используется для Интернет-протокола версии 4 (IPv4) и IPv6 . Хотя обе версии служат одной и той же цели, детали протокола для IPv4 и IPv6 достаточно различаются, чтобы их можно было рассматривать как отдельные протоколы. ^[7] В качестве альтернативы для работы 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-адрес. Если клиент остается подключенным к той же сети, сервер может удовлетворить запрос. В противном случае это зависит от того, настроен ли сервер как авторитетный или нет. Полномочный сервер отклоняет запрос, в результате чего клиент отправляет новый запрос. Неавторизованный сервер просто игнорирует запрос, что приводит к зависящему от реализации таймауту для клиента, чтобы истечь срок действия запроса и запросить новый IP-адрес.

Например, если 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. Клиент создаст бесплатный ARP, чтобы определить, есть ли в сети какой-либо другой хост с таким же IP-адресом. Если нет ответа от другого хоста, значит, в сети нет хоста с такой же конфигурацией TCP, и сообщение транслируется на сервер, показывая принятие IP-адреса. На основе требуемой опции идентификации сервера в запросе и широковещательном обмене сообщениями серверы информируются, чье предложение клиент принял. ^{[10] : Раздел 3.1, пункт 3} Когда другие DHCP-серверы получают это сообщение, они отменяют все предложения, сделанные клиенту, и возвращают предложенный IP-адрес в пул доступных адресов.

Благодарность [ править ]

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

Протокол ожидает, что DHCP-клиент настроит свой сетевой интерфейс с согласованными параметрами.

После того, как клиент получит IP-адрес, он должен проверить вновь полученный адрес ^[11] (например, с помощью протокола разрешения адресов ARP ), чтобы предотвратить конфликты адресов, вызванные перекрытием пулов адресов DHCP-серверов.

Информация [ править ]

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

Освобождение [ править ]

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

Параметры конфигурации клиента [ править ]

DHCP-сервер может предоставить клиенту дополнительные параметры конфигурации. RFC 2132 описывает доступные параметры DHCP, определенные Internet Assigned Numbers Authority (IANA) - ПАРАМЕТРЫ DHCP и BOOTP. ^[12]

Клиент DHCP может выбирать, изменять и перезаписывать параметры, предоставляемые сервером DHCP. В Unix-подобных системах это уточнение на уровне клиента обычно происходит в соответствии со значениями в файле конфигурации /etc/dhclient.conf .

Параметры [ редактировать ]

Опции - это строки октетов различной длины. Первый октет - это код опции, второй октет - это количество следующих октетов, а остальные октеты зависят от кода. Например, параметр типа сообщения DHCP для предложения будет отображаться как 0x35, 0x01, 0x02, где 0x35 - это код 53 для «типа сообщения DHCP», 0x01 означает, что следует один октет, а 0x02 - значение «предложения».

Документировано в RFC 2132 [ править ]

В следующих таблицах перечислены доступные параметры DHCP, указанные в RFC 2132 ^[13] и реестре IANA. ^[12]

Типы сообщений DHCP [ править ]

В этой таблице перечислены типы сообщений DHCP, задокументированные в RFC 2132 , RFC 3203 , ^[14] RFC 4388 , ^[15] RFC 6926 ^[16] и RFC 7724 . ^[17] Эти коды представляют собой значение в расширении DHCP 53, показанном в таблице выше.

Идентификация поставщика клиента [ править ]

Существует возможность идентифицировать поставщика и функциональность DHCP-клиента. Информация представляет собой строку символов или октетов переменной длины, значение которой определяется поставщиком DHCP-клиента. Один из методов, с помощью которого DHCP-клиент может сообщить серверу, что он использует определенный тип оборудования или микропрограмм, заключается в установке значения в его запросах DHCP, называемого идентификатором класса поставщика (VCI) (опция 60). Этот метод позволяет DHCP-серверу различать два типа клиентских машин и соответствующим образом обрабатывать запросы от двух типов модемов. Некоторые типы приставоктакже установите VCI (опция 60) для информирования DHCP-сервера о типе оборудования и функциональных возможностях устройства. Значение, установленное для этого параметра, дает серверу DHCP подсказку о любой дополнительной информации, которая требуется этому клиенту в ответе DHCP.

Документировано в другом месте [ править ]

Дополнительные параметры информации агента ретрансляции [ править ]

Опция информации агента ретрансляции (опция 82) ^[18] определяет контейнер для присоединения подпараметров к запросам DHCP, передаваемым между ретранслятором DHCP и сервером DHCP.

Ретрансляция [ править ]

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

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

В этой ситуации для связи между агентом ретрансляции и DHCP-сервером обычно используются UDP-порт источника и назначения 67.

Состояния клиентов [ править ]

Как описано в RFC 2131 , ^{[10] : Раздел 4.4,} DHCP-клиент может получать следующие сообщения от сервера:

• DHCPOFFER
• DHCPACK
• DHCPNAK

Клиент перемещается по состояниям DHCP в зависимости от того, как сервер отвечает на сообщения, которые отправляет клиент.

Надежность [ править ]

DHCP обеспечивает надежность несколькими способами: периодическое обновление, повторное связывание, ^{[10] : раздел 4.4.5} и аварийное переключение. Клиентам DHCP выделяется аренда на определенный период времени. Клиенты начинают попытки продлить свои договоры аренды по истечении половины интервала аренды. ^{[10] : Раздел 4.4.5 Параграф 3} Они делают это, отправляя одноадресное сообщение DHCPREQUEST на сервер DHCP, который предоставил исходную аренду. Если этот сервер не работает или недоступен, он не сможет ответить на DHCPREQUEST . Однако в этом случае клиент время от времени повторяет DHCPREQUEST , ^{[10] : Раздел 4.4.5 Параграф 8 [b]} поэтому, если DHCP-сервер снова включится или снова станет доступным, DHCP-клиент сможет связаться с ним и продлить аренду.

Если DHCP-сервер недоступен в течение длительного периода времени, ^{[10] : Раздел 4.4.5, параграф 5,} DHCP-клиент попытается выполнить повторную привязку, передав свой DHCPREQUEST, а не одноадресно. Потому что он транслируется , то DHCPREQUEST сообщение достигнет всех доступных серверов DHCP. Если какой-либо другой DHCP-сервер может продлить аренду, он сделает это в это время.

Чтобы повторная привязка работала, когда клиент успешно связывается с резервным DHCP-сервером, этот сервер должен иметь точную информацию о привязке клиента. Поддержание точной информации о привязке между двумя серверами - сложная проблема; если оба сервера могут обновлять одну и ту же базу данных аренды, должен быть механизм, позволяющий избежать конфликтов между обновлениями на независимых серверах. Предложение по внедрению отказоустойчивых DHCP-серверов было представлено Инженерной группе Интернета, но так и не было оформлено официально. ^{[24] [c]}

Если повторная привязка не удалась, срок аренды в конечном итоге истечет. По истечении срока аренды клиент должен прекратить использовать IP-адрес, предоставленный ему в его аренде. ^{[10] : Раздел 4.4.5 Параграф 9} В это время он перезапустит процесс DHCP с самого начала, рассылая DHCPDISCOVERсообщение. Поскольку срок его аренды истек, он примет любой предложенный IP-адрес. Как только он получит новый IP-адрес (предположительно от другого DHCP-сервера), он снова сможет использовать сеть. Однако, поскольку его IP-адрес изменился, все текущие соединения будут прерваны.

Современное приложение [ править ]

По состоянию на 2018 год DHCP по-прежнему широко используется для автоматического назначения IP-адресов. ^[25] Новые варианты назначения IP-адресов включают DHCPv6 и SLAAC . ^[25]

Безопасность [ править ]

Базовый DHCP не включает никаких механизмов аутентификации. ^[26] Из-за этого он уязвим для различных атак. Эти атаки делятся на три основные категории:

• Неавторизованные DHCP-серверы предоставляют клиентам ложную информацию. ^[27]
• Неавторизованные клиенты получают доступ к ресурсам. ^[27]
• Атаки исчерпания ресурсов от вредоносных DHCP-клиентов. ^[27]

Поскольку у клиента нет возможности проверить подлинность DHCP-сервера, неавторизованные DHCP-серверы (обычно называемые « мошенническим DHCP ») могут работать в сетях, предоставляя неверную информацию клиентам DHCP. ^[28] Это может служить либо атакой типа «отказ в обслуживании», не позволяющей клиенту получить доступ к сетевым соединениям ^[29], либо атакой типа «злоумышленник в середине» . ^[30] Поскольку DHCP-сервер предоставляет DHCP-клиенту IP-адреса сервера, такие как IP-адрес одного или нескольких DNS-серверов, ^[27] злоумышленник может убедить DHCP-клиента выполнить поиск в DNS через его собственный DNS-сервер, и поэтому может предоставлять свои собственные ответы на запросы DNS от клиента. ^[31][32] Это, в свою очередь, позволяет злоумышленнику перенаправлять сетевой трафик через себя, позволяя ему подслушивать соединения между клиентом и сетевыми серверами, с которыми он контактирует, или просто заменять эти сетевые серверы своими собственными. ^[31]

Поскольку DHCP-сервер не имеет безопасного механизма для аутентификации клиента, клиенты могут получить несанкционированный доступ к IP-адресам, предоставив учетные данные, такие как идентификаторы клиента, которые принадлежат другим клиентам DHCP. ^[28] Это также позволяет DHCP-клиентам исчерпать хранилище IP-адресов DHCP-сервера - представляя новые учетные данные каждый раз, когда он запрашивает адрес, клиент может использовать все доступные IP-адреса на конкретном сетевом канале, предотвращая доступ других DHCP-клиентов получение обслуживания. ^[28]

DHCP действительно предоставляет некоторые механизмы для смягчения этих проблем. Расширение протокола Relay Agent Information Option ( RFC 3046 , обычно обозначаемое в отрасли по его фактическому номеру как Option 82 ^{[33] [34]} ) позволяет операторам сети прикреплять теги к сообщениям DHCP, когда эти сообщения поступают в доверенную сеть оператора сети. . Затем этот тег используется в качестве токена авторизации для управления доступом клиента к сетевым ресурсам. Поскольку у клиента нет доступа к сети выше агента ретрансляции, отсутствие аутентификации не мешает оператору DHCP-сервера полагаться на токен авторизации. ^[26]

Другое расширение, Аутентификация для сообщений DHCP ( RFC 3118 ), обеспечивает механизм аутентификации сообщений DHCP. По состоянию на 2002 год RFC 3118 не получил широкого распространения из-за проблем с управлением ключами для большого количества клиентов DHCP. ^[35] В книге 2007 года о технологиях DSL отмечалось, что:

Было обнаружено множество уязвимостей безопасности, связанных с мерами безопасности, предложенными RFC 3118 . Этот факт в сочетании с внедрением 802.1x замедлил развертывание и скорость использования аутентифицированного DHCP, и он никогда не получил широкого распространения. ^[36]

В книге 2010 года отмечается, что:

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

Архитектурные предложения от 2008 года включают аутентификацию запросов DHCP с использованием 802.1x или PANA (оба из которых передают EAP ). ^[38] IETF было сделано предложение включить EAP в сам DHCP, так называемый EAPoDHCP ; ^[39] это, похоже, не продвинулось дальше уровня проекта IETF, последний из которых датируется 2010 годом. ^[40]

Документы стандартов IETF [ править ]

• RFC 2131 , протокол динамической конфигурации хоста
• RFC 2132 , параметры DHCP и расширения поставщика BOOTP
• RFC 3046 , опция информации агента ретрансляции DHCP
• RFC 3397 , опция поиска домена по протоколу динамической конфигурации хоста (DHCP)
• RFC 3942 , Реклассификация параметров протокола динамической конфигурации хоста версии четыре (DHCPv4)
• RFC 4242 , параметр времени обновления информации для протокола динамической конфигурации хоста для IPv6
• RFC 4361 , специфичные для узла идентификаторы клиентов для протокола динамической конфигурации хоста версии четыре (DHCPv4)
• RFC 4436 , Обнаружение сетевых подключений в IPv4 (DNAv4)
• RFC 3442 , опция бесклассового статического маршрута для протокола динамической конфигурации хоста (DHCP) версии 4
• RFC 3203 , расширение перенастройки DHCP
• RFC 4388 , запрос аренды протокола динамической конфигурации хоста (DHCP)
• RFC 6926, запрос массовой аренды DHCPv4
• RFC 7724 , активный запрос аренды DHCPv4

См. Также [ править ]

Примечания [ править ]

Ссылки [ править ]

Внешние ссылки [ править ]

• СМИ, относящиеся к протоколу динамической конфигурации хоста (DHCP) на Викискладе?