Блог ДоверьсяСервису

DHCP: как сервер выдает IP-адрес клиенту

DHCP автоматически передает устройству сетевые параметры: IP-адрес, маску подсети, адрес маршрутизатора, DNS-серверы и срок аренды. Без него каждый ноутбук, телефон или виртуальную машину пришлось бы настраивать вручную. Протокол упрощает подключение, но требует правильно рассчитанного пула, доверенной сетевой инфраструктуры и контроля конфликтов.

02.09.2026 Обновлено 02.09.2026 10 мин чтения Редакция ДоверьсяСервису

Коротко: DHCP-сервер не «дарит» адрес навсегда. Он создает привязку параметров к клиенту на ограниченный срок lease, а клиент периодически продлевает аренду или получает новую конфигурацию.

Что такое DHCP

Dynamic Host Configuration Protocol работает по модели клиент — сервер. Клиент запрашивает конфигурацию, сервер выбирает допустимый адрес и возвращает параметры для конкретной сети. DHCPv4 определен в RFC 2131, а набор базовых options — в RFC 2132.

DHCP выделяет адрес и доставляет параметры. Для доступа в другие сети и по именам клиенту также нужны корректные mask, default gateway и DNS.

Кто участвует в обмене

Участник	Роль	Где находится
DHCP client	Запрашивает и применяет параметры	Компьютер, телефон, принтер, VM
DHCP server	Управляет пулами, арендой и options	Маршрутизатор, сервер или managed service
DHCP relay	Передает сообщения между сегментами	Обычно L3-интерфейс или маршрутизатор
Network administrator	Определяет scope, exclusions и policy	Система управления инфраструктурой

Сервер выбирает адрес для локального сегмента или для подсети, указанной relay. Поэтому один центральный узел может обслуживать несколько VLAN.

Как работает DORA

DORA — четыре сообщения DHCPv4: Discover, Offer, Request, Acknowledgement. Так начинается работа клиента без действующей аренды.

DHCPDISCOVER: клиент ищет доступные серверы.
DHCPOFFER: сервер предлагает адрес, lease и options.
DHCPREQUEST: клиент сообщает, какое предложение выбрал.
DHCPACK: выбранный сервер подтверждает аренду и параметры.

Если сервер отклоняет запрос, он может вернуть DHCPNAK. Клиент способен отправить DHCPDECLINE, обнаружив занятость предложенного адреса, и DHCPRELEASE, когда добровольно освобождает аренду. Реальный обмен определяется текущим состоянием клиента, поэтому не каждый renewal проходит все четыре шага.

Почему первые сообщения широковещательные

Новый DHCPv4-клиент еще не знает свой адрес и адрес сервера. Обычно он отправляет сообщение с UDP-порта 68 на порт 67, используя исходный адрес 0.0.0.0 и broadcast. Ответ тоже может прийти широковещательно, пока IP-стек клиента не готов принять unicast.

Маршрутизаторы не пересылают broadcast между подсетями. Удаленному серверу нужен DHCP relay: открытие UDP-портов не заменяет пересылку.

Что находится в DHCP-ответе

Параметр	Пример	Зачем нужен
IP address	`10.20.30.77`	Адрес интерфейса в подсети
Subnet mask	`255.255.255.0`	Граница локальной сети
Router	`10.20.30.1`	Маршрут по умолчанию
DNS servers	`10.20.0.53`	Разрешение имен
Lease time	8 часов	Срок использования binding
Server identifier	Адрес сервера	Выбор и идентификация предложения
T1 и T2	Таймеры renewal/rebinding	Моменты повторных попыток

Options также передают domain suffix, classless routes и служебные параметры. Клиент запрашивает нужные значения, а сервер применяет свою policy.

Scope, pool и exclusion

Scope описывает обслуживаемую подсеть и ее параметры. Pool — диапазон адресов для динамической выдачи. Exclusion исключает адреса инфраструктуры, статических устройств или другой системы распределения.

Диапазон должен принадлежать нужной подсети и не включать network address, broadcast address, gateway и статически настроенные узлы. Пересекающиеся scopes двух независимых серверов создают риск двойной выдачи.

Расчет пула адресов

Мини-калькулятор для сети /24

В сети 10.20.30.0/24 доступны адреса .1–.254. Пусть .1–.49 заняты gateway и инфраструктурой, а .241–.254 оставлены под статические узлы. Динамический pool .50–.240 содержит 191 адрес: 240 − 50 + 1.

Для пика в 130 одновременно подключенных клиентов применим запас 30%: 130 × 1,3 = 169. Пул из 191 адреса подходит, остаются 22 свободных. Считать нужно одновременные устройства, включая телефоны, гостевые клиенты, VM и аренды, которые еще не истекли.

Аренда, T1 и T2

