Приоритет сетевых профилей и имена интерфейсов¶
В НАЙС.ОС CLOUD конфигурацией физических и виртуальных сетевых интерфейсов управляет systemd-networkd, а разрешением имён — systemd-resolved. Прежде чем добавлять .network, нужно понять, какой файл уже выбран для устройства. Это особенно важно, если образ содержит штатный 99-dhcp-en.network, а облачная платформа создаёт собственный профиль.
Граница подтверждения
systemd.spec из архива SPEC содержит Source4: 99-dhcp-en.network, но сам файл Source4 в архив не вложен. Не предполагается, что он точно соответствует обычному DHCP-шаблону: проверяйте установленную систему. Первая подходящая конфигурация .network выбирается по правилам systemd; другие совпавшие .network не сливаются с ней в одну конфигурацию.
1. Как устроен каталог /etc/systemd/network/¶
systemd-networkd читает профили .network (назначение адресов, DHCP и маршрутов), .netdev (создание виртуальных сетевых устройств: bridge, bond, VLAN) и .link (низкоуровневые параметры и правила именования). Файлы могут находиться в /usr/lib/systemd/network/, /run/systemd/network/, /etc/systemd/network/ — учитывать нужно все места, не только /etc.
Профили одного типа обрабатываются по имени в лексикографическом порядке, с правилами переопределения файлов одинакового имени и маскирования. Для .network применяется первый профиль, у которого удовлетворены условия [Match]. Поэтому файл 10-uplink.network часто перехватит интерфейс раньше 99-dhcp-en.network, но имя файла само по себе не гарантирует, что он сопоставится нужному устройству.
2. Снимок текущего состояния¶
networkctl list
ip -br link
ip -br address
ip -4 route
ip -6 route
networkctl status
find /etc/systemd/network /run/systemd/network /usr/lib/systemd/network \
-maxdepth 1 -type f 2>/dev/null | sort
Найдите имя конкретного интерфейса командой ip -br link. В примерах ниже это ens3, не универсальное имя НАЙС.ОС.
В networkctl status ищите поле Network File. Оно показывает активный профиль и помогает исключить конфликты. Если поле отсутствует, не утверждайте, что сеть «поломана»: выясните, управляет ли данным устройством networkd и какой режим сети предусмотрен образом.
3. Условия сопоставления¶
Типичный профиль для управляемой виртуальной машины:
Для виртуальных машин, где имя может изменяться, разумнее сопоставлять интерфейс по MAC-адресу или Path=, но только после его получения на экземпляре. При клонировании VM MAC может меняться, поэтому привязка по MAC иногда хуже привязки по уникальному идентификатору оборудования.
Проверьте, нет ли второго .network, который выбирается раньше. В облаке дополнительно проверьте взаимодействие с cloud-init — провайдер может пересоздать конфигурацию при следующем старте.
4. Проверка файла до применения¶
networkctl status ens3
systemd-analyze verify /usr/lib/systemd/system/systemd-networkd.service
journalctl -b -u systemd-networkd --no-pager -n 80
systemd-analyze verify проверяет unit, а не синтаксис .network. Для сетевых профилей основными средствами остаются проверка документации соответствующей версии systemd, последующее применение и журнал networkd. Не используйте успешную проверку unit как доказательство валидности адресного профиля.
При изменении на удалённом сервере сначала настройте обратный доступ через гипервизор или консоль. Затем:
Повторно проверьте адрес, маршруты, DNS и доступ в новом SSH-сеансе. Не перезапускайте всю сеть вслепую.
5. Распространённые ошибки¶
| Симптом | Что проверить | Почему |
|---|---|---|
| Адрес не изменился | Network File, [Match] |
Файл не соответствует интерфейсу или выбран другой |
| После перезагрузки старый адрес | файлы в /run/, cloud-init |
Сгенерирован новый профиль |
| Есть адрес, нет DNS | resolvectl status |
Адресация и разрешение имён независимы |
| У интерфейса два адреса | DHCP, старые адреса, несколько владельцев | Нужно исключить конфликт источников адресации |
| Сеть теряется при обновлении | udev .link, имена устройств |
Завязка на нестабильное имя |
См. также DHCP, статический IPv4, восстановление доступа.
Источники: Core/systemd/SPECS/systemd.spec; systemd.network, systemd.link.