Debian/Ubuntu: Failed to acquire DHCP lease — как вернуть IP и сеть

Сообщение Failed to acquire DHCP lease в Debian или Ubuntu почти всегда означает одно: интерфейс поднялся, но IP-адрес по DHCP так и не был получен. На практике это выглядит по-разному: сервер загружается без сети, адрес исчезает после перезагрузки, systemd-networkd пишет ошибки в журнал, netplan применяется без явных ошибок, но интерфейс остаётся без IPv4.

Проблема неприятна тем, что формально «сеть как будто есть»: интерфейс может быть в состоянии UP, MAC-адрес виден, а реального адреса и default route нет. Из-за этого часто начинают чинить не тот слой — DNS, firewall или маршруты, хотя первичный сбой находится именно в DHCP.

Ниже — рабочая схема диагностики для Debian и Ubuntu: от проверки линка и журналов до исправления конфигурации netplan, systemd-networkd, NetworkManager, dhclient и влияния cloud-init. Материал рассчитан на администраторов, которые работают через консоль, KVM или панель провайдера.

Сразу важный ориентир: DHCP-сбой — это не одна конкретная ошибка, а симптом. Причина может быть в интерфейсе, DHCP-клиенте, генераторе конфигурации, сетевом стеке ОС или вообще вне сервера — например, в VLAN, настройках виртуального свича, ACL или политике гипервизора.

Первое, что нужно выяснить: кто именно управляет сетью в системе — ifupdown, systemd-networkd, NetworkManager или cloud-init. Пока это не понятно, правка конфигов легко превращается в стрельбу по площадям.

Как быстро понять, что именно сломалось

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

Минимальный набор проверок:

ip -br link
ip -br addr
ip route
networkctl status -a
systemctl is-active systemd-networkd
systemctl is-active NetworkManager
ps aux | egrep 'dhclient|systemd-networkd|NetworkManager' | grep -v grep

Смотрите на несколько вещей сразу:

• есть ли нужный интерфейс вообще, например ens3, eth0, enp1s0;
• в каком он состоянии: DOWN, UP, NO-CARRIER;
• появился ли адрес и default route;
• кто реально управляет сетью — networkd или NetworkManager;
• не пытаются ли сразу две службы конфигурировать один и тот же интерфейс.

Очень частая ситуация в Ubuntu Server: сеть описана через netplan, но применяет её systemd-networkd. В Ubuntu Desktop обычно чаще участвует NetworkManager. На старых Debian и кастомных образах может использоваться ifupdown и /etc/network/interfaces. Если вы правите не тот стек, эффекта не будет.

Проверяем линк и имя интерфейса

Даже в виртуальной машине проблема может быть не в DHCP, а в том, что линк фактически отсутствует. Для bare metal это кабель, порт, автосогласование и VLAN на коммутаторе. Для виртуальной среды — состояние vNIC, привязка к нужной сети, фильтрация по MAC/IP или просто изменившееся имя интерфейса после миграции образа.

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

cat /sys/class/net/ens3/carrier
ethtool ens3
ip link show ens3

Если carrier равен 0 или ethtool показывает отсутствие линка, DHCP тут ни при чём: кадры просто не проходят. В виртуальной среде это часто связано с тем, что в конфиге остался старый eth0, а система уже использует ens3.

Проверьте фактические имена интерфейсов:

ls -1 /sys/class/net
udevadm info /sys/class/net/ens3

Если система ожидает eth0, а реально существует только ens3, DHCP-клиент может вообще не стартовать на нужной карте.

На серверах в облаке такая ситуация особенно заметна: образ переносится между площадками, а имя интерфейса меняется вместе с типом виртуального адаптера. Если вы поднимаете инфраструктуру на VDS, полезно сразу проверять фактическое имя интерфейса после первого старта, а не полагаться на старый шаблон.

Смотрим журналы: они почти всегда подсказывают причину

Следующий шаг — читать журнал именно того компонента, который управляет сетью. Для systemd-networkd:

journalctl -b -u systemd-networkd --no-pager
journalctl -b | grep -i dhcp

Для NetworkManager:

journalctl -b -u NetworkManager --no-pager
nmcli device status
nmcli connection show

Для dhclient и классических схем:

journalctl -b | grep -Ei 'dhclient|lease|dhcp'
grep -Ei 'dhclient|lease|dhcp' /var/log/syslog

Часто встречаются такие сообщения:

• No DHCPOFFERS received — запросы уходят, но сервер не отвечает;
• Failed to acquire DHCP lease — lease не получен за отведённое время;
• DHCPv4 address lost — адрес был, но потом исчез;
• Could not bring up interface — проблема шире, чем один DHCP;
• Link DOWN или No carrier — искать нужно на уровне линка.

Если в журнале нет даже попыток DHCP, это уже подсказка: клиент не запускался для данного интерфейса или был отключён конфигурацией.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Диагностика netplan в Ubuntu

В Ubuntu источник проблемы часто не в DHCP-сервере, а в описании интерфейса через netplan. Типичные ошибки: неправильное имя интерфейса, неверный renderer, отсутствие dhcp4: true, конфликт нескольких YAML-файлов или автоматическая перезапись через cloud-init.

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

ls -l /etc/netplan
sed -n '1,200p' /etc/netplan/*.yaml
netplan get
netplan status

Минимальный рабочий пример для DHCP:

network:
  version: 2
  ethernets:
    ens3:
      dhcp4: true

Если используется systemd-networkd:

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: true

Применять изменения лучше по шагам:

netplan generate
netplan try
netplan apply

netplan try особенно полезен на удалённой машине: если ошиблись и потеряли сеть, изменения можно откатить автоматически. Если же вы работаете через локальную консоль, после generate полезно посмотреть, что именно было сгенерировано в /run/systemd/network/.

Типовые ошибки в netplan

• неверное имя интерфейса;
• ожидание работы от networkd при включённом renderer: NetworkManager;
• ошибки отступов в YAML;
• конфликт нескольких файлов в /etc/netplan/;
• перезапись конфигурации со стороны cloud-init.

Если вы регулярно готовите шаблоны ВМ и переносите их между площадками, полезно отдельно проверить логику генерации сетевых конфигов в образе. Здесь пригодится и разбор про cloud-init в golden image: именно такие заготовки часто становятся источником трудноуловимых DHCP-сбоев после клонирования.

Когда виноват systemd-networkd

Если сетью реально управляет systemd-networkd, проверяйте уже его собственное состояние, а не только netplan:

networkctl list
networkctl status ens3
journalctl -b -u systemd-networkd --no-pager

Нужно понять три вещи:

• сопоставился ли интерфейс с нужным .network-файлом;
• разрешён ли DHCP именно для него;
• не мешает ли второй сетевой менеджер.

Минимальный пример конфигурации:

[Match]
Name=ens3

[Network]
DHCP=yes

После правок:

systemctl restart systemd-networkd
networkctl reload
networkctl renew ens3

Если lease не приходит, а журнал показывает исходящие DISCOVER без ответа, проверьте внешнюю сторону: DHCP-сервер, L2-сегмент, VLAN, фильтрацию MAC, настройки виртуального свича. Для быстрой проверки трафика удобно посмотреть DHCP-пакеты:

tcpdump -ni ens3 port 67 or port 68

Если видны только исходящие DHCPDISCOVER и нет DHCPOFFER, проблема чаще всего находится вне ОС. Если не видно даже исходящих пакетов, значит DHCP-клиент не активировался или интерфейс не готов к работе.

Проблемы с dhclient и ifupdown в Debian

На Debian и на системах после старых миграций до сих пор часто встречается схема с ifupdown и dhclient. В этом случае причина обычно сидит в /etc/network/interfaces, в ручной адресации, в старом lease-файле или в том, что интерфейс был поднят вне обычного механизма.

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

sed -n '1,200p' /etc/network/interfaces
ls -l /etc/network/interfaces.d

Минимальный DHCP-вариант:

auto ens3
iface ens3 inet dhcp

Для ручной перепроверки:

ifdown ens3
ifup ens3

Или напрямую через клиент:

dhclient -v -r ens3
dhclient -v ens3

Если lease-файл повреждён или содержит явно устаревшие данные, его можно временно исключить из диагностики, но делать это стоит осознанно. Ещё одна частая причина — интерфейс уже имеет вручную назначенный адрес.

ip addr show dev ens3

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

ip addr flush dev ens3
dhclient -v ens3

На небольших проектах со стандартной схемой сети такие проблемы проще держать под контролем, когда конфигурация не расползается между шаблонами и ручными правками. Для типовых сайтов и сервисов это удобнее организовать на виртуальном хостинге или заранее унифицировать шаблоны серверов.

Cloud-init может тихо переписывать сеть

В облачных образах и VPS cloud-init — одна из самых частых причин, почему конфиг вроде бы исправлен, но после перезагрузки снова пропадает IP. Администратор правит netplan, всё работает до reboot, а затем поведение откатывается назад.

Сначала проверьте, управляет ли сетью cloud-init:

cloud-init status --long
ls -l /etc/cloud/cloud.cfg.d
grep -R "network:" /etc/cloud /etc/netplan 2>/dev/null

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

После изменений полезно проверить, какие сетевые данные увидел cloud-init при загрузке:

grep -R "network config" /var/log/cloud-init*.log
sed -n '1,200p' /var/log/cloud-init.log

Если вы используете облачные шаблоны на VDS, лучше заранее договориться с собой, кто именно будет единственным источником истины для сети: cloud-init, netplan или ручная конфигурация. Смесь подходов почти всегда приводит к плавающим ошибкам.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Когда проблема находится вне ОС

Иногда Linux настроен правильно, но lease не выдаётся по причинам за пределами сервера. Это особенно часто бывает после миграции ВМ, клонирования шаблонов, изменения MAC-адреса или перевода машины в другую VLAN.

• DHCP-сервер в сегменте не работает или недоступен;
• интерфейс попал не в ту VLAN;
• на гипервизоре включена привязка IP к MAC и она не совпадает;
• после клонирования остались stale lease или одинаковый client ID;
• на сетевом оборудовании включён port security;
• DHCP relay настроен неверно;
• в панели провайдера интерфейс отключён или не подключён к нужной сети.

Если у вас есть доступ к панели виртуализации, проверьте attached/disconnected-состояние интерфейса, MAC-адрес, сетевой сегмент и ограничения по spoofing. Такие случаи коварны тем, что внутри гостевой ОС всё выглядит почти правильно, кроме одного факта: IP не приходит.

Пошаговый сценарий восстановления IP

Если нужен короткий runbook без лишней магии, используйте такой порядок:

1. Откройте локальную консоль или KVM.

2. Узнайте фактическое имя интерфейса через ip -br link.

3. Проверьте carrier и состояние линка.

4. Определите, кто управляет сетью: networkd, NetworkManager, ifupdown, cloud-init.

5. Прочитайте журнал именно этого компонента.

6. Проверьте, что DHCP включён для реального интерфейса.

7. Убедитесь, что нет второго менеджера сети.

8. Сделайте ручной тест через dhclient -v ens3 или tcpdump.

9. Если DISCOVER уходит, а OFFER не приходит — проверяйте внешнюю сеть, VLAN и гипервизор.

10. После исправления проверьте, переживает ли конфиг перезагрузку.

Как временно поднять сеть

Бывает, что сервер нужно срочно вернуть в онлайн для SSH, а на полноценную диагностику времени нет. Тогда можно временно назначить статический адрес, если вы точно знаете адрес, маску и gateway своей сети. Это именно временная мера.

ip addr add 192.0.2.10/24 dev ens3
ip route add default via 192.0.2.1
printf 'nameserver 1.1.1.1
' > /etc/resolv.conf

Если после этого сервер оживает, значит L2/L3-связность есть, а проблема действительно ближе к DHCP-клиенту или DHCP-серверу. Если не помогает даже статическая адресация, ищите более базовую неисправность: VLAN, порт, маршрутизацию, security group или фильтрацию на стороне платформы.

Не оставляйте временную ручную адресацию как постоянный костыль. Через несколько недель никто не вспомнит, почему сервер живёт не по стандартной схеме, а следующий reboot снова превратится в инцидент.

Что проверить после исправления

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

ip -br addr
ip route
resolvectl status
ping -c 2 192.0.2.1
journalctl -b -u systemd-networkd --no-pager
systemd-analyze critical-chain network-online.target

Если на сервере работают приложения, которые чувствительны к порядку запуска, проверьте зависимости от network-online.target. Иногда сам DHCP уже починен, но сервисы продолжают падать, потому что стартуют слишком рано.

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

Сценарий Failed to acquire DHCP lease почти всегда разбирается логически и без угадываний. Сначала определяем управляющий стек, затем проверяем линк, журналы, имя интерфейса, конфиг netplan или ifupdown, влияние cloud-init, а уже потом идём во внешнюю сеть.

Самые частые реальные причины — неправильное имя интерфейса, конфликт сетевых менеджеров, перезапись конфигурации через cloud-init и отсутствие ответа от DHCP-сервера из-за VLAN или политики гипервизора. Если идти именно в таком порядке, восстановить IP обычно можно быстро и без хаотичной правки всех сетевых файлов подряд.