Xen vagy KVM hálózat bridge eszközzel

 ( termih | 2019. július 13., szombat - 23:05 )

Cél: Helyi hálózaton virtualizálva két szerver:

Lenne egy fizikai gép, amin Linux (Debian 10) fut.
Ez a gép csak két virtuális gépet futtatja.
A virtualizáció lehet Xen vagy KVM.
A két szerver is Linux lenne, aminek az Internetet
látnia kellene, hogy telepítés, frissítés mehessen.

Csak a hálózattal nem boldogulok, konkrétan a bridge-el.

Lehet, hogy rosszul gondolom, hogyan kellene megterveznem a IP címeket.
Nekem az lenne az ideális, ha lenne például egy 192.168.10.0/24
hálózat. Ebből a tartományból kapna, IP címet a fizikai
gép is, és a két virtualizált gép is.

Amit eddig elértem:
Létrehoztam a xenbr0 hidat a fizikai gépen.
(/etc/network/interfaces)
Xen szerveren /etc/xen/test01.cfg fájlban
így kötöm össze a virtuális gép hálózati kártyáját a fizikai gép bridge eszközével.
vif=[ '00:16:3E:00:1B:d8,bridge=xenbr0' ]

Az egyik virtuális gépről elérhető a fizikai gép.
Ha a fizikai gépen beállítok NAT-t, akkor a virtuális
gép látja az Internetet is.

Ami nem megy:
A virtuális gépről nem látszik a helyi hálózat
többi gépe, és persze a helyi hálózat többi gépéről
sem látszik a virtuális gép.

Kérdés:
Nincs olyan korlát, hogy a virtuális gépeknek másik IP
cím tartományból kell kikerülnie?

Mi az az irány amerre "mennem" kell, hogy a virtuális gépek a
helyi hálózat összes gépe számára láthatóak legyenek?

A gazdagép interfészei jelenleg:

# ip a
1: lo: 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
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s3: mtu 1500 qdisc pfifo_fast master xenbr0 state UP group default qlen 1000
link/ether 08:00:27:5f:2b:ff brd ff:ff:ff:ff:ff:ff
3: xenbr0: mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 08:00:27:5f:2b:ff brd ff:ff:ff:ff:ff:ff
inet 192.168.5.90/24 brd 192.168.5.255 scope global xenbr0
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fe5f:2bff/64 scope link
valid_lft forever preferred_lft forever
4: vif1.0: mtu 1500 qdisc pfifo_fast master xenbr0 state UP group default qlen 32
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
inet6 fe80::fcff:ffff:feff:ffff/64 scope link
valid_lft forever preferred_lft forever

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Probald meg ezt:

echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables

Persze a host-on... a virtualis gepen semmit nem kell allitanod, az egesz bridge-dolog csak a host-on jatszik.

Kellett egy modprobe br_netfilter, hogy kiadhassam,
mert nem volt nekem /proc/sys/net/bridge könyvtár.
Ez után ki tudtam adni:
echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables

Persze nem segített.

Láttam néhány doksiban ezt beállítást, az arptables és ip6tables végződéssel együtt.
Értelmezésem szerint azért van erre szükség, hogy a netfilter tiltsuk a bridge interfészen.
De nekem még nincs netfilter beállítva. A netfilter alapállapotban van, a láncok üresek és ACCEPT van
alapértelmezetten.

Fent írtam, ha NAT-ot állítok be gazdagépen, akkor az Internetet látom a virtuális gépen.
Igen, ilyet állítottam a netfilterben a nat táblára, de a filter táblához még nem nyúltam.

Szóval, kipróbáltam a fenti beállítást; a helyi hálózat másik gépe elérhető a gazdagépről (host gép), mint eddig, de a virtuális gépről továbbra sem.

Akkor meg par kerdes :)
- A `brctl show` kimenete micsoda?
- Illetve jobban megnezve, az `ip a` kimenetei kozott nem latom a virtualis interface-eket (tap0, tapX). Azok hogysmint vannak?
- KVM eseten mi a qemu-system-whatever idevago parameterezese?

