Удаленный доступ к QEMU по bridge интерфейсу

а почему тут роутер, еси это свич?

И зачем нат в qemu, если достаточно бридж?

А почему роутер если это свич?

Но это по факту и вправду роутер, просто там отдельный интерфейс с 4 портами под патчкорд которые работают в режиме свича. А так то да, правильнее действительно надо было назвать свичом

И зачем нат в QEMU, если достаточно bridge?

Ну пока он нужен был для закачки пакетов, сейчас надобности нет в нем, это так. Но даже если снять NAT, то ничего не заработает

qemu-system-x86_64 \
	-enable-kvm \
	-cpu host \
	-m 4096 \
	-machine q35,accel=kvm \
	-smp cores=4,threads=1 \
	-drive 'file=debian-opkg-server.qcow2,if=virtio,format=qcow2' \
	-netdev bridge,id=net0,helper=/usr/lib/qemu/qemu-bridge-helper \
	-device virtio-net-pci,netdev=net0,mac=00:16:3e:77:84:58

И вот вывод

user@pc-1~$ ssh user@192.168.1.4
user@192.168.1.4's password:
Linux qemu-vm 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Nov 10 10:10:52 2022 from 192.168.1.3
user@qemu-vm:~$ exit
exit
Connection to 192.168.1.4 closed.
user@pc-1~$ exit
exit
Connection to 192.168.1.3 closed.
user@pc-2~$ ssh user@qemu-vm
ssh: connect to host 192.168.1.4 port 22: Operation timed out

Ну так гораздо меньше вопросов

brctl show

посмотри, работает ли бридж и в нем ди все интерфейсы

Как то не складывается.

Интерфейса tap1 нет в списке интерфейсов. Он должен быть, когда qemu запущен. да и отмечено же net0, а не tap1 хотя это можт так и надо.

По прежнему не работает, причем когда я включаю виртуальную машину появляется интерфейс tap1. Так что я решил немного модифицировать скрипт так.

ip link add name br0 type bridge
ip addr flush dev enp1s0
ip link set dev enp1s0 master br0
ip tuntap add tap0 mode tap
ip link set tap0 master br0
ip link set up dev br0
ip link set up dev tap0
ip link set ip dev enp1s0
ip addr add 192.168.1.3/24 dev br0

qemu-system-x86_64 \
	-enable-kvm \
	-cpu host \
	-m 4096 \
	-machine q35,accel=kvm \
	-smp cores=4,threads=1 \
	-drive 'file=debian-opkg-server.qcow2,if=virtio,format=qcow2' \
	-netdev tap,id=net0,ifname=tap0,script=no,downscript=no \
	-device e1000,netdev=net0,mac=00:16:3e:77:84:5e 

ip addr flush dev br0
ip link del dev tap0
ip link del dev br0
ip addr add 192.168.1.3/24 dev enp1s0

На виртуальной машине соответствующему интерфейсу назначил ip адрес 192.168.1.4/24 с гейтвеем 192.168.1.3. 192.168.1.4 пингуется со всех сторон, но вот удаленный ssh не получается. Сразу чтоб отмести подозрения у меня файрволы что на виртуальной машине, что на хосте разрешают порт 22

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

при чем тут форвардинг? это бридж.

попробуй

tshark -nni tap0 port 22

tshark -nni br0 host 192.168.1.4 and port 22

после запуска виртуалки проверь еще раз brctl show я кстати честно говоря даже не знал, что ip умеет в бриджи. Всегда конфигурил brctl add addif show…

Попробуй через brctl настрой, вдруг какая еще специфика нужна в ip типа set up еще что

Все получилось! Проблема была в том что не был назначен соответствующий gateway под интерфейс на госте. Код запуска QEMU на хосте такой

ip link add name br0 type bridge
ip addr flush dev enp1s0
ip link set dev enp1s0 master br0
ip tuntap add tap0 mode tap
ip link set tap0 master br0
ip link set up dev br0
ip link set up dev tap0
ip link set ip dev enp1s0
ip addr add 192.168.1.3/24 dev br0

qemu-system-x86_64 \
	-enable-kvm \
	-cpu host \
	-m 4096 \
	-machine q35,accel=kvm \
	-smp cores=4,threads=1 \
	-drive 'file=debian-opkg-server.qcow2,if=virtio,format=qcow2' \
	-netdev tap,id=net0,ifname=tap0,script=no,downscript=no \
	-device e1000,netdev=net0,mac=00:16:3e:77:84:5e 

ip addr flush dev br0
ip link del dev tap0
ip link del dev br0
ip addr add 192.168.1.3/24 dev enp1s0

Интерфейс в госте настроил статически, да так чтобы в качестве gateway у меня выступал bridge. Я тунель у меня идет к Qemu и там отображается как enp0s2

auto enp0s2
iface enp0s2 inet static
    address 192.168.1.4/24
    gateway 192.168.1.3

Ну с помощью tshark ты должен был увидеть, что в одну сторону пакеты идут, а в обратную уже нет.

Да и вообще при обращении из виртуалки наружу ничего работать не должно было.

Не ну так действительно пошли запросы, а ответов не было. Я решил удалить натовский интерфейс, чтобы по нормальному Gateway задать. Вообщем второй интерфейс для хоста - ну такое… Так теперь буду иметь ввиду про эту команду, спасибо=)

Всегда пожалста. ;)

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

Просто шлюз по дефолту должен быть установлен правильно на правильном интерфейсе, а у остальных прописаны их подсети и локальные маршруты, если надо.

И в ццелом, то, что ты сделал, нельзя назвать решением. Это просто ты разобрался, как настраивать qemu. Решение - поставить (к примеру) проксмокс, настроить в нем нужные сети и создавать виртуалки с нормальной конфигуряемостью, резервным копированием, управлением и пр пр пр