Мостовое сетевое взаимодействие в KVM/Qemu Пакеты, адресованные локальной сети, отбрасываются
Резюме: В мостовой конфигурации KVM/QEMU сетевые пакеты, предназначенные для гостевой ВМ, не доходят до нее.
Конфигурация: Хост - современный сервер Ubuntu 20.04.2 LTS; гость - любая из 3 ВМ, очень старый сервер Ubuntu 16.04, старый рабочий стол Ubuntu 20.04 и совершенно новый рабочий стол Ubuntu 21.04. Первые 2 ВМ преобразуются из немостовых, NAT'd, а третья была создана с указанием мостовой сети. В конечном итоге ВМ получат свои IP-адреса из основной локальной сети через DHCP, но пока и для лучшей отладочной информации они используют статические IP-адреса.
Определение моста хоста, /etc/netplan/01-netcfg.yaml, (это одна из многих попыток):
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
version: 2
renderer: networkd
ethernets:
enp3s0:
dhcp4: no
bridges:
br0:
# interfaces: [ enp3s0 ]
dhcp4: yes
# dhcp6: no
# link-local: [ ]
interfaces:
- enp3s0
# parameters:
# stp: true
# forward-delay: 4
Виртуальный материал, /etc/libvirt/qemu/networks/br0.xml:
<!--
WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
virsh net-edit br0
or other application using the libvirt API.
-->
<network>
<name>br0</name>
<uuid>40a8752c-d074-4802-bae8-b0aef95d9c99</uuid>
<forward mode='bridge'/>
<bridge name='br0'/>
</network>
Примечания: было опробовано много версий файлов bridge .xml, включая разные имена, и разные ссылки используют разные методы. Руководство Ubuntu Serverguide ссылается на this, где говорится, что имя и имя моста должны быть одинаковыми, но в других руководствах они не одинаковы. После того, как пустой файл был создан с помощью nano, эти команды:
virsh net-define br0.xml
virsh net-autostart br0
virsh net-start br0
были использованы для добавления и настройки. По умолчанию, NAT'd путь был развязан, из каталога автозапуска, чтобы не. В итоге он был не определен. Результат:
$ virsh net-list --all
Name State Autostart Persistent
----------------------------------------------
br0 active yes yes
На данный момент после перезагрузки вообще нет правил iptables. Однако виртуальные машины не имеют доступа к сети. Обратите внимание, что в некоторых ссылках упоминаются специальные правила iptables и специальные атрибуты для модуля br_netfilter, все это было испробовано. Этот вопрос и так достаточно длинный, не вдаваясь во все подробности вариаций, опробованных здесь.
Детали отладки: Независимо от варианта конфигурации, основная проблема всегда одна и та же, пакеты, предназначенные для VM, похоже, не доходят до хоста, по крайней мере, как видно из tcpdump. Однако пакеты широковещательного типа все же приходят и попадают на клиентскую ВМ.
В этом примере используется 192.168.111.59 (MAC: 52:54:00:60:ea:0e), серверная ВМ 16.04, и 192.168.111.132, raspberry-pi, в локальной сети. Хост-сервер 20.04 находится по адресу 192.168.111.136. Маска сети составляет 24 бита, 255.255.255.0. Шлюзом и DHCP-сервером является сервер Debian (на котором, кстати, отлично работают гостевые виртуальные машины с мостом).
Первый tpcudmp как видно с raspberry-pi во время ping:
doug@rpi2:~ $ sudo tcpdump -n -tttt -i eth0 ether host 52:54:00:60:ea:0e
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
2021-04-23 08:33:19.363553 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 08:33:19.487239 IP 192.168.111.132 > 192.168.111.59: ICMP echo request, id 27848, seq 14, length 64
2021-04-23 08:33:20.363542 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 08:33:20.527250 IP 192.168.111.132 > 192.168.111.59: ICMP echo request, id 27848, seq 15, length 64
2021-04-23 08:33:21.567215 IP 192.168.111.132 > 192.168.111.59: ICMP echo request, id 27848, seq 16, length 64
2021-04-23 08:33:22.607228 IP 192.168.111.132 > 192.168.111.59: ICMP echo request, id 27848, seq 17, length 64
2021-04-23 08:33:23.372351 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 08:33:23.647228 IP 192.168.111.132 > 192.168.111.59: ICMP echo request, id 27848, seq 18, length 64
2021-04-23 08:33:24.371431 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 46
Наблюдаем, что ВМ посылает пакеты просто отлично, что видно по всей активности ARP. Однако она никогда ни на что не отвечает. Теперь посмотрим на ту же активность с хоста, отмечая, что вывод tcpdump одинаков для любого из интерфейсов br0, enp3s0 или vnet0.
$ sudo tcpdump -n -tttt -i br0 ether host 52:54:00:60:ea:0e
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
2021-04-23 08:40:38.837608 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:39.837159 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:40.837122 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:43.842985 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:44.840895 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:45.840991 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:48.848508 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:49.848895 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:50.848871 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:51.514011 ARP, Reply 192.168.111.59 is-at 52:54:00:60:ea:0e, length 28
2021-04-23 08:40:52.928400 ARP, Reply 192.168.111.59 is-at 52:54:00:60:ea:0e, length 28
2021-04-23 08:40:53.853881 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:54.852472 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
Наблюдаем, что время от времени ВМ отвечает, но позже мы увидим, что это происходит на широковещательный пакет. Также кажется, что проблема в том, что 192.168.111.1 не отвечает. Так и есть, но по какой-то причине эти пакеты не видны на уровне tcpdump. Также обратите внимание на отсутствие ICMP-пакетов от raspberry-pi. Теперь покажите, что шлюз отвечает (это "br0" на другом компьютере. EDIT: заменен на лучший пример захвата, поэтому разные временные метки):
$ sudo tcpdump -n -tttt -e -i br0 ether host 52:54:00:60:ea:0e
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
2021-04-23 22:25:17.434415 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 22:25:17.434432 xx:xx:xx:xx:xx:xx > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at xx:xx:xx:xx:xx:xx, length 28
2021-04-23 22:25:20.440843 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 22:25:20.440859 xx:xx:xx:xx:xx:xx > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at xx:xx:xx:xx:xx:xx, length 28
2021-04-23 22:25:21.438316 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 22:25:21.438332 xx:xx:xx:xx:xx:xx > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at xx:xx:xx:xx:xx:xx, length 28
2021-04-23 22:25:22.438266 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 22:25:22.438283 xx:xx:xx:xx:xx:xx > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at xx:xx:xx:xx:xx:xx, length 28
2021-04-23 22:25:25.446312 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 22:25:25.446329 xx:xx:xx:xx:xx:xx > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at xx:xx:xx:xx:xx:xx, length 28
2021-04-23 22:25:26.446195 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 22:25:26.446211 xx:xx:xx:xx:xx:xx > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at xx:xx:xx:xx:xx:xx, length 28
Обратите внимание на исходящие пакеты VM, и ARP действительно завершен. Я не могу понять, как скопировать и вставить данные с ВМ, с которой я общаюсь через VNC, но она показывает несколько завершенных, но неактивных записей ARP в ответ на команду ip neigh, а tcpdump показывает некоторые ARP и широковещательные пакеты из локальной сети.
Другая информация (MAC, не относящиеся к этому вопросу, были скрыты):
$ brctl show br0
bridge name bridge id STP enabled interfaces
br0 8000.3c7c3f0d9983 no enp3s0
vnet0
$ brctl showmacs br0
port no mac addr is local? ageing timer
1 xx:xx:xx:xx:xx:xx no 0.00
1 3c:7c:3f:0d:99:83 yes 0.00
1 3c:7c:3f:0d:99:83 yes 0.00
2 52:54:00:60:ea:0e no 1.68
1 xx:xx:xx:xx:xx:xx no 2.14
1 xx:xx:xx:xx:xx:xx no 36.84
1 xx:xx:xx:xx:xx:xx no 89.57
1 xx:xx:xx:xx:xx:xx no 226.51
1 xx:xx:xx:xx:xx:xx no 13.28
1 xx:xx:xx:xx:xx:xx no 165.68
1 xx:xx:xx:xx:xx:xx no 165.68
1 xx:xx:xx:xx:xx:xx no 265.02
1 xx:xx:xx:xx:xx:xx no 27.62
2 fe:54:00:60:ea:0e yes 0.00
2 fe:54:00:60:ea:0e yes 0.00
$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
link/ether 3c:7c:3f:0d:99:83 brd ff:ff:ff:ff:ff:ff
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 3c:7c:3f:0d:99:83 brd ff:ff:ff:ff:ff:ff
inet 192.168.111.136/24 brd 192.168.111.255 scope global dynamic br0
valid_lft 51547sec preferred_lft 51547sec
7: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UNKNOWN group default qlen 1000
link/ether fe:54:00:60:ea:0e brd ff:ff:ff:ff:ff:ff
EDIT: интересно, что все ARP-пакеты от моего D-Link AC2600 Wi-Fi Gigabit Router, настроенного как коммутатор, всегда появляются на хосте, попадают на виртуальную машину и получают ответы:
$ sudo tcpdump -n -tttt -e -i br0 ether host aa:aa:aa:aa:aa:aa
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
2021-04-23 22:45:51.463524 aa:aa:aa:aa:aa:aa > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.59 (ff:ff:ff:ff:ff:ff) tell 192.168.111.58, length 46
2021-04-23 22:45:51.463631 52:54:00:60:ea:0e > aa:aa:aa:aa:aa:aa, ethertype ARP (0x0806), length 42: Reply 192.168.111.59 is-at 52:54:00:60:ea:0e, length 28
2021-04-23 22:46:51.466955 aa:aa:aa:aa:aa:aa > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.59 (ff:ff:ff:ff:ff:ff) tell 192.168.111.58, length 46
2021-04-23 22:46:51.467030 52:54:00:60:ea:0e > aa:aa:aa:aa:aa:aa, ethertype ARP (0x0806), length 42: Reply 192.168.111.59 is-at 52:54:00:60:ea:0e, length 28
2021-04-23 22:47:51.466889 aa:aa:aa:aa:aa:aa > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.59 (ff:ff:ff:ff:ff:ff) tell 192.168.111.58, length 46
2021-04-23 22:47:51.466965 52:54:00:60:ea:0e > aa:aa:aa:aa:aa:aa, ethertype ARP (0x0806), length 42: Reply 192.168.111.59 is-at 52:54:00:60:ea:0e, length 28
2021-04-23 22:48:51.479096 aa:aa:aa:aa:aa:aa > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.59 (ff:ff:ff:ff:ff:ff) tell 192.168.111.58, length 46
2021-04-23 22:48:51.479178 52:54:00:60:ea:0e > aa:aa:aa:aa:aa:aa, ethertype ARP (0x0806), length 42: Reply 192.168.111.59 is-at 52:54:00:60:ea:0e, length 28
EDIT 3 - Тест новой конфигурации: В попытке уменьшить количество переменных было сделано следующее:
- Скоро выходящий на пенсию Ubuntu 16. 04 сервер был включен, обеспечивая новую изолированную локальную сеть.
- главный сервер Ubuntu 20.04 был подключен непосредственно к сетевой карте со стороны LAN сервера 16.04. Не было задействовано никаких коммутаторов, только один длинный кабель Ethernet.
- Все было протестировано и, казалось, работало нормально. Доступ ко всему осуществлялся по ssh из моей основной LAN через мой основной статический IP WAN и обратно через мой тестовый статический IP WAN на старый сервер 16.04. Затем цепочка ssh-сессий с него на главный сервер 20.04.
- Клиент Ubuntu 16.04 VM был запущен на хосте.
- Была предпринята попытка "ping" со старого сервера-шлюза 16.04 на клиент.
- Результаты были такими же, как и в исходной конфигурации.
tcpdump на шлюзе старого сервера 16.04:
doug@DOUG-64:~$ sudo tcpdump -n -tttt -e -i enp2s0 ether host 52:54:00:60:ea:0e
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
2021-04-26 15:10:00.701941 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-26 15:10:00.701965 00:19:b9:0d:af:fa > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at 00:19:b9:0d:af:fa, length 28
2021-04-26 15:10:01.699156 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-26 15:10:01.699169 00:19:b9:0d:af:fa > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at 00:19:b9:0d:af:fa, length 28
2021-04-26 15:10:02.699141 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-26 15:10:02.699154 00:19:b9:0d:af:fa > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at 00:19:b9:0d:af:fa, length 28
2021-04-26 15:10:05.707404 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-26 15:10:05.707417 00:19:b9:0d:af:fa > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at 00:19:b9:0d:af:fa, length 28
2021-04-26 15:10:06.707097 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-26 15:10:06.707110 00:19:b9:0d:af:fa > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at 00:19:b9:0d:af:fa, length 28
2021-04-26 15:10:07.707094 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-26 15:10:07.707107 00:19:b9:0d:af:fa > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at 00:19:b9:0d:af:fa, length 28
tcpdump на сервере хоста 20.04:
doug@s19:~$ sudo tcpdump -n -tttt -e -i br0 ether host 52:54:00:60:ea:0e
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
2021-04-26 15:11:35.801771 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:36.800497 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:37.800491 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:40.807062 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:41.804469 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:42.804444 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:45.812553 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:46.812405 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:47.812398 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
В качестве примечания: из моей цепочки ssh-сессий на сервере хоста 20.04 я могу снова подключиться и ssh к клиенту VM просто отлично.
Заключение:Что-то не так на канальном уровне на сервере Ubuntu 20.04, так что входящие пакеты даже не "видны" tcpdump и не попадают на гостевую виртуальную машину. Diagram.
EDIT 4: По сравнению с информацией, предоставленной Кристианом Эрхардтом, потенциальная разница в моей системе заключается в том, что список MAC-адресов br0 может быть неправильным, с заменой первого байта. Примечание: неактуальные MAC удалены, запущено 3 ВМ:
doug@s19:~$ brctl showmacs br0
port no mac addr is local? ageing timer
1 3c:7c:3f:0d:99:83 yes 0.00 <<< enp3s0, br0
1 3c:7c:3f:0d:99:83 yes 0.00 <<< enp3s0, br0
4 52:54:00:22:2f:dc no 5.15 <<< VM 3
2 52:54:00:60:ea:0e no 3.29 <<< VM 1
3 52:54:00:60:ea:3e no 12.67 <<< VM 2
4 fe:54:00:22:2f:dc yes 0.00 <<< vnet2
4 fe:54:00:22:2f:dc yes 0.00 <<< vnet2
2 fe:54:00:60:ea:0e yes 0.00 <<< vnet0
2 fe:54:00:60:ea:0e yes 0.00 <<< vnet0
3 fe:54:00:60:ea:3e yes 0.00 <<< vnet1
3 fe:54:00:60:ea:3e yes 0.00 <<< vnet1
По какой-то причине Кристиан не показывает vnet, или как он называется в его системе, соединение с мостом (я не знаю, имеет это значение или нет):
$ brctl showmacs br0
port no mac addr is local? ageing timer
2 52:54:00:48:40:69 no 2.36 <- Guest
1 52:54:00:95:e4:2a no 0.00 <- outside system
1 52:54:00:9b:9b:0e yes 0.00 <- Host
1 52:54:00:9b:9b:0e yes 0.00 <- Host
EDIT 5: Данные, аналогичные EDIT 4, но с сервера Debian с 2 запущенными ВМ, который работает нормально:
doug@s15:~$ sudo brctl showmacs br0
port no mac addr is local? ageing timer
1 52:54:00:22:2f:dc no 17.85
2 52:54:00:27:1b:5e no 18.48 <<< VM 1
3 52:54:00:27:1b:ae no 2.14 <<< VM 2
1 f4:8c:eb:c8:08:a0 no 18.48
2 fe:71:fa:75:16:93 yes 0.00 <<< tap0 (VM1)
2 fe:71:fa:75:16:93 yes 0.00 <<< tap0
3 fe:e1:c5:2a:c7:e3 yes 0.00 <<< tap1 (VM2)
3 fe:e1:c5:2a:c7:e3 yes 0.00 <<< tap1
EDIT 6: информация от networkctl, нужно отметить, что сервер Debian показывает "Master: br0", а сервер Ubuntu нет:
Ubuntu:
doug@s19:~$ networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 enp3s0 ether enslaved configured
3 br0 bridge routable configured
4 vnet0 ether carrier unmanaged
4 links listed.
doug@s19:~$ man networkctl
doug@s19:~$ networkctl^Cnetworkctl
doug@s19:~$ networkctl status vnet0
● 4: vnet0
Link File: /usr/lib/systemd/network/99-default.link
Network File: n/a
Type: ether
State: carrier (unmanaged)
Driver: tun
HW Address: fe:54:00:60:ea:0e
MTU: 1500 (min: 68, max: 65521)
Queue Length (Tx/Rx): 1/1
Auto negotiation: no
Speed: 10Mbps
Duplex: full
Port: tp
Apr 30 07:40:51 s19 systemd-networkd[530]: vnet0: Link UP
Apr 30 07:40:51 s19 systemd-networkd[530]: vnet0: Gained carrier
Debian:
doug@s15:~$ networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 enp3s0 ether enslaved configured
3 enp1s0 ether routable configured
4 br0 bridge routable configured
10 tap0 ether carrier unmanaged
5 links listed.
doug@s15:~$ networkctl status tap0
● 10: tap0
Link File: /usr/lib/systemd/network/99-default.link
Network File: n/a
Type: ether
State: carrier (unmanaged)
Driver: tun
HW Address: fe:8a:6a:ce:18:9c
MTU: 1500 (min: 68, max: 65521)
QDisc: pfifo_fast
Master: br0 <<<<< Different than Ubuntu
Queue Length (Tx/Rx): 1/1
Auto negotiation: no
Speed: 10Mbps
Duplex: full
Port: tp
Вопрос: Что не так и как я могу заставить мостовые виртуальные машины работать правильно?