Ezutobbikat mi igy szoktuk csinalni:

qemu-system-x86_64 \
        [...]
        -net nic,vlan=0 \
        -net tap,vlan=0,script=/data/root/qemu/whatevermachine/qemu-ifup.sh,ifname=tap2 \
        [...]

Ahol a qemu-ifup.sh tartalma:

#!/bin/bash

/sbin/brctl addif br0 $1
/sbin/ifconfig $1 up

Ami erdekes lehet hogy a tap2-nek nincs is ip-cime, merthogy igy minek :) az a br0 reszeve valik - oszt annyi.

Valamiert deb/stretch alatt ez a nf-call-iptables aktiv volt alapertelmezesben, igy kellett ez a sysctl is. De azt leszamitva nem volt szuk keresztmetszet, ellenben meg ilyen finomsagokra is figyelni kell hogy a host-on a tapX iface-t el kell inditani.

Segithet meg az is hogy igazi konfiguratort hasznalsz (azaz `ifconfig`-ot), ill erdemes megnezni az `ifconfig -a` kimenetet is!

Itt a brctl show kimenete:


# brctl show
bridge name bridge id STP enabled interfaces
xenbr0 8000.0800275f2bff no enp0s3
vif1.0

Tap? Hát olyan nincs. Az is kell?
Van itt van egy leírás:
https://wiki.xenproject.org/wiki/Xen_Networking

Innen idézek egy sort:
"...tapDOMID.DEVID. More recently they have been named vifDOMID.DOMID-emu..."

Ezek szerint át lett nevezve vifDOMAZONOSITO.DOMAZONITO.
Olyan meg van nekem: vif1.0
Mint az látszik is fent az ip a kimenetében. Szóval az a tap nem vif
nálam?

Egyenlőre Xenel próbáltam, ma kipróbálom KVM-el is, nekem az is
jó, ha azzal működik. Bár kár a Xenért.

De még utána nézek a tap eszköznek...

Ja, ha csak at lett nevezve akkor jo :) Hogy most xen vagy qemu az szerintem ilyenszempontbol mindegy.

Ha levalasztod a vifX-et a xenbr0-rol, adsz neki egy ip-t, akkor latjak egymast? Btw mi az ip-je a guest-nek? Itten meg a nyito-osszefoglaloban azt irod hogy 192.168.10.0/24, de az `ip a` kimenetben mar 192.168.5.90/255.255.255.0-s a bridge host-oldali ip-cime. Ami meg ugye nem jo.

Igen, bocsánat, az 192.168.10.0/24 tartományt példának szántam, de éppen 192.168.5.0/24 tartományban próbálkozom, mert az van itthon.
A virtuálisgépenk fixen 192.168.5.86/24 állítottam (Azonos tartományban vannak :)

De itt a virtuális gép ip a parancsa:


# ip a s
1: lo: 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
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:16:3e:00:1b:d8 brd ff:ff:ff:ff:ff:ff
inet 192.168.5.86/24 brd 192.168.5.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::216:3eff:fe00:1bd8/64 scope link
valid_lft forever preferred_lft forever

Aha, oke. Pedig igy akkor jonak kell lennie. Ez azt jelenti ezekszerint hogy a helyi halozatban vannak meg 192.168.5.xx-es gepek (ahol xx az nem 86 ill 90), es akkor azokrol mar nem latszik a virtualis gep, de a bridge (*.90) meg igen? Egyeb ilyesmi aprosag hogy `iptables`-ben valami megfogna? Par ez elvileg teljesen layer2, szoval furcsa lenne.

Olyasmit is kiprobalhatnal, hogy a masik lan-os gepen (xx-en, ld elobb) megprobalod megpingeni a virtualis gepet. Ekkor ugye az nem fog visszapingeni, viszont az ott kiadott `/usr/sbin/arp -n` kimenetben meg tudod keresni hogy az ARP oldas az megtortent-e. Igy akkor meg tudod kulonboztetni hogy layer2-n (ethernet bridge) vagy layer3-on (ip) van-e az elakadas.

