L3 DHCP — автоматическая адресация, relay и защита

Раздать вручную адреса двумстам ноутбукам — безумие. Этим занимается DHCP: хост включился, «крикнул» в сеть — и через долю секунды у него есть адрес, маска, шлюз и DNS. Пока всё работает, DHCP невидим. Но стоит ему сломаться — и половина офиса ловит загадочный 169.254.x.x, «интернета нет», а причина не там, где её ищут. Это тема CCNA, ежедневная работа инженера СПД и любимый источник «мистических» аварий — разберём до последнего пакета.

Что узнаешь

Как хост получает адрес: четыре сообщения DORA по шагам, с портами и broadcast
Что именно выдаёт DHCP кроме адреса — и что такое опции (шлюз, DNS, lease, option 66/150)
Аренда: таймеры T1/T2, renew, rebind, expiry — почему адрес «сам меняется»
DHCP relay (ip helper-address) — как сервер обслуживает десятки подсетей из одной точки
Резервирование по MAC, исключения, пулы — и полный конфиг на Cisco + чтение show ip dhcp binding
Безопасность: rogue DHCP, starvation-атака, DHCP snooping и связка с DAI
IPv6: чем SLAAC отличается от DHCPv6 — обзорно
Плейбук «клиент не получает адрес» и мини-лаба на своём компьютере

Вспомни из прошлых модулей

Модуль 4: адрес, маска, шлюз, диапазон хостов и 169.254.0.0/16 (APIPA) — сегодня увидишь, откуда этот адрес берётся на практике. Модуль 2: broadcast и ARP — DHCP целиком стоит на broadcast, и именно поэтому он не проходит через роутер без relay. Модуль 3: VLAN и «один broadcast-домен» — DHCP работает в пределах домена, а между VLAN его «переносит» relay. Если что-то подзабылось — вернись, этот урок опирается на всё сразу.

1. Заявка: «новый филиал — раздать адреса»

Понедельник, ты дежуришь. Прилетает заявка:

Заявка №61207

«Открыли филиал на 120 рабочих мест. Сеть 10.20.5.0/24, шлюз 10.20.5.1. Нужно, чтобы ноутбуки и телефоны получали адреса сами. DHCP-сервер у нас централизованный в ЦОД (10.0.0.53). Настройте и проверьте».

Что здесь зашито? Во-первых, никто не будет ходить по 120 машинам и вбивать адреса руками — нужен автоматический механизм. Во-вторых, сервер стоит в другой подсети (10.0.0.53), а DHCP работает broadcast'ом, который туда не долетит, — значит, понадобится relay. К концу урока ты закроешь эту заявку двумя строками конфига и проверишь результат командой. А пока — с самого начала.

2. Зачем нужен DHCP

Каждому устройству в сети нужны минимум четыре вещи, чтобы работать: IP-адрес, маска, шлюз и DNS-сервер (модуль 4). Есть два способа их получить:

✍️ Статика (руками)

Инженер вбивает адрес на каждом устройстве
Адрес не меняется никогда — это критично для серверов, роутеров, стыков
Цена: 120 машин × ручной труд; ошибся в одном символе — устройство «пропало»
Дубликат адреса при невнимательности — конфликт и хаос

🤖 DHCP (автоматически)

Устройство при включении само просит адрес — и получает его за миллисекунды
Сервер ведёт учёт: кому что выдано, когда истекает
Один пул на сотни устройств; конфликтов нет — сервер не выдаст занятый адрес
Сменить DNS всему офису — одна правка на сервере, а не 120 обходов

Рабочее правило из модуля 1 трека СПД: всё, к чему подключаются другие (серверы, роутеры, шлюзы, стыки) — на статике; всё, что подключается само (ноутбуки, телефоны, принтеры) — на DHCP. DHCP — это про клиентов, а не про инфраструктуру.

Аналогия

DHCP = стойка регистрации в отеле

