Netplan на Ubuntu VDS: статический IPv4/IPv6, default route, DNS и безопасное применение по SSH

Инструкции
20 июл, 2026
Время на чтение: ~19 мин
Автор: AI (GPT 5)

Искусственный интеллект

Данная статья была создана с использованием искусственного интеллекта (GTP-5). Пожалуйста, имейте в виду, что текст может содержать неточности или ошибки.

Netplan на серверной Ubuntu кажется простым ровно до момента, когда вы правите сеть по SSH. Одна ошибка в отступе YAML, неверный default route или не тот gateway — и сервер перестает отвечать. Хорошая новость: если заранее подготовить откат, проверить конфигурацию и использовать netplan try, риск сильно снижается.

В этой инструкции разберем практичный сценарий для Ubuntu на VDS: как найти интерфейс, прописать статический IPv4 и IPv6, настроить DNS, задать маршрут по умолчанию через современный блок routes, проверить systemd-networkd и безопасно применить изменения.

Главное правило сетевых изменений на удаленном сервере: сначала обеспечить путь отката, потом менять конфигурацию. Не наоборот.

Когда Netplan используется на Ubuntu VDS

Netplan — это слой описания сетевой конфигурации в YAML. Он сам не поднимает интерфейсы, а генерирует настройки для backend-рендера. На серверных Ubuntu обычно используется systemd-networkd, а на desktop-образах чаще встречается NetworkManager. На VDS почти всегда актуальна связка Netplan плюс networkd.

Проверить текущие файлы и renderer можно так:

ls -l /etc/netplan
cat /etc/netplan/*.yaml
grep -R renderer /etc/netplan
systemctl status systemd-networkd --no-pager
networkctl status

На VDS Netplan-файлы часто создает cloud-init при первом запуске. Поэтому в каталоге можно увидеть имя вроде 50-cloud-init.yaml. Это нормально, но важно понимать: если cloud-init продолжает управлять сетью, ручные изменения теоретически могут быть перезаписаны после операций с метаданными или при пересоздании сервера из шаблона.

Подготовка: как не потерять SSH

Перед изменением сети по SSH сделайте несколько простых вещей: откройте вторую SSH-сессию, работайте в tmux или screen, сохраните резервную копию Netplan и убедитесь, что у вас есть доступ к VNC/serial-консоли в панели управления VDS.

Установить и запустить tmux на Ubuntu можно так:

sudo apt update
sudo apt install tmux
tmux new -s netplan

Сделайте резервную копию текущей конфигурации:

sudo mkdir -p /root/netplan-backup
sudo cp -a /etc/netplan /root/netplan-backup/netplan-$(date +%F-%H%M%S)

Если текущий рабочий файл называется 50-cloud-init.yaml, сохраните его отдельно для быстрого отката:

sudo cp -a /etc/netplan/50-cloud-init.yaml /root/netplan-good.yaml

Для критичных серверов можно заранее запланировать автоматический откат через несколько минут. Используйте этот прием аккуратно: если после успешной проверки забыть отменить таймер, он вернет старую сеть.

sudo systemd-run --on-active=5min --unit=netplan-rollback /bin/sh -c 'cp /root/netplan-good.yaml /etc/netplan/50-cloud-init.yaml && netplan apply'

После успешного применения остановите отложенный запуск:

sudo systemctl stop netplan-rollback.timer

На практике чаще достаточно netplan try: если вы не подтвердите изменения, Netplan сам откатит конфигурацию после таймаута.

Собираем исходные данные: интерфейс, адреса, шлюз

Перед редактированием файла нужно точно знать имя интерфейса, текущие адреса, маршруты и DNS. На VDS интерфейс может называться ens3, ens18, eth0, enp1s0 — это зависит от гипервизора и образа.

ip -br link
ip -br addr
ip route
ip -6 route
resolvectl status

Обратите внимание на имя интерфейса, через который идет SSH, на IPv4-адрес с префиксом, например 203.0.113.10/24, и на gateway после via в маршруте default.

default via 203.0.113.1 dev ens3 proto dhcp src 203.0.113.10 metric 100
203.0.113.0/24 dev ens3 proto kernel scope link src 203.0.113.10

Для IPv6 маршрут по умолчанию может выглядеть так:

default via 2001:db8:1234:10::1 dev ens3 proto static metric 100
2001:db8:1234:10::/64 dev ens3 proto kernel metric 256

Если сейчас сервер получает адрес по DHCP, не копируйте параметры вслепую. Уточните в панели VDS или в письме с параметрами сервера, какие адреса закреплены за вами: IPv4, IPv6-префикс, gateway, маска и DNS. Для статической настройки важен не только IP, но и правильный префикс: /24, /32, /64 и так далее.

Схема сбора параметров интерфейса, IP-адресов, шлюза и DNS для Netplan

Базовая структура Netplan

Файл Netplan — это YAML, поэтому в нем критичны отступы пробелами. Табуляцию использовать нельзя. Обычно достаточно одного понятного файла в /etc/netplan, например 01-vds.yaml. Если файлов несколько, Netplan объединяет их, и это иногда приводит к неожиданному результату.

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: no
      addresses:
        - 203.0.113.10/24
      routes:
        - to: default
          via: 203.0.113.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8

Здесь ens3 — имя интерфейса. Параметр dhcp4: no отключает получение IPv4 по DHCP, блок addresses задает статические адреса, routes отвечает за маршруты, а nameservers — за DNS.

В старых примерах часто встречаются параметры gateway4 и gateway6. Они могут еще работать, но в новых конфигурациях лучше использовать routes: это явнее, гибче и соответствует актуальному стилю Netplan.

Настройка статического IPv4

Допустим, у сервера такие параметры: интерфейс ens3, IPv4 203.0.113.10, префикс /24, шлюз 203.0.113.1, DNS 1.1.1.1 и 8.8.8.8.

Создайте отдельный файл. Если в каталоге уже есть cloud-init-файл, можно аккуратно заменить его содержимое или создать новый файл и убрать старый после проверки. Главное — не оставить две конфликтующие настройки одного интерфейса.

sudo nano /etc/netplan/01-vds.yaml

Пример IPv4-only конфигурации:

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: no
      dhcp6: no
      addresses:
        - 203.0.113.10/24
      routes:
        - to: default
          via: 203.0.113.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8

После сохранения выставьте корректные права: новые версии Netplan могут предупреждать о слишком открытом доступе к YAML-файлу.

sudo chmod 600 /etc/netplan/01-vds.yaml
sudo netplan generate

Если netplan generate ничего не вывел, синтаксис, скорее всего, корректен. Если есть ошибка, Netplan обычно укажет файл и строку. Чаще всего виноваты отступы, табуляция, лишнее двоеточие или неверный уровень вложенности.

Dual-stack: IPv4 плюс IPv6 в одном файле

Для современной VDS нормальный вариант — dual-stack, когда сервер доступен и по IPv4, и по IPv6. В Netplan оба адреса можно указать в одном списке addresses, а маршруты по умолчанию — в одном блоке routes.

Пример для IPv4 203.0.113.10/24, gateway 203.0.113.1, IPv6 2001:db8:1234:10::10/64 и gateway 2001:db8:1234:10::1:

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: no
      dhcp6: no
      accept-ra: no
      addresses:
        - 203.0.113.10/24
        - 2001:db8:1234:10::10/64
      routes:
        - to: default
          via: 203.0.113.1
        - to: default
          via: 2001:db8:1234:10::1
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8
          - 2606:4700:4700::1111
          - 2001:4860:4860::8888

Параметр accept-ra: no отключает принятие IPv6 Router Advertisement. Для полностью статической серверной конфигурации это часто ожидаемо. Но если провайдер выдает IPv6-маршрут именно через RA, отключать accept-ra не нужно.

Адреса 203.0.113.0/24 и 2001:db8::/32 используются в документации. В реальной конфигурации замените их на адреса, выданные вашей VDS.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Default route через routes: что важно проверить

default route — это маршрут, по которому сервер отправляет трафик во все сети, для которых нет более точного маршрута. Если он ошибочный, сервер может отвечать в локальный сегмент, но не будет доступен из интернета или сам не сможет подключаться наружу.

routes:
  - to: default
    via: 203.0.113.1

Для IPv6 запись аналогична:

routes:
  - to: default
    via: 2001:db8:1234:10::1

Иногда gateway находится не в той подсети, которая указана на адресе интерфейса. У провайдеров такое встречается, например при IPv4 с префиксом /32. В этом случае может потребоваться on-link: true.

routes:
  - to: default
    via: 203.0.113.1
    on-link: true

Не добавляйте on-link: true на всякий случай. Используйте его, когда это требуется схемой маршрутизации VDS или когда networkd отказывается установить маршрут из-за недостижимого gateway.

Схема маршрута по умолчанию и DNS на Ubuntu Server через Netplan

DNS в Netplan и systemd-resolved

DNS в Netplan задается в блоке nameservers. Но на Ubuntu запросы часто проходят через systemd-resolved, поэтому в /etc/resolv.conf можно увидеть локальный адрес 127.0.0.53. Это не ошибка: локальный stub-resolver принимает запросы приложений и пересылает их на DNS-серверы, полученные от Netplan, DHCP или других источников.

resolvectl status
resolvectl dns
resolvectl query example.com

Если после применения Netplan DNS не меняется, проверьте, нет ли второй конфигурации для того же интерфейса и не управляет ли сетью NetworkManager. Также полезно посмотреть сгенерированные файлы для networkd:

ls -l /run/systemd/network
networkctl status ens3

Для серверов лучше указывать минимум два DNS-сервера. Если включен IPv6, добавляйте IPv6 DNS только при рабочей IPv6-связности. Иначе часть запросов может зависать до таймаута, что выглядит как медленный apt, долгий curl или задержки приложений при обращении к внешним API.

Безопасное применение: generate, try, apply

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

sudo netplan generate
sudo netplan try --timeout 120

netplan try применит конфигурацию и запустит обратный отсчет. Если SSH-сессия осталась живой, маршруты корректны, DNS работает и сервер доступен снаружи, подтвердите изменения в терминале. Если доступ потерян и вы не подтвердили изменения, Netplan должен откатить конфигурацию после таймаута.

После подтверждения можно дополнительно выполнить обычное применение:

sudo netplan apply

Проверьте адреса, маршруты и DNS:

ip -br addr show ens3
ip route show default
ip -6 route show default
networkctl status ens3
resolvectl status

Проверьте исходящие соединения:

ping -c 3 1.1.1.1
ping -c 3 example.com
ping -6 -c 3 2606:4700:4700::1111
ping -6 -c 3 example.com

Если ICMP заблокирован где-то по пути, ping может быть неидеальным тестом. Тогда проверьте выбор маршрута без реального подключения к сервису:

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

И отдельно убедитесь, что SSH продолжает слушать нужный адрес:

ss -ltnp | grep sshd

Если в OpenSSH задан конкретный ListenAddress, а вы изменили IP-адрес сервера, демон может не подняться после перезапуска. В типовой конфигурации OpenSSH слушает все адреса, но на усиленных серверах это стоит проверить заранее.

Что делать с cloud-init

Если файл называется 50-cloud-init.yaml, в начале может быть комментарий о том, что изменения будут перезаписаны. На многих VDS после первого запуска сеть фактически уже не трогается, но это зависит от образа и datasource.

Если вы хотите явно запретить cloud-init управлять сетью, можно создать файл:

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

После этого ручной Netplan-файл остается главным источником сетевой конфигурации. Но не отключайте сетевую часть cloud-init, если у вас автоматизированное развертывание, где IP, gateway и hostname должны приходить из метаданных при каждом создании сервера.

Привязка к MAC-адресу и стабильное имя интерфейса

Иногда после миграции, смены образа или подключения дополнительного интерфейса имя сетевой карты может измениться. Для обычной VDS это редкость, но для критичных серверов можно привязать конфигурацию к MAC-адресу и задать стабильное имя через match и set-name.

ip link show ens3

Пример структуры:

network:
  version: 2
  renderer: networkd
  ethernets:
    uplink0:
      match:
        macaddress: aa:bb:cc:dd:ee:ff
      set-name: ens3
      dhcp4: no
      addresses:
        - 203.0.113.10/24
      routes:
        - to: default
          via: 203.0.113.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8

Здесь uplink0 — внутреннее имя записи в YAML, а фактическое имя интерфейса задает set-name. Не используйте этот прием без необходимости: если ошибиться в MAC-адресе, конфигурация не применится к нужной сетевой карте.

Типичные ошибки Netplan на Ubuntu VDS

Ошибка в YAML-отступах

YAML чувствителен к структуре. Если addresses находится не на том уровне, Netplan может выдать ошибку или сгенерировать не то, что вы ожидали. Используйте два пробела на уровень и не вставляйте табы.

sudo netplan generate

Неверное имя интерфейса

Если в YAML указан ens3, а реальный интерфейс называется enp1s0, настройки не попадут на сетевую карту. Всегда сверяйте имя перед применением:

ip -br link

Конфликт нескольких Netplan-файлов

Если в /etc/netplan лежит несколько файлов, один может включать DHCP, другой — static IP, третий — DNS. Для простой VDS лучше оставить один файл, а лишние переместить в резервную директорию.

sudo mkdir -p /root/netplan-disabled
sudo mv /etc/netplan/50-cloud-init.yaml /root/netplan-disabled/50-cloud-init.yaml

Делайте это только если уже перенесли все нужные параметры в новый файл и готовы проверить изменения через netplan try.

Gateway недоступен без on-link

Если у вас адрес с префиксом /32 для IPv4 или нестандартная IPv6-схема, networkd может не установить маршрут к шлюзу. Симптом: адрес на интерфейсе есть, а default route отсутствует.

ip route
journalctl -u systemd-networkd --no-pager -n 100

DNS не работает, хотя IP-пинг проходит

Если ping 1.1.1.1 работает, а ping example.com нет, проблема, скорее всего, не в маршруте, а в DNS. Проверьте systemd-resolved и фактические DNS-серверы:

systemctl status systemd-resolved --no-pager
resolvectl status
resolvectl query example.com

Быстрый план отката

Если после применения сеть работает неправильно, но SSH еще жив, откатитесь к сохраненному файлу:

sudo cp -a /root/netplan-good.yaml /etc/netplan/50-cloud-init.yaml
sudo netplan generate
sudo netplan apply

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

sudo rm -rf /etc/netplan
sudo cp -a /root/netplan-backup/netplan-2026-01-20-120000 /etc/netplan
sudo netplan apply

Имя резервной директории замените на свое. Если SSH уже потерян, используйте консоль VDS. В консоли можно временно вернуть DHCP, если провайдер его поддерживает:

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: yes
      dhcp6: yes

После восстановления доступа не оставляйте сервер в неопределенном состоянии. Зафиксируйте финальный Netplan-файл, проверьте перезагрузку и убедитесь, что сеть поднимается автоматически.

Проверка после перезагрузки

Финальный тест — перезагрузка. Она показывает, не зависела ли рабочая сеть от временного состояния, старого DHCP lease или ручной команды. Перед перезагрузкой убедитесь, что у вас есть консольный доступ и сохранен бэкап.

sudo reboot

После возврата сервера проверьте:

uptime
ip -br addr
ip route show default
ip -6 route show default
networkctl status
resolvectl status

Также полезно проверить входящий SSH с рабочей машины в новой сессии. Старую сессию держите открытой до завершения проверки. Если менялся публичный IPv4 или IPv6, не забудьте обновить DNS-записи домена, firewall-правила, allowlist в мониторинге и настройки внешних сервисов, привязанных к IP. Если вместе с переездом меняется домен или зона, заранее проверьте параметры на странице регистрации доменов.

Короткий чек-лист безопасной настройки

Узнали реальное имя интерфейса через ip -br link.
Сохранили текущие адреса, маршруты и DNS.
Сделали резервную копию /etc/netplan.
Открыли вторую SSH-сессию или запустили tmux.
Описали IPv4/IPv6 static IP в одном понятном YAML-файле.
Задали default route через routes, а не через старые gateway4 и gateway6.
Проверили синтаксис командой netplan generate.
Применили изменения через netplan try --timeout 120.
Проверили SSH, маршруты, DNS и исходящие соединения.
После подтверждения протестировали поведение после перезагрузки.

Netplan удобен, когда конфигурация аккуратная и проверяемая. Для Ubuntu VDS лучше держать сеть максимально явной: статические адреса, понятные маршруты, минимум конфликтующих файлов и обязательный безопасный сценарий применения. Тогда настройка IPv4, IPv6, DNS и default route превращается из рискованной операции по SSH в обычную админскую процедуру с контролируемым откатом.

Поделиться статьей