Zum Inhalt

Linux Netzwerk-Namespaces, veth-Paare & Software-Bridges: Virtualisierungs-Primitive

Erstellt: 08.11.2026  ·  Zuletzt aktualisiert: 08.11.2026  ·  Nejat Hakan

Management Summary: Wie schaffen es Container-Runtimes wie Podman, Docker und Kubernetes, jedem Container eine eigene eth0-Schnittstelle, eine isolierte IP-Adresse, eine unabhängige Routing-Tabelle und eigene Firewallregeln zuzuweisen – ganz ohne das Booten einer virtuellen Maschine? Durch die Kombination von drei nativen Virtualisierungs-Primitiven des Linux-Kernels: Netzwerk-Namespaces (ip netns), virtuelle Ethernet-Paare (veth) und Layer-2 Software-Bridges (type bridge).

  • Netzwerk-Namespaces (ip netns)

    Vollständige Netzwerk-Stacks im Kernel-RAM isolieren: Eigene Socket-Queues, Routing-Tabellen, Loopback-Devices und Netfilter-Regeln.

  • Virtuelle Ethernet-Paare (veth)

    Virtuelle Kernel-Patchkabel spannen: Pakete, die an einem Ende hineingeschoben werden, treten am anderen Ende über Namespace-Grenzen hinweg aus.

  • Linux Kernel Bridges

    Software-definierte Layer-2 Learning Switches im Kernel betreiben – inklusive MAC-Forwarding-Database (FDB) und STP-Unterstützung.

  • Container-Fabric selbst bauen

    Ein komplettes mandantenfähiges Container-Netzwerk ausschließlich mit iproute2-Befehlen errichten und die CNI-Funktionsweise entmystifizieren.

1. Die drei Bausteine der Linux-Netzwerk-Virtualisierung

Moderne Container-Netzwerke benötigen keine proprietäre Software, sondern setzen sich aus drei standardisierten Kernel-Mechanismen zusammen:

%%{init: {'flowchart': {'wrappingWidth': 350}}}%%
flowchart TB
    subgraph RootNS ["Host Root Namespace"]
        direction TB
        BR["Linux Bridge: br-app0<br/>Gateway: 10.88.0.1/24"]
        VH1["veth-app1-br (Slave Port)"]
        VH2["veth-app2-br (Slave Port)"]
        BR --- VH1
        BR --- VH2
    end

    subgraph NS1 ["NetNS: ns-app1 (Container 1)"]
        VC1["eth0 (veth Peer)<br/>IP: 10.88.0.11/24"]
    end

    subgraph NS2 ["NetNS: ns-app2 (Container 2)"]
        VC2["eth0 (veth Peer)<br/>IP: 10.88.0.12/24"]
    end

    RootNS --> NS1 --> NS2
    VH1 <==>|"veth Patchkabel"| VC1
    VH2 <==>|"veth Patchkabel"| VC2
  1. Netzwerk-Namespace (ip netns): Eine logische Kopie des gesamten Netzwerk-Stacks. Prozesse innerhalb eines Namespaces können weder Sockets noch Schnittstellen des Hosts oder anderer Namespaces sehen.
  2. Virtuelles Ethernet-Paar (veth): Verhält sich exakt wie ein physisches Patchkabel mit zwei Enden. Es wird immer als Paar erzeugt. Wird ein Ende in einen Namespace verschoben, bildet es die Brücke zum Host.
  3. Linux Bridge (type bridge): Ein IEEE 802.1D Software-Switch im Kernel. Er lernt MAC-Adressen an seinen Ports, pflegt die Forwarding Database (FDB) und leitet Frames zwischen den angeschlossenen veth-Kabeln weiter.

2. Netzwerk-Namespaces verwalten (ip netns)

Namespaces werden direkt über iproute2 gesteuert:

# 1. Zwei isolierte Namespaces erzeugen
sudo ip netns add ns-web
sudo ip netns add ns-db

# 2. Alle aktiven Namespaces auflisten
ip netns list

# 3. Namespaces sind als Bind-Mounts im Dateisystem hinterlegt
ls -la /var/run/netns/

Befehle innerhalb eines Namespaces ausführen

Befehle im Kontext eines Namespaces werden mit ip netns exec (oder der Kurzform ip -n <name>) abgesetzt:

# Schnittstellen im Namespace ns-web prüfen (anfangs existiert nur 'lo')
sudo ip -n ns-web link show

# Loopback-Schnittstelle im Namespace aktivieren (ZWINGEND ERFORDERLICH)
sudo ip -n ns-web link set lo up

# Beliebige Prozesse im isolierten Namespace starten
sudo ip netns exec ns-web ss -tulpn

3. Das virtuelle Patchkabel: veth-Paare in der Praxis

Ein veth-Interface kann niemals alleine existieren; es wird immer als gekoppeltes Paar generiert:

# veth-Paar erzeugen: 'veth-host' und 'veth-guest'
sudo ip link add veth-host type veth peer name veth-guest

# Das Ende 'veth-guest' in den Namespace 'ns-web' verschieben
sudo ip link set veth-guest netns ns-web

# Im Namespace das Interface auf den Standardnamen 'eth0' umbenennen
sudo ip -n ns-web link set dev veth-guest name eth0

# IP-Adressen zuweisen und beide Enden aktivieren
sudo ip addr add 10.88.0.1/24 dev veth-host
sudo ip link set veth-host up

sudo ip -n ns-web addr add 10.88.0.2/24 dev eth0
sudo ip -n ns-web link set eth0 up

Wird nun vom Host 10.88.0.2 angepingt, wandern die Pakete direkt durch das virtuelle veth-Kabel in den Namespace ns-web.