Mondtad meg hogy ez a host ket virtualis gepet futtat. Azok latjak egymast?

Az arpos dolgot mindjárt kipróbálom, a másik virtuális gépet, egyenlőre nem telepítettem, az csak terv.

"Ez azt jelenti ezekszerint hogy a helyi halozatban vannak meg 192.168.5.xx-es gepek (ahol xx az nem 86 ill 90), es akkor azokrol mar nem latszik a virtualis gep, de a bridge (*.90) meg igen?"
Igen, így van.

"Egyeb ilyesmi aprosag hogy `iptables`-ben valami megfogna?"
Egy postban már említettem, hogy üres a filter tábla.

"Olyasmit is kiprobalhatnal, hogy a masik lan-os gepen (xx-en, ld elobb) megprobalod megpingeni a virtualis gepet. Ekkor ugye az nem fog visszapingeni, viszont az ott kiadott `/usr/sbin/arp -n` kimenetben meg tudod keresni hogy az ARP oldas az megtortent-e. Igy akkor meg tudod kulonboztetni hogy layer2-n (ethernet bridge) vagy layer3-on (ip) van-e az elakadas."

Igen, itt az eredmény:

~# arp -n
Address HWtype HWaddress Flags Mask Iface
192.168.5.101 ether c8:d9:d2:e8:47:8c C enp1s0
192.168.5.90 ether 08:00:27:5f:2b:ff C enp1s0
192.168.5.1 ether a0:f3:c1:d7:5c:7a C enp1s0
192.168.5.86 ether 00:16:3e:00:1b:d8 C enp1s0

Ott van a táblában az utolsó sor, tehát layer2-ben látják egymást.

Nagyon jo! Akkor latjak egymast, es ip-szinten van valami ami blokkolja. Nezd meg azt az nftables/appize akarmit, amit lejjebb diskuraltatok. Azokat sajn annyira nem ismerem. Illetve a masik iranyban is csekkold le hogy az ARP oldas megy-e (azaz a guest-rol pingeted a masik lan-os masinat, es akkor ott megjelenik-e).

Opcionalisan csinalhatsz valami altalanos tcpdump-ot (pl csak icmp-re keresve), hatha azon mar latszik hogy hol akad el. Siman lehet hogy egyik iranyba jo a forgalom csak a masik iranyba nem (pl UDP-t is megprobalhatsz atlokni, netcat-tal: a guest-en `netcat -u -l -p 1122`, a masik lan-os masinan pedig: `echo deadbeef | netcat -u 192.168.5.86 1122`, majd ugyanez forditva).

Nos: Fordítva nem megy:

A virtuális gépen töröltem az arp táblát.
Majd pinggel ICMP küldtem a hálózat egyik gépének, legyen a továbbiakban gép neve C.
A virtuális gép nem veszi fel az ARP táblába.

Másik amit tapasztaltam:
Ha ezen a C gépen küldök ICMP-t pinggel a virtuális gépnek, akkor a
virtuálisgép ARP táblájba bekerül. De nem tudja azt használni, hiszen
a ping továbbra sem megy.

Csináltam egy ilyen tesztet:
C gépen (ahogy fentebb írtam ez a hálózat egy tetszőleges gépe),
elindítottam egy tcpdumpot, amit csak a virtuális gépről
érkező, oda tartó csomagokat mutatja. A virtuális gépen pedig
töröltem a ARP táblát, hogy legyen ARP kérs, majd pingetni
kezdtem a C gépet:


# tcpdump src 192.168.5.86 or dst 192.168.5.86
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp1s0, link-type EN10MB (Ethernet), capture size 262144 bytes
20:05:38.864751 ARP, Request who-has 192.168.5.5 tell 192.168.5.86, length 46
20:05:38.864764 ARP, Request who-has 192.168.5.5 tell 192.168.5.86, length 46
20:05:38.864776 ARP, Reply 192.168.5.5 is-at bc:5f:f4:7e:38:5d (oui Unknown), length 28