Ты приходишь в отель (включаешь ноутбук) и говоришь на ресепшене: «мне нужен номер». Тебе выдают ключ от свободного номера (IP-адрес), карту этажа (маску), объясняют, где выход (шлюз) и где справочная (DNS) — и всё это на срок проживания (lease). Уехал, не продлил — номер освобождается для другого гостя. Ты не выбираешь номер сам и не знаешь заранее какой — тебе его выдают. Это и есть DHCP.

3. DORA — четыре сообщения, как хост получает адрес

Сердце DHCP — обмен из четырёх сообщений. Запомни аббревиатуру DORA — её спрашивают на каждом собеседовании:

DISCOVER

«Есть тут DHCP? Мне нужен адрес»

клиент → broadcast

OFFER

«Держи 10.20.5.37, вот параметры»

сервер → клиент

REQUEST

«Беру именно этот»

клиент → broadcast

ACK

«Подтверждаю, он твой на N часов»

сервер → клиент

DISCOVER — «есть кто живой?»

Только включённый хост не знает ещё ничего — ни своего адреса, ни адреса сервера. Поэтому он шлёт broadcast с адреса 0.0.0.0 на 255.255.255.255, UDP-порт 67. Внутри — его MAC (chaddr), по нему сервер потом узнает клиента. Слышат все в сегменте; отвечает тот, кто DHCP-сервер.

OFFER — «вот тебе адрес»

Сервер выбирает свободный адрес из пула и предлагает его вместе с маской, шлюзом, DNS и сроком аренды. Ответ идёт на UDP-порт 68. Если серверов два — клиент получит два offer'а и выберет обычно первый пришедший.

REQUEST — «беру именно этот»

Клиент формально запрашивает предложенный адрес — и снова broadcast'ом. Почему broadcast, ведь адрес сервера уже известен? Чтобы все остальные DHCP-серверы услышали «я выбрал не тебя» и вернули свои offer'ы в пул. Иначе адреса утекали бы впустую.

ACK — «подтверждаю, пользуйся»

Сервер фиксирует привязку MAC → IP у себя (это будущая строка show ip dhcp binding) и шлёт подтверждение. С этого момента у клиента есть рабочий адрес. Если предложенный адрес вдруг занят — сервер шлёт NAK, и всё начинается заново.

Частая путаница джуна

«DISCOVER и REQUEST — оба broadcast, разве это не одно и то же?» Нет. DISCOVER — «есть ли вообще сервер». REQUEST — «я выбрал этот адрес, остальные свободны». Два разных сообщения с разным смыслом; между ними хост ещё без адреса, поэтому и там, и там broadcast.

4. Что выдаёт DHCP: адрес — это только начало

DHCP выдаёт не только IP. Всё дополнительное передаётся в виде опций (options) — пронумерованных полей. Знать ходовые номера полезно: их видно в дампах и в конфиге сервера.

Опция	Что несёт	Зачем
—	IP-адрес + маска	собственно адрес хоста
Option 3	Default Gateway	шлюз по умолчанию — куда слать «в чужие сети»
Option 6	DNS-серверы	кому задавать вопрос «какой IP у сайта»
Option 51	Lease Time	на сколько выдан адрес (в секундах)
Option 15	Domain Name	суффикс домена (например, `corp.local`)
Option 66 / 150	TFTP / IP серверов автоконфигурации	IP-телефоны и тонкие клиенты качают отсюда прошивку/конфиг
Option 82	Relay Agent Info	relay дописывает, с какого порта/свитча пришёл запрос — для учёта и защиты

Именно поэтому «выдать адрес» и «настроить DHCP правильно» — не одно и то же. Забыл option 3 — адрес есть, а «интернета нет»: пакеты в чужие сети некуда отправлять. Забыл option 6 — «сеть есть, сайты не открываются»: нет DNS. Половина заявок «DHCP выдал, но не работает» — это забытая опция.

5. Аренда: почему адрес «сам меняется»

