Wieso Bridging bei virtuellen Maschinen

[NoobOfLinux]

Hallo!

Ich lese immer wieder in HowTo's zu dem Thema Virtualisierung, dass die VM's in virtuellen Netzwerken realisiert sind und das die Möglichkeiten, eine VM direkt in ein Netz zu bekommen eher begrenzt sind. Ich habe in einem anderen Post hier im Forum bereits versucht, eine "Bridgeless" Lösung mittels virtuellen Schnittstellen und passtrough zu realisieren. Wem das interessiert, nachfolgender Link führt zum Post: viewtopic.php?f=12&t=179827 Langsam glaube ich, dass ich einen Denkfehler in meinem Ansatz habe bzw. es einen Grund dafür gibt.

Wieso ist das so? Welchen Mehrwert habe ich mit virtuellen Bridges?

[unitra]

Weil es einfach zu konfigurieren ist. Plug'n Play und schon läuft's. Keiner hat Lust sich stundenlang mit Routing zu beschäftigten, auch wenn es möglich ist. Du baust doch ein kein full dynamic routed network, bei Dir zu Hause. Switch, DHCP und schon kann ich arbeiten. Fire and forget. Simpel und schnell. Das ist der Grund.

[NoobOfLinux]

Erstmal danke für den Input.
Ich versteh' zwar was du damit sagen willst aber ich bin da nach Recherchen zu kvm, qemu, libvirt und auch HyperV nicht dabei rausgekommen, das dass Netzwerken bei VM's einfacher ist.

Die Dinger arbeiten so gut wie immer in einer anderen IP-Range (es wird ja ein Netz gespannt, oft mttels internen DHCP) weshalb man von aussen eigentlich nur über DNS Namen ran kommt oder die Subnetzmaske weiter erhöht (k.a. 16er Bereich anstatt 24er, zumindest wenn das erste Oktett 192 ist, 172er wären demnach noch größer). Alternativ müsste ich zum Routing bzw NAT greifen, um die IP erreichbar zu machen (ohne dass ich wüsste wie das gehen sollte - ich hatte mal gelernt, das Pakete zu anderen Netzen i. d. ersten Oktetten gleich zum Gateway gebrüllt werden). Und dann hat man noch auf dem Host-System irgendwelche Schnittstellen-Konstrukte, wo man sich erst mal einlesen muss, obwohl man doch nur einen Apache2 in einer VM laufen lassen wollte.

Aufgrund dessen glaube ich, dass es nicht der einfacheren Arbeitsweise geschuldet ist, das virtuelles Bridging (zwingend) eingesetzt wird. Warum man eine VM betreibt ist mir klar (Snapshots, eventuelles Failover, Portabilität, ect.).

Ich kann mir zwar herleiten, dass man so eben schwerer von einer (kompromittierten) VM' auf den Host kommt und die VM auch nur "wenig Angriffsfläche" auf Protokollebene bietet aber mir wills nicht in den Kopf, warum nicht trotzdem die einfachste möglichkeit realisiert werden kann (wäre für mich eine virtuelle Netzwerkkarte, die der VM übergeben wird).

[whiizy]

Wieso ist das so? Welchen Mehrwert habe ich mit virtuellen Bridges?

Wenn man eine bridge eingerichtet hat, kann man beliebig viele virtuelle VMs darüber aufschalten - denke das ist der Hauptgrund.

[NoobOfLinux]

Wieso ist das so? Welchen Mehrwert habe ich mit virtuellen Bridges?

Wenn man eine bridge eingerichtet hat, kann man beliebig viele virtuelle VMs darüber aufschalten - denke das ist der Hauptgrund.

Wahrscheinlich ist es wirklich nur der Skalierbarkeit und der Isolierung der VM's geschuldet.

[bluestar]

Die Dinger arbeiten so gut wie immer in einer anderen IP-Range (es wird ja ein Netz gespannt, oft mttels internen DHCP) weshalb man von aussen eigentlich nur über DNS Namen ran kommt oder die Subnetzmaske weiter erhöht....

Nicht wirklich die ganzen bridges sind in Normalfall so konfiguriert, dass du eben von außen wegen NAT auf die IP des Hostes gar nicht rankommst.

