KVM+Tap в Fedora

Привет всем!

Решил немного упростить достигнутую конфигурацию достигнутую в треде http://linuxforum.ru/viewtopic.php?id=23348. А именно - решил исключить VDE-мост. И построить простой бридж штатными стредствами но не на физическом"eth", а на tap-девайсе.
Итак создаем конфигурационные файлы:

[console]# cat ifcfg-tap0
DEVICE=tap0
TYPE=Tap
BOOTPROTO=static
HWADDR=3E:EA:64:DA:EC:48
ONBOOT=yes
BRIDGE=br0

# cat > ifcfg-br0
DEVICE="br0"
TYPE=Bridge
BOOTPROTO="static"
IPADDR=192.168.43.1
NETMASK=255.255.255.0
GATEWAY=192.168.43.2
ONBOOT="yes"[/console]

Делаем "Service network restart". Видим, что интерфейсы заказанные поднялись:

[console]# ifconfig
br0 Link encap:Ethernet HWaddr 2A:C5:2D:E4:AB:DE
inet addr:192.168.43.1 Bcast:192.168.43.255 Mask:255.255.255.0
inet6 addr: fe80::28c5:2dff:fee4:abde/64 Scope:Link
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:153 errors:0 dropped:0 overruns:0 frame:0
TX packets:56 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:8100 (7.9 KiB) TX bytes:7528 (7.3 KiB)

tap0 Link encap:Ethernet HWaddr 2A:C5:2D:E4:AB:DE
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

p5p1 Link encap:Ethernet HWaddr 14:DA:E9:B5:0B:DE
inet addr:192.168.43.8 Bcast:192.168.43.255 Mask:255.255.255.0
inet6 addr: fe80::16da:e9ff:feb5:bde/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:29161 errors:0 dropped:1198 overruns:0 frame:0
TX packets:18545 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:21806321 (20.7 MiB) TX bytes:3914695 (3.7 MiB)
Interrupt:50 Base address:0x8000

[/console]

p5p1 - это физический интерфейс, оставлен в этом выводе для дальнейшего рассуждения.
Далее - проверяем iptables:
[console]#iptables-save
-A FORWARD -m physdev --physdev-is-bridged -j ACCEPT
-A FORWARD -i p5p1 -o tap0 -j ACCEPT
-A FORWARD -i tap0 -o p5p1 -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
[/console]
Первая строка обеспечивает форвардинг внутри моста (если он, правда, поднят на физическом интерфейсе, на p5p1).
Проверяем работу - 192.168.43.1 пингуется и по нему можно зайти (по ssh) на хост удаленно.
Теперь настраиваем в virt-manager виртуальную KVM-машину, указываем ей в параметрах NIC имя моста br0. Стартуем. У меня там в сетевых настройках все прописано статически. Итак, старт проходит корректно, сетевой интерфейс в виртуальной машине инициализируется и получает свой статический адрес.
А вот далее - опять oopps. Попытка пропинговать даже 192.168.43.1 (br0 на tap0) неуспешна. Destination host unreacheble. Если смотреть tcpdump'ом на tap0 - то там нет никакой активности совершенно. То есть ARP-запросы от виртуалки до него не доходят. Если бы это был мост на физическом интерфейсе (p5p1, eth), то всё было бы намано. За это отвечает следующая строка в правилах "-A FORWARD -m physdev --physdev-is-bridged -j ACCEPT" А вот как её исправить, чтобы трафик шел внутри моста на tap0?

А для чего tap0 ? Возможно в iptables запрещен INPUT igmp пакетов.

Kettler написал:

А для чего tap0 ? Возможно в iptables запрещен INPUT igmp пакетов.

Блин... Для тех, кто в бронепоезде: Я НЕ МОГУ ПОВЕСИТЬ МОСТ НА ФИЗИЧЕСКИЙ ИНТЕРФЕЙС. Не могу повесить по целому ряду причин. Их я приводил раньше. Именно поэтому я и кувыркаюсь то с VDE, то (сейчас) c TAP. Поскольку VDE не слишком удобен в эксплуатации:
1. Нет поддержки его в libvirt;
2. Необходима перекомниляция qemu.
3. Глюк с нахождением библиотеки libvdeplug.so.3.
Сейчас я хочу настроиться без него. На штатном мосту.

Вот, что я вижу на мосту, связанном с tap0:
[console]# tcpdump -n -i br0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:03:40.189590 ARP, Request who-has 192.168.43.1 tell 192.168.43.208, length 28
12:03:41.189567 ARP, Request who-has 192.168.43.1 tell 192.168.43.208, length 28
12:03:42.077871 IP 192.168.43.1 > 224.0.0.251: igmp v2 report 224.0.0.251
12:03:43.190565 ARP, Request who-has 192.168.43.1 tell 192.168.43.208, length 28
12:03:44.190577 ARP, Request who-has 192.168.43.1 tell 192.168.43.208, length 28
[/console]
То есть, я пытаюсь пропинговать с виртуальной машины (192.168.43.208) сам бридж (192.168.43.1). Я вижу, что ARP-запросы на br0 приходят. Но вот отвечать он не спешит. Равно и на tap0 ничего не перебрасывает.

Настрой логирование все дропнутых пакетов в iptables. Это очень удобно для отладки.
И что показывает ip r ?

Macumazan написал:

И что показывает ip r ?

[console]# ip r
default via 192.168.43.2 dev p5p1
169.254.0.0/16 dev p5p1 scope link metric 1002
169.254.0.0/16 dev br0 scope link metric 1005
192.168.43.0/24 dev p5p1 proto kernel scope link src 192.168.43.8
192.168.43.0/24 dev br0 proto kernel scope link src 192.168.43.1
[/console]

"Cruiser78" написал:

То есть, я пытаюсь пропинговать с виртуальной машины (192.168.43.208) сам бридж (192.168.43.1). Я вижу, что ARP-запросы на br0 приходят. Но вот отвечать он не спешит.

Подозреваю, что ответы уходят через

192.168.43.0/24 dev p5p1  proto kernel  scope link  src 192.168.43.8 

Попробуй направить все пакеты на 192.168.43.208 через br0.

Macumazan написал:

Попробуй направить все пакеты на 192.168.43.208 через br0.

Блин, колдун... Белый шаман, однако :-)
Совсем забыл, что надо дать "route add IP-VM gw br0".
Но и это не совсем помогаИть. Кроме этого надо обязательно (выяснил натурным экспериментом) объявить br0 как Proxy-ARP, то есть выполнить
[console]#echo 1 > /proc/sys/net/ipv4/conf/br0/proxy_arp[/console]
После этого виртуальная машина, подключенная к этому мосту, смогла увидеть локальную сеть.
Итак, считаю, что и эта задача решена.