Настройка сети Linux через Netplan: IP, маршруты и DNS

Изменение одного IP-адреса на удалённом сервере может оборвать SSH и оставить систему без сети. Особенно опасно одновременно менять адрес, шлюз, DNS и имя интерфейса: после ошибки трудно понять, какой слой отказал. Netplan помогает описать желаемую конфигурацию Ubuntu в YAML, но безопасный результат зависит от подготовки и проверки.

Ниже настроим DHCP и статический IPv4, разберём маршруты, DNS и восстановление доступа. Примеры рассчитаны на современную Ubuntu Server с backend systemd-networkd. На рабочей станции может использоваться NetworkManager. Сначала определите владельца интерфейса; не пытайтесь управлять им несколькими системами одновременно.

Собираем факты до редактирования

Начните с команд, которые ничего не меняют:

ip -br link
ip -br address
ip route show
ip -6 route show
resolvectl status
networkctl status
ls -la /etc/netplan

Зафиксируйте точное имя интерфейса, текущий адрес с префиксом, шлюз, DNS, способ подключения и содержимое всех файлов Netplan. Учитываются все YAML-файлы каталога, поэтому два файла могут задавать противоречащие параметры. На облачном VPS конфигурацию способен генерировать cloud-init. Комментарий в файле обычно прямо предупреждает, будет ли он перезаписан.

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

Как читать YAML Netplan

YAML зависит от отступов. Используйте пробелы, не табуляцию. Верхний объект network содержит версию схемы, renderer и типы устройств. Имя под ethernets должно совпадать с реальным интерфейсом или с правилом match. Параметры применяются не по названию файла, а по объединённой конфигурации.

Вариант 1: адрес от DHCP

Для клиента, который должен получать IPv4 автоматически, минимальный файл выглядит так:

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

dhcp6: false здесь отражает конкретный учебный план, а не рекомендацию отключать IPv6 везде. IPv6 может настраиваться через Router Advertisement даже при выключенном DHCPv6; проектируйте его отдельно. Если сервер должен получать DNS или маршруты не от DHCP, Netplan позволяет переопределять принимаемые параметры, но сначала изучите фактический ответ DHCP.

Вариант 2: статический адрес и маршрут

Используем лабораторную сеть 192.168.50.0/24, адрес сервера 192.168.50.10, шлюз 192.168.50.1 и существующий DNS 192.168.50.53:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0:
      dhcp4: false
      addresses:
        - 192.168.50.10/24
      routes:
        - to: default
          via: 192.168.50.1
      nameservers:
        search:
          - lab.example
        addresses:
          - 192.168.50.53

Не копируйте эти адреса в свою сеть. Новый IP должен быть свободен и принадлежать локальной подсети, шлюз — реально маршрутизировать трафик, DNS — отвечать на запросы. Запись routes: to: default используется вместо устаревающих ключей gateway4 и gateway6. Один и тот же интерфейс не следует одновременно настраивать как DHCP-клиент и вручную без ясной причины.

Безопасное применение

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

sudo netplan generate
sudo netplan try --timeout 120

netplan try временно применяет настройки и ждёт подтверждения; без подтверждения программа пытается вернуть прежнее состояние. Документация предупреждает, что откат не является безусловной гарантией во всех случаях. Поэтому консоль и сохранённая конфигурация всё равно необходимы. На локальной машине подтвердите изменения только после проверки адреса, маршрута, DNS и нужных сервисов.

Если try неприменим в вашей среде, используйте netplan apply лишь при наличии проверенного плана отката. Команда изменяет активную сеть и может немедленно прервать соединение.

Диагностика по уровням

После применения не начинайте с браузера. Идите от локальной конфигурации к удалённому сервису:

ip -br address show dev enp1s0
ip route get 192.168.50.1
ip route get 1.1.1.1
ping -c 2 192.168.50.1
resolvectl status enp1s0
resolvectl query example.com
curl -I --max-time 10 https://example.com

Первая команда подтверждает адрес и префикс. ip route get показывает выбранный маршрут и исходный адрес. Доступность шлюза проверяет локальный путь, но некоторые устройства блокируют ICMP, поэтому вывод нужно сопоставлять с ARP/NDP и реальным трафиком. resolvectl query отделяет DNS от HTTP. Только затем curl проверяет TCP, TLS и ответ веб-сервера.

