Linux-Bridge-Networking für VMs einrichten

Standardmäßig sitzt eine KVM-VM hinter dem NAT-Netzwerk von libvirt: Sie erreicht die Außenwelt, aber nichts in Ihrem LAN erreicht sie direkt, und sie hat keine Adresse in Ihrem echten Netzwerk. Eine Linux-Bridge löst das. Sie verwandelt den Host in einen virtuellen Switch, sodass VMs und Container IP-Adressen im selben Subnetz wie der Host erhalten und als vollwertige Geräte im LAN erscheinen.

Diese Anleitung erstellt unter Ubuntu 24.04 eine dauerhafte Bridge mit Netplan, hängt eine KVM-VM daran und testet die Konnektivität — samt der Stolperfallen, die viele übersehen. Die Linux-Bridge ist zugleich das Primitiv unter OpenStack Neutron und OVN, sodass ihr Verständnis entmystifiziert, wie Cloud-Mandanten-Networking wirklich funktioniert.

Voraussetzungen

Sie benötigen Ubuntu 24.04 mit Netplan (Standard), eine funktionierende KVM/libvirt-Installation, eine kabelgebundene Schnittstelle (die Beispiele nutzen eno1) und idealerweise Konsolen- oder IPMI-Zugriff — das Umkonfigurieren der primären NIC über SSH kann Sie trennen. Bestätigen Sie zuerst Ihren Schnittstellennamen:

ip -br link

Wie eine Bridge funktioniert

Eine Bridge (br0) ist ein Software-Switch auf Layer 2. Sie hängen die physische NIC daran (enslave), verschieben die IP des Hosts auf die Bridge, und dann teilt sich jede an br0 angehängte VM-tap-Schnittstelle diesen Switch. Der Verkehr fließt, als wären alle am selben physischen Switch-Port eingesteckt.

Schritt 1: Die aktuelle Netplan-Konfiguration sichern

Behalten Sie immer einen Rückweg. Kopieren Sie die bestehende Datei vor dem Bearbeiten beiseite:

sudo cp /etc/netplan/50-cloud-init.yaml \
  /etc/netplan/50-cloud-init.yaml.bak
ls /etc/netplan/

Schritt 2: Die Bridge in Netplan definieren

Bearbeiten Sie Ihre Netplan-Datei so, dass die physische NIC keine IP trägt und die Bridge die statische Adresse besitzt. Verwenden Sie eine statische IP auf der Bridge — DHCP auf einer Bridge ist fragil. (Zur Auffrischung der statischen Adressierung siehe statische IP mit Netplan konfigurieren.)

network:
  version: 2
  renderer: networkd
  ethernets:
    eno1:
      dhcp4: no
      dhcp6: no
  bridges:
    br0:
      interfaces: [eno1]
      dhcp4: no
      addresses:
        - 10.10.10.20/24
      routes:
        - to: default
          via: 10.10.10.1
      nameservers:
        addresses: [1.1.1.1, 8.8.8.8]
      parameters:
        stp: false
        forward-delay: 0

Schritt 3: Sicher anwenden

Nutzen Sie netplan try, das nach 120 Sekunden automatisch zurücksetzt, falls Sie nicht bestätigen — Ihr Sicherheitsnetz gegen das Aussperren:

sudo netplan try

Funktioniert das Netzwerk weiterhin, drücken Sie Enter, um es zu behalten. Sind Sie sicher, wenden Sie es dauerhaft an:

sudo netplan apply

Prüfen Sie, dass die Bridge oben ist und die IP trägt und dass die NIC eingebunden (enslaved) ist:

ip -br addr show br0
bridge link
ip route

Schritt 4: Ein libvirt-Netzwerk für die Bridge anlegen

Damit VMs die Bridge per Namen wählen können, definieren Sie ein libvirt-Netzwerk, das auf br0 zeigt:

cat > br0-net.xml <<'EOF'
<network>
  <name>br0-net</name>
  <forward mode='bridge'/>
  <bridge name='br0'/>
</network>
EOF
virsh net-define br0-net.xml
virsh net-start br0-net
virsh net-autostart br0-net

Schritt 5: Eine VM an die Bridge anhängen

Für eine neue VM übergeben Sie --network bridge=br0,model=virtio an virt-install. Für eine bestehende VM hängen Sie eine Bridge-Schnittstelle live und dauerhaft an:

virsh attach-interface ubuntu-test \
  --type bridge --source br0 \
  --model virtio --persistent

Im Gast erhält sie nun eine Adresse im Subnetz des Hosts (über Ihr LAN-DHCP oder eine statische Konfiguration) statt des alten NAT-Bereichs.

Schritt 6: Konnektivität testen

Pingen Sie von einer anderen Maschine im LAN die neue Adresse der VM an. Pingen Sie von der VM das Gateway und einen externen Host:

ping -c3 10.10.10.50
ping -c3 10.10.10.1
ping -c3 1.1.1.1

Bestätigen Sie, dass das tap-Gerät der VM auf dem Host an die Bridge eingebunden ist:

bridge link | grep br0

Fehlerbehebung und Stolperfallen

• Host verliert nach dem Anwenden das Netzwerk — die IP liegt noch auf eno1 statt auf br0, oder beide tragen eine Adresse; nur die Bridge sollte das. Genau deshalb ist netplan try wichtig.
• VM hat keine Konnektivität — die Host-Firewall oder br_netfilter filtert Bridge-Verkehr; prüfen Sie sysctl net.bridge.bridge-nf-call-iptables.
• WLAN lässt sich nicht bridgen — die meisten WLAN-NICs verweigern im Client-Modus den Beitritt zu einer Bridge; Bridging ist für kabelgebundene Schnittstellen.
• Spanning-Tree-Verzögerungen — ist STP aktiv, brauchen Ports ~30 s zum Weiterleiten; belassen Sie stp: false bei einer einfachen Host-Bridge.
• Doppelte IP — Sie haben DHCP an NIC und Bridge aktiv gelassen; deaktivieren Sie es an der eingebundenen Schnittstelle.

Wie es weitergeht

Eine Host-Bridge ist manuelles Layer-2 auf einer einzelnen Maschine. Das Cloud-Äquivalent — softwaredefinierte Mandanten-Netze, Router und Floating IPs über viele Hosts — behandelt OpenStack Neutron: Netze, Router und Floating IPs. Für die zugrunde liegenden Adressierungsgrundlagen lesen Sie erneut statische IP-Konfiguration mit Netplan.

Fazit

Mit einer Linux-Bridge werden Ihre VMs und Container zu echten Bürgern Ihres Netzwerks, statt sich hinter NAT zu verstecken — unerlässlich für Server, die im LAN erreichbar sein müssen. Genau dieses Layer-2-Primitiv automatisieren OpenStack Neutron und OVN programmatisch über einen ganzen Cluster. Dieses Networking in großem Maßstab zu entwerfen, zu isolieren und zu betreiben ist ein ernsthaftes Unterfangen; clouditiv betreibt eine souveräne, ISO-27001-/BSI-C5-konforme Private Cloud auf Ubuntu 24.04 + OpenStack 2025.2 mit Self-Service-Mandanten-Netzen und Ihren Daten in Deutschland. Sehen Sie sich unsere On-Premise-Cloud-Lösung an.