Теория: DHCP: как хост получает адрес

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

Зачем нужен DHCP

Адрес, маску, шлюз и DNS можно прописать руками — и на десяти устройствах это даже разумно. На пятистах превращается в работу, которая никогда не заканчивается: человек уходит, приходит новый, ноутбук переезжает между этажами, телефон подключается к Wi-Fi на полчаса.

DHCP (Dynamic Host Configuration Protocol) раздаёт эти параметры сам. Устройство подключается к сети, не зная о ней ничего, и через доли секунды получает готовую настройку. Ровно поэтому телефон в кафе начинает работать без единого вопроса к пользователю.

DORA — четыре шага

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

D — Discover. Хост не знает ни своего адреса, ни адреса сервера, поэтому кричит на весь сегмент: широковещательный запрос с источником 0.0.0.0. Другого способа у него нет.
O — Offer. Сервер предлагает конкретный адрес из пула вместе с остальными параметрами.
R — Request. Хост публично объявляет, какое предложение принимает. Это тоже широковещательное сообщение — и не случайно: если серверов в сети несколько, остальные должны услышать отказ и вернуть свои адреса в пул.
A — Acknowledge. Сервер подтверждает и фиксирует аренду.

Только после ACK хост присваивает адрес интерфейсу. До этого момента он в сети формально безадресный.

Четыре шага DORA — и что у хоста есть на каждом из них

Хостадреса нет

Сегментвсе слышат

Сервер192.168.1.53

··

сообщение

Адрес присваивается интерфейсу только после ACK. До этого хост формально безадресный — поэтому первые два сообщения и не могут быть адресными.

Что выдаётся кроме адреса

Адрес — самое очевидное, но обычно наименее проблемное. Вместе с ним сервер отдаёт набор опций:
• маска подсети — без неё хост не поймёт, где своя сеть, а где чужая;
• шлюз по умолчанию — иначе не выйти за пределы сегмента;
• адреса DNS-серверов — без них не откроется ни один сайт по имени;
• домен поиска, серверы времени, адрес TFTP для загрузки телефонов и тонких клиентов.

Практический вывод: жалоба «интернет не работает» при живом адресе чаще всего означает не проблему с адресом, а неверную опцию — не тот шлюз или не тот DNS.

Аренда: почему адрес выдаётся на время

Адрес выдаётся не навсегда, а в аренду (lease) на заданный срок — сутки, неделя, в гостевом Wi-Fi иногда пятнадцать минут. Смысл в возврате: устройство ушло и не вернулось, а адрес обязан освободиться сам.

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

Срок аренды — это компромисс. Длинный бережёт трафик и переживает падение сервера, короткий быстрее возвращает адреса в пул. В гостевой сети с потоком людей выбирают короткий, в офисе — длинный.

DHCP relay: почему сервер не в каждом сегменте

Discover — широковещательное сообщение, а маршрутизатор широковещание не пересылает. Формально это означает, что DHCP-сервер нужен в каждом сегменте. Так, конечно, не делают.

Вместо этого на маршрутизаторе включают DHCP relay (в синтаксисе Cisco — ip helper-address). Он ловит широковещательный Discover, превращает его в обычный адресный пакет и отправляет серверу, дописав, из какой сети пришёл запрос. По этой пометке сервер и понимает, из какого пула выдавать адрес.

Отсюда типичная авария: в новом VLAN всё настроено, но адреса не выдаются — забыли relay. Симптом характерный: хосты получают адрес 169.254.x.x (это APIPA, который хост назначает себе сам от отчаяния) и не видят вообще ничего.

Резервирование и статические адреса

Серверу, принтеру и коммутатору нужен постоянный адрес. Есть два пути.

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

Зарезервировать на сервере по MAC-адресу — устройство по-прежнему получает настройку по DHCP, но всегда одну и ту же. Учёт остаётся в одном месте, конфликты исключены. Для инфраструктуры это почти всегда правильный выбор.

