Нет сети после перезагрузки: Ubuntu 24.04 и AlmaLinux 9

Сервер, который до перезагрузки отвечал на ping, а после неё молчит, редко бывает загадкой. Обычно виновата одна из пяти вещей, и если проверять их по порядку, ответ находится за минуту. Здесь разобраны два стека, которые реально встречаются на современных машинах: Ubuntu 24.04 LTS, где netplan генерирует конфигурацию для systemd-networkd, и AlmaLinux 9, где всеми интерфейсами управляет NetworkManager. В AlmaLinux 9 нет ни network.service, ни пакета network-scripts, поэтому изрядная часть старых советов там просто не работает.

Консоль нужна раньше, чем она понадобится

Всё дальнейшее предполагает, что вы можете печатать на машине, пока сеть лежит. Если сломан именно SSH, нужен доступ помимо сети: VNC или последовательная консоль в панели управления VPS либо IPMI и последовательный порт на выделенном сервере. Проверьте консоль один раз, пока всё исправно: в три часа ночи узнавать, что пароль к ней никто не задавал, поздно.

Приглашение на вход по последовательной линии включается одинаково в обеих системах:

systemctl enable --now serial-getty@ttyS0.service

А вот загрузчик и ядро туда выводятся по-разному. В Ubuntu 24.04 добавьте console=tty1 console=ttyS0,115200 в GRUB_CMDLINE_LINUX_DEFAULT в файле /etc/default/grub и выполните update-grub. В AlmaLinux 9 используйте grubby, который правит записи всех установленных ядер. В RHEL 9 конфигурацию grub для UEFI вернули в /boot/grub2/, так что путь /boot/efi/EFI/, знакомый по версиям 7 и 8, больше не то место, где её пересобирают.

grubby --update-kernel=ALL --args="console=ttyS0,115200"

Консоли нет, а конфигурацию сети всё равно надо править по SSH? Сначала подготовьте откат. Голый таймер перезагрузки спасёт, только если изменение жило в памяти, поэтому добавьте возврат файла:

cp /etc/netplan/60-static.yaml /root/60-static.yaml.good
systemd-run --on-active=5m /bin/sh -c "cp /root/60-static.yaml.good /etc/netplan/60-static.yaml; systemctl reboot"

Команда напечатает имя временного юнита; остановите этот таймер через systemctl stop, когда убедитесь, что связь жива. В AlmaLinux подстрахуйтесь так же вокруг файла профиля в /etc/NetworkManager/system-connections/, копируя его обратно через cp -p, чтобы сохранились права 600: nmcli пишет правку на диск, и неверный адрес сам по себе переживёт перезагрузку.

Четыре вопроса, именно в таком порядке

ip -br link
ip -br addr
ip route
cat /etc/resolv.conf

Линк, адрес, маршрут, разрешение имён. Каждый пункт зависит от предыдущего, поэтому угадывание стоит времени. Ключ -br печатает по одной строке на интерфейс. На шаге с DNS системы расходятся: в Ubuntu 24.04 именами занимается systemd-resolved и всё показывает resolvectl status, а в AlmaLinux 9 systemd-resolved по умолчанию выключен, /etc/resolv.conf пишет сам NetworkManager, и равнозначная команда там nmcli -f IP4.DNS,IP6.DNS device show enp1s0.

Дальше проверка трафиком, от ближнего к дальнему:

ping -c3 192.0.2.1
ping -c3 1.1.1.1
getent hosts cloudhosting.lv

Шлюз отвечает, а дальше тишина: причина выше по цепочке, а не в вашей конфигурации.

Ubuntu 24.04: netplan и systemd-networkd

