Статический IP и netplan перестают работать через пару дней после свежей установки Ubuntu Server 18.04 LTS.

Вопрос или проблема

У меня серьезные проблемы с сетью на Ubuntu 18.04 LTS. Свежая установка. Я установил статический IP во время установки, который работал в течение нескольких дней и оставался установленным после нескольких перезагрузок. Теперь интерфейс не показывает IP. Похоже, что когда я установил этот IP, был сгенерирован netplan, который выглядит правильным, однако netplan apply ничего не делает.

Это произошло со мной ранее на предыдущей установке. Я разбирался с некоторыми настройками DNS, поэтому решил просто переустановить систему и не трогать ни одно из сетевых утилит на этот раз, но проблема все равно сохраняется.

Проблема возникает примерно через день и полтора после установки, кажется, случайно. Я не использовал машину, когда возникла проблема, и единственное, что я сделал на этой установке, это настроил несколько контейнеров Docker с Samba и SFTP.

Содержимое моего 50-cloud-init.yaml

# Этот файл сгенерирован на основе информации, предоставленной
# источником данных. Изменения не сохранятся между экземплярами.
# Чтобы отключить возможности конфигурации сети cloud-init, создайте файл
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg с содержимым:
# network: {config: disabled}
network:
    version: 2
    renderer: networkd
    ethernets:
        enp0s25:
            dhcp4: no
            addresses: [192.168.0.32/24]
            gateway4: 192.168.0.1
            nameservers:
                addresses: [1.1.1.1,8.8.8.8]

Вывод терминала из netplan –debug apply

** (generate:2227): DEBUG: 23:11:19.520: Обработка входного файла /etc/netplan/50-cloud-init.yaml..
** (generate:2227): DEBUG: 23:11:19.520: начинается новая обработка
** (generate:2227): DEBUG: 23:11:19.520: enp0s25: установка бэкенда по умолчанию на 1
** (generate:2227): DEBUG: 23:11:19.520: Генерация выходных файлов..
** (generate:2227): DEBUG: 23:11:19.520: NetworkManager: определение enp0s25 не для нас (бэкенд 1)
DEBUG:netplan сгенерированная конфигурация networkd существует, перезагрузка networkd
DEBUG:конфигурация для NM не сгенерирована
DEBUG:enp0s25 не найден в {}
DEBUG:Слияние конфигураций:
network:
  bonds: {}
  bridges: {}
  ethernets:
    enp0s25:
      addresses:
      - 192.168.0.32/24
      dhcp4: false
      gateway4: 192.168.0.1
      nameservers:
        addresses:
        - 1.1.1.1
        - 8.8.8.8
  vlans: {}
  wifis: {}

DEBUG:Пропуск несетевой интерфейс: lo
DEBUG:Пропуск несетевой интерфейс: docker0
DEBUG:Пропуск несетевой интерфейс: br-98e8ea9c70cb
DEBUG:{}
DEBUG:netplan инициирует .link правила для lo
DEBUG:netplan инициирует .link правила для enp0s25
DEBUG:netplan инициирует .link правила для docker0
DEBUG:netplan инициирует .link правила для br-98e8ea9c70cb

Мой ifconfig

br-98e8ea9c70cb: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.18.0.1  netmask 255.255.0.0  broadcast 172.18.255.255
        ether 02:42:51:a6:a3:66  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        ether 02:42:d5:d6:46:8e  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp0s25: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 00:24:7e:00:e0:30  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 16  memory 0xfc500000-fc520000  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 7926  bytes 592108 (592.1 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 7926  bytes 592108 (592.1 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Вы правильно сконфигурировали статический IP? Посмотрите Этот учебник. Помните, что настройка статического IP в 18.04 отличается от 16.04.

Кроме того, я бы посоветовал проверить, не “украл” ли другой хост в сети этот IP, возможно, попробуйте использовать другой статический IP для хоста. Убедитесь, что вы можете ping новый статический IP, чтобы проверить, доступен ли он.

Наконец, убедитесь, что вы выполняете sudo netplan apply, или sudo netplan --debug apply, чтобы применить новые настройки.

Мой лучший предположение состоит в том, что /etc/netplan/50-cloud-init.yaml сконфигурирован неправильно, поэтому внимательно пройдитесь по нему еще раз.

Удачи.

Ответ или решение

Проблемы со статическим IP и Netplan на Ubuntu Server 18.04 LTS: Решение и рекомендации

Ваш опыт с Ubuntu Server 18.04 LTS может быть довольно неприятным, особенно когда статическая IP-адресация перестает работать без видимой причины. На первый взгляд, ваше сетевое конфигурирование кажется корректным, но давайте рассмотрим ситуацию подробнее и предложим возможные шаги для решения проблемы.

1. Проверка конфигурации Netplan

Согласно приведенной вами информации, файл конфигурации 50-cloud-init.yaml выглядит правильно:

network:
    version: 2
    renderer: networkd
    ethernets:
        enp0s25:
            dhcp4: no
            addresses: [192.168.0.32/24]
            gateway4: 192.168.0.1
            nameservers:
                addresses: [1.1.1.1,8.8.8.8]

Однако важно удостовериться, что:

  • Указанный интерфейс enp0s25 действительно существует. Попробуйте выполнить команду ip link show или ifconfig для проверки доступных интерфейсов.
  • Ваша конфигурация YAML не содержит синтаксических ошибок (неправильные отступы, неиспользование пробелов вместо табуляций и т.д.).

2. Влияние cloud-init

Вы упомянули, что cloud-init может автоматически генерировать сетевые настройки, которые могут перезаписывать ваш файл netplan. Чтобы предотвратить это, обязательно выполните следующие шаги:

  • Создайте файл /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg с конфигурацией:
network: {config: disabled}

Это отключит управление сетью со стороны cloud-init, что поможет вашей статической конфигурации оставаться в силе.

3. Проверка наличия конфликта IP

Убедитесь, что другой аппарат в вашей сети не использует тот же IP-адрес. Вы можете использовать команду ping 192.168.0.32 для проверки доступности адреса. Если вы получаете ответы, это может означать, что IP-адрес уже занят.

4. Выполнение команды netplan

Вы правильно заметили, что команда netplan apply не приводит к ожидаемым результатам. Попробуйте выполнить:

sudo netplan apply

Или же получите подробное логирование:

sudo netplan --debug apply

При этом обращайте внимание на сообщения об ошибках, которые могут указывать на конкретную проблему.

5. Обновление и перезагрузка

Если проблема сохраняется более 1-2 дней, проверьте наличие обновлений системы. Возможно, это связано с известными проблемами, которые уже были устранены в обновлениях Ubuntu. Используйте команды:

sudo apt update
sudo apt upgrade

Не забудьте перезагрузить сервер после обновлений.

6. Временные особенности

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

Заключение

Убедитесь, что конфигурация вашего файла Netplan корректна и не нарушена другими службами, такими как cloud-init. Отключение управления сетью со стороны cloud-init и проверка на IP-конфликты – это ключевые шаги для решения вашей проблемы. Если все вышеупомянутое не сработает, стоит проверить логи системы для более глубокого анализа, используя команды типа journalctl -u systemd-networkd.

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

Оцените материал
Добавить комментарий

Капча загружается...