В 2026 году выбор между NetworkManager и systemd-networkd перестал быть «вкусовщиной». Он влияет на предсказуемость загрузки, поведение зависимых сервисов и, главное, на риск потерять доступ при сетевой миграции (особенно по SSH). Чем сложнее конфигурация (VLAN, bonding, несколько таблиц маршрутизации, специфичные метрики), тем важнее понять, кто именно управляет сетью и как он принимает решения.
Ниже — практичное сравнение стеков и план миграции, который минимизирует шанс остаться «снаружи». Будем отталкиваться от серверных кейсов: статический IP, предсказуемый маршрут по умолчанию, аккуратная работа с systemd-networkd-wait-online, плюс контроль DNS и policy routing.
Ключевая разница: модель управления сетью
NetworkManager — менеджер подключений. Он мыслит «профилями», умеет автоконфигурацию, динамическое переключение сетей, интеграции с VPN/802.1X и удобен там, где сеть часто меняется.
systemd-networkd — минималистичный сетевой демон, рассчитанный на декларативные файлы и детерминированное поведение. На headless-серверах его ценят за простую модель, «меньше магии» и хорошую дружбу с systemd-юнитами.
Типичный тренд в 2026: на серверах с постоянной топологией чаще выбирают systemd-networkd, а NetworkManager оставляют для окружений с высокой интерактивностью и «профильной» логикой.
Когда NetworkManager объективно удобнее
- Частая смена сетей: переносимые VM, админские ноутбуки, стенды, где сеть «плавает».
- Нужно быстро менять настройки через nmcli или GUI без отдельной системы управления конфигами.
- VPN/802.1X/корпоративные профили, где NM часто даёт меньше боли «из коробки».
- Историческая база: уже есть отлаженные NM-профили, шаблоны образов и процессы вокруг них.
Риск на серверах — в скрытых автоправилах: при миграции можно не заметить, что изменились метрики маршрутов, приоритеты DNS или порядок применения профилей, и это «выстрелит» только после ребута.
Полезная практика для любых миграций — сначала обеспечить себе запас по доступу (вторая сессия, консоль провайдера, чёткий откат), а уже затем переключать стек. Особенно если сервер — ваш единственный «вход» в инфраструктуру.
Когда systemd-networkd чаще выигрывает на сервере
- Статическая адресация, один или несколько интерфейсов без необходимости автопереключения.
- Минимальные образы, где важны скорость загрузки и прозрачные зависимости systemd.
- Сложные L2/L3: VLAN, bonding, мосты, несколько таблиц маршрутизации, source-based routing.
- Предсказуемость после ребута: меньше внешних компонентов и фоновой «логики подключения».
При этом networkd не «страхует от ошибок»: неверный .network тоже легко лишает сеть. Разница в том, что причины обычно проще воспроизвести: меньше скрытых состояний и меньше попыток угадать «как лучше».
Если вы арендуете VDS и вам важна повторяемость сети после обновлений и перезагрузок, networkd часто удобнее именно как «скучная» предсказуемая база.
netplan в 2026: почему миграции ломаются на ровном месте
netplan сам сеть не поднимает: он генерирует конфигурацию для backend’а — обычно NetworkManager или systemd-networkd. Самая частая причина сюрпризов: админ «настроил netplan», но не понял, какой renderer реально применяется, и затем добавил ручные правки во второй стек.
Два типовых сценария в Ubuntu:
- netplan → systemd-networkd (часто на серверах);
- netplan → NetworkManager (обычно десктопы, но встречается и на серверах после ручных изменений).
Перед миграцией зафиксируйте: кто управляет интерфейсами сейчас, где «источник правды» (YAML netplan, NM-профили или файлы networkd), и какие сервисы завязаны на сетевую готовность.
systemd-networkd-wait-online: как не получить «вечную загрузку»
systemd-networkd-wait-online часто виноват в долгом boot и в том, что юниты «стоят и ждут». Он полезен, когда сервису действительно нужен готовый маршрут или конкретная подсеть к моменту старта, но по умолчанию нередко ждёт то, что вам не нужно (или то, что никогда не станет routable).
Типовые причины зависаний:
- Ожидание интерфейса/адреса, который поднимается позже (VLAN, bridge) или не должен получать адрес вообще.
- DHCP/RA не укладываются в таймауты, и systemd начинает «ронять» зависимости.
- Сервисы описали слишком жёсткую зависимость: им достаточно «link up», а они ждут «полного интернета».
Практическое правило: сначала определите, что именно для вас означает «онлайн» (линк, адрес, дефолтный маршрут, доступность конкретного хоста), и только потом заставляйте systemd это ждать. Иначе вы лечите симптомы.
В продакшне часто правильнее: корректно описать зависимости конкретных юнитов, а глобальное ожидание сети включать только там, где оно реально необходимо, и с явным таймаутом.
SSH loss prevention: базовая страховка перед любыми изменениями
Потеря SSH при миграции почти всегда возникает, когда изменения применяются «сразу в прод» без второго канала доступа и без плана отката. Вот практики, которые реально работают.
Держите план отката как набор команд
Перед любым переключением подготовьте команды, которые вы сможете выполнить через консоль провайдера (или out-of-band). Письменный «revert plan» снижает вероятность паники и ошибок в момент, когда связь уже нестабильна.
Две SSH-сессии и пошаговая проверка
Держите две сессии: в одной применяете изменения, во второй проверяете связность (маршрут до шлюза, дефолтный роут, DNS, доступность вашего bastion). Если вторая сессия умерла — не делайте следующий шаг, пока не восстановили контроль.
Не меняйте одновременно IP, маршруты, DNS и firewall
Самый опасный сценарий — «одним коммитом»: новый backend сети плюс новые правила firewall плюс переразметка policy routing. Разделяйте на этапы: сначала перенос управления, затем маршрутизация/метрики, затем DNS, затем всё остальное.
Тест после ребута обязателен
Сеть, которая работает только «до перезагрузки», — риск. Планируйте окно и один контролируемый ребут, чтобы убедиться, что стек поднимается детерминированно.
Сравнение по практическим критериям (серверный взгляд)
Предсказуемость после ребута
systemd-networkd обычно более детерминирован: конфиги читаются при старте, меньше фоновых автодействий. У NetworkManager может быть больше «состояния» (автоактивация профилей, взаимодействие с DNS-стеком и приоритетами), и различия иногда проявляются только на холодной загрузке.
Диагностика
- NetworkManager:
nmcliдля статуса и профилей, логи через journald. - systemd-networkd:
networkctl,ip/bridge, логи через journald.
Если команда и так живёт в systemd-юнитах и декларативных конфигурациях, networkd часто воспринимается проще.
VLAN/bonding/bridging
Оба стека умеют VLAN/bond/bridge. На серверах со сложной L2-схемой networkd нередко удобнее держать как набор файлов: отдельно bond, отдельно VLAN, отдельно адреса/маршруты. У NM это тоже возможно, но профильная модель может прятать часть деталей, которые важны при восстановлении после ребута.
Routing и policy routing
Если у вас несколько uplink, несколько таблиц маршрутизации и правила по source address, в миграциях чаще всего ломается именно маршрутизация: дефолтный маршрут «стал не тот», поменялись метрики, пропали правила, иначе начал работать reverse path filtering.
План миграции: NetworkManager → systemd-networkd без потери SSH
Логика безопасной миграции простая: собрать инвентарь, подготовить параллельную конфигурацию, затем переключить управление и проверить поведение до и после ребута. В идеале — иметь доступ к консоли на уровне панели/провайдера на случай отката.
Шаг 1. Инвентарь текущего состояния (сохраните вывод)
ip -br link
ip -br addr
ip route
ip rule
resolvectl status
nmcli -t -f NAME,UUID,TYPE,DEVICE,STATE connection show
nmcli -t device statusЕсли маршрутов и правил много, сохраните вывод в файл, чтобы быстро сравнить «до/после».
Шаг 2. Понять, участвует ли netplan и кто backend
Если у вас Ubuntu и есть netplan, обычно безопаснее мигрировать через него (переключить renderer), чем вручную «перехватывать» интерфейсы. Ключевое — не получить ситуацию «двух хозяев», когда часть настроек приходит из netplan, а часть — из ручных NM-профилей.
Шаг 3. Подготовить конфиги networkd в параллель
Подготовьте файлы .netdev/.network под вашу схему (адрес, шлюз, DNS, VLAN, bond). На этом шаге ничего не отключайте: сначала подготовьте, проверьте и только потом переключайте управление.
Минимальный пример статического IP (адаптируйте под ваш интерфейс):
; /etc/systemd/network/10-eth0.network
[Match]
Name=eth0
[Network]
Address=203.0.113.10/24
Gateway=203.0.113.1
DNS=1.1.1.1
DNS=8.8.8.8Пример VLAN: отдельный .netdev и отдельный .network для адреса.
; /etc/systemd/network/20-vlan10.netdev
[NetDev]
Name=vlan10
Kind=vlan
[VLAN]
Id=10
; /etc/systemd/network/20-eth0.network
[Match]
Name=eth0
[Network]
VLAN=vlan10
; /etc/systemd/network/21-vlan10.network
[Match]
Name=vlan10
[Network]
Address=192.0.2.2/24Пример bonding (упрощённо):
; /etc/systemd/network/30-bond0.netdev
[NetDev]
Name=bond0
Kind=bond
[Bond]
Mode=802.3ad
MIIMonitorSec=1s
; /etc/systemd/network/31-eth1.network
[Match]
Name=eth1
[Network]
Bond=bond0
; /etc/systemd/network/31-eth2.network
[Match]
Name=eth2
[Network]
Bond=bond0
; /etc/systemd/network/32-bond0.network
[Match]
Name=bond0
[Network]
Address=198.51.100.20/24
Gateway=198.51.100.1Шаг 4. Продумать wait-online и зависимости
До переключения решите, нужен ли вам systemd-networkd-wait-online. Если сервисам критичен дефолтный маршрут или доступность конкретной сети — ожидание может быть оправдано. Если сервисам достаточно поднятого линка или адреса — чаще лучше поправить зависимости конкретных юнитов, чем «замораживать» весь boot.
Шаг 5. Переключение управления (поэтапно)
Не отключайте NetworkManager «в лоб» до того, как убедились, что networkd реально применяет вашу конфигурацию и вы можете пережить ребут. Резкое отключение NM на некоторых системах приводит к мгновенному снятию адреса и падению SSH.
Если вы используете netplan, переключение renderer обычно контролируемее. Если netplan нет — действуйте маленькими шагами, проверяя каждый.
Шаг 6. Проверка: адреса, маршруты, правила, DNS и доступность
ip -br addr
ip route
ip rule
resolvectl query example.com
ss -tnlp | head -n 20И обязательно — тестовый ребут в окно, когда вы готовы быстро восстановиться через консоль доступа. Если после ребута всё совпадает с инвентарём — миграция прошла успешно.
Обратная миграция: systemd-networkd → NetworkManager
Иногда это действительно нужно: например, вы переносите образ в среду, где стандарт компании — NM и конфигурации через nmcli. Риск — в автоподхвате интерфейсов и изменении поведения (DNS приоритеты, метрики, автогенерация маршрутов).
Безопасный рецепт тот же: инвентарь, параллельная подготовка профилей, контролируемое переключение и тест после ребута. Если используется netplan — не смешивайте ручные NM-профили и netplan-генерацию без чёткого понимания, кто «главный».
Частые ловушки, которые ломают сеть при миграции
Переименование интерфейсов
После обновлений ядра/udev или смены виртуального NIC имя интерфейса может поменяться. Если конфиг завязан на Name=eth0, а после ребута интерфейс стал ens3, сеть не поднимется. На серверах часто разумнее матчить по MAC или использовать стабильные предсказуемые имена.
Несовпадение MTU
В схемах с VLAN/туннелями/overlay MTU критичен. NM и networkd могут по-разному наследовать MTU. Симптомы: «SSH вроде есть, но подвисает», странные таймауты, обрывы сессий. Фиксируйте MTU в инвентаре и задавайте явно там, где это важно.
Изменение метрик маршрутов
При двух uplink даже небольшое изменение metric может отправить трафик «не туда». В итоге SSH может работать только с одной стороны, или доступ будет лишь до части адресов.
DNS и systemd-resolved
Убедитесь, что понимаете, кто формирует resolv.conf, как задаются DNS и search domains, и как это выглядит в resolvectl status. При миграции сети DNS ломается не реже маршрутов.
Если вы завязаны на сертификаты и автоматизацию TLS, отдельно проверьте, что после миграции корректно работает валидация и доступность нужных доменных имён; по теме wildcard и DNS-01 полезно держать под рукой материал про автоматизацию wildcard SSL через DNS-01.
Что выбрать в 2026: короткая практическая рекомендация
- Сервер со статикой, VLAN/bonding/routing и требованием предсказуемости после ребута: чаще выбирайте systemd-networkd.
- Динамичная среда, много профилей, VPN/802.1X, активное управление через
nmcli: чаще удобнее NetworkManager. - Ubuntu + netplan: сначала определите backend и мигрируйте через netplan, чтобы не получить «двух хозяев».
И главное: проектируйте миграцию вокруг сохранения доступа. План отката плюс тест после ребута снижают риск «потерять SSH» на порядок — независимо от выбранного стека. Если для публичных сервисов вы ещё и закрываете управление TLS, лучше заранее подготовить и обновить SSL-сертификаты, чтобы во время сетевых работ не совпали два риска сразу.
