DHCP

Следующий протокол, который мы рассмотрим, -- это DHCP, Dynamic Host Configuration Protocol. Ещё один служебный протокол, необходимый в сетях Ethernet для того, чтобы поверх них нормально работал протокол IP. По названию понятно: протокол, который помогает динамически конфигурировать хосты.

Что умеет DHCP

DHCP умеет раздавать практически всё, что необходимо в современном мире:

• IP-адреса -- вам не нужно вручную настраивать адрес на каждом узле.
• Маска подсети -- мало знать свой IP-адрес, нужно ещё знать маску.
• Адрес шлюза по умолчанию -- для выхода за пределы локальной сети.
• Вспомогательные сервисы -- DNS, WINS, серверы времени NTP, TFTP.
• Почтовые серверы -- SMTP, POP3.
• Домашняя страница -- с какой страницы должна загружаться рабочая станция.
• Параметры стека IP -- TTL по умолчанию, MTU интерфейса.
• Параметры загрузки системы -- откуда грузиться, какой файл выполнить.

Понятное дело, что такие опции нужно, чтобы кто-то умел читать. Выдать опцию вы можете, но будет ли конкретный софт её поддерживать -- вопрос открытый. Тем не менее, в протоколе такая возможность есть.

Пример: MTU интерфейса

Если у вас есть интерфейс, похожий на Ethernet, и вроде бы в него можно отправлять IP-пакеты по полтора килобайта. Но внутри коммутируемой сети есть устройство, которое добавляет дополнительные заголовки. И после этих заголовков пакет проходит через ещё один коммутатор, который тоже пропускает только полтора килобайта. Поэтому вы не должны отправлять IP-пакеты больше, чем, допустим, 1492 байта. Чтобы сказать всем конечным узлам одновременно "не отправляйте IP-пакеты больше 1492 байт", вам поможет опция указания MTU интерфейса.

Зачем нужна автоматизация

Всё, что DHCP делает, можно настроить вручную. Но чем больше узлов и параметров, тем больше вероятность ошибки: где-то ошибиться, где-то недоделать, где-то прокосячить. Ручная настройка большого количества параметров обычно неэффективна.

Управление IP-адресами

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

Вам нужно будет:

• Отслеживать, какие адреса уже выданы
• Изымать адреса из обращения, когда узлы покидают сеть
• Понимать, у кого пора забирать адреса

Самый плохой вариант -- не вести никакой системы учёта вообще. Назначать IP-адреса "от балды" и пытаться угадать: свободен ли 192.168.0.100? Нет? А 200? Пингуется, значит, тоже занят. А 232? Наверно, свободен. Такой подход работает, когда узлов 5--10, но перестаёт работать в корпоративной сети.

IPAM -- системы учёта адресов

IPAM (IP Address Management) -- системы учёта адресов. Начинаются обычно с Excel, но дальше заканчиваются специализированным продуктом. В Windows Server 2012 появилась штатная роль IPAM, которая умеет собирать информацию с DHCP-сервера, DNS-сервера и других источников.

Но все эти системы ведутся руками и достаточно дороги в обращении -- не потому что за них нужно платить, а потому что бардак ведёт к трате времени на разбирательства.

Было бы здорово иметь систему, которая сама, без вашего участия, заведует всеми IP-адресами: выдаёт, когда нужно, и забирает, когда не нужно. Протокол DHCP как раз решает эту задачу.

История протокола

DHCP является логическим развитием протокола BootP и обратно совместим с ним. Формат сообщения DHCP -- это фактически формат BootP. DHCP-сообщения -- это BootP-сообщения, просто по-другому трактуемые. Во многих случаях вы передаёте лишние данные именно для обеспечения обратной совместимости.

BootP, в свою очередь, развился как логическое продолжение протокола RARP (Reverse ARP). BootP и RARP не совместимы между собой -- они решали одну и ту же задачу (получить IP из MAC-адреса), но BootP использовал принципиально другие сообщения.

