Нет сети после обновления Ubuntu: как вернуть доступ

Нет сети после обновления Ubuntu: что проверять в первую очередь

Нет сети после обновления Ubuntu почти всегда сводится к одной из четырёх причин: интерфейс поднялся под другим именем, cloud-init переписал конфигурацию, сменился рендерер netplan, или в /etc/netplan остался файл от старой системы. Проверить любую из них можно только с самой машины, потому что SSH уже не отвечает. Начните с консоли провайдера, а диагностику отложите до приглашения на вход.

Сразу уберём один ложный след. Речь здесь не про ошибки синтаксиса в YAML. Если netplan generate печатает ошибку разбора файла, это отдельная проблема, и обновление к ней отношения не имеет.

Как зайти на сервер, если SSH не отвечает

Консоль в панели провайдера (VNC или последовательная консоль) подключается к виртуальному монитору и клавиатуре машины. Она работает, даже когда у интерфейса нет адреса, потому что сеть гостя ей не нужна вообще. Последовательная консоль удобнее: в ней есть прокрутка и копирование текста, а вывод netplan status длинный.

Перед этим потратьте полминуты и отличите два разных отказа:

• ssh: connect to host ... port 22: Connection refused означает, что пакеты дошли и машина ответила отказом. Сеть жива, а вот sshd не запущен.
• ssh: connect to host ... port 22: Connection timed out означает, что ответа нет вообще. Вот это похоже на потерю сети.

Разница важна, и она разобрана отдельно: чем connection refused отличается от timed out.

Главная неприятность консоли в том, что она требует локальный пароль. На образах VPS вход обычно только по ключу, у root пароль не задан, и консоль встретит вас приглашением, на которое нечего ответить. Пароль задаётся заранее, до обновления: как сменить пароль root на VPS. Если пользователь вообще не был создан, это отдельная история: cloud-init не создал пользователя, и войти нечем.

Что делать, если консоли не хватает

Консоль бесполезна, когда система не доходит до приглашения входа: обновление прервалось или корневая файловая система не монтируется. Тогда остаётся режим восстановления (rescue mode) в панели провайдера. Он загружает машину с отдельного образа, а ваш диск отдаёт как обычный блочный.

lsblk -f
sudo mount /dev/vda1 /mnt
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt /bin/bash

lsblk -f печатает метки и типы файловых систем, по ним и выбирайте раздел. Имя устройства зависит от гипервизора: на KVM это чаще всего /dev/vda1, но встречается и /dev/sda1. Привязка /dev, /proc и /sys нужна, потому что без них внутри chroot не заработают ни apt, ни systemctl. Внутри chroot можно задать пароль командой passwd, и тогда обычная консоль вас пустит.

Если обновление остановилось на полпути, чинить надо его, а не сеть: как доделать прерванное обновление релиза.

Сначала прочитайте состояние, потом правьте файлы

Дальше идёт самая важная часть. Не правьте /etc/netplan по памяти. Сначала посмотрите, что на машине есть сейчас.

ip -br link
ip -br addr
ip route
ls -l /etc/netplan/

ip -br link печатает по строке на интерфейс: имя, состояние (UP или DOWN) и MAC-адрес. Выпишите имена. ip -br addr показывает, кому достался адрес. Пустая колонка адресов у единственного физического интерфейса плюс отсутствие маршрута по умолчанию в ip route это и есть ваша поломка.

Теперь спросите netplan, что думает он:

sudo netplan get
sudo netplan status --all
networkctl list
systemctl is-enabled systemd-networkd NetworkManager

netplan get склеивает все файлы из /etc/netplan и печатает итоговую конфигурацию. Содержимое одного файла ей не равно: файлы читаются в лексическом порядке, и поздний перекрывает ранний по совпадающим ключам. netplan status --all сопоставляет конфигурацию с живым состоянием системы. В netplan 1.x есть ещё sudo netplan status --diff, который печатает только расхождения. Если ваша версия его не знает, она сообщит о неизвестном аргументе, и тогда сравнивайте глазами.

Сравните два списка имён: те, что вернул ip -br link, и те, что вернул netplan get. Если они не совпадают, ответ уже найден.

Почему интерфейс вернулся под другим именем

Имена вроде ens3, enp1s0 или eth0 назначает systemd-udevd по данным о шине и прошивке, а не ядро. Правила выбора зависят от версии systemd, а обновление релиза меняет systemd целиком: в Ubuntu 26.04 LTS это systemd 259. Меняется и виртуальное железо, если провайдер обновил тип машины или порядок устройств PCI. Результат: файл netplan описывает ens3, в системе появился enp1s0, и настраивать оказывается нечего.

Посмотрите, что происходило при загрузке:

sudo dmesg | grep -iE 'renamed|eth[0-9]'
sudo udevadm test-builtin net_id /sys/class/net/enp1s0

