# Network Namespaces: Die Basis moderner Container-Netzwerke

TL;DR / Management Summary Ein Network Namespace (netns) ist eine isolierte Kopie des Netzwerk-Stacks im Linux-Kernel. Jeder Namespace hat seine eigenen Interfaces, IP-Adressen, Routing-Tabellen und Firewall-Regeln. Dies ist die Kerntechnologie hinter Docker, Kubernetes und LXC. Um diese isolierten “Blasen” mit der Außenwelt oder untereinander zu verbinden, nutzen wir veth-Pairs (virtuelle Ethernet-Kabel) und Bridges. Ein Senior Admin muss netns beherrschen, um Container-Netzwerke zu debuggen, die “magisch” erscheinen.

# 1. Einführung & Architektur

Isolation auf Kernel-Ebene.

Standardmäßig haben alle Prozesse Zugriff auf den globalen Netzwerk-Stack des Kernels (root namespace). Ein Network Namespace ändert das fundamental.

# Was wird isoliert?

# Architektur-Diagramm (Mermaid)

graph LR
    subgraph "Root Namespace"
    NIC[eth0]
    BR[br0 / Bridge]
    end

    subgraph "Namespace A (Container 1)"
    VETH_A[veth_a]
    end

    subgraph "Namespace B (Container 2)"
    VETH_B[veth_b]
    end

    VETH_A <-->|Veth Pair| BR
    VETH_B <-->|Veth Pair| BR
    BR <--> NIC

# 2. Praxis: Namespaces manuell bauen

Verstehen durch Handarbeit.

Anstatt Docker alles machen zu lassen, bauen wir einen isolierten Stack manuell auf.

# Schritt 1: Namespace anlegen

ip netns add blue
# Prüfen
ip netns list

# Schritt 2: Interfaces verbinden (veth-pair)

Ein veth-pair verhält sich wie ein Patchkabel. Was auf einer Seite reingeht, kommt auf der anderen raus.

# Pair erstellen
ip link add veth-root type veth peer name veth-blue

# Ein Ende in den Namespace verschieben
ip link set veth-blue netns blue

# Schritt 3: IPs konfigurieren

# Im Root Namespace
ip addr add 192.168.100.1/24 dev veth-root
ip link set veth-root up

# Im Blue Namespace
ip netns exec blue ip addr add 192.168.100.2/24 dev veth-blue
ip netns exec blue ip link set veth-blue up
ip netns exec blue ip link set lo up

# 3. Deep Dive: Routing & NAT

Die Grenze überqueren.

Damit unser blue Namespace das Internet erreicht, brauchen wir Routing im Root Namespace.

# IP Forwarding & Masquerading

# Routing aktivieren
sysctl -w net.ipv4.ip_forward=1

# Default Gateway im Namespace setzen
ip netns exec blue ip route add default via 192.168.100.1

# NAT (Masquerading) auf dem Host (Root Namespace)
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o eth0 -j MASQUERADE

# 4. Day-2 Operations: Troubleshooting Tools

In die Box schauen.

Das größte Problem für Admins: “Ich bin auf dem Host, sehe aber die Pakete des Containers nicht.”

# Befehle im Kontext ausführen

Mit ip netns exec können Sie jedes Tool so starten, als säße es im Namespace:

# Interface-Statistik im Namespace
ip netns exec blue ip -s link

# Routing Tabelle prüfen
ip netns exec blue route -n

# Connectivity Test aus der 'Sicht' des Namespaces
ip netns exec blue ping 8.8.8.8

# tcpdump & Namespaces

# Capture im Namespace starten
ip netns exec blue tcpdump -i veth-blue -n

# 5. Troubleshooting & “War Stories”

Wenn der Tunnel reißt.

# Top 3 Fehlerbilder

  1. Symptom: lo Interface ist DOWN.

    • Folge: Viele Applikationen (z.B. Java, Go Runtimes) werfen Fehler beim Starten oder beim Resolve von localhost.
    • Lösung: Immer ip link set lo up im neuen Namespace ausführen.

  2. Symptom: Ping geht, aber TCP (HTTP/SSH) hängen.

    • Ursache: MTU Mismatch. Veth-Pairs haben oft eine andere MTU als die physische NIC.
    • Lösung: MTU auf allen Interfaces im Pfad konsistent setzen.

  3. Symptom: Namespace verschwindet nach Reboot.

    • Ursache: /var/run/netns wird oft als tmpfs gemountet.
    • Lösung: Persistence-Scripts oder Systemd-Units für die Anlage nutzen.

# “War Story”: Der verwaiste Namespace

Wir hatten ein Phänomen, bei dem ein Server massiv RAM verbrauchte, obwohl keine Container liefen. Die Ursache: Ein fehlerhaftes Deployment-Skript löschte Container, aber nicht deren Network Namespaces. Tausende von ungenutzten virtuellen Interfaces und Routing-Einträgen fragmentierten den Kernel-Speicher. Ein simpler Loop über ip netns delete gab GB-weise RAM frei.

# 6. Monitoring & Alerting

Die Geister im Kernel zählen.

# Wichtige KPIs

# Monitoring via Prometheus Node Exporter

Der Node Exporter sammelt standardmäßig keine Daten aus isolierten Namespaces. Sie müssen Tools wie cAdvisor einsetzen, um tiefe Einblicke in die Container-Netzwerke zu erhalten.

# 7. Fazit & Empfehlung

Network Namespaces sind ein mächtiges Skalpell.

# Anhang: Cheatsheet

Aufgabe Befehl
Namespace erstellen ip netns add <name>
In Namespace springen ip netns exec <name> bash
Veth Pair erstellen ip link add veth0 type veth peer name veth1
Interface verschieben ip link set veth1 netns <name>
PIDs in Namespace finden ip netns pids <name>
Namespace löschen ip netns del <name>

# Referenzen