LINUX.ORG.RU
решено ФорумAdmin

Debian: рулить сетевыми интерфейсами через networking.service

 , , , proxmox 6,


0

1

Доброго здоровья ЛОРчане!

Сначала общий расклад есть дедик под Proxmox и две виртуалки KVM.

3 белых IP.

Шлюзом в мир на виртуалках служит бридж на гипервизоре.

Конфиг хоста

auto lo
iface lo inet loopback

auto enp4s0
    iface enp4s0 inet static
    address 23.40.141.243
    netmask 255.255.255.224
    gateway 23.40.141.225
    up route add -net 23.40.141.224 netmask 255.255.255.224 gw 23.40.141.225 enp4s0

auto vmbr0
iface vmbr0 inet static
    address 23.40.141.243
    netmask 255.255.255.255
    bridge_ports none
    bridge_stp off
    bridge_fd 0
    bridge_maxwait 0
    pre-up brctl addbr vmbr0
    up ip route add 23.40.141.251/32 dev vmbr0
    up ip route add 23.40.141.252/32 dev vmbr0

auto vmbr1
iface vmbr1 inet static
    address 10.20.30.1
    netmask 255.255.255.0
    bridge_ports none
    bridge_stp off
    bridge_fd 0
    post-up iptables -t nat -A POSTROUTING -s '10.20.30.0/24' -o enp4s0 -j MASQUERADE
    post-down iptables -t nat -D POSTROUTING -s '10.20.30.0/24' -o enp4s0 -j MASQUERADE

Конфиг виртуалки

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens18
#auto ens18
iface ens18 inet static
	address 23.40.141.252/32
	gateway 23.40.141.243
	post-up route add 23.40.141.243 default gw 23.40.141.243
        pre-down route del default gw 23.40.141.243
	# dns-* options are implemented by the resolvconf package, if installed
	dns-nameservers 1.1.1.1 8.8.8.8
	dns-search example.com

allow-hotplug ens19
#auto ens19
iface ens19 inet static
    address 10.20.30.3
    netmask 255.255.255.224
    gateway 10.20.30.1
    post-up route add default gw 10.20.30.1
    pre-down route del default gw 10.20.30.1

При таком раскладе все работает. Вчера была другая проблема.

Если настроить виртуалку немного «по-старинке», вот так

auto lo
iface lo inet loopback

auto ens18
iface ens18 inet static
    address 23.40.141.252
    netmask 255.255.255.255
    dns-nameservers 1.1.1.1 8.8.8.8
    post-up ip route add 23.40.141.243 dev ens18
    post-up ip route add default via 23.40.141.243 dev ens18
    pre-down ip route del default via 23.40.141.243 dev ens18
    pre-down ip route del 23.40.141.243 dev ens18


auto ens19
iface ens19 inet static
    address 10.20.30.3
    netmask 255.255.255.0
    gateway 10.20.30.1

я не могу сделать перезапуск через systemctl restart networking, падает с ошибкой

Starting Raise network interfaces...
июн 17 16:17:33 node42 ifup[661]: RTNETLINK answers: File exists
июн 17 16:17:33 node42 ifup[661]: ifup: failed to bring up ens18

Первично настройки брал отсюда

Итак вопрос №1, почему не работает networking при таких настройках?

Вопрос №2, когда меняю auto на allow-hotplug, то default route на ВМ прописывается случайным образом (чаще всего неправильно), почему так?

В результате ВМ теряют выход в Сеть, т.к. маршрут по-умолчанию идеть через vmbr1

Пришлось его явно прописывать в текущих, рабочих конфигах.

Все работает, но я требую объяснений :-)

Вчера полдня потратил на выяснение этих деталей.

P.S. На виртуалках тоже Debian Buster minimal

★★★★★

Последнее исправление: Twissel (всего исправлений: 4)
Ответ на: комментарий от FireFighter

Нет, все-таки правильно, зря коммент удалил)

Не понял, почему это должно быть опечаткой?

systemd на ВМ так именует интерфейсы, влом это отключать.

Twissel ★★★★★
() автор топика

Можно считать, что вопрос с неправильным маршрутом по-умолчанию снят, в конфиге vmbr1, действительно, не сменил имя сетевого интерфейса после копипасты с eth0 на enp4s0.

Первый вопрос актуален.

Twissel ★★★★★
() автор топика
Последнее исправление: Twissel (всего исправлений: 3)
Ответ на: комментарий от infomeh

Хм… да, похоже, что ты прав.

Twissel ★★★★★
() автор топика
Ответ на: комментарий от FireFighter

Спасибо, ты угадал.

Все было достаточно просто, ниже напишу решение.