В журнале ядра переименование выглядит примерно так: virtio_net virtio0 enp1s0: renamed from eth0. Подставьте в команду udevadm то имя, которое реально есть у вас. Она печатает все имена-кандидаты (ID_NET_NAME_PATH, ID_NET_NAME_SLOT и подобные), из которых и выбирается итоговое.

Самое надёжное лечение это привязка к MAC-адресу, потому что MAC переживает и смену шины, и смену systemd:

network:
  version: 2
  ethernets:
    main0:
      match:
        macaddress: "52:54:00:aa:bb:cc"
      set-name: main0
      dhcp4: true

MAC возьмите из вывода ip -br link, он там в последней колонке. Быстрый вариант это просто вписать новое имя вместо старого. Он работает, но следующее обновление может повторить тот же фокус.

Есть и третий путь: добавить net.ifnames=0 в параметры ядра и получить eth0. Он отключает предсказуемые имена целиком, поэтому при двух и более интерфейсах порядок eth0 и eth1 становится зависимым от порядка обнаружения устройств. На машине с одним интерфейсом это приемлемо, на машине с приватной сетью уже нет.

Почему cloud-init переписал ваш netplan

На образах VPS сетью почти всегда управляет cloud-init. Он берёт метаданные у провайдера и пишет /etc/netplan/50-cloud-init.yaml сам. Откройте файл: первые строки честно предупреждают, что он сгенерирован из данных источника и правки будут потеряны.

head -3 /etc/netplan/50-cloud-init.yaml
cloud-init status --long
sudo grep -iE 'netplan|network' /var/log/cloud-init.log | tail -40

Обновление релиза ставит новую версию cloud-init (в Ubuntu 26.04 LTS это cloud-init 26.1) и заново проходит этапы настройки. Если ваши правки лежали в этом файле, после перезагрузки на их месте будет то, что вернули метаданные. Иногда это рабочая конфигурация с другим именем интерфейса, иногда пустая.

Два честных решения. Первое: не трогать 50-cloud-init.yaml, а положить свои настройки в файл с большим номером, например /etc/netplan/99-static.yaml, который перекроет нужные ключи. Второе: отключить сетевой модуль cloud-init совсем.

printf 'network: {config: disabled}\n' | sudo tee /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

Отключение означает, что при пересоздании или переносе машины сеть из метаданных больше не приедет, и адрес придётся прописывать руками. Это осознанный размен, а не улучшение. Что ещё делает cloud-init на свежей машине, разобрано здесь: как cloud-init настраивает новый VPS.

Заодно про права на файлы. Начиная с netplan 0.106 команда предупреждает строкой вида Permissions for /etc/netplan/50-cloud-init.yaml are too open. Netplan configuration should NOT be accessible by others. Это предупреждение, а не причина отказа сети: конфигурация применяется и с открытыми правами. Многие тратят на него время зря. Закрыть его можно одной командой:

sudo chmod 600 /etc/netplan/*.yaml

Почему сменился рендерер

netplan ничего не настраивает сам. Он генерирует конфигурацию для бэкенда: systemd-networkd на серверах, NetworkManager на десктопах. Выбор задаётся ключом renderer. Если в файле назван бэкенд, который не установлен или не включён, netplan послушно сгенерирует файлы, и применять их будет некому.

sudo netplan generate
ls -l /run/systemd/network/
systemctl status systemd-networkd
journalctl -u systemd-networkd -b --no-pager | tail -40

После netplan generate в /run/systemd/network/ должны появиться файлы вида 10-netplan-enp1s0.network. Пустой каталог при непустом выводе netplan get означает, что рендерер не networkd. Дальше смотрите systemctl status systemd-networkd: строка Active: inactive (dead) или пометка masked объясняет молчание интерфейса лучше любой догадки.

Чужие файлы, которые пережили обновление

do-release-upgrade спрашивает про каждый изменённый конфигурационный файл и по умолчанию оставляет вашу версию, сохраняя новую рядом. За несколько лет таких пар накапливается много.

sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-old' -o -name '*.ucf-old'
dpkg -l ifupdown | tail -1
ls /etc/network/interfaces /etc/network/interfaces.d/ 2>/dev/null

netplan читает только файлы *.yaml, поэтому 50-cloud-init.yaml.dpkg-old он проигнорирует. А вот выживший пакет ifupdown вместе с /etc/network/interfaces это настоящий конфликт: два менеджера поднимают один интерфейс, и кто окажется последним, зависит от порядка юнитов. Если dpkg -l отвечает no packages found matching ifupdown, пакета нет и этот пункт можно закрыть. Если файл есть и описывает только lo, он безвреден. Если в нём описан физический интерфейс, выберите одного управляющего и уберите второго.

Отдельно про Ubuntu 26.04 LTS. В примечаниях к выпуску описана известная проблема: интерфейсы, оставшиеся ненастроенными на этапе установки, считаются DHCP-интерфейсами, и загрузка блокируется на ожидании сети. На консоли это выглядит как строка A start job is running for Wait for Network to be Configured. Лечится пометкой лишнего интерфейса как необязательного:

network:
  version: 2
  ethernets:
    enp2s0:
      dhcp4: true
      optional: true

optional: true говорит systemd-networkd-wait-online не ждать этот интерфейс. Загрузка перестаёт висеть, и до sshd дело доходит заметно быстрее.

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

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

sudo ip link set enp1s0 up
sudo ip addr add 203.0.113.10/24 dev enp1s0
sudo ip route add default via 203.0.113.1
sudo resolvectl dns enp1s0 1.1.1.1
ping -c 3 203.0.113.1
ping -c 3 1.1.1.1

Подставьте своё имя интерфейса, свой адрес и свой шлюз: они есть в панели провайдера. Если первый ping проходит, а второй нет, дело в маршруте по умолчанию или выше по сети, а не в интерфейсе. Всё это живёт до перезагрузки, потому что команды ip ничего не записывают на диск. Это и хорошо: ошибочная команда лечится перезагрузкой.

Как убедиться, что настройка переживёт перезагрузку

sudo netplan generate
sudo netplan apply
ip -br addr
ip route

Когда SSH вернулся, правьте конфигурацию только через sudo netplan try. Команда применяет файл, ждёт подтверждения около двух минут и откатывает всё обратно, если вы не нажали Enter. Оборвавшаяся сессия SSH при этом равна отказу от подтверждения, и сеть вернётся сама.

Последняя проверка это честная перезагрузка с открытой консолью:

sudo reboot

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

Десять минут подготовки перед do-release-upgrade

Всё описанное выше дешевле предотвратить.

1. Снимите текущее состояние сети в файл и сохраните его за пределами сервера. ip -br link, ip -br addr и ip route дают имена, MAC-адреса, адреса и шлюз.
2. Скопируйте конфигурацию: sudo cp -a /etc/netplan ~/netplan-backup, затем заберите копию к себе на машину.
3. Проверьте консоль провайдера заранее и убедитесь, что знаете пароль локального пользователя. Консоль, которую вы открываете впервые в момент аварии, редко радует.
4. Сделайте снимок диска, если провайдер это умеет. Откат снимка быстрее любой починки.
5. Откройте в брандмауэре порт 1022 до начала обновления.

Про последний пункт. Запущенный по SSH do-release-upgrade предупреждает, что поднимет второй sshd на порту 1022 специально для аварийного входа. Помогает это только тогда, когда порт открыт: sudo ufw allow 1022/tcp, а на многих VPS ещё и в сетевом брандмауэре панели, который живёт отдельно от ufw.

Держите вторую сессию SSH открытой всё время обновления. Открытая сессия переживает перезапуск sshd и остаётся рабочей тогда, когда новые подключения уже не проходят.

Сам порядок обновления и его подводные камни разобраны отдельно: обновление Ubuntu 24.04 до 26.04 по шагам. А если сервер старый и накопил много ручных правок, иногда честнее собрать новый: обновлять или переустанавливать сервер.

FAQ

Почему после обновления Ubuntu пропала сеть, хотя сервер загрузился?

Чаще всего интерфейс получил другое имя, а файл в /etc/netplan описывает старое. netplan настраивает то, что в нём написано, и молча ничего не делает для интерфейса, которого в конфигурации нет. Зайдите через консоль провайдера, выполните ip -br link и sudo netplan get и сравните имена. Реже виноваты переписанный cloud-init файл, невключённый systemd-networkd или оставшийся от старой системы /etc/network/interfaces.

Как попасть на сервер, если SSH не отвечает, а пароля root я не знаю?

Через консоль провайдера войти не выйдет, потому что она требует локальный пароль. Остаётся режим восстановления: загрузите машину с аварийного образа, смонтируйте корневой раздел, сделайте chroot и задайте пароль командой passwd. После этого обычная консоль вас пустит. Правильнее задать пароль заранее, до обновления, и один раз проверить, что вход через консоль работает.

Почему исчезли мои правки в /etc/netplan/50-cloud-init.yaml?

Этот файл принадлежит cloud-init, и его первые строки об этом предупреждают. cloud-init перегенерирует его из метаданных провайдера, а обновление релиза ставит новую версию cloud-init и заново проходит настройку. Кладите свои параметры в отдельный файл с большим номером, например 99-static.yaml, либо отключите сетевой модуль строкой network: {config: disabled} в /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg.

Сервер висит на сообщении Wait for Network to be Configured. Сколько ждать?

Ждать почти бессмысленно: systemd-networkd-wait-online ждёт интерфейс, который не поднимется. Загрузка продолжится по таймауту, но каждая перезагрузка будет стоить минут. Найдите интерфейс, которого нет в системе или который никуда не подключён, и пометьте его optional: true в netplan. В примечаниях к выпуску Ubuntu 26.04 LTS это описано как известная проблема для интерфейсов, не настроенных при установке.