Адрес выдаётся не навсегда, а в аренду (lease) — на срок из option 51 (часто 8–24 часа в офисе, минуты в публичном Wi-Fi). Это защищает пул: ушёл сотрудник с ноутбуком — адрес через время вернётся. Пока клиент включён, он не ждёт истечения, а заранее продлевает аренду по таймерам:

T1 ≈ 50% срока — RENEW (продление)

Клиент шлёт REQUEST unicast'ом напрямую своему серверу: «продли мне тот же адрес». Сервер отвечает ACK — таймеры сбрасываются. В 99% случаев всё заканчивается здесь, тихо и незаметно.

T2 ≈ 87.5% срока — REBIND (перепривязка)

Свой сервер молчит (упал, перезагрузка)? Клиент шлёт REQUEST broadcast'ом — «продлит кто угодно». Если ответит резервный сервер — аренда продолжается.

Срок истёк — EXPIRE

Никто не ответил до конца lease — клиент отпускает адрес и начинает DORA с нуля. Вот тогда пользователь и может внезапно получить другой адрес или, если сервер лежит, — тот самый 169.254.x.x.

Вопрос с собеседования

«Почему renew — unicast, а rebind — broadcast?» Потому что на renew клиент знает и доверяет своему серверу — экономит broadcast. На rebind свой сервер уже не отвечает, и клиент готов принять помощь от любого сервера в сегменте — поэтому кричит всем.

6. DHCP relay — один сервер на десятки подсетей

Вернёмся к заявке: сервер в 10.0.0.53, клиенты — в 10.20.5.0/24. DISCOVER от клиента — broadcast, а роутер broadcast между подсетями не пропускает (иначе широковещание одной сети топило бы весь интернет). Значит, запрос до сервера сам не долетит. Ставить по DHCP-серверу в каждый филиал — дорого и неуправляемо. Решение — DHCP relay (агент ретрансляции).

Relay живёт на роутере/L3-коммутаторе сегмента и делает вот что:

Ловит broadcast DISCOVER в своём сегменте

