проясните по мостам пожалуйста

Мост это считай обычный свич, соответственно делайте выводы.

мосту присваивается ip, а свичу - нет
у свича на проводах висят их айпишники на том конце, а с мостом как?
ключевой момент - мост создаёт общую локалку, а свич нет, он просто пакеты перекидывает с одного провода на другой

Ты бы документацию почитал. На каком уровне работает мост. На каком уровне работает роутинг. Всё станет понятно сразу.

я читал, что это OSI 2
только ip то он всё равно получает
и понятно стало почти всё, кроме того что я спросил в первом посте

Плохо читал. Ты можешь не назначать адрес на бридж. От этого он не перестанет работать на 2 уровне, просто ты не сможешь с хоста трафик на виртуалки маршрутизировать, а виртуалки между собой смогут общаться, если у них настроена маршрутизация.

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

У тебя каша, а не вопросы. Ты сначала нормально их задай.

виртуалки между собой смогут общаться, если у них настроена маршрутизация.

снаружи то как к ним послать пакет, если у них адреса нет?

Свои-то адреса у них есть?

так... Тогда если у моста адрес .1.5, а у виртуалки .2.5, то мне на роутере надо прописать маршрут к .2.5 через .1.5, или где его прописывать?

проясните по мостам

Это не к лору, это к дантисту.

Стык между сетями у тебя где?

Да ладно, скоро до него дойдёт уже.

на мосту
но я из локалки .1.0 буду слать пакеты по адресу .2.5
они откуда узнают, что через мост?

Значит, в двух местах настраивать будешь. Ты же не описал нормально схему сети, вот и не ясно что тебе советовать.

Значит, в двух местах настраивать будешь.

а что именно на хосте надо будет писать?

С такими вопросами тебе в Job.

Опиши уже нормально в начальном посте что ты хочешь сделать.

чтобы пакет с адреса .1.9 (просто комп в локалке) добрался до виртуалки .2.5

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

мосту присваивается ip, а свичу - нет

Ну свичу тоже может присваиваться ip. Намёк понятен?

Ну свичу тоже может присваиваться ip. Намёк понятен?

это какой-то очень умный свич уже

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

ну если 2 разных адреса воткнуть в свич, то пакеты не дойдут...
или нужен умный свич с гейтом.
короче на хосте надо маршрутить получается
про ip_forward=1 я уже знаю
+в route добавить строчку...
ещё и в iptables надо что-то писать?

короче на хосте надо маршрутить получается

Можете маршрутиризировать, можете выдавать виртуалкам адреса локалки, решать вам.

так qemu же создаёт свою локалку...
ему разве можно зарядить туже самую локалку хоста?

так qemu же создаёт свою локалку...

qemu не создает ничего, не локалку, не глобалку. Не путайте с libvirt.

ему разве можно зарядить туже самую локалку хоста?

Можно.

ну тогда совсем хорошо. Можно и без ip_forward обойтись, и без роутинга

вот ещё непонятка тут... в мануалах написано, что надо вот так мост поднимать:

В файл /etc/network/interfaces мост прописывается в виде:
auto mybridge
iface mybridge inet static
bridge_ports eth0 eth1
address 192.168.10.10
netmask 255.255.255.0
network 192.168.10.0
broadcast 192.168.10.255

systemctl status networking.service
● networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Mon 2021-08-02 19:49:56 MSK; 4min 18s ago
     Docs: man:interfaces(5)
  Process: 439 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)
 Main PID: 439 (code=exited, status=1/FAILURE)

авг 02 19:49:56 myhost ifup[439]: run-parts: /etc/network/if-pre-up.d/br0-up2 exited with return code 7
авг 02 19:49:56 myhost ifup[439]: ifup: failed to bring up lo     
авг 02 19:49:56 myhost ifup[439]: RTNETLINK answers: File exists  
авг 02 19:49:56 myhost ifup[439]: RTNETLINK answers: File exists
авг 02 19:49:56 myhost ifup[439]: SIOCADDRT: File exists
авг 02 19:49:56 myhost ifup[439]: run-parts: /etc/network/if-pre-up.d/br0-up2 exited with return code 7
авг 02 19:49:56 myhost ifup[439]: ifup: failed to bring up br0
авг 02 19:49:56 myhost systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
авг 02 19:49:56 myhost systemd[1]: networking.service: Failed with result 'exit-code'.
авг 02 19:49:56 myhost systemd[1]: Failed to start Raise network interfaces.

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

auto br0
iface br0 inet static
bridge_ports eth0
address 192.168.3.9
netmask 255.255.255.0
gateway 192.168.3.1
broadcast 192.168.3.255

В итоге приходится в /if-pre-up.d/ запускать скрипт:

#!/bin/bash

ip link add br0 type bridge
ip link set br0 up
ip link set eth0 up
ip link set eth0 master br0
ip address add dev br0 192.168.3.9/24 broadcast +
route add default gw 192.168.3.1

А что за дистр ? Да, и логи посмотрите.
PS Да и ручками тоже нормально.

Debian buster
логи systemctl status выдаёт

с ручками пока не очень понятно...
да и без ручек непонятно
bridge будет поднят ДО поднятия qemu, а ему уже надо ифейс виртуалки прописать

Покажи ip l

Достаточно интерфейса локалки. Виртуальные потом воткнутся.

с ручками пока не очень понятно...

А что именно не понятно? Как прописать в libvirt ?
Например так