4. Die Linux Bridge: Software Layer-2 Switching

Sobald mehr als zwei Namespaces miteinander kommunizieren sollen, reichen Punkt-zu-Punkt-Kabel nicht mehr aus. Wir stecken die Host-Enden aller veth-Kabel in eine Linux Bridge:

# 1. Virtuelle Bridge erstellen
sudo ip link add name br-app0 type bridge

# 2. Bridge mit IP versehen (dient als Standard-Gateway für alle Namespaces)
sudo ip addr add 10.88.0.1/24 dev br-app0
sudo ip link set dev br-app0 up

# 3. Das Host-Ende eines veth-Kabels an die Bridge anschließen
sudo ip link set veth-host master br-app0

# 4. Angeschlossene Ports und MAC-Forwarding-Tabelle (FDB) inspizieren
bridge link show
bridge fdb show dev br-app0

5. Hands-On Lab: Ein Container-Netzwerk von Grund auf selbst gebaut

Führe dieses Skript auf einem Debian-Server aus, um ein funktionierendes, isoliertes Zwei-Container-Netzwerk mit vollem Internetzugang zu errichten:

#!/usr/bin/env bash
# Datei: /opt/net-ops/build_container_fabric.sh
set -euo pipefail

echo "=== 1. Linux Bridge Gateway (br-app0) erstellen ==="
sudo ip link add name br-app0 type bridge
sudo ip addr add 10.88.0.1/24 dev br-app0
sudo ip link set dev br-app0 up

echo "=== 2. Zwei isolierte Netzwerk-Namespaces erstellen ==="
sudo ip netns add ns-app1
sudo ip netns add ns-app2

echo "=== 3. veth-Patchkabel erstellen und an die Bridge anschließen ==="
# App 1 Kabel
sudo ip link add veth-app1-br type veth peer name eth0 netns ns-app1
sudo ip link set veth-app1-br master br-app0 up

# App 2 Kabel
sudo ip link add veth-app2-br type veth peer name eth0 netns ns-app2
sudo ip link set veth-app2-br master br-app0 up

echo "=== 4. Netzwerkkonfiguration in den Namespaces vornehmen ==="
# ns-app1 konfigurieren
sudo ip -n ns-app1 link set lo up
sudo ip -n ns-app1 addr add 10.88.0.11/24 dev eth0
sudo ip -n ns-app1 link set eth0 up
sudo ip -n ns-app1 route add default via 10.88.0.1

# ns-app2 konfigurieren
sudo ip -n ns-app2 link set lo up
sudo ip -n ns-app2 addr add 10.88.0.12/24 dev eth0
sudo ip -n ns-app2 link set eth0 up
sudo ip -n ns-app2 route add default via 10.88.0.1

echo "=== 5. Internetzugang über Host-NAT-Masquerading aktivieren ==="
sudo sysctl -w net.ipv4.ip_forward=1 > /dev/null
sudo nft add table ip container_nat
sudo nft add chain ip container_nat post { type nat hook postrouting priority 100 \; }
sudo nft add rule ip container_nat post oifname "eth0" ip saddr 10.88.0.0/24 masquerade

echo "=== 6. Verbindungstest: Namespace-zu-Namespace & Internet ==="
# Ping von App 1 zu App 2 über die Bridge
sudo ip netns exec ns-app1 ping -c 2 10.88.0.12

# Ping von App 1 ins Internet über das Host-NAT
sudo ip netns exec ns-app1 ping -c 2 8.8.8.8

echo "=== Container-Netzwerk erfolgreich aufgebaut! ==="

6. High-Speed TCP Congestion Tuning: Google BBR & FQ

Virtualisierungs- und Container-Hosts mit tausenden gleichzeitigen TCP-Sitzungen sollten die alte paketverlustbasierte Überlastungssteuerung (cubic) durch Google BBR (Bottleneck Bandwidth and RTT) ersetzen:

%%{init: {'flowchart': {'wrappingWidth': 350}}}%%
flowchart TB
    CUBIC["Altes TCP CUBIC<br/>Erhöht Rate bis Verlust<br/>Bufferbloat & Latenz"]
    BBR["Google BBR + FQ Scheduler<br/>Misst Bandbreite & min RTT<br/>Kein Bufferbloat"]

    CUBIC -->|"Upgrade des Algorithmus"| BBR

BBR & Fair Queueing unter Debian aktivieren

Erstelle /etc/sysctl.d/99-tcp-bbr.conf:

# Datei: /etc/sysctl.d/99-tcp-bbr.conf
# 1. Fair Queueing (FQ) als Standard-Queueing-Discipline setzen
net.core.default_qdisc = fq

# 2. Google BBR Überlastungssteuerung aktivieren
net.ipv4.tcp_congestion_control = bbr

# 3. Socket-Puffergrenzen für Gigabit-Leitungen vergrößern (16 MB Maximum)
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# 4. TCP Fast Open (TFO) aktivieren
net.ipv4.tcp_fastopen = 3

Aktivieren:

sudo sysctl --system
sysctl net.ipv4.tcp_congestion_control

7. Nächste Schritte

Mit dem Verständnis der Kernel-Primitive (ip netns, veth und Bridges) folgt nun die Brücke zur modernen Container- und Cloud-Orchestrierung:

  • Container-Netzwerke & CNI-Architektur

    Docker-Bridges, Rootless Podman (pasta/slirp4netns), die CNI-Spezifikation und Kubernetes-Overlay-Netzwerke (Flannel vs. Cilium eBPF).

    Zum Container & CNI Leitfaden