Исследование и Анализ функционирования службы DHCP

 

Цель работы

Изучить назначение и основные принципы функционирования службы DHCP, а также овладеть практическими навыками анализа DHCP-трафика в целях локализации проблем в указанной службе

 

Методические указания по организации самостоятельной работы студентов

 

Основные понятия

Чтобы узел IP мог получать и отправлять пакеты, ему необходимы IP-адрес и маска подсети. IP-адрес присваивается узлу статически или динамически во время загрузки. Если узлу нужно взаимодействовать с другим узлом другой под­сети IP, дополнительно потребуется IP-адрес, по крайней мере, одного маршрутизатора. Кроме того, для отображения доменных имен на IP-адреса узлу нужны или статическая таблица адресов или адрес сервера имен домена (DNS), Чтобы понять, для чего был разработан протокол DHCP (RFC 2131, Dynamic Host Configuration Protocol) потребуется познакомиться с его предшественниками.

В начале развития сетей IP бездисковая рабочая станция должна была полу­чать IP-адрес с помощью протокола RARP (Reverse Address Resolution Protocol, обратный протокол разрешения адресов). Одним из недостатков RARP (как впрочем, и ARP) является то, что пакеты посылаются только по широковеща­тельным адресам уровня DLC и не перенаправляются маршрутизаторами. Ис­пользование RARP для присваивания IP-адресов потребует размещения сервера RARP в каждом сетевом сегменте. Более того, протокол позволяет по­лучить только IP-адрес, хотя лучше одновременно получать маску подсети IP, IP-адрес маршрутизатора по умолчанию, адрес сервера имен и, возможно, до­полнительные сведения.

Преодолеть недостатки RARP должен был помочь протокол ВООТР (Bootstrap, протокол начальной загрузки). Он позволяет бездисковой рабочей станции загрузить по протоколу TFTP (Trivial File Transfer Protocol, упрощен­ный протокол пересылки файлов) образ памяти, чтобы подготовиться к загруз­ке операционной системы. Формат пакетов ВООТР представлен на рисунке 4.1. Пакеты пересылаются по­верх UDP на порт 67 (сервер DHCP) и на порт 68 (клиент DHCP). Первый байт пакета ВООТР определяет тип операции: запрос (1) или ответ (2). Поле типа оборудования (HTYPE) описывает тип аппаратуры DLC, а поле длины аппаратного адреса (HLEN) — длину адреса DLC в байтах. Например, в Ethernet HTYPE = 1 и HLEN = 6. Поскольку ВООТР позволяет маршрутизаторам «за­держивать» запросы ВООТР, в пакете присутствует счетчик переходов (поле НОР), позволяющий подсчитать число пройденных пакетом маршрутизаторов. Идентификатор транзакции (Transaction ID) — это случайное 32-разрядное целое число, устанавливаемое клиентом для согласования запросов и ответов. Поле счетчика секунд, заполняемое клиентом, содержит время, прошедшее от начала процесса загрузки. Это поле может быть использовано, например, для активизации резервного сервера ВООТР, который начинает откликаться только тогда, когда клиент посылает пакет ВООТР. В нем значение счетчика секунд превышает определенную величину (скорее всего, не отвечает главный сервер ВООТР).

Если клиент пытается загружаться с ранее присвоенным IP-адресом, то поле IP-адреса уже может быть заполненным. В противном случае, оно обязано быть нулевым и содержать так называемый «неизвестный» IP-адрес начальной загрузки 0.0.0.0. В пакете ВООТР, поступающем от сервера, будет заполнено поле IP-адреса (IP-адрес пользователя). Поле IP-адреса сервера заполняется клиентом, когда он отправляет запрос определенному серверу DHCP; в про­тивном случае оно заполняется нулями. Если пакет запроса задерживается мар­шрутизатором, то это устройство помещает собственный IP-адрес в поле адреса шлюза (маршрутизатора).

 

 

Рисунок 4.1 - Формат пакета ВООТР

 

Клиент заносит свой адрес DLC в поле аппаратного адреса клиента. В поле имени хоста сервера находится ограниченная нулем строка, заполняемая сер­вером ВООТР. Когда бездисковой рабочей станции нужен образ памяти, серве­ром ВООТР заполняется поле имени файла загрузки для последующего перемещения образа на рабочую станцию по протоколу TFTP. Присвоенный клиенту IP-адрес является единственным параметром кон­фигурации, получаемым клиентом от сервера. Остальные параметры находятся в поле информации производителя. К ним относятся маска подсети и IР-адреса сервера(ов) имен и маршрутизатора(ов).

ВООТР отвечает основным требованиям загрузки по сети IP, но обладает рядом серьезных ограничений. Например, предполагается, что ВООТР работа­ет в весьма статичной среде, где любому адресу DLC всегда присваивается не­который IP-адрес. В такой среде трудно работать с беспроводными узлами, переносными компьютерами и постоянными перемещениями настольных ма­шин в разные помещения. Другой недостаток ВООТР связан с выделением под информацию производителей лишь 64 байт. Поэтому пришлось переходить на протокол DHCP.

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