Отдельно проверьте, что статические адреса не попадают в пул выдачи: иначе однажды сервер выдаст занятый адрес ноутбуку, и оба устройства начнут работать через раз.

Что здесь ломается

Чужой DHCP-сервер. Кто-то принёс домашний роутер и воткнул в сеть. Он честно раздаёт адреса своей выдуманной сети со своим шлюзом — и у части людей «интернет пропал». Кому какой сервер ответит, решает случай, поэтому симптомы плавают. Лечится на коммутаторе (DHCP snooping), а не на сервере.

Кончился пул. Адреса не выдаются новым устройствам, старые работают. Часто причина не в росте сети, а в слишком длинной аренде: адреса ушедших устройств ещё не вернулись.

Не настроен relay. Новый сегмент, всё верно, адресов нет, у хостов 169.254.x.x.

Верный адрес, неверная опция. Адрес получен, ping до соседа идёт, а наружу ничего — не тот шлюз. Или всё работает по IP, но не работает по имени — не тот DNS.

Как проверять

ip a — есть ли адрес вообще и какой. Увидели 169.254.x.x — ответа от сервера не было ни одного.

ip route — приехал ли шлюз. Адрес без шлюза выглядит работающим ровно до первой попытки выйти наружу.

cat /etc/resolv.conf — какие DNS-серверы выданы.

tcpdump -i eth0 -n port 67 or port 68 — увидеть сам обмен и понять, на каком из четырёх шагов он оборвался. Ушёл Discover, но нет Offer — сервер не услышал (или нет relay). Есть Offer, но нет ACK — спорят два сервера.

На стороне сервера смотрят таблицу аренд: кому, когда и до какого времени выдан адрес.

Команды — шпаргалка

# клиент (Linux)
ip a                          # сокращение от «ip addr»: какие адреса получены
ip route                      # появился ли маршрут по умолчанию от сервера
cat /etc/resolv.conf          # какие DNS-серверы приехали в аренде
dhclient -r eth0 && dhclient eth0
                              # -r — release, вернуть текущую аренду;
                              #      затем запрос заново. Имя в конце — интерфейс

# посмотреть обмен
tcpdump -i eth0 -n port 67 or port 68
                              # -i — интерфейс, -n — не превращать адреса в имена.
                              #      67 — порт сервера, 68 — порт клиента

# сервер (dnsmasq): строки конфигурации, не команды
dhcp-range=192.168.1.100,192.168.1.200,12h
                              # три поля подряд: первый адрес пула, последний,
                              #      срок аренды (h — часы, m — минуты)
dhcp-option=3,192.168.1.1     # 3 — номер опции DHCP «шлюз», дальше его адрес
dhcp-option=6,192.168.1.53    # 6 — номер опции «DNS-серверы»
dhcp-host=aa:bb:cc:11:22:33,192.168.1.50
                              # резервирование: MAC клиента и адрес, который
                              #      всегда выдавать именно ему

# relay на маршрутизаторе (Cisco-подобный синтаксис)
interface eth1
 ip helper-address 192.168.1.53
                              # адрес DHCP-сервера, которому пересылать
                              #      широковещательные запросы из этой сети

Контрольные вопросы

Дальше — лабораторная работа «DHCP: выдай адреса и достань их через роутер»

Для неё нужен аккаунт: стенд поднимается персонально под вас — свои роутеры, свои конфиги, никто в них не мешает. Регистрация — почта и пароль.

Создать аккаунт → У меня есть аккаунт

Теория прочитана. Дальше — руками.

Личный стенд из настоящих роутеров разворачивается за секунды. Платформа проверяет не ответы на тесты, а состояние вашей сети: поднялись ли соседства, сошлись ли маршруты, ходит ли ping. Рядом — AI-наставник, который видит ваши конфиги и ведёт к решению, не выдавая готовое.

Начать бесплатно → бета открыта, доступ бесплатный