89 Network Debugging

Netzwerkprobleme sind die häufigsten und zugleich frustrierendsten Störungen in Container-Umgebungen. Sie äußern sich vage – „Service nicht erreichbar“, „Latenz ungewöhnlich hoch“, „Container kommunizieren nicht“ – und liegen oft an Schichten, die außerhalb der Anwendung existieren: Bridging, Routing, IPAM, DNS, Firewalling, NAT. Podman bietet durch seinen daemonlosen Charakter ein Netzwerkmodell, das unmittelbar auf Linux-Namespaces und CNI-Plugins basiert. Das macht das Debugging einerseits transparent, andererseits anspruchsvoll, da man direkt mit Kernelmechanismen arbeitet. Dieses Kapitel führt strukturiert durch die Diagnose von Netzwerkfehlern in Podman.

89.1 Fundament: Netzwerknamespaces und CNI-Plugins

Jeder Container erhält einen eigenen Netzwerk-Namespace. Dort existieren eigene Interfaces, Routingtabellen und ein eigener DNS-Stack. Podman verwendet CNI (Container Network Interface) als Plugin-System, typischerweise:

Das Netzwerkmodell lässt sich so darstellen:

Wer das Modell versteht, weiß: Fehler können an jeder Stelle auftreten.

89.2 Einstieg: Netzwerkstatus ermitteln

Der erste Schritt jeder Diagnose:

podman network ls
podman network inspect <network>

Inspect zeigt:

Ist ein Container nicht im erwarteten Netzwerk, entstehen sofort Reichweiten- oder Routingprobleme.

89.2.1 Container-spezifische Informationen

podman inspect <container> | jq '.NetworkSettings'

Hier stehen:

Fehler beginnen oft mit simplen Dingen wie „keine IP vergeben“ oder „Port nicht gemappt“.

89.3 Netns-Diagnose: in den Netzwerk-Namespace eintreten

Netzwerkprobleme lassen sich oft nur innerhalb des Namespace sichtbar machen.

89.3.1 Netzwerk-Namespace betreten

nsenter --net=/proc/$(podman inspect -f '{{.State.Pid}}' <container>)/ns/net

Innerhalb des Namespace:

Damit erhält man das präziseste Bild der tatsächlichen Netzwerkkonfiguration.

89.4 Typische Probleme und Diagnosemethoden

89.4.1 1. Der Container ist unerreichbar

Meistens liegt es an:

Diagnose:

podman network inspect <network>
sudo iptables -L -n
sudo nft list ruleset

Pods und Container laufen zwar im eigenen Namespace, hängen aber letztlich an Linux-Firewallregeln.

89.4.2 2. Container kann DNS nicht auflösen

Teilweise tritt das auf nach:

Diagnose:

podman exec <ctr> cat /etc/resolv.conf
podman exec <ctr> dig google.com

Rootless-Podman verwendet nicht die Host-Resolver, sondern die slirp-Netzwerklösung, was oft überrascht.

89.4.3 3. Portmapping funktioniert nicht

Ein häufiger Klassiker: „Port 8080 ist gemappt, aber draußen nicht erreichbar.“

Mögliche Ursachen:

Diagnose:

ss -tulpen | grep 8080
podman port <ctr>
podman inspect <ctr> | jq '.NetworkSettings.Ports'

Wichtig: Container müssen auf 0.0.0.0 lauschen, nicht lokalen Loopback.

89.4.4 4. Container kommuniziert nicht mit anderen Containern

Häufig:

Diagnose:

podman network inspect
podman exec <ctr> ping <andere-ip>

Teilweise ist die Lösung schlicht: beide Container ins gleiche Netzwerk setzen.

89.4.5 5. NAT oder Hairpin-NAT funktioniert nicht

Hairpin NAT (Container ruft seine eigene externe IP auf) ist nicht immer aktiv.

Prüfen:

sysctl net.bridge.bridge-nf-call-iptables

und:

ip a | grep br-
bridge link

CNI-Plugins können NAT-Verhalten beeinflussen.

89.4.6 6. Rootless Networking

Rootless Podman nutzt nicht CNI, sondern:

In diesem Modus gelten andere Regeln:

Rootless Diagnose:

podman info | grep -i network

89.5 Bridging- und Routing-Probleme im Host untersuchen

Podman erstellt Bridges in /etc/cni/net.d/.

Beispiele:

/etc/cni/net.d/podman-default.conflist

Inspect:

cat /etc/cni/net.d/*.conflist

Keypunkte:

Routing-Tabellen des Hosts:

ip route
ip rule show

Überlappende Netzbereiche (Host-VPNs, Docker-Bridge, Podman-Bridge, k3s-/k8s-Podnetzwerke) führen oft zu Konflikten.

89.6 Firewall- und Packet-Filtering-Probleme

Podman unterliegt immer der Host-Firewall:

Prüfen:

sudo iptables -t nat -L -n --line-numbers
sudo nft list ruleset

Blockierende Regeln sind eine extrem häufige Ursache für Connectivity-Probleme.

89.7 Analyse von Paketflüssen mit tcpdump

Für tiefe Netzwerkdiagnose führt kein Weg an tcpdump vorbei.

Hostseitig:

sudo tcpdump -i br0

im Container:

nsenter --net=/proc/<pid>/ns/net tcpdump -i eth0

So erkennt man:

TCPdump zeigt reale Paketflüsse, unabhängig von Logs oder Firewall-Interpretationen.

89.8 Diagnose von Podman-Pods

Podman-Pods teilen sich einen Netzwerk-Namespace.

Fehlerquellen:

Diagnose:

podman pod inspect <name>
podman pod logs <name>

oder netzwerkbezogen:

podman exec <ctr> ss -tulpen

89.9 Netzwerkprobleme in Kombination mit Storage, CPU oder OOM

Manchmal wirkt ein Netzwerkfehler wie ein Netzproblem, ist aber keiner:

Stats hilft Querverifikation:

podman stats

Wenn CPU oder RAM limitieren, zeigt sich das häufig zuerst in Netzwerksymptomen.

89.10 Best Practices für robustes Network Debugging

Network Debugging in Podman ist die Kunst, Kernelmechanismen, Namespaces, CNI-Plugins und Containerprozesse zusammenzudenken. Es ist kein mystisches Feld, sondern eine strukturierbare Diagnosepraxis – vorausgesetzt, man weiß, an welchen Schichten und mit welchen Werkzeugen man ansetzt.