Администрирование #04. DHCP.⁠⁠

Предыдущая часть тут.

Прошу прощение за долгое отсутствие. Я поняла, что в моём man'е по DHCP написано прискорбно мало и решила полностью его переписать.

В данном посте я буду идти от сильного упрощению к менее сильному упрощению, и в конце приближусь к правде, мне кажется, это логичнее, чем сразу углубляться в протокол.

Для начала, что делает DHCP (Dynamic Host Configuration Protocol – протокол динамической настройки узла). С помощью этой штуки сетевые устройства могут получать IP-адрес и другие сетевые настройки автоматически. Работает этот протокол по клиент-серверной модели. В самом общем случае это выглядит так:

Клиент-всем: Дайте мне кто-нибудь настройки!

Сервер-клиенту: Держи, я тут сервер, вот настройки: «настройки». Тебе норм?

Клиент-серверу: Ага, «настройки» подходят, ништяк.

Сервер-клиенту: Пометил у себя, «настройки» записаны на твоё имя.

Клиент /сам с собой/  уф, применил «настройки», кажись пошел трафик.

Еще раз – это упрощение. На каждом этапе могут возникнуть свои нюансы и мы часть из них разберем. Пока о том, зачем это нужно: ведь есть статическое назначение адресов (и других настроек). На сегодняшний день, на мой взгляд, причина «во-первых» - это то, что для присвоения статических настроек надо хоть что-то знать о сетях, то есть – домохозяйка с роутером пролетает. Ну и причина «во-вторых», которая на самом деле наиболее важна – это автоматизация и централизация сетевой настройки. Круто, когда у вас 5 компов и в сети статика. Потом их станет 15 и появится файлик с адресами. Потом их становится 100… и в один непрекрасный момент срочно понадобится сменить DNS сервер или шлюз по умолчанию. И если на DHCP вы правите это в одном месте и настройки распространяются автоматом, то тут вы будете ходить и править сто компов руками (вас в процессе четвертуют скорее всего). К тому же, DHCP ведет за вас свой виртуальный «файлик» и не выдаст случайно одинаковые адреса разным хостам. В-третьих, это возможность выдавать адрес «на время», например, на неделю или на час. Вы же не будете каждому посетителю своего интернет-кафе прописывать адрес вручную и записывать в файлик. А так, адрес выдался автоматом, через час освободился и может быть выдан другому.

Для работы сервера выделяется некоторый пул (pool) – диапазон адресов, которые DHCP-сервер может раздавать клиентам.

Существует протокол, его описание и куча его реализаций на различных устройствах. Я не буду рассматривать каких-то конкретных реализаций – все они придерживаются единого формата.

Как видно из примера диалога выше, общение клиента и сервера разбито на несколько этапов-сообщений. В DHCP есть следующие типы сообщений: DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK, DHCPNAK, DHCPDECLINE, DHCPRELEASE, DHCPINFORM. Клиент и сервер общаются по протоколу UDP (у сервера порт 67, у клиента 68).

Эти сообщения выглядят в общем случае так: в шапке всякая важная мура из разряда кому, от кого, идентификаторы и всё такое, а в конце пачка опций. Вот эти опции и есть те настройки которые клиент запрашивает, а сервер выдаёт. Кому интересны подробности (а они правда интересны и важны), почитайте rfc2131.

На первом этапе клиент рассылает всем в локальной сети широковещательное сообщение на MAC-адрес FF:FF:FF:FF:FF:FF.

Отступление: Если у вас есть специальный сервер перенаправления запросов DHCP-relay, то сообщение может уйти и за пределы локальной сети.

Это сообщение DHCPDISCOVER. Тут возникает один нюанс: бывает так, что клиент «чистенький» - у него не было адреса, а бывает так, что у него был какой-то IP адрес и он говорит «неплохо бы повторить, если можно, бро». Во втором случае в список опций добавляется «requested IP address» с желаемым IP. Из важного в DHCPDISCOVER указывается ID транзакции (он будет одинаковым для всей цепочки обмена сообщениями) и идентификатор клиента (он должен быть уникальным в локальной сети, так что чаще всего это MAC).

