# LXC Networking: Virtuelle Brücken & Netz-Isolation in Proxmox

TL;DR / Management Summary Ein LXC-Container erhält seine Netzwerkverbindung über ein virtuelles Paar von Ethernet-Geräten (veth). Das eine Ende liegt im Container (eth0), das andere Ende ist an eine Bridge auf dem Proxmox-Host (vmbr0) angeschlossen. Ein Senior Admin nutzt diese Architektur zur strikten Trennung: Jede Container-Gruppe landet in ihrem eigenen VLAN, und sensitive Dienste werden in isolierten NAT-Netzen ohne direkten Weg nach außen betrieben.

# 1. Die veth-Architektur

Die Brücke zum Kernel.

Anders als bei VMs gibt es keine emulierte Netzwerkkarte. Proxmox nutzt den Linux-Kernel, um ein transparentes Kabel (veth pipe) zwischen dem Namespace des Containers und der Bridge des Hosts zu spannen.

# 2. Standard-Netzwerkmodi

Vom LAN zur Isolation.

# 1. Bridged Mode (Standard)

Der Container verhält sich wie ein physischer PC im Netzwerk.

# 2. VLAN Tagging

Nutzen Sie eine VLAN-Aware Bridge am Host (Artikel 662).

# 3. Deep Dive: Container hinter NAT

Sicherheit durch Verstecken.

Wenn Sie Container in einem privaten Netz betreiben wollen, das keine echte WAN-IP hat:

  1. Erstellen Sie eine neue Bridge am Host (z.B. vmbr1) ohne physischen Port.
  2. Weisen Sie der OPNsense-Firewall ein Bein in dieser Bridge zu.
  3. Die OPNsense übernimmt DHCP und NAT für alle Container in dieser Bridge.

# 4. Day-2 Operations: Bandbreiten-Limitierung

Gerechtigkeit am Host.

Verhindern Sie, dass ein Container die 10G Leitung des Hosts für Backups allein beansprucht.

# 5. Troubleshooting & “War Stories”

Wenn die Pakete im Namespace sterben.

# Top 3 Fehlerbilder

  1. Symptom: Container kann das Gateway pingen, aber keine Webseiten erreichen.

    • Ursache: DNS-Konfiguration im Container falsch oder IPv6-Präferenz stört.
    • Lösung: DNS Server in den Container-Optionen explizit setzen (z.B. auf 1.1.1.1).

  2. Symptom: MAC-Adress-Konflikt.

    • Ursache: Zwei Container haben (z.B. durch manuelles Editieren der Config) die gleiche MAC bekommen.
    • Fix: Klicken Sie in der GUI auf das “Refresh” Icon neben der MAC-Adresse, um eine neue, zufällige ID zu generieren.

  3. Symptom: Keine Konnektivität nach dem Verschieben des Containers auf einen anderen Host.

    • Ursache: Die Bridge-Namen am Ziel-Host sind anders (vmbr0 vs. bridge0).

# “War Story”: Der “Double-ARP” Albtraum

Ein Admin konfigurierte eine feste IP im Container und die gleiche IP gleichzeitig am Host auf einem Alias-Interface. Das Ergebnis: Die Netzwerkkarte des Switches geriet in Panik (Flapping). Pakete landeten abwechselnd beim Host und beim Container. Da beide den gleichen ARP-Eintrag schickten, war die Verbindung für beide extrem instabil. Lehre: Nutzen Sie ein IPAM-System (Artikel 730) und vergeben Sie IPs niemals “aus dem Kopf”. In einer LXC-Umgebung sind die Grenzen zwischen Host-IPs und Container-IPs fließend – behalten Sie den Überblick!

# 6. Monitoring & Reporting

Traffic-Audit.

# Live-Verbrauch sehen (Shell)

Nutzen Sie pct am Host:

# Zeigt Echtzeit-Durchsatz für Container 100
watch -n 1 pct status 100

# 7. Fazit & Empfehlung

Container-Networking ist mächtig, erfordert aber Disziplin beim VLAN-Design.

# Anhang: Cheatsheet (pct net)

Aufgabe Befehl
Netz-Config zeigen `pct config
IP ändern pct set <id> -net0 name=eth0,bridge=vmbr0,ip=10.0.0.5/24
Rate Limit setzen pct set <id> -net0 ...,rate=10 (in MB/s)
Interface löschen pct set <id> -delete net1

# Referenzen