Как настроить bridge для KVMGT?

d-7, как у тебя дела с аналогичной задачей? Что думаешь? Извини, что флудил в твоей теме.

Нда, вот это реально - каша.

Дружище, бридж - это просто бридж, без «privat», «public» и прочего невменяемого бреда. Или это терминология в каком-то веб-интерфейсе?

Эту терминологию используют в документации к KVM: http://www.linux-kvm.org/page/Networking

лол. Вот чудаки. Бридж - это просто L2 коммутатор. Куда ты его воткнёшь, там он и будет коммутировать.

Главное - не забудь бридж заизолировать.

Хорошо. Куда и как его нужно воткнуть, чтобы можно было:

1. Подключаться по сети с хоста на гостя, но гость без доступа в интернет.
2. Подключаться по сети с хоста на гостя, гость с доступом в интернет.

И что прочитать про команды ip link, ip tuntap, br и прочее?

я могу использовать Private Virtual Bridge?

Там же английским по белому написано:

This network won't be seen from the other virtual machines nor from the real network.

Т.е. с хоста эта сеть доступна не будет.

изолируется вот типа так

$IPTABLES -A FORWARD -i $HOST_IFACE -o $HOST_IFACE -j ACCEPT
$IPTABLES -A FORWARD -o $HOST_IFACE -j REJECT --reject-with icmp-port-unreachable
$IPTABLES -A FORWARD -i $HOST_IFACE -j REJECT --reject-with icmp-port-unreachable

#$IPTABLES -A FORWARD -i $LAN_52_IFACE -o $LAN_52_IFACE -j ACCEPT
#$IPTABLES -A FORWARD -o $LAN_52_IFACE -j REJECT --reject-with icmp-port-unreachable
#$IPTABLES -A FORWARD -i $LAN_52_IFACE -j REJECT --reject-with icmp-port-unreachable

Бридж — это, как писали выше, L2 коммутатор. Нельзя ли к br0 подключить хост и гостя так, чтобы интернет хост получал не через бридж, а через eth0?

Ты не в ту сторону копаешь. Это простой бридж. Это просто коммутатор. Тебе надо организацию сети думать, а не какие правила на бридж применить. Это ОБЫЧНАЯ сеть. Обычная. Ты что, не в состоянии обычную сеть спланировать?

Возьми лист бумаги и нарисуй.

Тебя смущает, что бридж и виртуалка размещены «внутри» хоста? Прекрати брать этот момент в рассчет. Просто прекрати делать это. Есть машина. Есть коммутатор. Есть еще машина. Есть линия или линии связи. Забудь, что всё происходит в рамках одной машины. Просто забудь об этом.

Назначаешь этому бриджу ip-адрес.

Может гостю IP назначить ты имел в виду? На L2 же нет IP, если я не путаю.

Ну если ты из изолированной сети хочешь попасть «наружу», то тебе нужна машина-шлюз, которая будет включена И в изолированную сеть И во внешнюю сеть. МАГИЯ!!!!

Это ясно.

Ковырянием пальцем в разных местах ты ничего не добьёшься. НАРИСУЙ на листе бумаге свою сеть.

Вот линии связи. Вот машины. Я хочу сделать так и так. Расставь на рисунке коммутаторы и шлюзы. Просто нарисуй.

Нет, именно бриджу.

https://imgur.com/7k6A7i4

Я примерно так представляю. Это позволит хосту (шлюзу) как давать доступ во внешнюю сеть, так и нет для гостя.

Что почитать про подобное управление?

Извините, я и впрямь слаб в сетях.

Отлично.
Значит, смотри. Теоретически, на хост-машине должен быть отдельный интерфейс, который ты включал бы в бридж для получения доступа к этому бриджу из хост-системы. Практически, они сделали проще. Они просто дали возможность выдавать ip адрес прямо непосредственно бриджу.
То есть, на хост-машине ты поднимаешь бридж, даёшь этому бриджу ip адрес и включаешь в этот бридж машину 2. Не забудь озаботиться выдачей ip настроек для машины 2. В результате ты получаешь обычную «прозрачную» тупую сеть, в которой все сетевые ресурсы доступны из любой машины (если правильно выдал ip второй машине и не забыл включить forward на хост-машине)
Далее, ты из этой сырой сети делаешь нужный тебе результат
Средствами iptables изолируешь бридж.
Средствами iptables на хост машине выполняешь задачу файрволла. Смысл в том, что следует эти вещи четко разделять. Это просто роли. Покольку у тебя в сети нет выделенной машины-шлюза, то эту роль будет выполнять хост-машина, средствами iptables.

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

