DHCP: откуда устройство берёт настройки сети

Распространённое упрощение — «DHCP раздаёт IP-адреса». Раздаёт, но не только их. В том же ответе приезжает маска подсети, адрес шлюза по умолчанию и адреса DNS-серверов, а при необходимости и более специфические вещи: суффикс домена, адрес сервера времени, параметры загрузки по сети для бездисковых машин.

Фактически это весь набор, который иначе пришлось бы вбивать руками на каждом устройстве. Поэтому неверная настройка DHCP ломает сеть не одним способом, а сразу несколькими: адрес может быть выдан правильный, а шлюз или DNS — нет, и симптомы будут совершенно разные.

Как выглядит каждая поломка

• Неверная маска — часть сети видна, часть нет.

• Неверный шлюз — локальная сеть работает, интернета нет.

• Неверный DNS — по адресам всё доступно, по именам ничего не открывается.

• Адрес из чужого диапазона — устройство не видит вообще никого.

Обмен состоит из четырёх сообщений, и по первым буквам их названий процесс называют DORA. Запомнить порядок полезно: по нему легко понять, на каком этапе всё встало, если смотреть дамп трафика.

• Discover — клиент, у которого ещё нет адреса, кричит на всю сеть: есть тут кто-нибудь, кто раздаёт настройки?

• Offer — сервер отвечает предложением: вот свободный адрес, вот маска, шлюз и DNS.

• Request — клиент подтверждает, что согласен именно на это предложение. Шаг кажется лишним, но он нужен, когда серверов в сети несколько: так остальные понимают, что их предложение отклонено, и возвращают адреса в пул.

• Acknowledge — сервер фиксирует выдачу и запоминает, кому и до какого времени отдал адрес.

Первые два шага идут широковещательно — по-другому и не получится, своего адреса у клиента ещё нет. Работает DHCP поверх UDP: сервер слушает порт 67, клиент — 68.

Граница широковещательного домена

Отсюда важное следствие: DHCP работает только в пределах своего сегмента. Если сервер стоит в другой подсети — например, один общий сервер на весь офис с несколькими VLAN, — нужен DHCP relay на маршрутизаторе. Он принимает широковещательный запрос, подставляет информацию о том, из какой сети тот пришёл, и пересылает серверу обычным адресным пакетом. Сервер по этой пометке понимает, из какого пула выдавать адрес.

Адрес выдаётся во временное пользование, на срок аренды: в домашних сетях это обычно сутки, в гостевых Wi-Fi — час или меньше. Примерно на середине срока клиент сам просит продлить аренду, и в норме продолжает пользоваться тем же адресом месяцами, а то и годами.

Продление идёт уже адресно, без широковещания: клиент знает, с кем говорить. Если сервер не ответил, попытки повторяются, а когда срок истекает совсем — устройство остаётся без адреса и начинает всё заново с Discover.

Как выбирать срок

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

Опасность подстерегает, когда адресов в пуле впритык, а аренда длинная. Устройства приходят и уходят, но их адреса ещё числятся занятыми, и однажды новому ноутбуку выдать нечего — он уходит в 169.254 и не работает. Диагностируется это по заполненности пула на сервере, а лечится либо расширением диапазона, либо сокращением аренды.

Принтеру, сетевому хранилищу или камере нужен постоянный адрес — иначе их придётся каждый раз искать заново. Соблазн прописать адрес руками на самом устройстве велик, но есть вариант лучше: резервирование по MAC на DHCP-сервере. Устройство по-прежнему получает настройки автоматически, но всегда одни и те же.

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

Практическая схема разбивки

Удобный способ навести порядок в небольшой сети — разделить диапазон по назначению. Например, в сети /24: адреса с 1 по 20 — сетевое оборудование, прописанное статически; с 21 по 99 — резервирования для серверов, принтеров и камер; со 100 по 254 — динамический пул для ноутбуков и телефонов. Схема держится в голове без документации, а по адресу сразу понятно, что это за устройство.

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

Симптом характерный и потому узнаваемый: у половины сотрудников всё работает, у половины нет, причём состав этих половин меняется после каждой перезагрузки. Выигрывает тот сервер, который ответил быстрее, а это лотерея.

Как найти виновника

На проблемной машине смотрим, какой сервер выдал адрес: ipconfig /all в Windows покажет строку «DHCP-сервер», в Linux ту же информацию можно найти в журнале службы или в lease-файле. Дальше по этому адресу находим устройство — и по ARP-таблице коммутатора определяем порт, в который оно подключено.

Как предотвратить

Системно лечится функцией DHCP snooping на управляемых коммутаторах: порты делятся на доверенные и недоверенные, и ответы DHCP разрешены только с тех, где сервер действительно стоит. С остальных они молча отбрасываются. Настройка занимает несколько минут и один раз навсегда закрывает целый класс аварий — включая ситуации, когда чужой сервер появляется не по глупости, а намеренно.

Кроме адреса, маски, шлюза и DNS сервер может передать клиенту десятки дополнительных параметров — они пронумерованы и называются опциями. В обычной жизни хватает четырёх базовых, но несколько остальных выручают в конкретных ситуациях.

Самая недооценённая здесь — 121-я. Она позволяет раздать клиентам не только шлюз по умолчанию, но и конкретные маршруты: например, «сеть 10.20.0.0/16 — через 192.168.1.5». Без неё такие маршруты приходится прописывать руками на каждой машине, и рано или поздно кто-то оказывается забыт.

Не все клиенты поддерживают все опции — телевизоры и принтеры обычно игнорируют всё, кроме базового набора. Поэтому на критичные вещи опции лучше не закладывать: то, без чего устройство не заработает, надёжнее настроить явно.

Сервер выдаёт адрес из своего пула, считая его свободным, но в сети уже есть устройство с этим адресом, прописанным вручную. Вежливый клиент перед использованием проверяет адрес ARP-запросом и, обнаружив ответ, отправляет серверу сообщение DHCPDECLINE — мол, этот не подходит, дай другой.

Сервер помечает адрес как проблемный и больше его не предлагает. Механизм полезный, но односторонний: устройство со статическим адресом ни о чём не знает и продолжает работать, а из пула тихо исчезает один адрес за другим.

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