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

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

21. Проблемы виртуальных машин

Для серверов в виртуальной среде частые причины:

• клонирование без смены MAC;
• откат снапшота, после которого аренда «старая»;
• миграция между хостами с кратковременным сбоем сети;
• виртуальный коммутатор не пропускает broadcast;
• неверный VLAN на порту;
• энергосбережение виртуального адаптера;
• неправильная модель сетевого драйвера.

Что делать:

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

---

---

---

22. Если проблема беспроводная

Для Wi-Fi добавьте:

• проверку роуминга между точками;
• проверку изоляции клиентов;
• проверку, не блокирует ли контроллер DHCP;
• проверку случайного MAC на клиенте;
• проверку поддержки 802.11r/802.11k/802.11v и их взаимодействия с 802.1X;
• проверку, не происходит ли смена подсети при переходе между точками.

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

---

23. Пошаговый алгоритм расследования

Я бы действовал так.

Шаг 1. Определить, кто и что теряет

Ответьте:

• рвётся связь с сервером у клиента?
• или сам сервер теряет клиентов?
• теряется доступ по имени, по IP или и так и так?
• теряется весь сетевой доступ или только один сервис?

Шаг 2. Зафиксировать время

Нужно получить:

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

Шаг 3. Собрать состояние до и после

• текущий IP;
• маска;
• шлюз;
• DNS;
• маршруты;
• имя сервера и его фактический IP;
• ARP-кэши;
• статус линка.

Шаг 4. Включить мониторинг

• пинг до шлюза;
• пинг до сервера по IP;
• резолв имени;
• дамп DHCP.

Шаг 5. Дождаться события

Не перезагружайте систему сразу. Лучше поймать живой момент.

Шаг 6. Разобрать дамп

Смотрите:

• были ли DHCPREQUEST;
• были ли ответы;
• был ли DHCPACK или DHCPNAK;
• менялся ли адрес;
• доходили ли ответы сервера.

Шаг 7. Определить уровень

Возможные выводы:

• клиент не отправляет запрос;
• клиент отправляет, но сервер не отвечает;
• сервер отвечает, но клиент не применяет;
• адрес меняется, и проблема выше;
• адрес не меняется, но трафик блокируется сетью.

Шаг 8. Устранять причину, а не симптом

Например:

• не просто перезагрузить, а исправить путь продления аренды;
• не просто дать статический адрес клиенту, если это временная мера;
• не просто увеличить аренду, если пул исчерпан;
• не просто очистить кэш, если DNS-запись неверная.

---

24. Безопасные временные меры

Если нужно быстро стабилизировать ситуацию:

Для сервера

• назначить статический IP вне пула;
• или сделать резервирование;
• проверить DNS;
• перезапустить сервисы.

Для клиента

• выполнить ipconfig /renew, если это безопасно;
• проверить службу клиента DHCP;
• отключить случайный MAC;
• отключить энергосбережение адаптера;
• временно увеличить срок аренды, чтобы выиграть время;
• проверить доступность запасного/второго DHCP-сервера.

Для сети

• проверить ip helper-address;
• проверить ACL;
• проверить доверенные порты для DHCP;
• проверить failover/scope.

---

Важно: увеличение времени аренды может временно уменьшить частоту обрывов, но если продление не работает, проблема всё равно вернётся и может проявиться в неудобное время.

---

25. Рекомендуемая правильная конфигурация

Чтобы такого не было:

Для серверов

• статический IP или резервирование;
• корректные PTR/A записи;
• сервисы не должны зависеть от динамического IP;
• DNS TTL перед миграцией можно временно снизить;
• мониторинг доступности и сетевых параметров.

Для DHCP-инфраструктуры

• достаточный размер пула;
• отдельные области для разных подсетей;
• корректные опции: шлюз, DNS, домен;
• резервирования для критичных устройств;
• исключения для статических адресов;
• отказоустойчивость: второй сервер или failover;
• актуальная база аренд и бэкапы;
• мониторинг свободных адресов;
• синхронизация времени;
• логирование;
• защита от несанкционированных DHCP-серверов.