Látszik, hogy a érkezik az ARP kérés, és C gép válaszol is.
Ezek szerint válasz érkezik a virtuális gép felé, de valahol eltűnik.

Vagyis mégiscsak layer2 szinten van hiba.

Utána néztem az nftablesnek is. Úgy látom a táblák és az alapértelmezett
láncok nem változtak. A láncok alapszabálya pedig most is ACCEPT.
Vagyis itt nem lehet gond. A nat tábla sem változott.

Az apparmort a GRUB-ból, kernel paraméterként kikapcsoltam.
Ez sem hozott megoldást.

Hat, nem valoszinu, de valami ilyesmi? `echo 0 > /proc/sys/net/bridge/bridge-nf-call-arptables`

UDP megy? C -> virtualis iranyba, ahol/ahogy az ARP is megy.

Mindenesetre tenyleg furcsa ez az egesz. Eleg sok ilyesmivel jatszottam mar, de ennyire furcsa akadast nem lattam :/ Igaz, hogy leginkabb stretch-en, nem buster-en, es leginkabb qemu/kvm-n, nem xen-en. Az egyetlen nem-trivialis dolog mindig a /proc/sys/net/bridge/bridge-nf-call-* beallitasokkal volt.

Ha nem nagyon bonyolult, szerintem probald meg qemu-val is.

A /proc/sys/net/bridge/bridge-nf-call-arptables nem segített.
Nem megy át az UDP-sem.

Csinálok egy stretch megoldást, xen. Ha nem megy egy kvm.
Ha azon megy, akkor márpedig a különbségeket kell keresni,
az új Debian10-en. Az eredményekről itt beszámolok majd.

Mellesleg lehet jók ezek a parancsok:
echo 0 > /proc/sys/net/bridge/bridge-nf-call-arptables
echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables

Csak ezek helyére kell mást keresni, mivel már nincs Debian10 iptables.
Az iptables minden utasítása le van fordítva nftables-re.
Úgy tűnik, ezek a fenti kernelparaméterek iptables-hez kőtödnek.

Leválasztottam a gazdán a vif1.0-t így:

ip link set up dev vif1.0

Ezek után nem látta a gazdagép és a virtuális gép sem egymást.

Najo, de igy nincs a vif1.0-nak ipeje :) Szoval a/ a bridge-bol szedd ki b/ huzd fel c/ adj neki valami random ip-cimet (ami lehetoleg az enoX-tol is diszjunk) d/ a virt gepnek is abban legyen a cime e/ hajra! Szoval az itten erosen nem ajanlott hogy pl a vif1.0-nak (pl) 192.168.5.11, mig a bridge maradekanak a 192.168.5.90 legyen az ip-cime :)

Ez alapján a bridge-ben csak a fizikai hálókártya meg az egyik VM vnic-e van. Bele kellene dugni a bridgebe a másik gép vnic-ét.

Üdv!

No, rájöttem mi a probléma. Eleve virtualizált környezetben csináltam,
amit nem írtam. Mint kiderült ez fontos momentum, ezért elnézést, lehet néhány
kört megkíméltem volna.

VirtualBoxon futott egy Debian, azon Xen gazdagép; azon futott a vendéggép.
Vagyis virtualizált környezetben virtualizáltam, teszteltem. A VirtualBoxban
szükség volt a hálózat haladó beállításánál "Kevert mód", mindenkinek
beállítás.

Így működik minden, mint le van írva. Xen, KVM, bármi.
Tehát szimpla bridge, így működik szépen. Most már mehet
valódi gépen.

Köszönöm a segítséget, a hozzászólást mindenkinek!