Lease ограничивает время действия binding. Пока сервер доступен, клиент обычно пытается продлить аренду в момент T1 прямым DHCPREQUEST исходному серверу. Если это не удалось, после T2 он переходит к rebinding и ищет любой сервер широковещательно.

Если сервер не передал отдельные значения, RFC 2131 задает расчетные defaults: T1 — половина lease, T2 — 87,5%. По окончании аренды клиент не должен продолжать использовать адрес как действующий. Короткий lease быстрее возвращает адреса, но увеличивает обмен; длинный — снижает нагрузку, но удерживает ушедшие устройства.

Как выбрать срок аренды

Сценарий	Логика выбора	Риск
Гостевой Wi-Fi	Клиенты быстро меняются, lease короче	Слишком короткий срок увеличит запросы
Офисные рабочие места	Устройства возвращаются регулярно	Слишком длинный lease задержит освобождение
Принтеры и оборудование	Нужен предсказуемый адрес или reservation	Динамическое изменение нарушит зависимости
Аварийное уменьшение pool	Сначала сократить lease и дождаться старого	Мгновенное сжатие создаст конфликты

Универсального значения нет. Выбор зависит от емкости пула, churn, времени недоступности сервера и требований к стабильности. Контролируйте фактический peak utilization, а не только число созданных reservations.

Dynamic, automatic и manual allocation

RFC 2131 различает динамическую выдачу на срок, автоматическое постоянное и ручное назначение сервером. Reservation связывает адрес с client identifier или hardware address, но продолжает передавать gateway, DNS и другие options через DHCP.

Идентификатор клиента и MAC-адрес

Сервер сопоставляет запрос по client identifier, hardware address и правилам реализации. MAC не всегда единственный ключ: смена адаптера или приватизация адреса способны создать новую идентичность.

Перед reservation сначала посмотрите фактический identifier в lease и журнале. Дублирующиеся client identifiers нарушают корректное сопоставление, а перенос записи «по памяти» может закрепить адрес не за тем интерфейсом.

DHCP relay между VLAN

Relay принимает локальное сообщение клиента и пересылает его серверу. В DHCPv4 поле giaddr помогает серверу выбрать scope. Option 82 может добавить circuit ID и remote ID от доверенного сетевого устройства.

Relay настраивают на каждом клиентском L3-интерфейсе, а обратный путь и firewall проверяют в обе стороны. Option 82 имеет смысл только при определенной trust boundary: RFC 3046 прямо предполагает доверенную инфраструктуру между relay и сервером.

Несколько серверов и отказоустойчивость

Клиент может получить несколько offers и выбрать одно. Но два сервера не становятся согласованным кластером автоматически. Без общего состояния или разделенных диапазонов они способны предложить один адрес разным клиентам.

Failover, load balancing и replication зависят от реализации. Документируйте ownership каждого адреса, время синхронизации, поведение при потере связи между узлами и процедуру возврата. Проверка «оба процесса запущены» не подтверждает отсутствие split brain.

DHCP и DNS

DHCP может передать адреса DNS-серверов и domain suffix, но сам не разрешает имена. Некоторые системы интегрируют lease с динамическим обновлением прямых и обратных DNS-записей. Владелец обновления, credentials и очистка записей должны быть заданы явно.

Старая DNS-запись после истечения аренды может указывать на адрес уже другого клиента. Для важных систем согласуйте lease, DNS TTL, aging и scavenging; не публикуйте имя только потому, что адрес появился в таблице аренды.

DHCPv6 и SLAAC

DHCPv6 описан в RFC 8415 и отличается от DHCPv4 сообщениями и устройством протокола. Он может назначать IPv6-адреса и prefixes statefully либо передавать параметры без выдачи адреса. Клиент использует UDP 546, сервер и relay — UDP 547.

IPv6-узел может получать адрес через SLAAC, DHCPv6 или их сочетание. Default router сообщает Router Advertisement, а не DHCPv6. Поэтому наличие DHCPv6-сервера не исправляет отсутствующие или неверные RA.

DHCP в облачной сети

В virtual network выдача адресов часто встроена в платформу, а пользователь управляет subnet, route, DNS и параметрами интерфейса через control plane. Нельзя переносить настройки физического relay или DHCP failover без проверки модели облака.

Карточки Yandex Cloud и Selectel дают отправные точки для знакомства с облачными платформами. Возможность задать собственный DHCP, reservation, DNS, static address и route подтверждайте по актуальной документации выбранной сети.

Rogue DHCP и атаки на пул

Несанкционированный сервер может отвечать быстрее легитимного и выдавать ложный gateway или DNS. DHCP starvation создает множество запросов, пытаясь исчерпать pool. Базовый DHCPv4 не следует считать механизмом строгой аутентификации клиента и сервера.

Защита строится на контроле доступа к сети, DHCP snooping, trusted/untrusted ports, rate limits, port security, segmentation и мониторинге неожиданных server identifiers. Названия и поведение функций различаются у коммутаторов.