Динамическое присваивание адресов основано на выделении администра­тором сервера DHCP диапазона свободных IP-адресов. Одни IP-адреса никогда не предоставляются клиентам (поскольку отдельные сетевые узлы, например маршрутизаторы, имеют постоянные адреса), другие адреса могут быть зарезер­вированы для определенных узлов (которые идентифицируются адресом DLC в заголовке ВООТР) и выделяются им статическим способом (как в ВООТР).

Динамические адреса выдаются временно, что позволяет сберечь свобод­ные адреса даже на длительном периоде времени. Адреса «арендуются» клиен­тами у сервера DHCP. Если клиент не обновляет срок действия своей аренды, то адрес может быть предоставлен другому клиенту.

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

Формат пакета DHCP показан на рисунке 4.2 и почти совпадает с ВООТР. Основное отличие состоит в появлении поля флагов и увеличении длины поля дополнительной информации. Единственным специфицированным флагом является крайний левый бит поля флагов. Если он равен 1, то сервер DHCP отвечает широковещательным пакетом, а не пакетом, посланным непо­средственно клиенту. Для чего клиент запрашивает широковещательный ответ?

При возвращении датаграммы IP по адресу DEC клиента стек IP может от­бросить пакет, поскольку клиент может еще не иметь «правильного» IP-адреса.

 

Рисунок 4.2 - Формат пакетов DHCP

 

С другой стороны, протокол IP способен обслужить любые датаграммы IP, по­сланные по широковещательному IP-адресу 255.255.255.255. Установив флаг широковещательного ответа на запрос, клиент точно знает, что получит от сервера DHCP пакет по широковещательному IP-адресу. Адрес DLC в нем также будет широковещательным. (Сервер DHCP в Windows NT всегда возвращает широковещательные ответы, вне зависимости от состояния указанного флага). Все клиенты IP подсети получат широковещательный пакет, но отбросят его. Только ожидающая ответа станция примет его от сервера DHCP.

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

 

Процедура выделения IP-адреса с использованием службы DHCP

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

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

Выдача нового адреса.

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

2. Любой из DHCP-серверов может ответить на поступившее сообщение DHCPDISCOVER сообщением DHCPOFFER, включив в него доступный IP-адрес (yiaddr) и, если требуется, параметры конфигурации клиента. На этой стадии сервер не обязан резервировать указанный адрес. В принципе, он имеет право предложить его другому клиенту, также отправившему запрос DHCPDISCOVER. Тем не менее, спецификации RFC 2131 рекомендуют серверу без необходимости не применять подобную тактику, а, кроме того, убедиться (например, выдав эхо-запрос ICMP) в том, что предложенный адрес в текущий момент не используется каким-либо из компьютеров сети.

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

Не исключено, что клиента не устроит ни одно из серверных предложений. Тогда вместо DHCPREQUEST он снова выдаст в сеть запрос DHCPDISCOVER, а серверы так и не узнают, что их предложения отклонены. Именно по этой причине сервер не обязан резервировать помещенный в DHCPOFFER адрес.

Если в процессе ожидания серверных откликов на DHCPDISCOVER достигнут тайм-аут, клиент выдает данное сообщение повторно.

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

Если к моменту поступления сообщения DHCPREQUEST предложенный адрес уже <ушел> к другому клиенту (например, первая станция слишком долго <размышляла> над поступившими предложениями), сервер отвечает сообщением DHCPNACK.

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

Обнаружив, что адрес уже используется другой станцией, клиент обязан отправить серверу сообщение DHCPDECLINE и не ранее чем через 10 с начать всю процедуру снова. Процесс конфигурирования возобновляется и при получении серверного сообщения DHCPNACK.

При достижении тайм-аута в процессе ожидания серверных откликов на сообщение DHCPREQUEST клиент выдает его повторно.

6. Для досрочного прекращения аренды адреса клиент отправляет серверу сообщение DHCPRELEASE.

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

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

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

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

При пролонгировании аренды клиент проходит два состояния - обновления адреса (RENEWING) и обновления конфигурации (REBINDING). Первое наступает примерно на половине срока аренды адреса (так называемый момент T1), второе - по истечении приблизительно 7/8 полного времени аренды (момент T2); для рассинхронизации процессов реконфигурирования разных клиентов значения этих временных меток рандомизируются с помощью случайной добавки.

В момент T1 клиент оправляет DHCP-серверу, выдавшему адрес, сообщение DHCPREQUEST с просьбой продлить срок аренды. Получив положительный ответ (DHCPACK), клиент пересчитывает срок аренды и продолжает работу в обычном режиме. Клиент ожидает прихода ответа от сервера в течение (T2 - t)/2 с (при условии, что это значение не меньше 60 с), где t - время отсылки последнего сообщения DHCPREQUEST, после чего отправляет данное сообщение повторно.

Если ответ от сервера не поступил к моменту T2, клиент переходит в состояние REBINDING и передает уже широковещательное сообщение DHCPREQUEST со своим текущим сетевым адресом. В этом случае моменты повторных выдач запросов DHCPREQUEST рассчитываются аналогично предыдущему случаю, только вместо T2 фигурирует время окончания срока аренды.

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

 

Недостатки DHCP

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

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

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