Роутер настроен слушать DHCP на интерфейсе клиентов (

ip
        helper-address

Превращает его в unicast к серверу

Broadcast 255.255.255.255 заменяется на конкретный адрес сервера 10.0.0.53 — такой пакет спокойно маршрутизируется через всю сеть.

Проставляет giaddr — «откуда клиент»

В поле giaddr (gateway IP address) relay кладёт адрес своего интерфейса в клиентской сети (10.20.5.1). Сервер по giaddr понимает: «запрос из сети 10.20.5.0/24 — выдам адрес из соответствующего пула». Без giaddr сервер не знал бы, из какого диапазона брать.

Возвращает ответ клиенту

OFFER/ACK от сервера приходят на relay, а он доставляет их клиенту в сегменте. Для клиента всё выглядит так, будто сервер стоял рядом.

Одна строка ip helper-address 10.0.0.53 на интерфейсе филиала — и централизованный сервер обслуживает сотни удалённых сетей. giaddr — ключ ко всему: по нему сервер выбирает пул. Нет relay или неверный helper — клиенты ловят APIPA, хотя сервер жив.

7. Конфиг на Cisco и чтение состояния

Соберём обе стороны. Сначала — сам DHCP-сервер (на Cisco его умеет и роутер):

# --- сторона DHCP-сервера --- # исключаем адреса инфраструктуры, чтобы сервер их не раздал R(config)# ip dhcp excluded-address 10.20.5.1 10.20.5.10 R(config)# ip dhcp pool FILIAL-VOICE-DATA R(dhcp-config)# network 10.20.5.0 255.255.255.0 # из какой сети раздавать R(dhcp-config)# default-router 10.20.5.1 # option 3 — шлюз R(dhcp-config)# dns-server 10.0.0.53 8.8.8.8 # option 6 — DNS R(dhcp-config)# domain-name corp.local # option 15 R(dhcp-config)# lease 0 8 # аренда 8 часов (дни часы минуты)

Теперь — relay на роутере филиала (если сервер в другой подсети — это твой случай из заявки):

# --- сторона relay (интерфейс в сторону клиентов) --- R(config)# interface gi0/1 R(config-if)# ip address 10.20.5.1 255.255.255.0 R(config-if)# ip helper-address 10.0.0.53 # пересылать DHCP на сервер

Проверяем результат — какие адреса реально выданы:

R# show ip dhcp binding IP address Client-ID/MAC Lease expiration Type 10.20.5.11 aabb.cc00.1122 Mar 02 2026 09:14 AM Automatic 10.20.5.12 aabb.cc00.33d4 Mar 02 2026 09:15 AM Automatic R# show ip dhcp pool # сколько адресов занято/свободно в пуле R# show ip dhcp conflict # конфликты (сервер ping'ует адрес перед выдачей)

Частая ошибка джуна

Забыть ip dhcp excluded-address для шлюза и серверов. Тогда DHCP спокойно выдаст клиенту 10.20.5.1 — адрес шлюза — и в сети начнётся конфликт: «интернет то есть, то нет у всего сегмента». Всегда исключай инфраструктурный диапазон первым делом.

8. Резервирование, исключения, несколько пулов

Исключения (excluded-address) — адреса, которые сервер не тронет: шлюз, принтеры на статике, серверы. Обычно исключают весь «нижний» диапазон .1–.10.
Резервирование (reservation) — «этому MAC всегда выдавать этот IP». Нужно, когда устройство должно иметь предсказуемый адрес (принтер, камера, касса), но настраивать его статикой неудобно. Привязка идёт по MAC-адресу клиента.
Несколько пулов — на одном сервере десятки пулов, по одному на подсеть/VLAN; нужный выбирается по giaddr от relay (для удалённых) или по интерфейсу (для локальных).

9. Безопасность: rogue DHCP, starvation и DHCP snooping

DHCP построен на доверии и broadcast'е — а значит, уязвим. Два классических вектора:

🕵️ Rogue DHCP («левый» сервер)

Кто-то воткнул домашний Wi-Fi-роутер в офисный порт — или поставил его специально. Он тоже отвечает на DISCOVER и раздаёт свой шлюз. Клиенты, получившие такой offer первым, шлют весь трафик через злоумышленника (man-in-the-middle) или просто в никуда. Симптом: «у части офиса другой шлюз/DNS, сайты подменяются».

💥 DHCP starvation (исчерпание пула)

Атакующий шлёт лавину DISCOVER с тысячами поддельных MAC — сервер выдаёт адреса «фантомам», пул кончается, реальные клиенты остаются без адресов (отказ в обслуживании). Часто это прелюдия к подъёму rogue-сервера на освободившемся месте.

Лечится это на коммутаторе — механизмом DHCP snooping:

Делим порты на trusted и untrusted

Аплинк к легитимному DHCP-серверу (или relay) помечается trusted. Все клиентские порты — untrusted по умолчанию.

Режем серверные ответы с untrusted-портов

OFFER и ACK имеет право слать только сервер. Пришли они с клиентского (untrusted) порта — это rogue DHCP, кадр отбрасывается. Домашний роутер в офисном порту больше никого не «обслужит».

Строим таблицу привязок snooping

Коммутатор запоминает легитимные пары MAC ↔ IP ↔ порт ↔ VLAN. Эта таблица — фундамент для DAI (Dynamic ARP Inspection, защита от ARP-spoofing) и IP Source Guard.

# DHCP snooping на Cisco SW(config)# ip dhcp snooping SW(config)# ip dhcp snooping vlan 10,20 SW(config)# interface gi0/24 # аплинк к серверу/relay SW(config-if)# ip dhcp snooping trust # всё остальное — untrusted по умолчанию

Так на работе решают «мистику»

«У случайных пользователей неверный шлюз, ловятся странные DNS» — классический rogue DHCP. Ищи лишний DHCP-ответ: show ip dhcp snooping, а на этапе диагностики — дамп в сегменте (Wireshark, фильтр bootp): если два разных сервера шлют OFFER — вот и виновник. DHCP snooping закрывает это навсегда.

10. А в IPv6? SLAAC против DHCPv6 — обзорно

В IPv6 (модуль 13) адрес чаще раздаётся без DHCP — через SLAAC: роутер рассылает Router Advertisement с префиксом /64, а хост сам достраивает себе адрес. Но SLAAC не выдаёт DNS так же удобно, поэтому существует и DHCPv6:

Stateless DHCPv6 — адрес хост берёт по SLAAC, а у DHCPv6 просит только доп. параметры (DNS, домен). Сервер не ведёт учёт адресов.
Stateful DHCPv6 — как привычный DHCP: сервер сам выдаёт адреса и ведёт учёт (нужно, когда важен контроль «кому что выдано»).

Чем именно пользоваться, хост решает по флагам M (managed) и O (other) в Router Advertisement. Для CCNA достаточно понимать: в IPv6 адрес можно получить и без DHCP.

11. Мини-лаба: DHCP на своём компьютере

Всё это можно потрогать прямо сейчас, без оборудования:

# Windows — посмотреть, что выдал DHCP C:\> ipconfig /all # Ищи строки: DHCP Enabled: Yes, DHCP Server, Lease Obtained/Expires, # Default Gateway (option 3), DNS Servers (option 6) C:\> ipconfig /release # отпустить адрес (увидишь, как связь пропала) C:\> ipconfig /renew # пройти DORA заново — адрес вернётся

# Linux — аренда и запрос $ ip addr # твой адрес и срок (valid_lft) $ cat /var/lib/dhcp/dhclient.leases # история аренд (где есть dhclient) $ sudo dhclient -v eth0 # увидишь DISCOVER/OFFER/REQUEST/ACK в реальном времени

Что увидишь: в ipconfig /all — адрес самого DHCP-сервера (обычно это твой домашний роутер, 192.168.0.1 или 192.168.1.1), время получения и истечения аренды. Сделай release → renew и заметь: интернет на секунду пропал и вернулся — это ты вручную прогнал DORA.

12. Плейбук: «клиент не получает адрес» (ловим 169.254)

Заявка «у пользователя нет интернета, адрес 169.254.x.x». Идём снизу вверх, меняя по одному (модуль 12):

Физика и порт (L1/L2)

Линк есть? Порт в нужном access-VLAN? Кабель/трансивер? APIPA часто значит, что кадр DISCOVER просто не доехал до сервера — начни с самого дешёвого.

Есть ли DHCP в этом сегменте / работает ли relay

Сервер локальный — жив ли он и не кончился ли пул (

show ip dhcp
        pool

)? Сервер удалённый — стоит ли ip helper-address на интерфейсе сегмента и верный ли адрес? Забытый или неверный helper — причина №1.

Дамп: доходит ли DISCOVER, приходит ли OFFER

Wireshark/tcpdump, фильтр bootp (или

port 67 or port
        68

). Видишь DISCOVER, но нет OFFER — проблема на сервере/relay. Нет даже DISCOVER — проблема на L1/L2/VLAN.

Пул и исключения на сервере

Не кончились ли адреса? Нет ли конфликтов (show ip dhcp conflict)? Верны ли giaddr-пулы под нужную подсеть?

Защита не режет ли легитимный трафик

DHCP snooping настроен, но аплинк к серверу забыли пометить trust? Тогда коммутатор рубит настоящие OFFER — и весь сегмент без адресов. Классическая «сам себе авария».

13. Частые ошибки и вопрос с собеседования

Три грабли, на которые наступают все

1) Не исключили шлюз/серверы из пула → конфликт адресов. 2) Настроили relay, но забыли trust на аплинке при включённом snooping → сервер жив, а клиенты без адресов. 3) Выдали адрес, но забыли option 3/6 → «адрес есть, интернета/сайтов нет».