Конфигурация лежит в /etc/netplan/*.yaml и читается в порядке имён файлов, поэтому более поздний файл перекрывает одинаковые ключи более раннего, а каждый ключ, который вы не повторили, сохраняет значение из более раннего файла. Netplan 1.0 в 24.04 ругается, если файл доступен на чтение кому-то кроме root, так что поставьте им chmod 600. YAML требует пробелов: одна табуляция ломает разбор, а номер строки в сообщении об ошибке обычно указывает не на неё.

netplan get
netplan generate
netplan status --all

netplan generate проверяет синтаксис и пишет юниты networkd, не трогая работающую сеть. Минимальная статическая конфигурация:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0:
      match:
        macaddress: "52:54:00:11:22:33"
      set-name: enp1s0
      dhcp4: false
      dhcp6: false
      addresses:
        - 192.0.2.10/24
      routes:
        - to: default
          via: 192.0.2.1
      nameservers:
        addresses: [192.0.2.1, 9.9.9.9]

Обратите внимание на routes: вместо gateway4:. Старый ключ объявлен устаревшим, и netplan предупреждает о нём при каждом запуске.

Теперь команда, которая спасает карьеры. netplan try применяет новую конфигурацию, ждёт 120 секунд нажатия Enter и откатывается, если его не нажали. Разорвали собственную SSH-сессию, нажимать Enter уже некому, значит конфигурация вернётся к прежней и машина снова ваша. Два ограничения: нужен интерактивный терминал, и откатывается только то, что менял сам netplan, а не адрес, добавленный руками через ip. netplan apply оставьте на случай, когда вы уже сидите за консолью.

netplan try
networkctl status enp1s0
networkctl reconfigure enp1s0
journalctl -b -u systemd-networkd

Загрузка, замирающая на две минуты на systemd-networkd-wait-online, означает описанный в конфигурации интерфейс, который так и не поднялся, обычно вторую карту, куда ничего не воткнуто. Пометьте её optional: true.

AlmaLinux 9: NetworkManager и nmcli

Ни ifup, ни /etc/init.d/network, а пакет network-scripts из RHEL 9 убрали. NetworkManager всё ещё читает старые файлы ifcfg-, но формат объявлен устаревшим, и всё, что создаёт nmcli, попадает в keyfile в /etc/NetworkManager/system-connections/ с расширением .nmconnection и правами 0600. Начинайте отсюда:

nmcli device status
nmcli -f NAME,DEVICE,AUTOCONNECT,ACTIVE connection show
journalctl -b -u NetworkManager

Самый частый виновник виден в третьей колонке: профиль с autoconnect no. Поднятый руками, он работает идеально, а при загрузке не применяется. Такое оставляют инсталляторы, клонирование виртуальных машин и nmcli connection add без этого флага.

nmcli connection modify "enp1s0" connection.autoconnect yes
nmcli connection modify "enp1s0" ipv4.method manual ipv4.addresses 192.0.2.10/24 ipv4.gateway 192.0.2.1 ipv4.dns "192.0.2.1 9.9.9.9"
nmcli connection up "enp1s0"

modify пишет файл, но не трогает активное соединение. После него выполните connection up или nmcli device reapply enp1s0, иначе будете проверять изменение, которого ещё нет. Правили keyfile редактором? Сначала nmcli connection reload, чтобы NetworkManager его перечитал.

Вторая классика: два профиля на одно устройство, рядом с вашим статическим остаётся «Wired connection 1». Оба поднимаются автоматически, выигрывает один, и решать это жребием не стоит. Лишний удалите через nmcli connection delete uuid ... или расставьте connection.autoconnect-priority. За консолью то же самое делает nmtui, и там сложнее ошибиться в наборе.

DNS здесь идёт мимо systemd-resolved. В AlmaLinux 9 эта служба выключена, пока вы не включите её сами, а /etc/resolv.conf пишет сам NetworkManager: обычный файл, первая строка которого # Generated by NetworkManager. Так и должно быть, превращать его в симлинк не надо. resolvectl приезжает отдельным пакетом, поэтому его может не оказаться, а если он есть, на нетронутой машине он покажет пустое состояние DNS, хотя имена через glibc разрешаются прекрасно. Проверяйте то, что реально обслуживает сервер:

cat /etc/resolv.conf
nmcli -f IP4.DNS,IP6.DNS device show enp1s0
getent hosts cloudhosting.lv

Пустой файл или файл с резолверами прежнего провайдера означает, что в профиле прописаны не те серверы: задайте их через nmcli connection modify "enp1s0" ipv4.dns "192.0.2.1 9.9.9.9" и поднимите соединение заново. Если их раз за разом перетирает ответ DHCP, добавьте ipv4.ignore-auto-dns yes. Отсюда и берётся знакомая картина: по IP работает, по имени нет.

cloud-init возвращает старую конфигурацию

Признак: правка работает, после перезагрузки старая конфигурация на месте, а ваш файл переписан. В облачных образах обеих систем cloud-init заново генерирует сетевую конфигурацию при загрузке: в Ubuntu это /etc/netplan/50-cloud-init.yaml, в AlmaLinux профили NetworkManager.

cloud-init status --long
head -5 /etc/netplan/50-cloud-init.yaml

Отключается созданием /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg с одной строкой:

network: {config: disabled}

Дальше кладите свою конфигурацию в отдельный файл, который сортируется после cloud-init, например /etc/netplan/60-static.yaml, снова с правами 600. Сам файл cloud-init не трогайте: если образ когда-нибудь развернут заново, выжить должен ваш. Здесь есть ловушка: netplan объединяет оба файла для одного интерфейса по ключам, а не заменяет один другим. Сопоставление идёт по идентификатору интерфейса, поэтому сначала загляните в файл cloud-init и возьмите ровно тот идентификатор, который записан там, eth0, enp1s0 или какой окажется. Другой идентификатор для той же карты даёт два отдельных описания вместо одного переопределения, и dhcp4: true из cloud-init продолжает работать. Всё, что вы не повторили, продолжает действовать, и больнее всего бьёт dhcp4: true из облачного образа. Оставите его, и на одной карте одновременно работают ваш статический адрес и DHCP-клиент: два маршрута по умолчанию с непредсказуемыми метриками, выданные по DHCP серверы имён спорят с вашими, а поведение меняется от загрузки к загрузке. Поэтому в примере выше явно прописаны dhcp4: false и dhcp6: false. Итог слияния показывает netplan get: он печатает общее дерево, а не отдельный файл.

У интерфейса другое имя, чем вчера

Предсказуемые имена собираются из данных прошивки и топологии PCI, поэтому enp1s0 превращается в ens18 после установки новой сетевой карты, смены модели виртуальной карты или переноса диска в другое железо. В конфигурации описан интерфейс, которого нет, значит не настраивается ничего, а ip -br link показывает незнакомца.

ip -br link
udevadm info -q property /sys/class/net/ens18 | grep ID_NET_NAME

Спрашивайте про то имя, которое реально печатает ip -br link, а не про записанное в конфигурации: старого интерфейса в sysfs уже нет, и udevadm ответит только ошибкой про неизвестное устройство. Значения ID_NET_NAME_* в выводе показывают варианты, из которых выбирал udev, и по ним видно, откуда взято имя: из слота, из пути PCI или из MAC-адреса.

Правьте конфигурацию, а не пытайтесь переименовать мир обратно: в Ubuntu сопоставляйте по macaddress вместе с set-name, как выше, в AlmaLinux задайте connection.interface-name или привяжите профиль к карте через 802-3-ethernet.mac-address. Оговорка для тех, кто делает шаблоны виртуальных машин: клонирование меняет MAC, и сопоставление по MAC перестаёт совпадать с чем-либо. В шаблонах надёжнее шаблон имени или DHCP.

Когда ping идёт, а SSH нет

Значит с сетью всё в порядке и вы отлаживаете не тот уровень.

ss -tlnp | grep :22
systemctl status ssh.service ssh.socket
systemctl status sshd

В Ubuntu 24.04 OpenSSH перевели на активацию сокетом, поэтому там нужна вторая команда, а в AlmaLinux третья. Последствие удивляет: директива Port в sshd_config на 24.04 игнорируется, потому что слушает юнит сокета. Выполните systemctl edit ssh.socket, задайте пустой ListenStream=, чтобы сбросить значение по умолчанию, и следом ListenStream=2222. В AlmaLinux 9 нестандартный порт должен одобрить ещё и SELinux: semanage port -a -t ssh_port_t -p tcp 2222 из пакета policycoreutils-python-utils.

Остаются правила фаервола. В AlmaLinux всё, что добавлено через firewall-cmd без --permanent, после перезагрузки исчезает; firewall-cmd --runtime-to-permanent сохраняет то, что действует сейчас.

Проверьте, что починка переживёт перезагрузку

Сеть, поднятая через ip addr add, не починена, она взята взаймы до следующей загрузки. Когда конфигурация верна, перезагрузитесь намеренно, с открытой консолью, в выбранное вами время. Потом убедитесь, что службы, которые поднимают сеть, вообще включены, первая строка для Ubuntu, вторая для AlmaLinux, где systemd-resolved в проверку намеренно не включён, потому что на здоровой машине он выключен:

systemctl is-enabled systemd-networkd systemd-resolved
systemctl is-enabled NetworkManager
ip -br addr; ip route

Копию рабочей конфигурации с адресом, шлюзом и именем интерфейса держите вне сервера. Это превращает плохую ночь в пять минут набора текста. Если сервер в нашем дата-центре в Риге после всего этого молчит, наши инженеры на связи круглосуточно, а IT-поддержка зайдёт по консоли и посмотрит вместе с вами.