Как настроить маршрутизацию в Ubuntu через Netplan

Маршрутизация в Ubuntu через Netplan задается в YAML-файле из каталога /etc/netplan/. В конфигурации указывают сетевой интерфейс, статический IP-адрес с префиксом, маршрут по умолчанию, DNS и дополнительные маршруты к удаленным подсетям.

Базовый порядок такой: определить имя интерфейса, сохранить резервную копию YAML-файла, подготовить конфигурацию, выполнить netplan generate или netplan try, применить изменения командой netplan apply, а затем проверить адреса и таблицу маршрутизации через ip addr и ip route. При работе по SSH заранее подготовьте консоль провайдера или вторую сессию: ошибка в сетевых параметрах может оборвать соединение.

Ниже разобраны статический адрес, шлюз по умолчанию, маршруты к отдельным подсетям, метрики, проверка после перезагрузки и типовые причины сбоев. Для общей шпаргалки по Linux можно использовать руководство по маршрутизации через ip route, Netplan и systemd-networkd.

Настройка маршрутизации в Ubuntu через Netplan: что нужно сделать

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

Определите интерфейс командой ip link.
Проверьте текущие адреса и маршруты через ip addr и ip route.
Сохраните копию файла из /etc/netplan/.
Задайте адрес, шлюз и маршруты в YAML.
Проверьте структуру через netplan generate.
Для удаленного сервера примените изменения через netplan try, если команда доступна.
После подтверждения выполните netplan apply и проверьте фактическое состояние сети.

Имя YAML-файла может отличаться: например, в каталоге встречаются файлы с именами 00-installer-config.yaml, 50-cloud-init.yaml или собственными именами, заданными администратором. Редактируйте файл, который действительно используется в вашей системе.

Какие параметры участвуют в маршрутизации

Статический адрес определяет, как сервер идентифицируется в локальной сети. Префикс, например /24, задает размер этой сети. Запись 192.168.10.20/24 означает адрес узла 192.168.10.20 и локальную сеть 192.168.10.0/24.

Маршрут по умолчанию обозначается как default или 0.0.0.0/0. Он используется, когда в таблице нет более точной записи для адреса назначения. Шлюз, указанный в параметре via, передает пакет в следующую сеть.

Дополнительный маршрут описывает конкретную сеть назначения. Например, запись 10.20.0.0/16 via 192.168.10.1 направляет трафик к сети 10.20.0.0/16 через шлюз 192.168.10.1. Адрес next-hop должен быть достижим через выбранный интерфейс.

Параметр	Назначение	Пример
Интерфейс	Сетевое устройство, через которое идет трафик	`ens18`
Адрес	IP-адрес сервера и префикс локальной сети	`192.168.10.20/24`
Шлюз	Следующий узел для выхода в другие сети	`192.168.10.1`
Назначение	Удаленная сеть или отдельный узел	`10.20.0.0/16`
Метрика	Приоритет маршрута при наличии конкурирующих записей	`100`

Что проверить перед изменением конфигурации

Сначала определите активное сетевое устройство:

ip link
ip addr
ip route

В выводе ip link найдите интерфейс со статусом UP, например ens18 или enp1s0. Не подставляйте имя из чужого примера: предсказуемые имена интерфейсов зависят от оборудования, гипервизора и настроек загрузки.

Проверьте текущий IP-адрес, префикс, маршрут default и доступность шлюза. Узнайте версию Ubuntu:

cat /etc/os-release

Перед редактированием сохраните исходный файл. Например:

sudo cp /etc/netplan/50-cloud-init.yaml /etc/netplan/50-cloud-init.yaml.bak

Если имя файла другое, замените его в команде. При удаленной работе держите открытой текущую SSH-сессию и подготовьте вторую сессию или доступ к консоли.

Статический IP-адрес и шлюз по умолчанию в Netplan

Пример конфигурации интерфейса с постоянным адресом

Ниже приведен шаблон для одного Ethernet-интерфейса и backend systemd-networkd:

network:
  version: 2
  renderer: networkd
  ethernets:
    ens18:
      dhcp4: false
      addresses:
        - 192.168.10.20/24
      routes:
        - to: default
          via: 192.168.10.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8

Замените ens18 на имя своего интерфейса. Адрес 192.168.10.20/24 должен соответствовать сетевой схеме, а 192.168.10.1 должен находиться в локальной сети интерфейса. DNS-адреса в примере тоже относятся к шаблону: в корпоративной сети обычно указывают внутренние DNS-серверы.

Ключ dhcp4: false отключает получение IPv4-параметров через DHCP. Если DHCP и статические настройки смешать без четкой схемы, сервер может получить несколько адресов и маршрутов, что усложнит диагностику.

В YAML критичны пробелы и вложенность. Используйте пробелы вместо табуляции. После сохранения проверьте права файла:

sudo chmod 600 /etc/netplan/50-cloud-init.yaml

Маршрут по умолчанию и его назначение

После применения конфигурации маршрут по умолчанию должен появиться в таблице:

default via 192.168.10.1 dev ens18

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