DHCP оброс такой штукой, как опции -- и именно они позволили DHCP "взлететь".

Три механизма выдачи адресов

Все адреса в DHCP выдаются на время, то есть даются в аренду (lease). Клиент теоретически должен вернуть адрес через определённое время. Но то, что адреса выдаются в аренду, не означает, что они всегда будут разные.

Есть три разных механизма, как DHCP может выдавать адреса.

1. Динамическое распределение (Dynamic)

Самый известный и популярный механизм. Есть пул свободных IP-адресов. Клиент приходит, просит адрес -- сервер выдаёт свободный из пула. Когда адрес больше не нужен, сервер забирает его обратно. При этом совершенно не факт, что адрес будет одинаковым: сегодня вам дали один, завтра -- другой.

2. Ручное размещение (Manual / Static)

Администратор привязывает конкретный MAC-адрес к конкретному IP-адресу. Например, принт-сервер с MAC 00:01:02:03:04:05 всегда получает один и тот же IP. Этот адрес больше никому не выдаётся.

3. Автоматическое размещение (Automatic)

Когда приходит новый незнакомый клиент, ему выдаётся IP из пула, после чего он становится "знакомым" -- и привязка запоминается в базе.

Клиент не знает, каким механизмом ему выбран адрес. Он просто говорит "дай адрес", а сервер выдаёт. Независимо от механизма, адрес всегда выдаётся на определённое время.

Транспорт DHCP

DHCP использует вложение в UDP, который вкладывается в IP.

• Порт 67 -- серверный порт
• Порт 68 -- клиентский порт

Специальные IP-адреса:

Адрес	Назначение
0.0.0.0	Адрес источника, когда клиент ещё не знает свой адрес
255.255.255.255	Local broadcast -- широковещательная рассылка в пределах канала

DHCP broadcast, как и ARP, не проходит через маршрутизаторы. Но в отличие от ARP, DHCP вкладывается в IP, поэтому теоретически можно заставить роутеры перекладывать пакеты из одной канальной среды в другую (через DHCP Relay).

Процедура получения адреса (DORA)

Основные сообщения DHCP:

Сообщение	Направление	Описание
DHCP Discover	Клиент -> Broadcast	Клиент ищет серверы: "Дайте адрес!"
DHCP Offer	Сервер -> Broadcast	Сервер предлагает адрес
DHCP Request	Клиент -> Broadcast	Клиент выбирает предложение
DHCP ACK	Сервер -> Broadcast	Сервер подтверждает аренду

Все четыре сообщения посылаются broadcast:

• Discover -- broadcast, потому что непонятно, куда слать.
• Offer и Request -- broadcast, чтобы все серверы слышали о предложениях друг друга.
• Если серверов несколько, каждый предлагает свой Offer и помечает адрес как "возможно занятый". Клиент выбирает одно предложение, остальные серверы помечают свои адреса обратно как свободные.

В Discover клиент может указать пожелания -- например, адрес, который был у него в прошлый раз.

Вместе с ACK идёт финальное согласование опций: маска подсети, NTP-серверы и всё остальное, что клиент и сервер договорились использовать.

Другие сообщения

• DHCP NAK -- явное несогласие с клиентским запросом. Клиент обязан прекратить использование адреса и пройти всю процедуру заново.
• DHCP Release -- клиент досрочно освобождает адрес.
• DHCP Force Renew -- сервер принудительно заставляет клиента продлить аренду (на практике в большинстве реализаций не поддерживается).

Время аренды и таймеры

Все адреса передаются в аренду -- даже статические (зарезервированные). Время аренды обозначается буквой T.

Таймер T1 (Renewal Time)

• Равен T/2 (половина срока аренды)
• Через это время клиент начинает unicast-запросами продлевать аренду у своего сервера
• Продление: клиент посылает DHCP Request напрямую серверу (минуя Discover/Offer)
• При успехе -- время T отсчитывается заново

Попытки продления

Если сервер не отвечает на T1, клиент продолжает попытки каждый раз после половины оставшегося срока:

1. T/2 -- первая попытка (unicast)
2. 3T/4 -- вторая попытка (unicast)
3. 7T/8 -- третья попытка (unicast), далее переход к T2

Таймер T2 (Rebinding Time)

• Равен 7T/8
• После этого момента клиент переключается на broadcast -- кричит на всю сеть, вдруг другой сервер сможет подтвердить аренду
• Если даже broadcast не помог -- клиент сдаётся и обязан пройти полную процедуру DORA заново

Досрочное прекращение аренды

Клиент может послать DHCP Release, чтобы сервер знал -- адрес больше не нужен и его можно выдать другому.

Сервер тоже может принудительно отобрать адрес: посылает DHCP Force Renew, клиент отвечает Request, а сервер отправляет DHCP NAK. Но на практике Force Renew в большинстве реализаций отсутствует.

Формат DHCP-пакета

Формат пакета -- наследие BootP, содержит много полей:

Поле	Размер	Описание
Op	1 байт	Тип операции: 1 -- BootRequest, 2 -- BootReply
HType	1 байт	Тип аппаратного адреса (1 = Ethernet)
HLen	1 байт	Длина аппаратного адреса (6 для MAC)
Hops	1 байт	Количество relay-агентов
XID	4 байта	Идентификатор транзакции (случайное число)
Secs	2 байта	Секунды с начала получения адреса (обычно 0)
Flags	2 байта	Флаги (в т.ч. broadcast)
CIAddr	4 байта	Client IP -- заполняется при продлении аренды
YIAddr	4 байта	Your IP -- адрес, предлагаемый сервером
SIAddr	4 байта	Server IP
GIAddr	4 байта	Gateway/Relay Agent IP
CHAddr	16 байт	Аппаратный адрес клиента (MAC + padding)
SName	64 байта	Имя сервера (null-terminated строка)
File	128 байт	Имя файла для удалённой загрузки
Options	переменная	Опции, начинаются с Magic Cookie

Поле CHAddr -- 16-байтовое для совместимости с BootP. MAC-адрес занимает 6 байт, остальные 10 забиваются нулями. Для определения реальной длины используется поле HLen.

Magic Cookie

Поле опций всегда начинается с Magic Cookie -- числа 0x63825363. Любой DHCP-пакет с опциями начинается с этого значения.

Размер поля опций ограничен размером IP-пакета. Для совместимости со старыми PPP-соединениями (MTU 576 байт) на опции приходится порядка 340 байт. Обычно этого достаточно.

Основные опции DHCP

Код	Название	Описание
1	Subnet Mask	Маска подсети, 4 байта
3	Router	Шлюз по умолчанию. Можно указать несколько (кратно 4 байтам), первый -- наивысший приоритет
6	DNS Servers	Адреса DNS-серверов, кратно 4 байтам
12	Hostname	Имя хоста клиента (null-terminated строка)
23	Default TTL	TTL по умолчанию для IP-пакетов
26	Interface MTU	MTU интерфейса
33	Static Routes	Статические маршруты (классовые, устаревшая; в бесклассовом мире -- маршрут на /32 хост + шлюз, 8 байт)
35	ARP Cache Timeout	Время жизни кэша ARP
50	Requested IP Address	Запрашиваемый клиентом адрес
51	Lease Time	Время аренды (T)
55	Parameter Request List	Список опций, которые клиент поддерживает и хочет получить
58	Renewal Time (T1)	Время до первой попытки продления
59	Rebinding Time (T2)	Время до начала broadcast-продления
61	Client Identifier	Идентификатор клиента (FQDN, имя машины и т.д.)
66	TFTP Server Name	DNS-имя TFTP-сервера для загрузки
121	Classless Static Routes	Бесклассовые маршруты (замена опции 33)
150	TFTP Server Address	IP-адрес TFTP-сервера для загрузки
255	End	Конец списка опций

Опции 66 и 150: загрузка с TFTP

Особенно полезны для IP-телефонов, которые загружаются с TFTP-сервера. Вы указываете адрес Call Manager, и телефоны тянут с него конфигурацию и прошивку.

