Какая система управления сетью подходит вашему Linux и почему ошибка в выборе стоит дорого

Каждый администратор Linux рано или поздно стоит перед этим выбором: systemd-networkd или NetworkManager. На первый взгляд оба инструмента делают одно и то же: поднимают интерфейсы, раздают адреса, прокладывают маршруты. Но за этим внешним сходством скрываются принципиально разные философии, разные целевые среды и разные последствия неверного выбора.

Сисадмин, поставивший NetworkManager на минималистичный production-сервер, получает лишние зависимости и D-Bus поверх headless-системы. Тот, кто попытался обойтись systemd-networkd на ноутбуке с частой сменой Wi-Fi-сетей, знает, каково это - писать конфиги вручную там, где хватило бы пары кликов. Инструмент без понимания среды превращается в источник проблем.

Архитектурная разница, которая определяет всё остальное

systemd-networkd не существует отдельно от systemd. Это часть единой экосистемы, демон, который при старте системы читает декларативные конфигурационные файлы из /etc/systemd/network/, выстраивает граф зависимостей интерфейсов и применяет настройки. Один раз прочитал, применил. Никакого постоянного наблюдения за интерфейсами, никаких скрытых состояний в рантайме.

NetworkManager устроен принципиально иначе. Это полноценный событийный демон с D-Bus API, который непрерывно отслеживает состояние интерфейсов, реагирует на события (появилась новая сеть, подключился USB-адаптер, пропал кабель), управляет профилями подключений и предоставляет API для графических приложений и скриптов. По сути, это не просто конфигуратор, а живой диспетчер сетевых событий.

Разница в архитектуре порождает разницу в ресурсах. systemd-networkd запускается быстро и занимает минимум памяти. NetworkManager несёт более тяжёлый footprint: собственный daemon, подсистема плагинов, хранилище профилей, dispatcher-скрипты. На рабочей станции с 32 ГБ ОЗУ эта разница незаметна. На хосте с сотнями контейнеров или встраиваемой системе каждый мегабайт имеет вес.

Есть и вопрос философии управления конфигурацией. systemd-networkd тяготеет к подходу "infrastructure as code": вся конфигурация живёт в файлах, файлы можно версионировать, тестировать, раскатывать через системы управления конфигурацией. NetworkManager же исторически рос как инструмент рантаймового управления, где конфигурация создаётся и меняется в процессе работы. Для командных сред с жёсткими требованиями к воспроизводимости это существенная разница в культуре работы с сетью.

Как устроена конфигурация в реальных файлах

Работа с systemd-networkd строится на трёх типах файлов. Файлы .link описывают физические свойства интерфейсов, файлы .netdev создают виртуальные устройства (VLAN, bond, bridge), файлы .network назначают адреса и маршруты. Вся конфигурация хранится в /etc/systemd/network/ и читается строго по имени файла.

Статический адрес на интерфейсе описывается так:

# /etc/systemd/network/10-eth0.network
[Match]
Name=eth0

[Network]
Address=192.168.1.10/24
Gateway=192.168.1.1
DNS=8.8.8.8

NetworkManager хранит профили в /etc/NetworkManager/system-connections/, однако прямое редактирование этих файлов нежелательно. Канонический способ управления - утилита nmcli:

# Создать статическое подключение
nmcli connection add type ethernet ifname eth0 con-name my-eth0 \
  ip4 192.168.1.10/24 gw4 192.168.1.1

# Поднять подключение
nmcli connection up my-eth0

Это удобно и защищает от опечаток, но создаёт дополнительный уровень абстракции, который при отладке иногда мешает увидеть, что именно происходит с интерфейсом.

Серверная инфраструктура и контейнерные среды как родная среда для systemd-networkd

Серверный сетевой стек, как правило, статичен: несколько физических интерфейсов, предсказуемые VLAN, возможно bonding для отказоустойчивости. Конфигурация однажды написана и не меняется месяцами. В таких условиях событийный механизм NetworkManager просто не нужен.

Конфигурация bonding в systemd-networkd показывает его сильную сторону - декларативный подход позволяет описать всю топологию несколькими файлами, которые легко хранить в git и воспроизводить через Ansible:

# /etc/systemd/network/10-bond0.netdev
[NetDev]
Name=bond0
Kind=bond

[Bond]
Mode=active-backup
MIIMonitorSec=100ms

# /etc/systemd/network/11-eth0.network
[Match]
Name=eth0

[Network]
Bond=bond0

Kubernetes-окружения тоже тяготеют к systemd-networkd. Лёгкость и предсказуемость делают его предпочтительным выбором для хостов кластера. Проверить состояние интерфейсов можно командой:

networkctl status
networkctl list

Почему NetworkManager незаменим на десктопе и ноутбуке

Ноутбук, рабочая станция разработчика, десктоп с регулярной сменой сетей - вот территория NetworkManager. Здесь его событийная архитектура перестаёт быть недостатком и становится главным преимуществом.

Подключение к корпоративной Wi-Fi с WPA2-Enterprise, переключение на мобильный интернет через USB-модем, автоматическое поднятие VPN при входе в определённую сеть - всё это NetworkManager обрабатывает без дополнительной конфигурации. systemd-networkd в тех же сценариях потребует написания скриптов и дополнительных systemd-юнитов.

Базовые команды для работы с сетью через nmcli:

# Статус устройств и подключений
nmcli device status
nmcli connection show

# Список доступных Wi-Fi сетей
nmcli device wifi list

# Подключение к Wi-Fi
nmcli device wifi connect "MyNetwork" password "mypassword"

Поддержка графических интерфейсов - весомый аргумент. GNOME, KDE Plasma, Xfce интегрированы с NetworkManager напрямую через D-Bus. Иконка сети в трее, диалог выбора точки доступа, индикатор VPN - всё это работает именно потому, что NetworkManager постоянно транслирует события сети в D-Bus-шину.

Отдельного внимания заслуживает работа с WPA2-Enterprise и сертификатами. В корпоративной среде, где точки доступа требуют EAP-аутентификации с клиентскими сертификатами, NetworkManager обрабатывает весь этот сценарий через wpa_supplicant-плагин и хранилище секретов (keyring). Настройка через nmcli занимает несколько команд. В systemd-networkd тот же результат потребует ручной конфигурации wpa_supplicant отдельным юнитом и написания скрипта для управления его жизненным циклом.

Ошибки при переключении между системами и как их избежать

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

Перед переключением нужно полностью отключить предыдущий инструмент:

# Переход на systemd-networkd
systemctl disable --now NetworkManager
systemctl enable --now systemd-networkd
systemctl enable --now systemd-resolved

# Обратный переход на NetworkManager
systemctl disable --now systemd-networkd
systemctl enable --now NetworkManager

Ещё одна распространённая ошибка при работе с systemd-networkd - забыть про systemd-resolved. Сам networkd не управляет DNS-резолвером. Для корректной работы нужен systemd-resolved, а символическая ссылка должна указывать на его stub-файл:

ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

Без этого шага DNS может работать непредсказуемо даже при правильно настроенных .network-файлах - типичная ловушка, в которую попадают при первом знакомстве с networkd.

Как сделать осознанный выбор без угадывания

Выбор между двумя системами сводится к нескольким конкретным вопросам о среде. Полезно проверить себя по короткому списку критериев:

• Серверная headless-система со статичной топологией - systemd-networkd, минимальный footprint, конфигурация в файлах, полная воспроизводимость.
• Десктоп или ноутбук с переключением между сетями - NetworkManager, событийная архитектура, поддержка GUI, плагины для Wi-Fi и VPN.
• Контейнерный хост или узел Kubernetes - systemd-networkd, предсказуемость под нагрузкой, никаких неожиданных перестроений.
• Разработческая машина с частыми изменениями сетевого окружения - NetworkManager, гибкость профилей и удобство nmcli.
• Граничный сценарий с динамическим виртуальным стеком - гибридная схема, где NetworkManager управляет физическими интерфейсами, а виртуальные описаны через netdev-файлы с флагом unmanaged в настройках NetworkManager.

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