---

---

Для клиентов

• включённая служба/процесс DHCP;
• корректные драйверы;
• отключённая рандомизация MAC в корпоративной проводной сети;
• нормальная работа сна/пробуждения;
• отсутствие дублей образов с одинаковым MAC.

Для сетевых устройств

• правильные ip helper-address;
• ACL разрешают DHCP;
• DHCP snooping настроен корректно;
• IP Source Guard не ломает легитимных клиентов;
• порты не уходят в ошибку из-за errdisable;
• STP PortFast/Edge Port на пользовательских портах, если это допустимо политикой;
• мониторинг link down/up.

---

26. Если нужно проверить именно сервер, который потерял связь

Если под «сервером» понимается машина, к которой клиенты теряют доступ, выполните на сервере:

Быстрая проверка

Windows

ipconfig /all
route print
netstat -ano | findstr LISTENING

Get-NetIPConfiguration -Detailed
Get-NetIPAddress -AddressFamily IPv4
Get-NetTCPConnection | Where-Object State -eq Established

Linux

ip -brief -4 addr
ip route
ss -tlnp
ss -tnp
journalctl --since "2 hours ago" | grep -Ei 'dhcp|lease|ack|nak|link|eth'

Проверьте:

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

---

27. Особый случай: клиентский адрес меняется, а сервер обрывает сессии

Если клиент каждый раз получает новый IP, а серверное приложение:

• рвёт сессии;
• сбрасывает авторизацию;
• блокирует повторное подключение;
• использует привязку к IP;
• имеет жёсткие таймауты;

то проблема может быть в дизайне приложения.

Варианты решения:

1. Дать клиенту стабильный IP через резервирование.
2. Обеспечить стабильный исходящий IP через NAT.
3. Настроить приложение на переподключение.
4. Не использовать клиентский IP как идентификатор сессии.
5. Использовать балансировщик с корректной обработкой клиентских переподключений.
6. Проверить таймауты TCP keepalive и состояния файрвола.

---

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

Ошибка 1: статический адрес внутри пула DHCP

Если вы вручную поставили машине адрес из динамического диапазона, но не сделали исключение/резервирование, сервер может выдать этот адрес другому клиенту.

Правильно:

• либо статика вне пула;
• либо резервирование внутри пула.

Ошибка 2: увеличить аренду вместо поиска причины

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

Ошибка 3: перезагрузка без логов

После перезагрузки всё может временно заработать, но причина останется.

Ошибка 4: смотреть только клиент

Если клиент шлёт DHCPREQUEST, а ответа нет, проблема может быть на сервере, relay, firewall или коммутаторе.

Ошибка 5: проверять только имя сервера

Если тестировать только ping server.domain.local, можно перепутать проблему DNS с проблемой IP/маршрутизации.

---

29. Минимальный набор команд для быстрого сбора информации

Windows

ipconfig /all
route print
ping IP_шлюза
ping IP_сервера
nslookup имя_сервера
netstat -ano

Get-NetIPConfiguration -Detailed
Get-NetIPAddress -AddressFamily IPv4
Get-Service Dhcp
Get-WinEvent -LogName Microsoft-Windows-Dhcp-Client/Admin -MaxEvents 50

Linux

ip -brief -4 addr
ip route
ping -c 4 IP_шлюза
ping -c 4 IP_сервера
getent hosts имя_сервера
ss -tnp
journalctl --since "2 hours ago" | grep -Ei 'dhcp|lease|ack|nak|offer|request'

DHCP-сервер

Проверить:

• активна ли область;
• есть ли свободные адреса;
• видны ли аренды клиента;
• есть ли DHCPNAK;
• нет ли ошибок пула;
• работает ли второй сервер;
• корректны ли резервирования.