/etc/libvirt/qemu/networks/default.xml
<network>
  <name>default</name>
  <forward mode='bridge'/>
  <bridge name='br0'/>
</network>

А что именно не понятно? Как прописать в libvirt ?

да это есть. А libvirt сам добавляет в мост чтоли?

Ну например так.
/etc/libvirt/qemu/networks/default.xml

...
  <forward mode='bridge'/>
  <bridge name='br0'/>
...

а uuid, mac address, ip address там не надо указывать?

и ещё вот это походу надо:

<interface type='bridge'>
    <source bridge='br0'/>
    <model type='virtio'/>
</interface>

uuid - тама ужо должон был быть.

и ещё вот это походу надо:

А, вы про виртуалку.

<interface type='network'>
<source network='default'/>

ну в общем всё прекрасно заработало и снаружи пингуется, когда та же подсетка на виртуалке, что и хост
другую локалку не пробовал, но думаю с роутингом там тоже должно норм взлететь

всем спасибо

Делать ничего не надо, bridge получает IP от внешнего роутера. Как бы твоя сетевая карта получает несколько mac адресов, получит ли ip адрес и какой занимается внешний роутер.

Плюсы большие: можно снаружи по выданному адресу, подключатся к виртуальной машине, минус один, без внешнего устройства, не получишь доступ к машине (для решения этой проблемы, я поднимаю ещё один интерфейс с виртуальной сетью).

bridge получает IP от внешнего роутера
получит ли ip адрес и какой занимается внешний роутер

С каких это пор функцией роутера стало раздача ip адресов?

bridge получает IP

Ага, сам. Магическим образом!

получает IP от внешнего роутера

Совершенно не факт что роутер этим занимается.

Совершенно не факт что роутер этим занимается.

Если он по DHCP этим не занимается то и не получит.

Удивительно, для меня, если brige (virtualbox, promux: brige в сетевом смысле может быть иниым) назначить wifi интерфейсу, то ноуту роутер выдаст 2 ip и подключатся, допустим в макдоналдсе надо только один раз, а ip 2 хостовой машине и виртуальной. На практике оно так работает.

С каких это пор функцией роутера стало раздача ip адресов?

Если он по DHCP этим не занимается то и не раздаст. Но как правило они этим и занимаются.

Удивительно, для меня, если brige (virtualbox, promux: brige в сетевом смысле может быть иниым) назначить wifi интерфейсу, то ноуту роутер выдаст 2 ip и подключатся, допустим в макдоналдсе надо только один раз, а ip 2 хостовой машине и виртуальной. На практике оно так работает.

Ну тут либо бриджу не назначать DHCP, либо интерфейсу который смотрит наружу. Вообще, вешать DHCP-клиент на все доступные интерфейсы — не лучшая идея (а этим грешат все десктопно-ориентированные дистрибутивы Linux, насколько я помню).

Совершенно не факт что роутер этим занимается.

Если он по DHCP этим не занимается то и не получит.

Домашние искаропки (потому что они ориентированы на тех, кто в сетях вообще ноль и настроить что-либо не сможет), хотя и там можно отключить DHCP-сервер.

Но как правило они этим и занимаются.

«Как правило» они этим не занимаются.

Вообще, вешать DHCP-клиент на все доступные интерфейсы — не лучшая идея

Чем конкретно «идея» «не лучшая»?

(а этим грешат все десктопно-ориентированные дистрибутивы Linux, насколько я помню).

И правильно делают.

Вообще, вешать DHCP-клиент на все доступные интерфейсы — не лучшая идея

Чем конкретно «идея» «не лучшая»?

В комментарии, на который я отвечал, уже есть пример.

DHCP-клиент на все доступные интерфейсы — не лучшая идея (а этим грешат все десктопно-ориентированные дистрибутивы Linux, насколько я помню)

Хм ты заставил меня задуматся и напрячь память. Обычно, ещё при установке указываешь какой интерфейс хочешь использовать, и на него в interfaces прописывается DHCP, если ты хочешь другие сетевые использовать приходилось править, это я помню делал. Но в случае wifi эту операцию я не делал никогда, при установке как правило eth использую.

Бридж назначают на тот интерфейс через который хотят к виртуальной машине обращались, DHCP роутер как правило на нём есть, а нет так и вручную интерфейс можно сконфигурировать статичный, или получение автоматом.

Главное: твой интерфейс на реальной машине превращается в несколько, с несколькими мак адресами, одна сетевая карта в несколько. DHCP и остальное ip адреса уже вторично.

Хм ты заставил меня задуматся и напрячь память. Обычно, ещё при установке указываешь какой интерфейс хочешь использовать, и на него в interfaces прописывается DHCP, если ты хочешь другие сетевые использовать приходилось править, это я помню делал. Но в случае wifi эту операцию я не делал никогда, при установке как правило eth использую.

Не-не-не, я не об этом. В контексте мемберов бриджа DHCP-клиент вешается либо на одного мембера (интерфейс, смотрящий наружу), либо на бридж (который получает IP через интерфейс, смотрящий наружу).

Честно, не понял. Можно развернуть мысль?

Честно, не понял. Можно развернуть мысль?

bridge0  [DHCP]
├─ em0
└─ em1

или

bridge0
├─ em0   [DHCP]
└─ em1   [DHCP]

но не

bridge0  [DHCP]
├─ em0   [DHCP]
└─ em1

Аааа, ви в этом смысле.