Категория безопасности и инфраструктуры помогает увидеть смежные классы решений. Сам каталог не заменяет схему trust boundaries, проверку поддержки snooping и тестирование конкретной модели оборудования.

Как диагностировать DHCP

Маршрут из восьми проверок

Убедитесь, что интерфейс поднят и выбран режим автоматической конфигурации.
Зафиксируйте адрес, mask, gateway, DNS, lease, server ID и время получения.
Проверьте емкость и exclusions нужного scope.
Найдите Discover/Request клиента и Offer/Ack сервера в журнале или capture.
Для другой VLAN проверьте relay, giaddr, ACL и обратный маршрут.
Сравните client identifier с reservation и существующей арендой.
Исключите второй сервер и конфликт статического адреса.
После исправления обновите lease и повторно проверьте связность и DNS.

В Windows полезен полный вывод ipconfig /all; в Linux — состояние адресов, маршрутов и используемого network manager. В capture для DHCPv4 фильтруют UDP 67/68. Сначала сохраняйте исходный обмен, затем очищайте lease: иначе исчезает причина отказа.

Что означает адрес 169.254.x.x

Некоторые IPv4-клиенты при отсутствии другой конфигурации выбирают link-local адрес из 169.254.0.0/16. Он позволяет ограниченную связь в локальном сегменте, но не подтверждает доступность DHCP и обычно не маршрутизируется как корпоративный адрес.

Проверяйте VLAN, Wi-Fi, кабель, relay, firewall, pool и сервер. Случайный ручной адрес может создать конфликт и скрыть проблему.

План изменения DHCP

Экспортируйте scopes, options, reservations и активные leases.
Найдите статические адреса внутри будущего pool.
Рассчитайте емкость и запас по фактическому пику.
Снизьте lease заранее, если меняете subnet или диапазон.
Подготовьте server, relay, routes, ACL и monitoring.
Проверьте тестовый VLAN и полный DORA.
Переключайте сегменты поэтапно с rollback.
После старого lease удалите прежний scope и верните целевой срок.

Типичные ошибки

включать gateway или статические серверы в динамический pool;
создавать пересекающиеся scopes;
забывать relay для отдельного VLAN;
блокировать ответ сервера межсетевым экраном;
надеяться, что два независимых сервера сами разделят аренды;
считать reservation ручным статическим адресом;
привязывать reservation не к фактическому client identifier;
выдавать неверный gateway или DNS через option;
уменьшать pool до истечения старых leases;
не учитывать гостевые устройства и VM в capacity;
разрешать ответы DHCP с пользовательских портов;
путать DHCPv6 с Router Advertisement;
очищать lease до сохранения журналов и packet capture.

Чек-лист эксплуатации

scope соответствует subnet и не пересекается с другими;
pool имеет запас относительно peak utilization;
gateway, DNS и routes проверены на тестовом клиенте;
exclusions и reservations документированы;
lease соответствует churn и емкости;
relay настроен на всех нужных VLAN;
failover не выдает одинаковые адреса;
snooping trust задан только инфраструктурным портам;
журналы связывают время, client ID, address и server ID;
есть alerts по заполнению pool и отказам выдачи;
DHCPv6 и RA проверены независимо;
резервная копия конфигурации и rollback актуальны.

Частые вопросы

Меняется ли IP после каждого подключения?

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

Что лучше для принтера: static или reservation?

Reservation часто удобнее: адрес предсказуем, а gateway и DNS управляются централизованно. Ручной static подходит при осознанной схеме, но его нужно исключить из pool и документировать.

Работает ли DHCP через маршрутизатор?

Широковещательный запрос сам по себе обычно не проходит в другую подсеть. Настроенный relay принимает его в клиентском сегменте и пересылает известному серверу.

Можно ли использовать DHCP для серверов?

Можно, если платформа и зависимости рассчитаны на reservation либо управляемую адресацию. Для критичного узла важно гарантировать предсказуемость адреса, доступность DHCP и корректное восстановление после сбоя.

Почему адрес получен, а интернет не работает?

DHCPACK подтверждает конфигурацию, но не доступность gateway, DNS, NAT, firewall или внешнего канала. Проверяйте последовательно локальный адрес, маршрут, gateway, удаленный IP и разрешение имени.

Итог

Надежный DHCP — это не только запущенный server process. Нужны непересекающийся scope, достаточный pool, понятные leases, корректные options, relay для каждой подсети, защита от посторонних ответов и журналирование binding. Если фиксировать DORA по шагам и считать емкость до изменений, большинство проблем с автоматической адресацией локализуются без случайной ручной настройки клиентов.

Редакция ДоверьсяСервису

Эксперты по онлайн-сервисам. Команда проекта проверяет материалы о сервисах, тарифах и задачах, обновляет данные и помогает сравнивать сервисы по фактам.