systemd-networkd на VDS: пропал интернет после reboot — DHCP, cloud-init и метрики маршрутов

Ситуация «после reboot нет сети» на сервере — одна из самых неприятных: по SSH не зайти, а в консоли видно, что интерфейс вроде бы поднят. В современных Debian/Ubuntu сеть часто строится вокруг systemd-networkd, но поверх него могут вмешиваться netplan и cloud-init. Добавьте DHCP, несколько интерфейсов (публичный/приватный), IPv6 — и получите сценарий, когда default route исчезает или выбирается «не туда».

Ниже — практичный чек-лист: как быстро понять, где сломалось (линк, DHCP, маршруты, DNS), как вычислить конфликтующих «управляющих», и как закрепить конфигурацию так, чтобы после перезагрузки сеть поднималась предсказуемо.

Типовые симптомы и причины: «интерфейс есть, интернета нет»

Чаще всего это выглядит так:

• интерфейс в состоянии UP, но пакеты наружу не ходят;
• IP по DHCP получен, а шлюза (Gateway) нет;
• маршрут по умолчанию есть, но выбран не тот интерфейс из-за метрики;
• маршруты в порядке, но не работает DNS: домены не резолвятся.

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

• cloud-init перегенерирует сеть при загрузке и перетирает ваши настройки;
• netplan генерирует конфиги для networkd, а вы параллельно ведёте свои файлы в /etc/systemd/network/;
• двойной DHCP: одновременно работают systemd-networkd и, например, dhclient, NetworkManager или другой агент;
• метрики маршрутов приводят к выбору «неправильного» default route;
• DNS-слой сломан из-за рассинхрона /etc/resolv.conf и systemd-resolved.

Быстрая диагностика: networkctl, маршруты и логи

Команды ниже безопасны: они ничего не меняют, только показывают состояние.

1) Проверяем линк, адреса и шлюз

networkctl list
networkctl status

Найдите нужный интерфейс (часто ens3, eth0, enp1s0) и проверьте:

• есть ли IPv4/IPv6 адрес;
• есть ли Gateway;
• какой статус DHCP и что именно он принёс.

2) Смотрим маршруты и метрики

ip route
ip -6 route

Ключевая строка для IPv4 — default via X.X.X.X dev IFACE metric N. Если default route отсутствует — «интернета» не будет. Если их несколько — выигрывает маршрут с меньшей метрикой (в Linux «меньше = приоритетнее»).

3) Смотрим логи systemd-networkd

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

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

4) Проверяем, кто ещё управляет сетью

systemctl is-active systemd-networkd
systemctl is-active NetworkManager
systemctl is-active networking

Для сервера почти всегда правильно оставить одного «главного». Одновременная активность NetworkManager и networkd — типичный источник нестабильности после перезагрузки.

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

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

Подробнее

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

cloud-init и netplan: кто генерирует сеть и почему это ломает reboot

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

Проверяем netplan и его «источник правды»

ls -la /etc/netplan
netplan get

Если в /etc/netplan есть YAML — вероятно, именно он должен быть главным источником конфигурации. В таком случае «ручные» файлы networkd лучше либо не использовать, либо делать так, чтобы они не дублировали настройки (иначе после reboot поведение может зависеть от порядка применения).

Проверяем, трогал ли cloud-init сеть

cloud-init status --long
journalctl -u cloud-init -b --no-pager
journalctl -u cloud-init-local -b --no-pager

Если cloud-init продолжает применять network config на каждой загрузке, он будет откатывать ваши изменения. Для админов, которые собирают «эталонные» образы, полезно вынести подход в отдельный процесс и проверить, что сеть воспроизводима: см. статью про сборку образа с cloud-init и packer.

Практическое правило: выберите один слой управления сетью (netplan или чистый systemd-networkd) и уберите автоматическую перегенерацию там, где она не нужна. Тогда после reboot поведение будет повторяемым.

Если cloud-init мешает: отключаем только сетевой модуль

Частый и безопасный подход — запретить cloud-init трогать сеть, не выключая его целиком. Проверьте каталог конфигов:

ls -la /etc/cloud/cloud.cfg.d

Затем создайте файл, отключающий сетевую конфигурацию cloud-init:

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

Важно: делайте это только имея доступ к консоли провайдера. Любая ошибка в сетевых файлах может отрезать SSH до следующего вмешательства через панель или serial-консоль.

systemd-networkd + DHCP: рабочие конфиги и типовые «грабли»

Если вы используете «чистый» systemd-networkd, обычно нужен один .network-файл на интерфейс. Критичная настройка для многосетевых VDS — метрики: WAN должна иметь меньшую метрику, LAN — большую, либо LAN вообще не должна приносить default gateway.

Минимальный DHCP-конфиг для публичного интерфейса (WAN)

sudo tee /etc/systemd/network/10-wan.network > /dev/null <<'EOF'
[Match]
Name=ens3

[Network]
DHCP=yes

[DHCPv4]
UseDNS=yes
RouteMetric=100
EOF

Параметр RouteMetric задаёт приоритет маршрутов, которые придут по DHCP. Чем меньше число — тем выше приоритет.