Ich kann mir zwar herleiten, dass man so eben schwerer von einer (kompromittierten) VM' auf den Host kommt und die VM auch nur "wenig Angriffsfläche" auf Protokollebene

Die Angriffsfläche aus er VM auf den Host erhöht eine Bridge keineswegs.

warum nicht trotzdem die einfachste möglichkeit realisiert werden kann (wäre für mich eine virtuelle Netzwerkkarte, die der VM übergeben wird).

Das macht man doch heute so ... Ich habe eine Bridge br0 - darin steckt die physikalische Netzwerkkarte (eth0) und meine IP/DHCP Konfiguration läuft auf br0, wenn ich jetzt eine VM - die aus dem LAN her erreichbar sein soll - anlege, dann sage ich der VM bitte nutze die br0 als Brücke und schon steckt die VM im LAN.

Daneben habe ich eine zweite Bridge "vmbr0" diese hat einen eigenen IP-Range und auf dem Host läuft dnsmasq für DHCP und DNS, alle Verbindungen, die aus dem Netzbereich der vmbr0 kommen werden ausgehend ganz einfach genattet.

[NoobOfLinux]

Die Dinger arbeiten so gut wie immer in einer anderen IP-Range (es wird ja ein Netz gespannt, oft mttels internen DHCP) weshalb man von aussen eigentlich nur über DNS Namen ran kommt oder die Subnetzmaske weiter erhöht....

Nicht wirklich die ganzen bridges sind in Normalfall so konfiguriert, dass du eben von außen wegen NAT auf die IP des Hostes gar nicht rankommst.

Na das hab ich ja geschrieben gehabt, das die VM über IP nicht erreichbar ist. Gut, wenn man DNS kennt, weiß man, dass Bspweise die FQDN in eine IP übersetzt wird aber dass kann ja auch im virtualisierten Netz passieren. Aber sehe ich das falsch, das so oder so eine unidirektionale Verbindung herauskommt? Ein Server funktioniert ja meistens nicht als "Fire-And-Forget"-Lösung.

Ich kann mir zwar herleiten, dass man so eben schwerer von einer (kompromittierten) VM' auf den Host kommt und die VM auch nur "wenig Angriffsfläche" auf Protokollebene

Die Angriffsfläche aus er VM auf den Host erhöht eine Bridge keineswegs.

So hatte ich das auch geschrieben gehabt.

warum nicht trotzdem die einfachste möglichkeit realisiert werden kann (wäre für mich eine virtuelle Netzwerkkarte, die der VM übergeben wird).

Das macht man doch heute so ... Ich habe eine Bridge br0 - darin steckt die physikalische Netzwerkkarte (eth0) und meine IP/DHCP Konfiguration läuft auf br0, wenn ich jetzt eine VM - die aus dem LAN her erreichbar sein soll - anlege, dann sage ich der VM bitte nutze die br0 als Brücke und schon steckt die VM im LAN.

Daneben habe ich eine zweite Bridge "vmbr0" diese hat einen eigenen IP-Range und auf dem Host läuft dnsmasq für DHCP und DNS, alle Verbindungen, die aus dem Netzbereich der vmbr0 kommen werden ausgehend ganz einfach genattet.

Versteh mich auch mal - die Lösung von dir beinhaltet zwei DHCP-Server, einen dnsmasq und zwei bridges -- ich frag mich halt nur, warum nicht einfach sowas wie's nativ im qemu-kvm geht, ne tap persistent erzeugt, der vm beim übergeben und gut hat. Da hab ich nur die tap erzeugt, hab demnach weniger heap und benutz' den dhcp/dns des netzwerkes.

Wenn du mir's nicht glaubst, hier der Commandostring:

Code: Alles auswählen

qemu-system-x86_64 -name winsrv2008r2 -enable-kvm WinSrv2008R2.img -usbdevice tablet -vnc :2 -k de -m 16384M -net nic,vlan=0,macaddr=52:54:00:12:34:58,model=virtio -net tap,vlan=0,ifname=tap0 -boot d -smp 12  -daemonize

K.A. ob das jetzt genau der Commandostring war, den damals genauso funktioniert hatte, wie ich es hier als Frage stelle (ich habs aus der alten History, da liefert grep an die 100 Ergebnisse). Die Config ist in libvirt schon nicht mehr umsetzbar (übrigens, auch nicht mehr in HyperV)