Один default route подходит для сервера с одним основным каналом выхода. Несколько шлюзов требуют отдельного решения: используют метрики, разные таблицы маршрутизации или policy routing. Простое добавление двух равноправных шлюзов может привести к непредсказуемому выбору исходящего пути и асимметричному трафику.

В актуальном синтаксисе Netplan маршрут по умолчанию задают через routes и to: default. Старые варианты с gateway4 могут встречаться в документации и существующих конфигурациях, но для новых файлов лучше использовать структуру маршрутов и проверять предупреждения команды Netplan.

Как добавить маршрут к отдельной подсети

Маршрут к одной внутренней подсети

Чтобы направить трафик к сети 10.20.0.0/16 через шлюз 192.168.10.1, добавьте маршрут в секцию интерфейса:

network:
  version: 2
  renderer: networkd
  ethernets:
    ens18:
      dhcp4: false
      addresses:
        - 192.168.10.20/24
      routes:
        - to: default
          via: 192.168.10.1
        - to: 10.20.0.0/16
          via: 192.168.10.1
      nameservers:
        addresses:
          - 192.168.10.53

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

10.20.0.0/16 via 192.168.10.1 dev ens18

Маршрут к подсети имеет больший приоритет для адресов из диапазона 10.20.0.0/16, чем общий маршрут default. Трафик к адресу 10.20.15.30 пойдет через 192.168.10.1, если в таблице нет более специфичной записи.

Несколько маршрутов и приоритет записей

Несколько сетей задают отдельными элементами списка:

routes:
  - to: default
    via: 192.168.10.1
  - to: 10.20.0.0/16
    via: 192.168.10.1
  - to: 172.16.40.0/24
    via: 192.168.10.254
    metric: 120

Маршрут к конкретной подсети выбирается раньше default route. Если два маршрута имеют одинаковое назначение, ядро Linux сравнивает метрики: меньшая метрика обычно получает более высокий приоритет.

Пересекающиеся диапазоны требуют проверки. Запись 10.20.0.0/16 менее специфична, чем 10.20.15.0/24, поэтому для адресов из второй сети будет выбран маршрут с префиксом /24. Проверяйте фактический выбор командой ip route get, а не только чтением YAML.

Практические сценарии с несколькими шлюзами, VLAN и policy routing разобраны в статье о статической маршрутизации в Linux.

Маршрут без отдельного шлюза

Если целевая сеть подключена непосредственно к интерфейсу, отдельный next-hop не нужен. Пример для дополнительной сети на том же интерфейсе:

routes:
  - to: 192.168.30.0/24

В ряде конфигураций Netplan и backend могут потребовать явного указания интерфейса или параметра scope: link. Вариант зависит от версии Netplan и сетевой схемы, поэтому после генерации проверяйте результат через ip route.

Шлюз via нельзя указывать произвольно. Он должен находиться в сети, которая доступна через этот интерфейс, либо система должна иметь отдельную настройку для разрешения next-hop.

Проверка и безопасное применение конфигурации

Проверка YAML до применения

Команда netplan generate проверяет YAML и создает конфигурацию для backend, не меняя активное состояние сети:

sudo netplan generate

Ошибки отступов, неизвестные ключи и проблемы вложенности нужно исправить до применения. Корректный синтаксис еще не подтверждает правильность IP-адреса, шлюза или маршрута. Эти параметры проверяются по сетевой схеме и фактической таблице маршрутизации.

Для удаленного сервера используйте:

sudo netplan try

Команда временно применяет настройки и ожидает подтверждения. Если доступ не подтвердить, Netplan возвращает предыдущую конфигурацию после тайм-аута. Перед использованием проверьте, доступна ли эта команда в установленной версии Ubuntu.

Применение через netplan apply

Когда YAML прошел проверку, примените его:

sudo netplan apply

Затем сразу проверьте интерфейс и маршруты:

ip addr show dev ens18
ip route

При изменении адреса или default route SSH-сессия может прерваться. Подключитесь заново по новому адресу и убедитесь, что маршрут к целевой подсети появился. Если соединение пропало, используйте вторую SSH-сессию, консоль облачного сервера или out-of-band-доступ, восстановите резервную копию и снова выполните проверку.

Для серверов, которые размещаются в облаке, заранее проверьте правила виртуальной сети, security groups и таблицы маршрутов у провайдера. Например, при аренде VDS в Timeweb Cloud маршрут внутри гостевой Ubuntu должен согласовываться с сетевой конфигурацией самой облачной площадки.

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

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

ip link show ens18
ip addr show dev ens18
ip route
ip route get 10.20.15.30

Сопоставьте с YAML имя интерфейса, IP-адрес, префикс, default route, next-hop и метрику. Проверьте доступность шлюза и хотя бы одного узла в каждой целевой подсети. Результаты удобно записать в документацию сервера вместе с датой изменения.

Как проверить результат маршрутизации

Проверка интерфейса и адресов

Состояние интерфейса и его адреса проверяют командами:

ip link show ens18
ip addr show dev ens18

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