для полноты понимания на схеме обозначь сетевые интерфейсы. Включая lo 127.0.0.1. Это очень облегчает.

вот это себе распечатай и держи перед глазами https://www.frozentux.net/iptables-tutorial/chunkyhtml/c962.html

Решение задачи «можно подключиться туда, но оттуда подключиться нельзя» решается очень просто. Средствами iptables. Для подключений туда используешь обычные правила для INPUT + для OUTPUT только established related. То есть, исходящий трафик будет возможен только для уже установленных соединений, которые возможны только при входящем подключении.

Я все ещё не могу представить, как бридж (коммутатор) может иметь IP, если IP — это L3, а коммутатор на L2. Или там какой-то хак используется?

Есть еще L3 коммутаторы.

Так, попробую уточнить (извиняюсь за расспросы).

Вот возьмем обычный маршрутизатор (роутер, например). У него есть внешний и внутренний IP. А коммутатор третьего уровня — это по сути маршрутизатор, чей внешний и внутренний IP совпадают, и который вдобавок делает так, что компы в внутренней и внешней сети находятся в едином VLAN?

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

Ты хочешь сказать, что схема сети примерно такая: https://imgur.com/t2lrqqf ?

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

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

Лично я не оч люблю виланы. Я бы без виланов сделал бы. Тебя никто не обязывает три машины-участника сети (внешний шлюз + хост + виртуалка) размещать в одной сети. Размещай на хосте еще одну сеть, тогда можно применять маршрутизацию и вообще фильтровать удобно. Тупо по сетям.

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

Меня в этом смущают сразу две вещи: как можно подключаться ко внутренней виртуальной сети без выделенного интрфейса и как коммутатор может иметь IP, если это L3 коммутатор, то как он работает.

А ты не смущайся. Роли, просто роли. Бридж умеет две роли. Да, собственно, все умные коммутаторы имеют ip и всякие веб-морды.

который вдобавок делает так, что компы в внутренней и внешней сети находятся в едином VLAN?

Все девайсы, воткнуте в бридж, находятся в одном широковещательном домене, vlan тут ни при чем.

Линуксовый бридж это все же L2 коммутатор, с опциональным виртуальным сетевым интерфейсом, воткнутым в него. Если бы его не было, то для того чтобы иметь доступ с хоста к сегменту сети в этом бридже, пришлось бы колупаться с veth интерфейсом, один конец пихая в бридж, а на другом настраивая ip.

Т.е. если создать бридж, напихать в него интерфейсов, и не назначить ip, то это будет аналогично тому, как если бы рядом с хостом лежал коммутатор, никак к нему не подключенный.

Хорошо. Допустим, хост получает инет по eth0. Я создал бридж br0 и выделил ему IP. Виртуалки при старте включаются в br0.

Можешь нарисовать схему сети в этом случае? Я извиняюсь, что задаю такие вопросы, мне кажется, что я не могу понять чего-то очевидного.

Тыц для примера. У тебя на хосте получается 2 сети, 192.168.1.0/24 и 10.0.0.0/24. Если на хосте выключен форвардинг, то виртуалки будут иметь доступ только к 10.0.0.0/24. Ну и к ней доступа не будет. Аналогично будет, если убрать ip c br0.

Интернета у виртуалок не будет (если только на роутере, который за хостом, нет маршрута для 10.0.0.0/24 через 192.168.1.101). Чтобы он появился, нужно городить NAT. В качестве default gw у виртуалок будет 10.0.0.1.

Если нужно, чтобы у виртуалок был ip из 192.168.1.0/24, тогда eth0 нужно включать в бридж, и ему присваивать ip 192.168.1.101 (или не присваивать, но тогда у хоста не будет доступа в сеть). Для адресов в другой подсети делать еще одни бридж, либо городить vlan'ы.

З.ы. я не мастер объяснять, но надеюсь понятно.

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

