Подробный гайд: Почему пропадает сеть при истечении DHCP-аренды и как это исправить - Часть 2

Подробный гайд: Почему пропадает сеть при истечении DHCP-аренды и как это исправить - Часть 2

11. Если связь теряется только с одним сервером

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

11.1. Не поменялся ли IP самого сервера

Если сервер получил другой адрес, а клиенты ходят по старому, проблема в:

• устаревшей DNS-записи;
• ARP-кэше;
• кэше приложения;
• конфигурации клиента;
• балансировщике;
• firewall-правилах;
• сертификате, если имя/адрес важны для TLS;
• кэше соединений.

---

---

Проверьте:

nslookup server.domain.local

и сравните с фактическим IP сервера.

11.2. Не привязано ли приложение к старому IP

Некоторые сервисы:

• слушают только конкретный IP;
• хранят лицензию по IP;
• используют IP-аутентификацию;
• имеют белый список клиентских адресов;
• не умеют переподключаться после смены клиентского IP.

Если клиент сменил адрес, сервер может сбросить сессию или отказаться от соединения.

Решение:

• фиксированный адрес для клиента или сервера;
• использование имён вместо IP;
• корректная обработка разрыва в приложении;
• стабильный NAT/исходящий IP;
• отказ от привязки к IP в авторизации, если это возможно.

11.3. Проверьте таблицы соединений

На сервере можно посмотреть, видит ли он подключения.

Windows

netstat -ano | findstr ESTABLISHED

или:

Get-NetTCPConnection | Where-Object State -eq Established

Linux

ss -tnp

или:

netstat -tnp

---

12. Диагностика DHCP-сервера

Если клиент отправляет DHCPREQUEST, но не получает DHCPACK, нужно смотреть сервер и промежуточную сеть.

12.1. Если у вас Windows Server DHCP

Проверьте области:

Get-DhcpServerv4Scope -ComputerName DHCP01

Статистику:

Get-DhcpServerv4Statistics -ComputerName DHCP01

Аренды:

Get-DhcpServerv4Lease -ComputerName DHCP01 -ScopeId 10.0.0.0

Failover, если настроен:

Get-DhcpServerv4Failover -ComputerName DHCP01

Логи DHCP Server:

%SystemRoot%\System32\Dhcp\DhcpSrvLog-*.log

Также смотрите события:

Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> Dhcp-Server

Ищите:

• нет свободных адресов;
• область неактивна;
• конфликт адресов;
• сбой failover;
• некорректная авторизация сервера в домене;
• ошибки записи базы.

12.2. Если у вас ISC DHCP на Linux

Проверьте конфигурацию:

sudo dhcpd -t /etc/dhcp/dhcpd.conf

Логи:

sudo journalctl -u dhcpd --since "2 hours ago"

или:

sudo grep -Ei 'DHCPREQUEST|DHCPACK|DHCPNAK|no free leases|lease' /var/log/syslog | tail -n 100

База аренд часто здесь:

sudo tail -n 100 /var/lib/dhcpd/dhcpd.leases

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

• нет свободных адресов;
• клиент из другой подсети не совпадает ни с одним subnet;
• неверно указан range;
• неверно обрабатывается giaddr от relay;
• сервер не знает аренду после восстановления из бэкапа;
• несколько DHCP-серверов раздают перекрывающиеся диапазоны.

12.3. Если у вас Kea DHCP

Проверка конфига:

sudo kea-dhcp4 -t /etc/kea/kea-dhcp4.conf

Логи обычно через journalctl:

sudo journalctl -u kea-dhcp4 --since "2 hours ago"

---

13. Проверка DHCP Relay / ip helper-address

Если клиенты и DHCP-сервер находятся в разных подсетях, обязателен корректный DHCP Relay.

На оборудовании уровня Cisco это обычно:

interface Vlan10
 ip helper-address 10.0.100.5

Проверки:

show running-config interface Vlan10
show ip interface brief
show ip dhcp binding

Что важно:

• ip helper-address указан на интерфейсе клиентской VLAN;
• адрес сервера доступен;
• ACL не блокирует UDP 67/68;
• сервер может отвечать на адрес агента;
• на сервере есть scope для подсети, из которой пришёл запрос;
• параметр giaddr корректно воспринимается сервером.

Если клиент в одной подсети с сервером, relay не нужен.

---

14. Проверка firewall и ACL

DHCP использует:

UDP/67 — сервер/relay
UDP/68 — клиент

Нужно разрешить:

• клиентские broadcast-запросы в локальном сегменте;
• пересылку relay-агентом запросов на DHCP-сервер;
• ответы сервера клиенту или relay;
• unicast-продление аренды, если клиент уже имеет адрес и отправляет запрос напрямую серверу.

---

---

---

Частая ошибка: сервер доступен по пингу, но продление не проходит, потому что где-то закрыт UDP/67 или UDP/68.

---

На Linux проверить локальные правила можно так:

sudo iptables -S
sudo nft list ruleset

Искать правила, связанные с:

udp dport 67
udp dport 68
bootp

На межсетевых экранах проверяйте политики для:

• клиентская подсеть → DHCP-сервер;
• relay-агент → DHCP-сервер;
• DHCP-сервер → клиентская подсеть;
• DHCP-сервер → relay-агент.

---

15. Типовые причины и решения

Ниже таблица частых причин.

Симптом	Вероятная причина	Что проверить	Решение
Клиент получает 169.254.x.x	Нет ответа DHCP	дамп, сервер, порт, VLAN, relay	починить сервер/порт/relay
Адрес пропадает ровно в момент окончания аренды	Не проходит продление	лог клиента, дамп DHCPREQUEST/DHCPACK	чинить DHCP-путь
Адрес меняется, связь рвётся	клиент получил другой IP	сравнивать IP до/после	резервирование, статика
Сервер получил новый IP, клиенты отваливаются	динамический IP сервера	DNS, ARP, настройки сервиса	статика или резервирование
Имя сервера резолвится в старый IP	старый DNS/кэш/TTL	nslookup, ipconfig /displaydns, кэш клиентов	статика/корректный DDNS, уменьшить TTL
DHCP-сервер отвечает NAK	аренда неизвестна/конфликт	логи сервера	восстановить базу, проверить MAC/Client ID
Пул исчерпан	нет свободных адресов	статистика области	расширить пул, убрать дубли, уменьшить аренду для гостей
Продление уходит, ответа нет	блокировка на коммутаторе/файрволе	дамп с двух сторон	разрешить UDP 67/68, проверить relay
Всё работает после перезагрузки	клиент перезапускает DORA и получает адрес	логи, время аренды	выяснить, почему не проходит RENEW
Проблема на виртуальной машине	клонированный MAC, снапшоты, сбой виртуального коммутатора	гипервизор, MAC, время	уникальный MAC, статика, порядок снапшотов
Проблема на ноутбуках	случайный MAC, Wi-Fi roaming, энергосбережение	настройки адаптера	отключить случайный MAC для корп. сети, обновить драйвер

---

16. Отдельно: если клиент получает другой IP

Это один из самых частых сценариев.

Почему это происходит:

1. Клиент не смог продлить аренду вовремя.
2. Сервер не нашёл старую аренду.
3. Сервер выдал новый адрес из другого диапазона.
4. Клиент сменил MAC или Client ID.
5. Используется случайный MAC.
6. Машина клонирована из образа с одинаковым MAC.
7. DHCP-сервер был восстановлен без старой базы.
8. Есть второй/несанкционированный DHCP-сервер.
9. Клиент перемещается между подсетями и получает новый адрес.

Что делать:

• сделать резервирование по аппаратному MAC;
• проверить, какой именно идентификатор использует клиент;
• отключить рандомизацию MAC для рабочей сети;
• проверить, не меняется ли client-id после обновления ОС или смены сетевого профиля;
• на сервере проверить привязку аренды к нужному идентификатору;
• проверить отсутствие дублей.

---

17. Отдельно: если сервер получает другой IP

Если сервер сам является DHCP-клиентом, это почти всегда архитектурная ошибка.

Что может сломаться:

• клиенты используют старый IP из кэша;
• сервис слушал старый адрес;
• приложение хранит адрес в конфиге;
• лицензия привязана к IP;
• firewall/NAT/балансировщик ждут старый адрес;
• DNS не обновился;
• кластерные ресурсы не могут мигрировать корректно;
• сервисы регистрации/мониторинга теряют узел.

Решение:

1. Назначить серверу статический адрес.
2. Либо создать резервирование на DHCP-сервере.
3. Исключить этот адрес из динамического пула.
4. Проверить, что в DNS правильный A/AAAA/PTR.
5. При необходимости уменьшить TTL перед изменениями.
6. Перезапустить сервисы после фиксации адреса.

---

---

---

18. Проблемы с коммутаторами: DHCP snooping, IP Source Guard, 802.1X

Это очень важный раздел, если адрес вроде бы есть, а трафик не ходит.

18.1. DHCP snooping

Коммутатор может строить таблицу соответствия:

MAC + IP + порт + VLAN

Если клиент не смог продлить аренду, запись может устареть. Тогда последующий трафик клиента может отбрасываться.

Симптомы:

• клиент имеет IP;
• пинг шлюза может пропадать;
• дамп на клиенте показывает DHCPREQUEST;
• сервер может даже отвечать;
• но трафик клиента не проходит дальше порта.

Что проверить:

• включён ли ip dhcp snooping;
• настроен ли доверенный порт к DHCP-серверу;
• не блокируются ли ответы сервера;
• не слишком ли агрессивный лимит пакетов;
• корректно ли работает option 82;
• совпадает ли время аренды с таймаутами привязок.

18.2. IP Source Guard

Если включен ip verify source, коммутатор может блокировать трафик, когда привязка устарела или изменился адрес.

18.3. 802.1X

Если порт закрылся на reauth или смена состояния произошла в момент продления аренды, клиент может не успеть обменяться DHCP.

Проверяйте:

• время разрыва линка;
• события аутентификации;
• show dot1x / RADIUS-логи;
• есть ли кратковременные link down/up.

---

19. Проблемы клиентского идентификатора и MAC-адреса

Некоторые DHCP-серверы различают клиентов не только по MAC, но и по client-id / option 61.

Если client-id меняется:

• клиент может получать другой адрес;
• сервер может не находить старую аренду;
• резервирование может не срабатывать.

Где это встречается:

• Linux с разными настройками dhclient/NetworkManager/systemd-networkd;
• виртуальные машины после миграции;
• док-станции для ноутбуков;
• смена сетевого адаптера;
• случайный MAC в Windows/Linux на беспроводных сетях;
• клонированные VM.

Что делать:

• проверить, по какому идентификатору сервер создаёт аренду;
• сделать привязку к стабильному идентификатору;
• при необходимости настроить одинаковый client-id;
• для корпоративных проводных сетей отключить рандомизацию MAC;
• для VM задать статический MAC.

---

20. Проблемы времени

Казалось бы, неочевидно, но бывает.

На клиенте

Если система была в глубоком сне/гибернации, таймеры аренды могли «уехать». После пробуждения клиент может считать аренду истёкшей.

Проверяйте:

• события сна/гибернации;
• время включения;
• системные события вокруг момента обрыва.

На DHCP-сервере

Для отказоустойчивых конфигураций важна синхронизация времени.

Проверьте:

• время на серверах;
• работу NTP;
• корректность логов;
• состояние failover.

---

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

---