[EDIT] und ja, ich geb zu, das vlan ist auch schon nicht mehr notwendig, ich konnt' es aber nicht umgehen.

[bluestar]

Wenn du mir's nicht glaubst, hier der Commandostring:

Code: Alles auswählen

qemu-system-x86_64 -name winsrv2008r2 -enable-kvm WinSrv2008R2.img -usbdevice tablet -vnc :2 -k de -m 16384M -net nic,vlan=0,macaddr=52:54:00:12:34:58,model=virtio -net tap,vlan=0,ifname=tap0 -boot d -smp 12  -daemonize

K.A. ob das jetzt genau der Commandostring war, den damals genauso funktioniert hatte, wie ich es hier als Frage stelle (ich habs aus der alten History, da liefert grep an die 100 Ergebnisse). Die Config ist in libvirt schon nicht mehr umsetzbar (übrigens, auch nicht mehr in HyperV)

Ja natürlich geht das, doch das bedeutet ja für jede VM ein neues Device auf dem Host, welches du konfigurieren musst und wie du erkannt hast -> Libvirt kann das auch nicht und warum sollte ich da jetzt anfangen zu basteln?

[NoobOfLinux]

Da hast du mich bisschen missverstanden aber das werf' ich dir nicht vor. Ich hab 'n Kommunikationsproblem, das weiß ich. Ich erklär mich mal, damit's nicht zum nächsten shitstorm im Forum führt: Ich stelle mich bzw. meine Aussage infrage. Das was ich schreibe ist meistens weniger ein Standpunkt, eher eine Hypothese. Im Endeffekt hab ich keine Ahnung, ob ich auf dem Holzweg bin oder nur nicht die richtigen Seiten gelesen habe. Was ich aber weis ist, dass es anscheinend möglich ist (qemu-kvm) und wenn ich merk', dass die "best practise" in den meisten anderen, etabliert(eren) Lösung (hyperV, libvirt, damit also auch xen) eine andere ist, bin ich im Handlungszwang und muss ich doch Fragen, um wenigstens so herauszufinden, welche Info bzw welches Entwicklungsmuster da an mir vorbei gegangen zu sein scheint.

[bluestar]

Vielleicht noch mal zu deinem Denkfehler, in den meisten HowTos findest du Bridges, die ausschließlich virtuell konfiguriert sind und Bridges wo eine echte Netzwerkkarte als "Uplink"-Port enthalten ist. Die Standardbridge von libvirt ist konfigurationstechnisch gleich der br-virt ohne DHCP & NAT auf dem Host haben die VMs die an dieser Bridge hängen keinerlei Zugriffe auf dein Lan. Die zweite von mir skizzierte Bridge - verhält sich exakt wie du es dir an folgenden Stellen wünschst:

Ich möchte auf einer VM einen Webserver für's Intranet einrichten, der sich aber (im Netzwerk) wie ein physischer Host verhält, also als wenn ich vor einem realen Rechner sitzen würde mit allen Möglichkeiten und notwendigen Konfigurationsschritten.

Code: Alles auswählen

auto br-virt
iface br-virt inet static
    address 10.0.0.1/24
    bridge_ports none
    bridge_stp off
    bridge_fd 0

auto br-real
iface br-real inet dhcp
    bridge_ports enp2s0
    bridge_stp off
    bridge_fd 0

Für libvirt sieht die 2. Bridge Definition in XML dann folgendermaßen aus:

Code: Alles auswählen

<network>
  <name>Reale Bridge</name>
  <uuid>ca1dfe82-5fb8-4eea-91c7-7a7ab9403cc9</uuid>
  <forward mode='bridge'/>
  <bridge name='br-real'/>
</network>

Wenn du jetzt VMs an diese Reale Bridge anschließt, dann fühlt sich das in deinem Netzwerk so an, als wäre die VM als echter Server im Lan vorhanden.

[NoobOfLinux]

Sry für die Funkstille .. und danke dir! Es läuft wie du es in Erwartung gestellt hast! Ich bin begeistert!
Ich hatte ein wenig Zeit gebraucht zu bemerken, dass bridge-utils nicht installiert war und ohne das Paket war die Umsetzung einer Bridge doch etwas knifflig.