А NAT и прочее для того, чтобы гости внутри 10.0.0.0/24 могли выходить в 192.168.1.0/24 настраиваем не по eth0 и eth1, как в обычном шлюзе, а по диапазону IP.

А NAT и прочее для того, чтобы гости внутри 10.0.0.0/24 могли выходить в 192.168.1.0/24 настраиваем не по eth0 и eth1, как в обычном шлюзе, а по диапазону IP.

В 192.168.1.0/24 гости смогут ходить и без ната, да и в другие сети тоже, в которые роутит хост. Правда ответные пакеты до них могут не дойти, если на той стороне нет маршрутов до, 10.0.0.0/24. С помощью ната это можно обойти.

Вообще, советую посмотреть и почитать цикл «сети для самых маленьких», чтобы иметь общее представление о проиходящем в сети.

да и в другие сети тоже, в которые роутит хост

Хост вроде как клиент в 192.168.1.0/24, он просто к роутеру подключен, что раздает эту сеть.

А за цикл спасибо, прочту непременно.

Ну дома-то можно и обычной маршрутизацией обойтись, без NAT.

Как? Мне ведь нужно, чтобы я мог с хоста устанавливать двухстороннее соединение с гостями, а так же чтобы они имели доступ в интернет, который я бы смог контролировать, в том числе и запрещая полностью.

Так, я в процессе экспериментов наткнулся на это: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854241 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766664 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765936

TL;DR: в Debian чуть ли не с 8 версии qemu виртуалки не могут подключаться к бриджу, если не из-под root запущены. Не знаешь дистрибутив, где нет такого?

а ты не используешь libvirt и virt-manager?

Я делаю так:

1. Я прописал в /etc/qemu/bridge.conf

   allow bridge0

2. ip link add name bridge0 type bridge

3. ip link set bridge0 up

4. Потом запускаю виртуалку:

   vsevolod@hp15debian9:~$ qemu-system-x86_64 -hda qemu-vms/lubuntu.qcow -boot d -cdrom os/lubuntu-16.04.3-desktop-amd64.iso -m 2048 -enable-kvm -soundhw ac97 -vga qxl -net nic -net bridge,br=bridge0
   failed to create tun device: Operation not permitted
   qemu-system-x86_64: -net bridge,br=bridge0: bridge helper failed
   

5. При этом если ту же самую команду из-под root вводить, то виртуалка стартует. Причем вроде все условия для пользователя создал:

   vsevolod@hp15debian9:~$ groups vsevolod
   vsevolod : vsevolod dialout cdrom floppy audio dip video plugdev netdev bluetooth kvm libvirt-qemu vboxusers unpriv_ping
   vsevolod@hp15debian9:~$ ls -la /usr/lib/qemu/qemu-bridge-helper
   -rwxr-xr-x 1 root root 14328 окт  2 16:11 /usr/lib/qemu/qemu-bridge-helper
   

UPD: да, я в курсе, что эта виртуалка включена в бридж, в который ничего более не воткнуто, и на ней не будет сети. Я просто провожу предварительные тесты.

rhel7, centos7. Я правда через virsh пускаю, и под рутом сижу, но от пользователя тоже работает, если ему прав дать.

CentOS 7 мне не подходит — intel gvt-g требует ядро от 4.10

А какие права нужно дать пользователю?

CentOS 7 мне не подходит — intel gvt-g требует ядро от 4.10

elrepo в помощь

А какие права нужно дать пользователю?

Сейчас не могу посмотреть, это где-то в конфигах libvirt'а настраивается.

Мне еще QEMU от 2.8.50 нужно — где его взять для CentOS 7?

Либо собери, либо тогда fedora.

Я тут искал, и вот что нашел: http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/

Там есть упоминание пакета qemu-kvm-common-ev-2.9.0-16.el7_4.13.1.x86_64.rpm — это QEMU 2.9.0, что будет установлен в случае ядра старше 4.13?

Да, и Fedora сильно от CentOS 7 в плане сети отличается?

что будет установлен в случае ядра старше 4.13?

Без понятия, если честно. Добавил этот реп, зависимостей от ядра у этого пакета вроде нет.

Да, и Fedora сильно от CentOS 7 в плане сети отличается?

Ничем не отличается.