• Опция 150 -- IP-адрес сервера (надёжный вариант)
• Опция 66 -- DNS-имя сервера (требует работающий DNS)

Имя файла для загрузки в этих опциях не указывается -- клиент (телефон) сам знает, какой файл ему нужен.

Опция 82: информация от relay-агента

Опция 82 добавляется агентом ретрансляции (relay agent) и содержит:

• Circuit ID -- номер порта, с которого пришёл запрос
• Remote ID -- идентификатор самого relay-агента (например, MAC коммутатора)

Особенно полезна для провайдеров. Пример: в жилом доме стоит коммутатор, каждый порт -- отдельная квартира. Клиент кричит "дайте адрес", коммутатор запоминает номер порта, оборачивает запрос в unicast и отправляет на центральный DHCP-сервер. Сервер проверяет по биллингу: если Вася Петечкин не заплатил -- выдаёт ему адрес с маршрутом только на страницу "заплати деньги".

Безопасность DHCP

Аутентификация

В 2001 году была предложена опция DHCP Authentication, которая не позволяла неавторизованным серверам выдавать адреса. Но опция не взлетела: она была сложной в реализации и требовала ручной настройки на клиентах. Смысл в автоматическом протоколе, который требует ручной настройки, -- никакой.

Несколько серверов в сети

Если вы штатно размещаете два сервера, есть два подхода:

1. Непересекающиеся диапазоны. Левый сервер раздаёт первую половину адресов, правый -- вторую. Можно подшаманить задержкой: один сервер отвечает сразу, другой -- через 0.1 секунды.

2. Синхронизация базы. Оба сервера раздают один диапазон, но синхронизируют состояние между собой. В Windows Server 2012 появилась возможность настроить два сервера с общей базой. До этого требовался полноценный кластер с общей дисковой полкой -- дорого и неудобно.

Ложный DHCP-сервер (Rogue DHCP)

Типичная ситуация: сотрудник приносит из дома домашний роутер, подключает LAN-порт к корпоративной сети -- и этот роутер начинает раздавать адреса из своего пула вместо правильных корпоративных.

Механизма на уровне протокола для защиты от этого нет. Варианты:

• Ручной поиск: найти узел с неправильным адресом, посмотреть адрес сервера, определить MAC, отследить порт коммутатора.
• DHCP Snooping -- функция коммутатора, при которой он отслеживает DHCP-трафик. Порты делятся на "доверенные" (trusted) -- откуда могут приходить Offer -- и "недоверенные". Offer с недоверенного порта сбрасывается, а администратору отправляется уведомление. Оборудование с такой поддержкой стоит дороже, но, например, Cisco 2960 это уже умеет.

Атака на истощение пула (DHCP Starvation)

Атакующий посылает множество DHCP-запросов с разными идентификаторами, исчерпывая пул адресов. Защита -- коммутатор отслеживает количество DHCP-запросов с порта. Если больше определённого порога (например, 10 пакетов в секунду) -- блокирует запросы или порт целиком.

Рекомендации по времени аренды

Корпоративная сеть -- длинный срок

Сотрудник может уйти в отпуск на месяц. Если срок аренды истечёт за это время, его адрес может быть выдан другому. Рекомендация: срок аренды больше максимального периода неактивности (например, 2 месяца).

Также важно, чтобы DHCP-сервер не забывал свою базу при перезагрузке. Windows Server хранит базу в MDB-файле и не теряет данные. Если же сервер -- это Cisco-роутер, после сброса питания он забудет все выданные адреса.

Для машин, которым обязательно нужен постоянный адрес, лучше использовать ручное размещение (резервирование по MAC или клиентскому идентификатору).

Гостевая сеть -- короткий срок

В кафе, переговорках, публичных зонах люди приходят на 15--60 минут. Рекомендация: срок аренды 15 минут. Клиент несколько раз продлит аренду и ничего не заметит, а после ухода адрес быстро вернётся в пул.