Второй интерфейс (LAN): запретить default gateway

Если приватная сеть нужна только для внутреннего обмена и не должна становиться выходом в интернет, запретите ей default gateway:

sudo tee /etc/systemd/network/20-lan.network > /dev/null <<'EOF'
[Match]
Name=ens4

[Network]
DHCP=yes

[DHCPv4]
UseRoutes=yes
UseGateway=false
RouteMetric=500
EOF

UseGateway=false не даёт DHCP на приватном интерфейсе подсовывать маршрут по умолчанию.

Применяем и проверяем результат

sudo systemctl restart systemd-networkd
networkctl status ens3
ip route show default

Если после рестарта сеть появляется, а после reboot снова ломается — почти всегда виноват внешний генератор конфигов (cloud-init/netplan) или второй DHCP-клиент.

Отдельно проверьте, что у панели/сайта всё корректно по HTTPS и цепочка сертификатов не «сыпется» после миграций и переустановок: SSL-сертификаты помогают закрыть вопрос с доверием браузеров и клиентов.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Default route есть, но интернета нет: метрики, два шлюза и «побеждает не тот»

Иногда ip route показывает default route, но трафик не ходит. На VDS это чаще всего один из сценариев:

• default route указывает на приватный интерфейс без NAT в интернет;
• есть два default route, и «неправильный» имеет меньшую метрику;
• провайдер выдал IPv6 default route, а IPv4-шлюз не пришёл, и приложения ведут себя неоднозначно.

Быстро увидеть конкурирующие маршруты по умолчанию

ip route show default
ip -6 route show default

Дальше исправление простое: либо выставляете корректные RouteMetric в .network, либо запрещаете default gateway на «неинтернетном» интерфейсе.

Если у вас Ubuntu и сеть через netplan

Для netplan метрика задаётся через DHCP overrides. Пример (как текст):

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: true
      dhcp4-overrides:
        route-metric: 100
    ens4:
      dhcp4: true
      dhcp4-overrides:
        route-metric: 500

Применение делайте аккуратно, лучше через консоль провайдера или с запасным сеансом:

sudo netplan apply

DNS и resolved.conf: когда IP пингуется, а домены нет

Если IP-адреса пингуются, а доменные имена — нет, проблема почти всегда в цепочке /etc/resolv.conf → systemd-resolved → DNS, либо в том, что DHCP принёс неожиданные DNS-сервера.

Проверяем, что у вас в resolv.conf

ls -la /etc/resolv.conf
cat /etc/resolv.conf

Если /etc/resolv.conf — симлинк на /run/systemd/resolve/stub-resolv.conf или /run/systemd/resolve/resolv.conf, значит система ожидает работу через systemd-resolved.

Проверяем systemd-resolved и текущие DNS

systemctl is-active systemd-resolved
resolvectl status

Если systemd-resolved не активен, а resolv.conf указывает на 127.0.0.53, резолвинг работать не будет. Тогда либо включайте resolved, либо переводите систему на статический resolv.conf и следите, чтобы его не перетирал DHCP или агенты.

Тонкость с /etc/systemd/resolved.conf

Файл /etc/systemd/resolved.conf задаёт глобальные DNS-настройки (DNS=, FallbackDNS=). Но если в networkd включён UseDNS=yes, то per-link DNS, полученный по DHCP, часто будет приоритетнее глобальных значений. Поэтому при «после reboot DNS ломается» проверяйте одновременно:

• какие DNS пришли по DHCP (в resolvectl status и логах networkd);
• не отключён ли UseDNS в вашем .network;
• не подменяет ли DNS cloud-init из метаданных.

Контрольный список устойчивости к reboot

1. Определите «источник правды»: netplan или чистый systemd-networkd. Не смешивайте без необходимости.

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

3. Убедитесь, что нет второго менеджера сети или второго DHCP-клиента.

4. Явно задайте метрики: WAN ниже (например, 100), LAN выше (например, 500) или запретите default gateway на LAN через UseGateway=false.

5. Проверьте DNS-цепочку: /etc/resolv.conf соответствует вашей модели, systemd-resolved активен, DNS видны в resolvectl status.

Мини-рукбук, если сервер уже без сети

Если вы уже в состоянии «after reboot no network», действуйте через VNC, serial-консоль или консоль провайдера:

1. Соберите факты: networkctl status, ip route, journalctl -u systemd-networkd -b --no-pager.

2. Выясните, есть ли netplan/cloud-init, и не перетирают ли они конфиги.

3. Временно поднимите сеть самым простым способом (поправьте .network и перезапустите networkd), затем закрепите изменения: устраните конфликтующие генераторы и выровняйте метрики.

Итог

В большинстве случаев «после reboot пропала сеть» при systemd-networkd сводится к одному из трёх: конфликт управления (cloud-init/netplan/NetworkManager), неправильный default route из-за метрик или сломанный DNS-слой (resolved.conf и связка с resolv.conf). Приведите систему к единой модели управления и задайте явные метрики для интерфейсов — и сеть будет подниматься предсказуемо на каждой загрузке.

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