Debian/Ubuntu: восстановление сети при сбое netplan и systemd-networkd — диагностика и аварийный доступ

Когда «network not coming up»: симптомы и что важно понять

Ситуация типовая: после изменения сетевых настроек (особенно на Ubuntu с netplan) сервер внезапно перестаёт отвечать по сети. Снаружи это выглядит как «не пингуется», «SSH не подключается», «маршрута нет». В логах и статусах — от молчаливого «всё ok» до явных ошибок YAML.

Цель первой диагностики — быстро выяснить три вещи:

• какой интерфейс должен быть uplink и как он реально называется (например, ens3, eth0, enp1s0);
• кто именно управляет сетью: systemd-networkd, NetworkManager, классический ifupdown/networking или смесь;
• на каком уровне ломается связность: линк не поднялся, IP не назначился, default route отсутствует, DNS не резолвит.

Дальше — практический чек-лист для работы из консоли: локально, через консоль провайдера или в rescue/recovery.

Шаг 0. Не усугубляйте: как безопасно применять изменения netplan

Если доступ ещё есть, используйте «ремень безопасности» для netplan: интерактивную проверку. Она откатит конфиг, если вы не подтвердили, что сеть жива.

sudo netplan try

Перед применением полезно сначала сгенерировать файлы и применить с отладкой — так вы сразу увидите конфликт renderer’ов, неверное имя интерфейса, «двойной» gateway и ошибки YAML:

sudo netplan generate
sudo netplan --debug apply

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

Шаг 1. Проверка линка и имени интерфейса: ip link, ip addr

Одна из самых частых причин «всё применилось, но сети нет» — вы настраиваете не тот интерфейс (после миграции/обновления меняются предсказуемые имена) или он в состоянии DOWN.

ip link
ip addr

Что смотреть:

• интерфейс должен быть UP (административно) и желательно LOWER_UP (линк поднят);
• на интерфейсе должен быть корректный IPv4/IPv6 адрес (или ожидаемая конфигурация через DHCP);
• не перепутайте lo, docker0, br-* и реальный uplink.

Если интерфейс «админски down», временно поднимите его вручную (это не заменяет правильный конфиг, но иногда даёт возможность вернуть доступ):

sudo ip link set dev ens3 up

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

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

Подробнее

Шаг 2. Проверка маршрутов и default gateway

Даже с правильным IP сервер будет «вне сети», если нет маршрута по умолчанию или он указывает не туда (например, добавили второй gateway или указали неверную подсеть).

ip route
ip -6 route

Минимальная «здоровая» картина для IPv4 — наличие строки default via ... dev .... Если default route отсутствует, временно можно добавить его вручную (до исправления netplan/systemd-networkd):

sudo ip route add default via 192.0.2.1 dev ens3

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

Шаг 3. Кто управляет сетью: systemd-networkd, NetworkManager или networking

Дальше критично понять, какой «движок» в системе должен поднимать интерфейсы. В Ubuntu Server обычно связка netplan + renderer (systemd-networkd или NetworkManager). В Debian часто встречается ifupdown (файл /etc/network/interfaces), но на новых установках тоже бывает systemd-networkd.

Быстрые проверки:

systemctl is-enabled systemd-networkd
systemctl is-active systemd-networkd
systemctl is-enabled NetworkManager
systemctl is-active NetworkManager

И для классической службы (актуально для ifupdown):

systemctl status networking

Если одновременно активны NetworkManager и systemd-networkd, и оба «трогают» один и тот же интерфейс, получите неустойчивое поведение: адрес то есть, то нет, маршрут «прыгает», DNS ломается. Для сервера обычно выбирают один подход и придерживаются его.

Шаг 4. Диагностика systemd-networkd: networkctl и журналы

Если используется systemd-networkd, смотрите статус через инструменты systemd, а не «по ощущениям».

networkctl list
networkctl status

Журналы по текущей загрузке:

journalctl -u systemd-networkd --no-pager -b

Типовые подсказки в логах:

• «Could not set address» — конфликт адреса/маски, дубликат адреса, неверная подсеть;
• «DHCPv4 lease lost» — DHCP не отвечает, нет линка, проблема на стороне сети/виртуального коммутатора;
• «Link is not ready» — интерфейс не видит линк (или виртуальный порт down);
• ошибка чтения конфигурации — если netplan сгенерировал некорректные файлы.

Шаг 5. Диагностика netplan: YAML, имена интерфейсов и итоговая генерация

У netplan две самые частые проблемы: синтаксис YAML (отступы, табы, двоеточия) и несоответствие имён интерфейсов. Файлы обычно лежат в /etc/netplan/.

ls -la /etc/netplan
sudo netplan --debug generate

Если netplan generate падает — исправляйте до применения. Если generate успешен, но после netplan apply сеть не поднимается, значит проблема чаще в логике: маршруты/gateway, неверный renderer, конфликт с другим менеджером.

Полезно посмотреть, что именно netplan сгенерировал для systemd-networkd (если выбран этот renderer):

ls -la /run/systemd/network

Это временная директория, но она быстро показывает, какой итоговый конфиг получает systemd-networkd.

Шаг 6. Быстрое временное восстановление доступа: поднять сеть вручную