Проверьте, что адрес не получил неожиданный второй источник, например DHCP. Несколько адресов допустимы в отдельных архитектурах, но каждый из них должен быть частью осознанной сетевой схемы.

Проверка таблицы маршрутизации

Полный список маршрутов выводит команда:

ip route

Для конкретного адреса используйте:

ip route get 10.20.15.30

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

Проверяйте маршрутизацию по IP-адресу. DNS отвечает за преобразование имени в адрес и не исправляет отсутствие маршрута.

Проверка доступности через ping и tracepath

Диагностику выполняйте последовательно:

ping -c 4 192.168.10.1
ping -c 4 10.20.15.30
tracepath 10.20.15.30

Если шлюз недоступен, ищите ошибку в адресе, префиксе, VLAN, состоянии интерфейса или физической связности. Если шлюз отвечает, а узел в удаленной сети недоступен, проверяйте обратный маршрут, ACL, firewall и состояние промежуточных маршрутизаторов.

tracepath показывает путь пакетов и MTU на маршруте. ICMP или UDP-пакеты могут фильтроваться, поэтому отсутствие ответа на отдельном переходе не всегда доказывает отсутствие маршрута.

Типовые ошибки Netplan и способы их исправления

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

Частые причины отказа:

табуляция вместо пробелов;
неверная вложенность routes, addresses или nameservers;
пропущенное двоеточие;
неверный формат списка;
несогласованные кавычки или лишние символы.

Запустите sudo netplan generate, исправляйте одну группу ошибок за раз и повторяйте проверку. Применяйте конфигурацию только после успешной генерации.

Неверное имя интерфейса или адрес шлюза

Если Netplan сообщает, что устройство не найдено, сравните имя в YAML с выводом:

ip link

Шлюз должен находиться в непосредственно доступной сети. Для адреса 192.168.10.20/24 шлюз 192.168.10.1 подходит, а адрес из несвязанного диапазона без дополнительной настройки обычно недостижим.

Маршрут не появился или выбирается другой маршрут

Сначала выполните:

ip route
ip route get 10.20.15.30

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

Если маршрут отсутствует после netplan apply, проверьте, находится ли он в правильной секции интерфейса, не перезаписывает ли файл cloud-init локальные изменения и не использует ли система другой backend.

Потеря SSH-доступа после применения

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

Проверьте состояние интерфейса через ip link.
Проверьте адрес через ip addr.
Посмотрите маршруты через ip route.
Верните резервную копию YAML-файла.
Выполните netplan generate.
После проверки снова выполните netplan apply.

План отката должен быть готов до изменения адреса или default route. Это особенно важно для серверов без локальной консоли.

Где искать журналы и сообщения об ошибках

Если команда Netplan не объясняет причину, проверьте состояние backend и системный журнал:

systemctl status systemd-networkd
journalctl -u systemd-networkd -b
journalctl -b | grep -i netplan

Сопоставьте ошибку с этапом сбоя: чтение YAML, генерация backend-конфигурации, применение параметров или передача пакетов. Если интерфейс получил адрес, но трафик не проходит, проблема уже может находиться в шлюзе, обратном маршруте или правилах фильтрации.

Для системной диагностики ошибок маршрутизации пригодится шпаргалка по неверным шлюзам, маскам, метрикам и конфликтующим записям.

Контрольный список перед внедрением маршрутов в Ubuntu

Минимальный набор команд для проверки

cat /etc/os-release
ip link
ip addr
ip route
ip route get 10.20.15.30
ping -c 4 192.168.10.1
ping -c 4 10.20.15.30
tracepath 10.20.15.30
sudo netplan generate
sudo netplan apply

Сопоставьте результаты с YAML-конфигурацией:

используется правильное имя интерфейса;
адрес и префикс соответствуют сетевой схеме;
шлюз доступен;
маршрут default указывает нужный next-hop;
каждая целевая подсеть имеет ожидаемый маршрут;
ip route get выбирает правильный интерфейс и шлюз;
узлы в удаленных сетях отвечают или причина блокировки подтверждена;
после перезагрузки параметры сохраняются.

Что зафиксировать в документации сервера

Запишите имя YAML-файла, интерфейс, IP-адрес, префикс, шлюз, DNS, целевые подсети, next-hop и метрики. Добавьте дату изменения, результат проверки через ip route get, доступность контрольных адресов и порядок отката.

Для рабочих систем полезно зафиксировать зависимость от внешних компонентов: VLAN, маршрутизатора, VPN, облачной таблицы маршрутов, firewall и обратных маршрутов. Такая запись сокращает время восстановления, когда сетевую проблему ищет другой администратор.

Перед применением маршрутов проверьте YAML, сохраните копию, используйте netplan try при удаленной работе и подтвердите результат командами ip addr, ip route, ip route get и ping.

Маршрутизация через Netplan сводится к точному описанию интерфейса и направлений трафика. Предсказуемый результат дает связка из корректного префикса, достижимого шлюза, проверенных маршрутов и контроля после перезагрузки.