---

30. Что собрать для эскалации или глубокого анализа

---

---

Подготовьте:

1. ipconfig /all или ip addr + ip route до и после.
2. Время начала и конца проблемы.
3. Скриншот/лог с датой истечения аренды.
4. Дамп DHCP.
5. Логи клиента:
   • Windows Event Viewer DHCP-Client;
   • Linux journalctl.
6. Логи DHCP-сервера за тот же период.
7. Статистику пула и аренды.
8. Конфигурацию коммутатора/маршрутизатора:
   • ip helper-address;
   • ACL;
   • DHCP snooping;
   • 802.1X;
   • port security.
9. MAC-адрес и используемый клиентом идентификатор.
10. Есть ли второй сервер/резервный пул.
11. Менялся ли адрес сервера, к которому теряется доступ.
12. Работает ли доступ по IP и по имени.

---

31. Итоговая логика принятия решения

Если связь теряется при окончании аренды:

Если клиент не продлевает аренду

Смотрите:

• клиент отправляет DHCPREQUEST или нет;
• сервер отвечает или нет;
• приходит ACK или NAK;
• блокируется ли пакет по пути.

Решение:

• починить сервер/сеть/relay/ACL;
• исправить клиентскую службу/драйвер;
• устранить конфликт идентификаторов.

Если клиент получает другой адрес

Смотрите:

• почему не сохранится старая аренда;
• не меняется ли MAC/Client ID;
• нет ли дублей/клонов/случайного MAC.

Решение:

• резервирование;
• статика;
• исправление клиентского идентификатора.

Если сервер теряет доступ из-за смены собственного адреса

Решение почти всегда одно:

• статический IP или резервирование;
• правильный DNS;
• проверка сервисов, привязанных к IP.

Если адрес не меняется, но связь пропадает

Смотрите:

• коммутатор;
• 802.1X;
• IP Source Guard;
• firewall state table;
• драйвер;
• энергосбережение;
• линк/порт;
• гипервизор.

---

32. Практический минимум, который можно сделать прямо сейчас

Если проблема уже есть:

На клиенте

1. Выполнить:

   ipconfig /all

Записать:

• текущий IP;
• DHCP-сервер;
• время истечения аренды.

2. Дождаться обрыва или вызвать его в тестовом окне.

3. Сразу после обрыва снова выполнить:

   ipconfig /all

4. Сравнить:

• исчез ли адрес;
• появился ли 169.254.x.x;
• изменился ли адрес;
• изменились ли шлюз и DNS.

На сервере, к которому теряется доступ

1. Проверить фактический IP сервера.
2. Проверить DNS:

   nslookup server.domain.local

3. Сравнить имя и фактический адрес.
4. Если сервер получает адрес по DHCP — назначить статический адрес или резервирование.

На сетевом оборудовании

1. Проверить, есть ли ip helper-address, если сервер в другой подсети.
2. Проверить, не блокируются ли UDP 67/68.
3. Проверить, нет ли исчерпания адресов.
4. Проверить, не включены ли функции, которые могут блокировать трафик после истечения аренды.

---

33. Короткий вывод

Если при окончании DHCP-аренды теряется связь с сервером, чаще всего причина одна из пяти:

1. Клиент не может продлить аренду — нет ответа от DHCP-сервера.
2. Клиент получает другой IP, и из-за этого рвутся сессии или ломается маршрутизация.
3. Сервер сам получает новый IP, а клиенты или сервисы продолжают использовать старый.
4. Сетевое оборудование блокирует трафик после истечения аренды.
5. Проблема не в DHCP, а в DNS, firewall, приложении, драйвере или виртуализации.

---

Самое правильное действие для сервера — не использовать динамическую аренду, а сделать статический адрес или резервирование. Для клиента — проверить продление аренды через дамп и логи, а затем устранить причину, по которой DHCPREQUEST не превращается в DHCPACK.

---

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

---