Собеседование: «Клиент получил 169.254.100.5. Твои первые три проверки?»

1) Линк/порт/VLAN (доехал ли DISCOVER вообще). 2) Есть ли DHCP в сегменте или настроен ли ip helper-address (и верный ли). 3) Дамп bootp: видно ли DISCOVER и приходит ли OFFER — так за минуту понимаешь, где рвётся: на клиенте, на пути или на сервере.

14. Словарик модуля

Термин	По-английски	Смысл в одну строку
DORA	Discover/Offer/Request/Ack	четыре сообщения, за которые хост получает адрес
Аренда	lease	срок, на который выдан адрес; продлевается по T1/T2
Relay-агент	DHCP relay / ip helper-address	пересылает broadcast-запрос на сервер в другой подсети
giaddr	gateway IP address	адрес интерфейса relay; по нему сервер выбирает пул
Опция	DHCP option	доп. параметр: шлюз (3), DNS (6), lease (51), TFTP (66/150)
Резервирование	reservation	«этому MAC всегда этот IP»
Rogue DHCP	rogue / unauthorized server	чужой DHCP-сервер, раздающий неверные параметры
DHCP snooping	DHCP snooping	защита L2: серверные ответы только с trusted-портов
APIPA	automatic private IP addressing	169.254.0.0/16 — заглушка при неудачном DHCP
SLAAC	stateless address autoconfiguration	получение IPv6-адреса без DHCP, по RA от роутера

