Работа DHCP

Работа DHCP

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

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

Процесс получения настроек происходит в несколько этапов и описывается схемой DORA (Discover-Offer-Request Acknowledge).

Рисунок — Процесс получения настроек от DHCP сервера

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. Опция 82 – опция протокола DHCP, нужная для передачи DHCP-серверу разнообразной информации, применяется для защиты DHCP-сервера от атак с использованием DHCP-протокола и не является обязательной для использования.

Клиент может проверить полученный от 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).

Режим ретрансляции

EcoRouter поддерживает 2 режима ретрансляции:

• DHCP-relay;
• DHCP-proxy.

Если опция 82 включена на EcoRouter, то в режиме DHCP-relay ее параметры добавляются в запрос (REQUEST) клиента.

В таблице ниже приведены особенности этих режимов.

Таблица — Особенности режимов DHCP-relay и DHCP-relay-proxy

Действие или событие	Действие EcoRouter в режиме DHCP-relay	Действие EcoRouter в режиме DHCP-proxy
⇒ DHCPDISCOVER Клиент послал широковещательное сообщение DISCOVER	EcoRouter перенаправляет широковещательное (multicast) сообщение DISCOVER	EcoRouter перехватывает широковещательное сообщение DISCOVER, вносит в таблицу DHCP mac-адрес и VLAN клиента, после чего перенаправляет сообщение DISCOVER в виде unicast
⇐ DHCPOFFER DHCP-серверы отправили сообщения OFFER	EcoRouter перенаправляет сообщения OFFER от всех ответивших DHCP-серверов клиенту	EcoRouter подменяет в сообщении OFFER от первого ответившего клиенту DHCP-сервера его адрес своим адресом, добавляет в таблицу информацию о выданном ip-адресе и времени начала аренды, а остальные сообщения OFFER игнорирует
⇒ DHCPREQUEST Клиент послал сообщение REQUEST	EcoRouter перенаправляет широковещательное сообщение REQUEST	EcoRouter подменяет адрес клиента на собственный и перенаправляет сообщение REQUEST выбранному DHCP-серверу
<⇐ DHCPACK DHCP-сервер послал сообщения ACK на mac-адрес компьютера, указанного в сообщении REQUEST	EcoRouter перенаправляет сообщение ACK клиенту	EcoRouter перенаправляет сообщение ACK клиенту
Наступил момент для запроса обновления аренды адреса (RENEWING) (определяется настройками DHCP-сервера)	EcoRouter перенаправляет DHCP-серверу сообщение REQUEST от клиента с просьбой продлить срок аренды	EcoRouter самостоятельно направляет DHCP-серверу сообщение REQUEST с просьбой продлить срок аренды. EcoRouter также хранит информацию о времени последнего получения запроса обновления аренды адреса от клиента и времени получения последнего пакета подтверждения от сервера
Наступил момент для запроса обновления конфигурации (REBINDING) (определяется настройками DHCP-сервера)	EcoRouter перенаправляет широковещательное сообщение REQUEST с текущим сетевым адресом клиента	EcoRouter самостоятельно направляет широковещательное сообщение REQUEST с текущим собственным сетевым адресом

Настройка опции 82

Для начала настройки необходимо выбрать соответствующий dhcp-profile:

ecorouter>enable
ecorouter#config
ecorouter(config)# dhcp-profile DHCP_PROFILE_INDEX
ecorouter(config-dhcp)#

В этом режиме можно настроить опцию 82:

ecorouter(config-dhcp)#information-option ?
  circuit-id  Circuit ID identifies the circuit
  remote-id   Remote ID identifies the remote host
  rewrite     Re-write option (82) toward servers

После ввода circuit-id или remote-id можно посмотреть подсказку:

ecorouter(config-dhcp)#information-option circuit-id ?
  LINE  Circuit ID line
  hex   Circuit ID in HEX format
ecorouter(config-dhcp)#information-option circuit-id hex ?
  HEX_DATA  Circuit ID in HEX format

После hex можно вводить значение, которое будет интерпретировано как шестнадцатеричное число и передано без изменений.

Число должно начинаться с 0x, иначе не будет валидировано, и будет выведено сообщение об ошибке.

Максимально доступная длина HEX числа для ввода — 512 байт (256 двухбайтных ASCII символов).

Пример ввода HEX значения:

ecorouter(config-dhcp)#information-option circuit-id hex 0x010203ff9900

Можно использовать следующие шаблоны:

• %{vr}             - Virtual Router ID             - Кодируется в HEX как Int
• %{cmac}             - Client MAC Address             - Передается в CISCO-формате, в виде одного шестнадцатеричного числа без разделителей
• %{port}             - Символьное имя порта.             - Кодируется в HEX как ASCII
• %{hname}             - Hostname роутера.             - Кодируется в HEX как ASCII
• %{svlan}             - Service (Outer) VLAN ID.             - Кодируется в HEX как Int
• %{cvlan}             - Customer (Inner)  VLAN ID.             - Кодируется в HEX как Int

Пример использования шаблона:

ecorouter(config-dhcp)#information-option circuit-id hex 0x010203%{cvlan}ff9900

Настройка DHCP-ретранслятора

DHCP-ретранслятор (DHCP Relay Agent) — это сетевой компонент, который пересылает DHCP-запросы между клиентами и DHCP-серверами, находящимися в разных подсетях.

Для указания IP-адреса интерфейса DHCP-ретранслятора, на котором было получено DHCP-сообщение, ретранслятор отправляет в сообщениях в адрес DHCP-сервера поле giaddr (Gateway IP Address / Relay Agent IP).

Функции поля giaddr:

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

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

В EcoRouterOS есть возможность автоматического подбора IP адресов в опцию giaddr DHCP-ретранслятора из списка IP адресов, которые представлены на L3 интерфейсе за которым находятся DHCP клиенты. Это функционал называется smart relay.

Функция включается из режима конфигурирования профиля DHCP в режиме proxy:

R1(config)#dhcp-profile 1
R1(config-dhcp)#mode proxy
R1(config-dhcp)#relay-agent smart <1-65535> 

<1-65535> — количество попыток отправки запросов DISCOVER в адрес DHCP-сервера. Запрос считается неудачным, если в течении одной секунды от DHCP-сервера не приходит ответа.

При отсутствии ответа после указанного числа попыток, агент ретрансляции (маршрутизатор) возьмёт следующий IP из списка secondary на L3 интерфейсе и отправит DHCP запросы с ним в поле giaddr. И так по порядку, пока DHCP сервер не ответит.

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

Если высвободились адреса нескольких абонентов — DHCP proxy пытается отправить запросы DHCP серверу с соответствующими IP-адресами в порядке прописанном на интерфейсе.