DHCP Relay (агент ретрансляции)

Когда клиент и сервер находятся в разных канальных средах, используется DHCP Relay (агент ретрансляции):

1. Клиент посылает Discover broadcast
2. Relay-агент (роутер) принимает broadcast, возможно добавляет опцию 82, и пересылает unicast на известный ему DHCP-сервер
3. Сервер отвечает Offer unicast на relay
4. Relay транслирует Offer broadcast в сторону клиента
5. Клиент посылает Request broadcast
6. Relay перепаковывает в unicast, отправляет серверу
7. Сервер отвечает ACK unicast
8. Relay транслирует ACK broadcast клиенту

Где используется

• Провайдерские сети -- основной сценарий. Кастомный DHCP-сервер завязан на биллинг, стоит в офисе провайдера. Делать много серверов или протаскивать транки неудобно.
• Корпоративные сети -- нужен редко. Обычно проще поднять пул адресов прямо на маршрутизаторе в каждом VLAN.

DHCP-сервер на роутере

Типичная ситуация для небольших компаний и домашних сетей -- роутер одновременно является DHCP-сервером. Логика: без роутера сеть не работает, поэтому нет смысла разделять точки отказа. Домашний D-Link DIR-300 -- он же и DHCP-сервер.

Технически можно выстроить цепочку из нескольких relay, но на практике в этом нет необходимости -- одного посредника, который из broadcast делает unicast, всегда достаточно.

Демонстрация в Wireshark

DHCP Discover

Клиент отправляет запрос из-под порта 68 на порт 67:

• Op: 1 (Request)
• HType: 1 (Ethernet)
• HLen: 6 байт
• Hops: 0
• XID: случайное число (например, 0x01B7)
• Secs: 0
• CIAddr: 0.0.0.0 (адреса ещё нет)
• YIAddr: 0.0.0.0
• CHAddr: MAC-адрес клиента + 10 байт padding
• Magic Cookie: 0x63825363
• Опции: тип сообщения (Discover), максимальный размер DHCP-сообщения, клиентский идентификатор, hostname, список запрашиваемых опций (маска, DNS, шлюз, маршруты, TFTP и др.)

Проверка сервером

Перед отправкой Offer сервер проверяет: свободен ли адрес на самом деле? Он посылает ARP-запрос с адресом, который собирается предложить. Если ответа нет -- адрес действительно свободен.

DHCP Offer

Сервер предлагает адрес:

• YIAddr: предлагаемый адрес (например, 10.0.0.5)
• Lease Time (T): 86400 секунд (1 сутки)
• Renewal Time (T1): 43200 секунд (12 часов)
• Rebinding Time (T2): 75600 секунд (21 час)
• Опции: маска подсети 255.255.255.0, статические маршруты (опция 33), и другие запрошенные

Сервер не обязан отдавать все запрошенные опции. Если опции у него нет -- он молча её игнорирует.

DHCP Request и ACK

Клиент подтверждает выбор: указывает идентификатор сервера (10.0.0.1) и запрашиваемый адрес (10.0.0.5). Сервер отвечает ACK -- адрес зафиксирован.

Gratuitous ARP после получения адреса

После получения ACK клиент на всякий случай проверяет адрес -- посылает Gratuitous ARP с полученным IP. Если никто не возражает, клиент начинает использовать адрес. Gratuitous ARP отправляется дважды и заодно обновляет ARP-кэш у всех остальных узлов.

Затем клиент посылает обычный ARP-запрос: "кто такой 10.0.0.1?" -- чтобы заполнить свой ARP-кэш записью о сервере (ведь всё предыдущее взаимодействие шло через broadcast).

Заключение

DHCP и ARP -- два очень полезных протокола, которые позволяют нормально существовать в сети без ручной настройки всех узлов. Без них количество необходимых настроек растёт квадратично: для 100 узлов нужно было бы прописать порядка 10 000 связей вручную. DHCP + ARP автоматизируют всё это настолько, что мы даже не замечаем, как они работают.