Twissel ★★★★★
() автор топика

Решение

  • Была опечатка в конфиге(ах) ВМ, как уже сказали выше;
  • Чтобы работал перезапуск через networking нужно менять auto $ifname на allow-hotplug $ifname

На засыпку, кто работает с Ubuntu 18/20.04 киньте аналогичный конфиг ВМ для netplan, если вам не лень)

Twissel ★★★★★
() автор топика
Ответ на: комментарий от FireFighter

Не, рано я радовался, default route прописывается не тот, даже после того как сконфигурировал все как надо :-\

А после systemctl restart networking в таком случае вообще все ломается…

Помогает перезагрузка ВМ из интерфейса Proxmox… но это ж не дело.

Twissel ★★★★★
() автор топика
Последнее исправление: Twissel (всего исправлений: 1)

Опишу еще раз проблему:

Если мы отдаём службе networking управление сетевыми интефейсами ВМ, указывая, например allow-hotplug ens18, у нас маршрут по-умолчанию прописывается кривой и случайным образом.

Когда же сменить в конфиге allow-hotplug на auto служба радостно рапортует, что не может поднять интерфейсы, НО все работает и таблица маршрутизации в норме.

Все-таки мне не показалось(((

Вариант конфига из ОП все исправляет, но причину я не знаю.

Twissel ★★★★★
() автор топика
Последнее исправление: Twissel (всего исправлений: 1)

Возможно, если прописать gateway везде в конфигурации туториала тоже все заведётся, но уже лень проверять.

Вернулся к тому, с чего начал.

Twissel ★★★★★
() автор топика

Какая то дичь в сетевых настройках на хосте. Должен быть один бридж. В него должен быть добавлен enp4s0. Адреса на enp4s0 быть не должно. Адрес должен быть на бридже. Никакого ната не надо, адреса в виртуалках белые, шлюз такой же как на хосте.

iliyap ★★★★★
()
Последнее исправление: iliyap (всего исправлений: 1)
Ответ на: комментарий от iliyap

Почему дичь?

Все логично. А если мне надо, чтобы VM общались в LAN, по локальным адресам?

Вопрос не в этом.

Twissel ★★★★★
() автор топика
Ответ на: комментарий от iliyap

шлюз такой же как на хосте

Вот тут, пожалуй, соглашусь, попробую при случае.

P.S. Но, как я сказал выше при таком раскладе мы не спрячем виртуалку от Мира.

Twissel ★★★★★
() автор топика
Последнее исправление: Twissel (всего исправлений: 1)
Ответ на: комментарий от iliyap

Вопрос в том, почему при auto для интерфейса networking падает (описано в Сети многократно), лечится allow-hotplug.

При allow-hotplug другая проблема, default route выставляется рандомно.

Работает все только когда явно указываешь gateway, как в ОП, «по-новому».

Twissel ★★★★★
() автор топика
Последнее исправление: Twissel (всего исправлений: 1)

Мне в голову приходила другая очевидная идея:

А не потому ли выбирается маршрут по умолчанию через LAN-шлюз, что у него маска больше?!

Twissel ★★★★★
() автор топика

2 вопроса уже можно объединить в один:

Кто и как строит таблицу маршрутизации именно при использовании networking.service ?

Уже понятно, что дело именно в ней.

Если ручками назначить правильный маршрут, все работает.

Twissel ★★★★★
() автор топика
Ответ на: комментарий от Twissel

А если мне надо, чтобы VM общались в LAN, по локальным адресам?

Дык для этого мост и делается. Все виртуалки в него как в коммутатор включаются и работают как полноправные хосты в сети, получая настройки по DHCP.

Radjah ★★★★★
()
Ответ на: комментарий от Radjah

Не, ты совсем уводишь тред с топика)

Вопрос не в этом, см. выше.

Я уже почти докопался до причины, как я её понимаю.

Twissel ★★★★★
() автор топика
Ответ на: комментарий от Twissel

@intelfx

Что тебе арчевод-системдешник подскажет, кроме перевода на networkd? И будет прав, потому что тот же restart в networking давно поломан и все об этом знают:

force-reload|restart)
        process_options

        log_warning_msg "Running $0 $1 is deprecated because it may not re-enable some interfaces"
gremlin_the_red ★★★★★
()

ключевое слово "шлюз"

Как было сказано в первом ответе: " —Конфиги проще сравнивать через diff ".

Если присмотреться к конфигу в туториале, можно заметить, что шлюз прописан только для LAN-моста в ВМ.

В этом вся причина) Это сбивает с толку networking чаще всего

Т.е. это происходит примерно так:

" —О, у нас есть шлюз и он единственный, давай-ка я через него пропишу default route! "

