Portál AbcLinuxu, 6. června 2024 04:07
Dobry vecer,
prosim, poradte, jestli to, co se snazim udelat, je vubec mozne.
PC s Ubuntu 22 LTS ma nekolik sitovek, vsechny jsou pres PCI passthrough vecpane do virtualky s pfSense. Vedle pfSense na stejne masine bezi jeste dalsi VM.
pfSense (VM1)
WAN (em1, PCI passthrough)
LAN0,1,2,3 (em2-5, PCI passthrough), sdruzene do bridge
OPT (vmnet0, virtio sitovka z hypervisoru, vnet1 na strane hosta.. ale kam ji pichnout?)
^ pfSense je nastaven dobre, u fyzickych rozhrani vse funguje, routuje, vsechno slunickove.
CentOS (VM2)
eth0 na strane VM, vnet2 na strane hosta
Ubuntu (host)
Predstava spravneho nastaveni je, ze udelam bridge, do nej vecpu vnet1, vnet2 a nejaky virtualni interface (rikejme mu treba tun0) a vsechno bude standardne fungovat jako u rozhrani fyzickych. Jenze tomu tak neni.
Co jsem zkousel: pripojit obe VM v ruznem rezimu k hostu pres virtual networks pres virt-manager GUI, postupne vsechny 4 rezimy. Nejblize uspechu jsem byl, kdy fungovalo aspon spojeni pfSense VM > host, fungovalo dokonce i host > pfSense. Nefungovalo vsak: LAN (preroutovano na pfSense) > host (prestoze wireshark pusteny na Ubuntu ukazoval prichozi ICMP, odpoved nikdy neprisla, vypnuti FW zadnej rozdil... )
No a definitivne to rozbil zasah do pripojeni vytvoreneho libvirtem ze strany NetworkManageru, kdy jsem se z nej snazil udelat default gateway... Takze pres defaultne nabizene virtual networks zrejme cesta nevede, nakolik to neumoznuje nastavit defaultni vibr jako vychozi branu. OK, chapu, neni to uplne bezny use case.
Zkousim ted laborovat s bridgem na hostu vytvorenym pres NetworkManager, ale taky bez uspechu. Vytvorim bridge, dam do nej vmnet1 a vmnet2 jako slaves, overim, ze vNIC u obou VM je nastaveny na pripojeni do tohoto bridge a.... Host unreachable, ARP prazdny, nic, nada. A to porad jeste nejsem v bode, kdy bych do toho bridge chtel pridat i nejaky (tun?) adapter z hosta...
Tak si rikam, jestli to, ceho chci docilit, je vubec mozne? Nebo muze cesta vest pres OpenVSwitch?
Diky za napady.
Tak si rikam, jestli to, ceho chci docilit, je vubec mozne?Ceho chces docilit? Z textu jsem pochopil, ze mas dva virtualy na Ubuntu.
Tak jsem to mozna napsal nesrozumitelne, pardon.
Snazim se docilit toho, aby VM1, host i VM2 mohly komunikovat bez omezeni.
Pokud by se melo jednat o fyzicke sitovky, vytvorim nad nimi bridge a vse by fungovalo dle ocekavani.
Jenze u virtualnich sitovek mi to pri stejnem postupu, ale vlastne jen s jinymi nazvy interfacu, nefunguje.
Pro jednodussi ladeni uvedu jako priklad spojeni mezi CentOS VM a hostem (Ubuntu).
Na Ubuntu vytvorim bridge pres nmcli, dam mu nejakou ipv4 a pojmenuju treba virt_br.
ve vlastnostech VM CentOS dam vNIC nastaveni tak, at pouzije virt_br jako bridge
Startuju CentOS, nastavim ipv4 ze stejneho rozsahu, cajk.
Na Ubuntu spusteny prikaz pro overeni, ze je vse ok:
brctl show
ukaze vnet1 jako slave pod virt_br, v poradku a melo by to fungovat, zejo?
Jenze. Pustim ping z CentOS na adresu bridge, vse timeout.
Wireshark pusteny na interface bridge vidi prichozi ICMP a upozornuje, ze neni reply. Nicmene... ty pakety prisly.
ARP zaznam na strane CentOS VM se objevi.
Pustim ping opacnym smerem, z Ubuntu na adresu CentOS VM. Vse konci na host unreachable, Wireshark bezici na hostu ukazuje ARP dotazy, avsak bez odpovedi.
Cili pakety mezi hostem a CentOS VM prolezou jen jednim smerem, a jeste k tomu nejak divne polovicate, jako kdyby je mel pozrat firewall. Opacnym smerem pak neprojde vubec nic a ARP ani nezjisti, kam to ma vlastne poslat.
Diky za tip.
Defaultne ve vypisu sysctl -a tyto polozky vubec nevidim:
net.bridge.bridge-nf-call-ip6tables
net.bridge.bridge-nf-call-iptables
net.bridge.bridge-nf-call-arptables
Po spusteni:
modprobe br_netfilter
mi sysctl tyto hodnoty zobrazil, prenastavil jsem je na 0, avsak zmenu to neprineslo.
Dobry den
Takhle se to muze chovat, kdyz jsou nastavene nekonzistentne masky siti(jeden stroj si mysli, ze jsou na stejne siti, druhy je jineho nazoru).
marekUznavam, ze jsem s tim otravny, ale nespustil byste prosim na hostu prikaz:
ip route get ADRESA_QUESTA
A na questu prikaz:
ip route get ADRESA_HOSTA
a odpoved ukazal?
dekuji
marekDobry vecer,
v pohode, vazim si kazde snahy pomoci!
Masky podsite jsou uvedeny spravne, vsude /24, preklep jsem tam neudelal.
Adresy pro virt_br (na strane Ubuntu) i na strane VM (CentOS) jsou nastaveny rucne:
virt_br na hostu ma 192.168.122.254/24
eth0 (viditelny na hostu jako vnet0) ma 192.168.122.97/24, opet, rucni konfigurace.
Na ubuntu spusteno:
ip route get 192.168.122.97
192.168.122.97 dev virt_br src 192.168.122.254 uid 0
cache
Na centOS:
ip route get 192.168.122.254
192.168.122.254 dev eth0 src 192.168.122.97
cache
To dle meho vypada taky spravne.
Jdu jeste prubnout pridani fyzickeho rozhrani do tohoto bridge...
Kdysi jsem zazil, ze bridge byl up, ale jeden z portu byl down, pak se to chovalo divne...ale to bylo nekdy v pocatcich nm.
Doporucil bych spustit tcpdump na bridge, portu a questu a navzajem porovnat.
Dale bych zkusil bridge fdb show, jestli se alespon nauci forwardovat.
Provozuji vpodstate stejny setup a vse mi funguje bez fyzickeho rozhrani.
Vse jsem nastavoval pomoci nmtui a virt-manager, nikde jsem nenastavoval zadny spek...
Po restartu hosta se nastavi bridge a startujici quest se do nej pripoji.
Pote je mozne mezi hostem a questem po siti komunikovat.
marekNo, tak s pridanim fyzickeho rozhrani do bridge jsem si nepomohl, tak jsem z toho jelen.
Pravda, srovnat tcpdump primo na bridgi a na vnetx mne nenapadlo... Budu tedka par dni mimo, pristi tyden to omrknu, diky!
Nicmene videl bych to jeste na rozjeti druhe fyzicke masiny s cistym Ubuntu, novym pokusem a srovnavanim configu, to prece neni mozny totok... tuplem, kdz vam to jede.
Skús pozrieť tento blog. Potom je tu dokumentácia priamo na QEMU, kde si môžeš pozrieť príklad konfigurácie. Najdi si časť kde sa píše o bridge. Tam máš stručný popis ako dosiahneš sieťový most.
Myslím, že tento scenár asi nebude možné naklikať a môže do toho zasahovať networkmanager.
Vsechno sedi, vytvoreni bridge, poveseni VM na bridge, kontrola XMLka pro danou VM, overeni pres brctl show.
Jedine, co mne zarazi, je zminka:
Limitations
The libvirt server must be connected to the LAN via Ethernet. If it is connected wirelessly, a Routed network or NAT-based network are the only options.
Coz je ale dale vysvetleno tak, ze se to tyka spise Wi-Fi a toho, jak se zpracovavaji framy...
Bridging with a wireless NIC
Just like you can bridge two wired ethernet interfaces, you can bridge between an ethernet interface and a wireless interface. However, most Access Points (APs) will reject frames that have a source address that didn’t authenticate with the AP. Since Linux does ethernet bridging transparently (doesn’t modify outgoing or incoming frames), we have to set up some rules to do this with a program called ebtables.
Schvalne teda zitra prubnu, jestli to nahodou kouzelne nezacne fungovat pote, co do bridge pridam jednu fyzickou sitovku.
OK, tak uz jsem trosku moudrejsi, akorat stale ne dostatecne 
Wireshark na vnetx nebo primo na bridgi nedelal zadny rozdil, ale rikam si fajn, vsechno to rozbiju a pojedu znovu.
A dostal jsem se do celkem vtipne situace, opet, pres nmtui vytvoreny bridge br0 a VM povesene na dany bridge.
Tedka mi pro zmenu virtualky v bridgi pri startu pfSense, kdy pfSense zacne konfigurovat rozhrani, proste zmizi...
Z dmesg | grep br0 hypervisoru:
Spoustim CentOS VM:
br0: port 1(vnet0) entered blocking state
br0: port 1(vnet0) entered disabled state
br0: port 1(vnet0) entered blocking state
br0: port 1(vnet0) entered forwarding state
vsechno cajk dle ocekavani.
Spoustim pfSense VM:
br0: port 2(vnet1) entered blocking state
br0: port 2(vnet1) entered disabled state
br0: port 2(vnet1) entered blocking state
br0: port 2(vnet1) entered forwarding state
pfSense startuje a zacina nastavovat interfacy, mezitim v dmesg:
br0: port 1(vnet0) entered disabled state (mi to sestrelilo i sit z te CentOS VM?!)
br0: port 2(vnet1) entered disabled state (a tady to odstrihne i sebe; fyzicka rozhrani se na pfSense vsak bezi v poradku)
... a proste schluss.
Tak pro zmenu mudruju, proc se deje tady todle.
Loop tam nikde neni a chtelo by to fakt hodne kreativity jej dokazat vytvorit, takze STP je na tom bridgi neaktivni, nicmene jeho zapnuti na zkousku nemelo zadny vliv.
Ted uz ale mam aspon funkcni workaround. Po startu pfSense staci pustit
brctl addif br0 vnet0 vnet1
a najednou je vsechno azuro...
Tak prinejhorsim si holt udelam nejakej skript na autostart virtualek s pevnym cekanim dvou minut, nez porty do bridge rucne prida a bude, ale ... prece to musi mit nejakej duvod, ze se todle deje...?
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.