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 для домохозяек".

DHCP
Вы проснулись после дикой пьянки. Первые ваши слова «кто я?» и «где я?». Сосед, который не запивал водку пивом, вам сообщает все ваши параметры: кто вы и где. Этот сосед выступает в роли DHCP-сервера. Учтите, что в сети могут быть так называемые «ложные DHCP-сервера», например жена – на ваш вопрос «кто я?» она выдаст неверную информацию: «алкоголик ты проклятый». Так что не всегда динамическая выдача параметров безопасна, рекомендуется записывать свои параметры (как зовут, ваш адрес и т.д.) на бумажке.

Маршрут по умолчанию
Подойтите к прохожему и спросите «не подскажите ли вы как пройти к моргу имени Невмировича-Данченко?». С большой долей вероятности вас пошлют на три буквы. Так вот это и есть маршрут по умолчанию, другими словами если адрес назначения не известен, то пакеты посылаются на маршрут по умолчанию (синонимы: шлюз по умолчанию, dafault gateway).

Понятие TTL
Представьте себе, что вам 5 лет и вы хотите кушать. Вы идете к папе и говорите: «Папа, я хочу кушать». Ваш папа смотрит телевизор, согласно таблице маршрутизации о посылает вас к маме. Вы идете к ней и просите «Мамааа, я хочу кушать». Мама болтает с подругой по телефону и согласно своей таблице маршрутизации посылает вас к папе. И так вы ходите как дурак от папы к маме и обратно, туда-сюда, туда-сюда, а все потому что криворукие админы (родители папы и мамы) неправильно настроили таблицу маршрутизации. Чтобы защититься от таких ситуаций придумали понятие TTL (Time To Live), что применительно к нашей ситуации означает количество терпения у мальчика, пока он не скажет «заколебало» и не упадет перед ногами мамы или папы в беспомощном состоянии. Последний, по правилам (стандарты – это «так заведено в семье»), обязан послать короткий нелестный отзыв адрес того, кто послал мальчика кушать. Это так называемый icmp-пакет «мальчик издох»

Ping
Вы конечно бывали в ситуации «сам дурак». Вы кричите «Петя ты, мудак», а в ответ слышите «Вася, сам мудак». Это простеший пинг. Вы только что пропинговали Васю. Не все отвечают на пинги, особо культурные, например Microsoft. com не утруждают себя реагированием на ваши запросы. С такими переругиваться бесполезно, мы знаем, что они слышат и злятся, но реакции добиться не можем. Тем не менее, пинг – неплохой способ узнать жив ли хост, ведь пиная труп ногами не добьешься реакции «сам дурак»

Traceroute
Представь себе, что ты живешь на 9м этаже и хочешь узнать всех жильцов которые живут от тебя до Клавки с 3го. Ты берешь взрывпакет и, исходя из формулы свободного падения, рассчитываешь время взрыва пакета над 8м этажом. Это TTL=1. После того как пакет взорвется - выглянет озверевшая рожа соседа с 8го этажа. Время реакции зависит от загруженности сервера, т.е. от занятости соседа и от шейпов, т.е. в воздухе ли ваша система или ты живешь на планете, где атмосфера жидкий азот. Так вот, если вообще не дождешься ответа - твой сосед глухой - у него запрещены icmp ответы, либо он запретил их только для тебя если его уже заколебали твои финты и он научился тебя игнорировать. Дальше выставляешь TTL=2 и т.д. Не забывай, что если Клавка живет выше тебя – это No route to host

DNS
Представь, что на дворе 17й год, ты - вождь мирового пролетариат и тебе нужно срочно попасть в одно место. Ты поднимаешь трубку и начинаешь орать "Але, багышня, багышня, мне Смольный!" Если ты слышишь, как "багышня" начинает орать: "Дуськ, а Дуськ? Опять этот мудак картавый звонит! Где эта су... Лизавета Павловна... Смольный на ейном участке?" Это рекурсивный ДНС- сервер. Если она молча передает трубку Дуське, а та, выслушав тебя, Лизавете Павловне - сервер нерекурсивный.