Если имя не разрешается, но соединение с известным IP работает, смотрите DNS. Если шлюз недоступен, смена DNS ничего не исправит. Если адрес и маршрут верны, а один TCP-порт закрыт, проверяйте firewall и сервис — не переписывайте Netplan без основания.

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

Команды ip address add и ip route add полезны в лаборатории и при диагностике, но их результат обычно исчезает после перезагрузки или повторного применения сетевого менеджера. Netplan описывает постоянное желаемое состояние. Не используйте временную команду как единственное исправление и не удивляйтесь, когда backend удалит адрес, которого нет в конфигурации.

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

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

      routes:
        - to: default
          via: 192.168.50.1
          metric: 100
        - to: 10.20.0.0/16
          via: 192.168.50.254
          metric: 200

Маршрут к 10.20.0.0/16 специфичнее default, поэтому будет выбран для этой сети независимо от того, что default имеет меньшую метрику. Выбор сначала учитывает длину префикса, затем параметры маршрутов одинаковой специфичности.

VLAN и MTU

Netplan умеет создавать VLAN, мосты, bonds и Wi‑Fi-подключения. Но наличие VLAN в YAML не настраивает порт коммутатора: тег должен быть разрешён на всём пути. Неверный MTU проявляется коварно — маленькие пакеты проходят, а крупные соединения зависают. Не уменьшайте MTU наугад; сравните путь, туннели и значения на обоих концах.

Firewall и безопасность изменений

Netplan не заменяет межсетевой экран. После смены адреса правила могут перестать совпадать, а служба — продолжить слушать только старый адрес. Проверяйте ss -lntup и действующую систему фильтрации. Не очищайте firewall командой массового сброса на удалённом сервере: это одновременно создаёт риск доступа и не объясняет исходную ошибку.

Если сеть получает конфигурацию через DHCP, доверяйте только контролируемому сегменту. Поддельный DHCP может навязать шлюз и DNS. Защита реализуется на уровне сетевой инфраструктуры, например функциями DHCP snooping, а не одной строкой Netplan.

Типичные ошибки

• Интерфейс назван eth0, но существует enp1s0. Netplan не применит блок к нужному устройству.
• Адрес указан без префикса. Запись должна включать /24, /27 или другую рассчитанную длину.
• Шлюз не находится в доступной on-link сети. Нужна корректная адресация или явно спроектированный маршрут.
• DNS указан, но не обслуживает клиентов. Проверьте порт 53 и сам запрос, а не только строку конфигурации.
• Изменён генерируемый cloud-init файл. После перезагрузки правка исчезает. Настройте источник конфигурации согласно документации облака.

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

После успешного теста перезагрузку выполняйте только в согласованное окно и при доступной консоли. Снова проверьте ip address, маршруты, DNS, прослушиваемые порты и прикладной мониторинг. Успешный SSH сразу после apply ещё не доказывает постоянство настроек.

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

Почему /etc/resolv.conf выглядит как ссылка?

В Ubuntu DNS часто обслуживает systemd-resolved, а файл указывает на сгенерированную конфигурацию или локальный stub. Редактирование его вручную может быть временным. Источник DNS задавайте в Netplan, DHCP или другом владельце конфигурации.

Нужно ли перезапускать сервер после изменения Netplan?

Обычно нет: конфигурацию применяет netplan try или netplan apply. Контролируемая перезагрузка полезна как финальный тест постоянства, но не как способ скрыть ошибку.

Можно ли отключить IPv6, если он не используется?

Сначала убедитесь, что он действительно не является частью инфраструктуры. Ошибочную AAAA-запись или маршрут лучше исправить. Глобальное отключение может повлиять на приложения и выходит за рамки простой настройки IPv4.

Перед практикой прочитайте как связаны IP, маска и шлюз, а для автоматической выдачи параметров — руководство по DHCP Kea.

Документация

• Netplan: примеры конфигураций.
• Netplan: безопасная проба и ограничения отката.
• systemd: resolvectl.

Статья может содержать партнёрские ссылки. Это не влияет на стоимость для вас, но помогает развивать блог.