Még a centos7 első kiadásán én is próbálkoztam egy KVM-es bridge-el, akkor sehogyan sem jött össze, legközelebb majd tudom, kihez kell fordulni(:

mekkora szakmai ongyilkossag a "kevert mod" (es egyaltalan igy hasznalni mindent) egy 100as skalan? 4500?

Eliras vagy tenyleg ugy allitottad be, hogy host gepen xenbr0 ip tartomanya 192.168.5.90/24, mig guest-ben a 192.168.10.0/24 van konfigolva?
Avagy hogy nez ki hoston es guest-en ip addr es ip route kimenet?

Igen, mint írtam elírás, de fentebb be is másoltam a virtuális gép ip a s kimenetét.

Felteszem routingjuk is ugyanaz akkor, aminek jonak kellene akkor lenni.
Nem lehet, hogy debian 10 alatt nem megy csak neked? Abban mar default-ban be van kapcsolva apparmor, illetve iptables helyett nftables-t hasznal, ezek esetleg nem fogjak meg a bridge-en levo forgalmat?

nftables, apparmor: de lehet, ezeket megnézem.

Szia!

A "bridge-utils" ( brctl xxx ) csomag helyett használd az "openvswitch" csomagot, mivel a "bridge-utils" - bugos és nem jól működik együtt a virtuális gépekkel ( saját tapasztalat szerint: sehogy se ).

Tudtommal elég rég óta "openvswitch" a default csomag mind XEN/KVM alatt. (Ezért nem akar működni neked).

syntax:
ovs-vsctl add-br $bridge
ovs-vsctl add-port $bridge $interface
ovs-vsctl del-port $bridge $interface

A sima bridge-nek kellene mukodni ilyen alap felallasra, ott valamit te neztel be ha nalad annyira "bugos".

Tudtommal openvswitch nem a default egyiknel se, honnan veszed ezt?

Kolléga belinkelte:

https://wiki.xenproject.org/wiki/Xen_Networking

[ The Xen 4.3 release will feature initial integration of Open vSwitch based networking. ]

https://www.openvswitch.org/

[ It is the default switch in XenServer 6.0, the Xen Cloud Platform and also supports Xen ... ]

:)

"The Xen 4.3 release will feature initial integration of Open vSwitch based networking."
Szoval tamogatja, de nem default.

"It is the default switch in XenServer 6.0"
Szoval xenserver es nem sima xen.

Ahogy libvirt (kvm) is tamogatja de nem default.

a bridge-utils hol bugos, és mi nem működik jól?

Szia!

A "bridge-utils" akkor működik, ha csak fizikai interface-t használsz pl.: br0 ( eth1 eth2 )
Amikor már "nem fizikai" interface-t bridgelsz össze, akkor "furcsán" működik, és nem viszi át rendesen a forgalmat pl.: br0 ( eth1 eth2 tap0 tap1 )

Ilyen tipikus eset pl.: VM-ben futtatsz egy dhcp servert ( tap0 ), majd a másik VM-ben kérsz DHCP-vel ip-t ( tap1 ), ilyenkor nem fogsz ip-t kapni. Ha tcpdump-al rámész, akkor látod a kérést, csak a választ sehol.

Nalunk a DHCP szerver egy VM-ben fut, az oszt cimet a fizikai gepeknek is es a tobbi VM-nek is. Proxmox, linux bridge. Semmi gond...

szerintem ennek olvass utana mielott butasagokat beszelsz.

Szia!

Utánaolvastam, és már az említett OpenvSwitch volt a megoldás.
Google: bridge-utils kvm bug

Nálatok akkor valami extra-patchelt verzió futhat :)

en egy 2012-es bugot talalok csak errol, nem hiszem, hogy erre gondolnal, tekintve hogy ez meg ubuntu 12.04 alatt volt. tudnal adni egy friss linket?

az openvswitch egy teljesen mas megoldas, mint a linux kernelben levo bridge kod; ha nem kell belole mas funkcionalitas mint a linux bridge, akkor nem latom sok ertelmet azt hasznalni a standard kernelben levo bridge koddal szemben.

érdekes, nekem kiválóan működik a bridge úgy, hogy van benne taggelt VLAN interface-től kezdve OpenVPN ethernet tunnel interface-en át Xen domU (több VNIC-el).
Fizikai és virtuális gépen belül is "keverve".
Szóval nem tudom, melyik részének "nem kéne" működnie. Még jó, hogy Ő nem olvasta a post-odat :-)

sub
-----------------------------------------
Linux parancsok, kezdőknek