В ответ все DHCP-серверы, до которых дошел запрос, присылают свои предложения DHCPOFFER тоже широковещательно на MAC-адрес FF:FF:FF:FF:FF:FF. Это происходит в том случае, если желаемый IP НЕ указан (о том, что происходит, когда указан – будет ниже). Клиент из них выбирает наиболее приглянувшееся (чаще всего по принципу «кто раньше прислал – того и тапки»). Сервер же, прежде чем прислать адрес, проверяет (протокол не обязывает, но настоятельно рекомендует), что адрес ещё не занят. В этом сообщении указывается уже предлагаемый IP, предлагаемые параметры и известен адрес-идентификатор сервера.

Подробнее про то, как выглядят остальные сообщения DHCP в Wireshark можно посмотреть в посте из соседней лиги. Или запустить wireshark дома.

Клиент, когда выбрал предложение, посылает DHCPREQUEST тоже широковещательно на MAC-адрес FF:FF:FF:FF:FF:FF, но с идентификатором сервера в соответствующем поле.

Сервер, если ничего криминально не случилось и адрес всё ещё свободен, посылает клиенту (всё так же широковещательно на MAC-адрес FF:FF:FF:FF:FF:FF) DHCPACK с настройками и помечает у себя адрес выданным. Уникальный идентификатор клиента и выданный IP-адрес однозначно идентифицируют DHCP-lease – так называемую аренду IP адреса. Если же адрес в процессе успел стать занятым, то клиенту посылается DHCPNACK с отказом и всё идёт заново.

Клиент получает сообщение DHCPACK с настройками, может сделать финальную проверку на занятость адреса и применяет эти параметры. С этого момента клиент сконфигурирован (и у вас пишется в винде «сеть1: подключено»).

Общая схема еще раз:

Когда клиент заканчивает работу, например, при выключении интерфейса, он посылает серверу сообщение DHCPRELEASE о том, что адрес свободен – можно пользоваться.

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

На самом деле, сколько ни ловила, так такую ситуацию и не поймала. У меня на DHCPDISCOVER с предпочитаемым IP в ответ приходил "Неправильный" DFCPOFFER на конкретный адрес. Подозреваю, что это ловился ipconfig /renew.

Если клиент обнаруживает, что с адресом что-то не в порядке, он посылает серверу DHCPDECLINE.

Немного о времени аренды IP-адреса. Это время в секундах, оно относительно, а потому не требует синхронизации времени между сервером и клиентом. То есть «забрать адрес через 3600 секунд» и без разницы, что у вас локаль Камчатки, а у сервера Москвы. Время аренды надо выбирать сообразно задачам – чтоб и адреса не кончались и слишком большой нагрузки на сервер не было. Интернет-кафе – час, дома – месяц, на работе – неделя, например. А еще есть время, через которое IP-адрес можно перезапросить, не отдавая его. Оно должно быть меньше времени аденды, тогда никто не захапает ваш адрес, пока ваш комп онлайн.

Теперь об опциях. Чаще всего, это DNS сервер, шлюз по умолчанию, ntp-сервер. А может быть куча всего – на это даже отдельный rfc2132 есть. У нас, например, такие.

Бывает еще такая вещь, как резервации (reservations). Это не когда индейцев ограничивают, а когда адрес добавляют к резервированию. Некоторые lease’ы запоминаются (админ указывает, какие именно). То есть, пара MAC-IP становится постоянной. Это позволяет получить статические адреса внутри пула, которые клиенты тем не менее получают по DHCP.

P.S.: Тема очень обширна, можно добавлять и добавлять. Но мне хотелось выдержать баланс между пересказом rfc и "DHCP для домохозяек".