1. У всего нового VLAN клиенты ловят 169.254, сервер в другой подсети жив и раздаёт другим VLAN нормально. Первое подозрение?

Забыт или неверен ip helper-address на интерфейсе именно этого VLAN/сегмента. DISCOVER — broadcast, без relay он не долетит до удалённого сервера, а другие VLAN работают, потому что там helper настроен. Проверь конфиг SVI/интерфейса этого сегмента.

2. Пользователи жалуются, что «иногда» получают чужой шлюз и подменённые сайты. Что это и чем закрыть?

Rogue DHCP — в сети появился лишний DHCP-сервер (часто чей-то домашний роутер). «Иногда» — потому что клиент берёт тот offer, что пришёл первым, а это гонка. Закрывается DHCP snooping: пометить аплинк к настоящему серверу как trust, остальные порты — untrusted.

3. DHCP выдаёт адрес и маску, пинг до шлюза идёт, но сайты не открываются и «интернета нет» в чужие сети. Чего не хватает в выдаче?

Двух опций. Пинг до шлюза идёт — значит, адрес/маска верны и L2 работает. «Сайты не открываются» → нет option 6 (DNS). «В чужие сети не идёт» → нет option 3 (default gateway). Часто забывают именно их при ручной настройке пула.

4. Зачем сервер перед выдачей адреса иногда пингует его, и что показывает show ip dhcp conflict?

Чтобы не выдать адрес, который кто-то уже занял статикой. Если на ping отвечают — адрес помечается конфликтным и в пул не идёт; такие адреса и показывает show ip dhcp conflict. Много конфликтов — признак пересечения статики и DHCP-диапазона (нужно исключить статические адреса).

DHCP — это «стойка регистрации» сети: DORA выдаёт клиенту адрес, шлюз и DNS в аренду; relay (ip helper-address + giaddr) позволяет одному серверу обслуживать сотни подсетей; а DHCP snooping защищает всё это от чужих серверов. Половина «мистических» аварий с 169.254.x.x и «неверным шлюзом» — это DHCP, и теперь ты закрываешь их по плейбуку, а не гаданием.

Мост к следующему модулю

DHCP snooping построил таблицу «MAC ↔ IP ↔ порт» — и это фундамент целого пласта защиты на L2: port-security, Dynamic ARP Inspection, IP Source Guard, 802.1X. Как превратить коммутатор доступа из «дырявого» в «крепость» и не пустить в сеть чужое устройство — в следующем модуле про безопасность порта.