netplan на Ubuntu: статический IP, VLAN, bridge — на одной странице

В Ubuntu Server и Cloud-образах сетью управляет netplan: единый YAML-конфиг в /etc/netplan, который потом транслируется в systemd-networkd (на сервере) или NetworkManager (на десктопе). Никаких /etc/network/interfaces, никаких ручных ip route — пишете 10 строк YAML, делаете netplan apply, и интерфейс поднялся со статикой, VLAN-ом или мостом. В статье — рабочие шаблоны под типовые серверные сценарии (статический IP, мост для KVM, VLAN, bond), команды apply/try/generate и что делать, когда YAML «не применяется».

Где живёт конфиг netplan

Все конфиги лежат в /etc/netplan/*.yaml. Имя файла произвольное (часто 00-installer-config.yaml, 50-cloud-init.yaml, 99-custom.yaml), но порядок применения — по алфавиту: файл 99-custom.yaml переопределит 50-cloud-init.yaml. Это удобно, когда cloud-init на старте машины положил свой YAML, а вам нужно его перекрыть, не редактируя «чужой» файл.

Базовая структура любого netplan-конфига:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0:
      dhcp4: true

Что значат поля:

• version: 2 — единственная актуальная версия формата.
• renderer — кто исполняет правила. На Ubuntu Server по умолчанию networkd (systemd-networkd), на Desktop — NetworkManager. Менять обычно не нужно: cloud-init на серверной 24.04 ставит правильный сам.
• ethernets/vlans/bridges/bonds/tunnels — типы интерфейсов. Дальше идут блоки по именам интерфейсов.

Имена интерфейсов в современных Ubuntu — predictable: enp1s0, enp3s0f0, ens3 (для KVM/cloud). Узнать своё:

ip -br a
# или:
networkctl

⚠️ С Ubuntu 24.04 LTS netplan ругается, если YAML-файл лежит без ограниченных прав. Перед netplan apply поставьте: sudo chmod 600 /etc/netplan/*.yaml. Иначе получите Permissions for /etc/netplan/...yaml are too open и ничего не применится.

DHCP — простейший рабочий конфиг

Если провайдер/гипервизор раздаёт IP по DHCP, минимум выглядит так:

# /etc/netplan/99-custom.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0:
      dhcp4: true
      dhcp6: false

Применили: sudo netplan apply. Интерфейс берёт IP, шлюз и DNS от DHCP-сервера. Это конфиг, который ставится на свежеустановленный Ubuntu Server по умолчанию — менять его обычно не нужно, пока не появится требование статического адреса.

netplan статический IP

Типовой случай — серверу нужен фиксированный IPv4-адрес, чтобы DNS, мониторинг и SSH-конфиги других машин не путались. Шаблон:

# /etc/netplan/99-custom.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0:
      addresses:
        - 192.168.10.50/24
      routes:
        - to: default
          via: 192.168.10.1
      nameservers:
        addresses:
          - 192.168.10.1
          - 1.1.1.1
        search:
          - lan.example.com

Что важно:

• CIDR обязателен. Не 192.168.10.50 + отдельной маской, а 192.168.10.50/24 одним полем. netplan на старых форматах падает с Invalid address.
• routes: вместо устаревшего gateway4. До netplan 0.103 был gateway4: 192.168.10.1, теперь он deprecated и в логах появится предупреждение. Используйте routes: с to: default.
• nameservers.addresses — провайдерский DNS + публичный fallback. search — суффикс для коротких имён, чтобы ssh srv01 искал сначала srv01.lan.example.com.

После правки:

sudo chmod 600 /etc/netplan/99-custom.yaml
sudo netplan try        # пробует применить с откатом через 120 сек
# Enter — подтвердить
# или Ctrl+C — откатить

Ниже в статье разберём apply vs try подробнее.

Несколько адресов на одном интерфейсе

Один сервер часто имеет основной IP + один-два alias-а (для приложений, миграций, Anycast). netplan делает это естественно — просто добавляете адреса в список:

network:
  version: 2
  ethernets:
    enp1s0:
      addresses:
        - 192.168.10.50/24
        - 192.168.10.51/24
        - 10.20.30.40/32
      routes:
        - to: default
          via: 192.168.10.1

/32 для второго подсетевого адреса нужен, когда он не входит в основную подсеть, — netplan не пытается на нём строить broadcast-домен.

netplan VLAN

VLAN — отдельный тип vlans: в верхнем блоке. Ссылается на физический интерфейс через link: и тег через id::

# Сервер с одним физическим uplink-ом и тремя VLAN-ами:
# 10 — management, 20 — приложение, 30 — backup-сеть
network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0:
      dhcp4: false
      dhcp6: false
  vlans:
    enp1s0.10:
      id: 10
      link: enp1s0
      addresses:
        - 192.168.10.50/24
      routes:
        - to: default
          via: 192.168.10.1
      nameservers:
        addresses:
          - 192.168.10.1
    enp1s0.20:
      id: 20
      link: enp1s0
      addresses:
        - 10.20.0.50/24
    enp1s0.30:
      id: 30
      link: enp1s0
      addresses:
        - 10.30.0.50/24

Имя вида enp1s0.10 — конвенция (физический.тег), не обязательная, но удобная для ip link. Физический интерфейс при использовании VLAN обычно НЕ имеет своего IP (dhcp4: false, нет addresses:) — он несёт только VLAN-теги.

На стороне коммутатора порт должен быть в режиме trunk и пропускать нужные VID. Если коммутатор шлёт трафик без тегов на «нативном VLAN» — запретить или подцепить как нетегированный VLAN на отдельный bridge: netplan этого автоматически не делает.

netplan bridge — мост для KVM/Docker/LXD

Bridge нужен, когда виртуалки или контейнеры должны висеть в той же сети, что и хост (получать IP от того же DHCP, быть видимыми извне без NAT):

# Хост с одним сетевым адаптером, виртуалки получают IP в LAN
network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0:
      dhcp4: false
      dhcp6: false
  bridges:
    br0:
      interfaces:
        - enp1s0
      addresses:
        - 192.168.10.50/24
      routes:
        - to: default
          via: 192.168.10.1
      nameservers:
        addresses:
          - 192.168.10.1
      parameters:
        stp: false
        forward-delay: 0

Что происходит:

• enp1s0 теряет свой IP — он становится «портом» моста.
• IP, шлюз и DNS навешиваются на br0.
• KVM/libvirt и LXD умеют подключать VM/контейнеры к существующему мосту — указываете в их конфиге br0 вместо встроенного default/virbr0, и виртуалка получает IP из той же подсети, что хост.
• stp: false + forward-delay: 0 ускоряют поднятие моста при старте: STP в «плоской» сети не нужен, иначе bridge задержит трафик на 30 секунд после старта.

⚠️ Если делаете это на удалённом сервере — лучше через netplan try (см. ниже): неправильный конфиг положит сетевой доступ, а с откатом через 120 секунд можно спокойно проверить.

netplan bond — агрегация двух линков

Bond (он же LAG, port-channel) объединяет два физических порта в один логический — для отказоустойчивости и/или удвоения пропускной способности. Самый ходовой режим — active-backup (один работает, второй в горячем резерве, не требует поддержки на коммутаторе) или 802.3ad (LACP, нужен LAG на коммутаторе):

network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0f0:
      dhcp4: false
    enp3s0f1:
      dhcp4: false
  bonds:
    bond0:
      interfaces:
        - enp3s0f0
        - enp3s0f1
      addresses:
        - 192.168.10.50/24
      routes:
        - to: default
          via: 192.168.10.1
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        mii-monitor-interval: 100

Для 802.3ad коммутатор должен иметь сконфигурированный LAG для этих двух портов. Для active-backup — никаких требований к коммутатору, оба порта могут смотреть в разные коммутаторы (full-redundancy).

netplan apply, try, generate

Три команды, которые надо знать наизусть:

sudo netplan apply       # применить немедленно, без подтверждения
sudo netplan try         # применить с автооткатом через 120 сек, если не подтвердить
sudo netplan generate    # только сгенерировать конфиги networkd, не применять

• apply — обычный путь. Выполняет generate + перезапускает networkd/NetworkManager. Если YAML невалиден — печатает ошибку и не применяет. Если применил, но конфиг разорвал сеть — придётся идти к консоли провайдера / IPMI.
• try — лучший друг при удалённой настройке. Применяет конфиг и стартует таймер; если в течение 120 секунд вы нажмёте Enter — изменения остаются. Не успели (потеряли SSH) — netplan возвращает старый конфиг автоматически.
• generate — генерирует файлы в /run/systemd/network/*.network без применения. Полезно, чтобы посмотреть, во что транслируется ваш YAML, или убедиться, что синтаксис валиден перед apply.

Ещё одна команда — netplan get/netplan set для скриптов CI:

sudo netplan get ethernets.enp1s0.dhcp4
sudo netplan set ethernets.enp1s0.dhcp4=true

Они работают с YAML напрямую и могут быть полезны в Ansible-задачах вместо template + apply.

Отладка: что делать, когда конфиг не применяется

Сценарии, в которые попадают чаще всего:

1. Permissions for /etc/netplan/...yaml are too open. Файл с правами шире чем 600. sudo chmod 600 /etc/netplan/*.yaml.

2. Invalid YAML at /etc/netplan/... Чаще всего табы вместо пробелов или неправильный отступ. netplan-конфиги всегда 2 пробела на уровень. Проверить: python3 -c 'import yaml,sys; yaml.safe_load(open("/etc/netplan/99-custom.yaml"))' — если пройдёт, синтаксис ОК, проблема в семантике.

3. apply прошёл, но интерфейс не получил IP. Смотрим что сгенерилось и что говорит networkd:

sudo netplan generate           # без ошибок?
ls /run/systemd/network/        # появились файлы?
networkctl                      # статус интерфейсов
networkctl status enp1s0        # детали по конкретному
sudo journalctl -u systemd-networkd -n 100 --no-pager

networkctl status — самый информативный вывод: показывает state, address, gateway, DNS, ошибки конфигурации.

4. После netplan apply отвалился SSH на удалённом сервере. Если есть try, делаете try следующий раз. Если нет — лезете через консоль провайдера / IPMI: sudo nano /etc/netplan/99-custom.yaml, исправляете, sudo netplan apply. Ну и на будущее: никогда не делайте apply на проде без try.

5. cloud-init перетирает ваш конфиг при ребуте. На VPS-провайдерах cloud-init часто ставит свой /etc/netplan/50-cloud-init.yaml. Чтобы он не возвращался, отключите конфигурацию сети cloud-init:

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

И положите свой YAML в /etc/netplan/99-custom.yaml с приоритетом выше 50-cloud-init.yaml.

Частые вопросы

Какой renderer ставить — networkd или NetworkManager?

На Ubuntu Server — networkd (он по умолчанию, легковесный, без GUI). На Desktop — NetworkManager (нужен для апплета в трее, Wi-Fi, VPN-плагинов). Менять то, что поставил инсталлятор/cloud-init, обычно не надо — настройки wifis: всё равно работают только через NetworkManager.

Где брать дефолтный шаблон для нового файла?

Скопируйте /etc/netplan/50-cloud-init.yaml (если есть) или 00-installer-config.yaml под именем 99-custom.yaml, поставьте chmod 600 и правьте копию. Так оригинальный конфиг останется как референс, и при откате вы не потеряете рабочее состояние.

Можно ли смешивать DHCP и статический адрес?

Можно, но обычно не нужно. DHCP может поставить шлюз и DNS, которые перекроют ваши routes: и nameservers. Если нужен «статика + DHCP только для чего-то конкретного» — отключите получение через DHCP-опции:

ethernets:
  enp1s0:
    dhcp4: true
    dhcp4-overrides:
      use-routes: false
      use-dns: false
    nameservers:
      addresses: [1.1.1.1]

Нужно ли перезагружать сервер после netplan apply?

Нет. apply перезапускает networkd, и новая конфигурация применяется немедленно. Перезагрузка нужна только если вы меняли драйвер сетевой карты, MAC-адрес или подключали новый физический интерфейс.

Куда смотреть YAML-документацию по всем полям?

Полная справка: man netplan и man systemd.netdev. Все поля (включая wakeonlan, mtu, accept-ra, тонкости bond) описаны там. На сайте Canonical есть playground с подсказками: попробовать конфиг без сервера.

Что запомнить

• На 24.04 файлам в /etc/netplan/*.yaml нужны права 600 — иначе apply молча игнорируется.
• gateway4: устарел, шлюз пишем через routes: - to: default, via: ....
• На удалённом сервере применяем только через sudo netplan try — 120 секунд на откат спасают от ошибки в YAML.
• VLAN — отдельный блок vlans:, физический интерфейс остаётся без IP.
• Bridge — bridges:, физика становится «портом» моста, IP навешивается на br0. Удобно для KVM/LXD.
• Если cloud-init перетирает конфиг — отключаем сетевую часть cloud-init через 99-disable-network-config.cfg.
• Перед прод-применением — python3 -c 'yaml.safe_load(open(...))' для синтаксиса и netplan generate для семантики.