Это объясняет и то, почему если прописать оба шлюза, все ОК.

Twissel ★★★★★
() автор топика
Последнее исправление: Twissel (всего исправлений: 2)
Ответ на: комментарий от gremlin_the_red

Ну он, как и я, может заметить, что ЛОР уже не торт.

Я пришел с одним конкретным вопросом, а вместо этого мне начинают рассказывать про dhcp, кривые настройки сети в целом, systemd.

Жаль, что адекватные спецы вроде Димеза, Тазика, Шомана нас покинули…

Twissel ★★★★★
() автор топика
Ответ на: комментарий от gremlin_the_red

Т.е. «вина» networking тут только в том, что он не проверяет синтаксис настроек и не кричит юзеру, что тот идиот.

Ну то такое, не знаю как обстоят с этим дела у убунтят в netplan, позже гляну.

Twissel ★★★★★
() автор топика
Последнее исправление: Twissel (всего исправлений: 1)
Ответ на: комментарий от gremlin_the_red

Багованность networking тоже подтверждаю, но проявляется тот баг, что ты упомянул при других условиях)

Позже напишу.

Twissel ★★★★★
() автор топика
Ответ на: комментарий от gremlin_the_red

Баг тут другой.

Если мы используем синтаксис из шпаргалки и хотим порулить ВМ из GUI гипервизора, тогда снова внешний сетевой интерфейс не поднимается через networking, да.

ЧСХ, если перезагружать/выключать ВМ по KVM/SSH-консоли, все в норме.

Не знаю, может это лечится правильной установкой qemu-guest-agent, не проверял.

Ну и «новом» варианте без add/del ip dev $iface все работает тоже.

Twissel ★★★★★
() автор топика
Последнее исправление: Twissel (всего исправлений: 1)
Ответ на: комментарий от gremlin_the_red

Что тебе арчевод-системдешник подскажет, кроме перевода на networkd? И будет прав

Бгг.

intelfx ★★★★★
()
Ответ на: комментарий от Twissel

с тебя такая же конфигурация для networkd :-)

У меня сделано так, как @iliyap предложил.

Но то, что ты хочешь, делается тоже самоочевидно. Создаёшь два .netdev, три .network, переписываешь настройки из своего формата в .network. В networkd нет встроенного pre-up/post-down, но он и не нужен, одно несчастное правило можно вписать статически куда угодно.

intelfx ★★★★★
()
Ответ на: комментарий от Twissel

Можно начать с man systemd.netdev, man systemd.link, man systemd.network.

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

#
# /etc/systemd/network/40-lan.link
#

[Match]
MACAddress=70:85:c2:f3:66:16

[Link]
NamePolicy=
Name=lan0

#
# /etc/systemd/network/50-lan-bridge.netdev
#

[NetDev]
Name=br-lan
Kind=bridge

#
# /etc/systemd/network/50-lan-bridge.network
#

[Match]
Name=br-lan

[Network]
DHCP=yes
IPForward=yes
IPv6AcceptRA=yes

[DHCP]
UseDomains=yes

#
# /etc/systemd/network/50-lan.network
#

[Match]
Name=lan*

[Network]
Bridge=br-lan
intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

я не буду за тебя переписывать конфиги из одного формата в другой

Схемы вполне достаточно.

Twissel ★★★★★
() автор топика
Ответ на: комментарий от Twissel

По одной для каждого хоста?

По одной для каждого интерфейса, которых я в твоём исходном конфиге насчитал три.

intelfx ★★★★★
()

@beastie, не подскажешь откуда мне врезалось в память, что чем больше маска, тем выше приоритет маршрута?

Twissel ★★★★★
() автор топика

100% рабочий конфиг

Оставлю для памяти, может пережить перезагрузки кнопкой из веб-морды Proxmox.

qemu-guest-agent установлен.

Важно, что шлюз должен быть задан только один и шлюзом должен быть явно указан адрес гипервизора. Без этого все та же свистопляска.

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens18
#auto ens18
iface ens18 inet static
	address 23.40.141.252/32
	gateway 23.40.141.243
	post-up route add 23.40.141.252 default gw 23.40.141.243
        pre-down route del default gw 23.40.141.243
	# dns-* options are implemented by the resolvconf package, if installed
	dns-nameservers 1.1.1.1 8.8.8.8
	dns-search example.com

allow-hotplug ens19
#auto ens19
iface ens19 inet static
    address 10.20.30.2
    netmask 255.255.255.224
    #gateway 10.20.30.1
    post-up route add default 10.20.30.1
    pre-down route del default 10.20.30.1
Twissel ★★★★★
() автор топика
Последнее исправление: Twissel (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.