Когда задача — срочно вернуть доступ (чтобы дальше чинить конфиг спокойно), можно временно поднять интерфейс вручную через ip. Это «одноразовая» настройка: после перезагрузки исчезнет, зато часто хватает, чтобы снова подключиться по SSH.

Пример: поднять интерфейс, назначить IP и маршрут:

sudo ip link set dev ens3 up
sudo ip addr add 198.51.100.10/24 dev ens3
sudo ip route add default via 198.51.100.1

Если после этого пингуется шлюз, но «имена не резолвятся», проверьте текущие DNS-настройки:

cat /etc/resolv.conf

Важно: ручное поднятие — только чтобы вернуть управление. После восстановления доступа исправьте постоянную конфигурацию (netplan или /etc/network/interfaces) и перепроверьте логи.

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

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

Подробнее

Аварийный доступ: что делать, если SSH уже недоступен

Если сеть уже «отрезана», остаются сценарии аварийного доступа. На виртуальных серверах чаще всего выручает консоль провайдера или rescue/recovery режим.

1) Подключение через консоль и вход в систему

Через консоль вы попадаете на локальный логин. Дальше идите по чек-листу: ip link, ip addr, ip route, затем journalctl и статусы сервисов.

Если интерфейс называется не так, как в конфиге, это почти всегда объясняет, почему netplan apply «успешен», но сеть не появляется.

2) Rescue/recovery и правка конфигов на диске

В rescue-ОС логика простая: смонтировать диск системы и поправить сетевые файлы, затем перезагрузиться в основную ОС.

Минимальный «скелет» команд (устройства подставьте свои):

lsblk -f
sudo mount /dev/vda1 /mnt
sudo ls -la /mnt/etc/netplan
sudo nano /mnt/etc/netplan/01-netcfg.yaml

Если на системе используется systemd-networkd без netplan (часто в Debian), правки могут быть в /etc/systemd/network/:

sudo ls -la /mnt/etc/systemd/network

После исправлений — перезагрузка в основную систему. Если конфиг валиден и соответствует именам интерфейсов, SSH вернётся без дополнительных действий.

3) Быстрый откат: вернуть предыдущий конфиг

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

Проверьте набор файлов и порядок:

ls -la /etc/netplan

Иногда «лишний» файл с более высоким приоритетом (по имени, лексикографически) переопределяет ожидаемую конфигурацию.

Частые причины, почему сеть не поднимается после netplan apply

Неправильное имя интерфейса

После миграции/изменения виртуального оборудования интерфейс мог стать, например, ens18 вместо ens3. Проверяйте через ip link и правьте конфиг по факту.

Конфликт renderer: networkd vs NetworkManager

На сервере обычно выбирают systemd-networkd. Если параллельно активен NetworkManager и он управляет тем же интерфейсом, получаете нестабильность: адрес/маршрут/DNS меняются «сами».

Два gateway или неверная логика маршрутов

Частая ошибка — задать gateway4 в нескольких местах или одновременно описать дефолтный маршрут и gateway, получив конфликт. В итоге ip route не соответствует ожиданиям, а внешняя доступность пропадает.

Ошибки YAML и «тихие» опечатки

YAML не прощает табы и кривые отступы. Всегда прогоняйте netplan generate перед применением. Если конфиг маленький — часто быстрее перепечатать ключевые строки аккуратно, чем искать невидимый символ.

Линк не поднят или проблема на уровне гипервизора/порта

Если в ip link нет LOWER_UP, а в логах «Link is not ready», причина может быть не в ОС, а в состоянии порта/сети. Пока линка нет, любые попытки настроить IP в ОС не помогут.

Контрольный чек-лист (распечатать и держать под рукой)

1. Смотрим интерфейсы и их состояние:

   ip link
   ip addr

2. Проверяем маршруты:

   ip route
   ip -6 route

3. Понимаем, кто управляет сетью:

   systemctl status networking
   systemctl status systemd-networkd
   systemctl status NetworkManager

4. Если systemd-networkd — проверяем статус и логи:

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

5. Если netplan — проверяем генерацию и применяем с отладкой:

   sudo netplan generate
   sudo netplan --debug apply

6. Если нужно срочно вернуть доступ — временно поднимаем сеть вручную через ip, затем приводим в порядок постоянный конфиг.

Как снизить риск повторения в продакшене

Чтобы следующий netplan apply не превращался в лотерею:

• делайте бэкап файлов из /etc/netplan перед изменениями;
• применяйте изменения через netplan try, особенно на удалённых серверах;
• зафиксируйте, какой renderer используется, и не смешивайте сетевые менеджеры без необходимости;
• после изменений сразу проверяйте ip route и доступность шлюза;
• держите доступ к аварийной консоли провайдера и заранее проверьте, что вход работает.

Если сеть «падает» у приложения, а не у ОС (например, PHP-сайты отваливаются из-за таймаутов и подвисаний), полезно отдельно включить диагностику на уровне сервиса: смотрите руководство по диагностике PHP-FPM через slowlog в продакшене.

А если у вас внешние зависимости и статика, иногда проблема выглядит как «сеть сломалась», хотя это кэш/объектное хранилище и гонки версий. На этот случай держите под рукой материал про версионирование статики и борьбу с кэшем CDN.