Route-Table-Debugging: Warum Pod/Service nicht aus der VPC kommt

Route-Table-Debugging ist eine der effektivsten Methoden, wenn ein Pod oder Service „einfach nicht aus der VPC kommt“ – also keine externen Ziele erreicht, keine Partnernetze ansprechen kann oder beim Zugriff auf öffentliche APIs ständig Timeouts liefert. In Cloud- und Kubernetes-Umgebungen wirkt das Problem häufig wie ein Security-Thema („Firewall blockt“), ein DNS-Thema („Name wird nicht aufgelöst“) oder ein Applikationsthema („Client hängt“). In der Praxis ist die Ursache jedoch oft viel bodenständiger: Die Route Table zeigt für das relevante Zielpräfix auf den falschen Next Hop, die falsche Route Table ist am Subnet gebunden, der Egress läuft unerwartet über ein Gateway ohne Rückpfad, oder ein NAT-/Inspection-Pfad ist nicht konsistent. Besonders tückisch ist, dass Pods und Services nicht dasselbe sind: Ein Service ist ein virtuelles Konstrukt, während der tatsächliche Datenpfad immer über Nodes, Interfaces und reale Routen läuft. Wer beim Debugging zuerst den Pfad modelliert und dann systematisch die Route-Entscheidung validiert, verkürzt die Fehlersuche drastisch und vermeidet teure Workarounds wie „temporär alles öffnen“. Dieser Artikel vermittelt eine praxistaugliche Vorgehensweise, um Routing-Fehler schnell zu isolieren, typische Cloud-Fallen zu erkennen und bei Pod- und Service-Egress gezielt die richtigen Route-Tabellen zu prüfen.

Mentales Modell: Was eine Route Table tatsächlich entscheidet

Eine Route Table ist im Kern eine Menge aus Zielpräfixen (CIDR) und Next Hops (z. B. Internet Gateway, NAT Gateway, Transit/Hub, VPN, virtuelle Appliance). Für jedes ausgehende Paket wird anhand der Ziel-IP die „beste“ Route ausgewählt. In IP-Netzen gilt dabei das Prinzip der längsten Präfixübereinstimmung (Longest Prefix Match): Je spezifischer die Route, desto höher die Priorität. Dieses Prinzip erklärt viele „Überraschungen“, wenn eine neue, spezifische Route eine allgemeine Default Route verdrängt.

Longest Prefix Match als Entscheidungsregel

$\mathrm{route}=\mathrm{argmax}\left(\mathrm{prefixLength}\right)$

Praktisch bedeutet das: Wenn sowohl 0.0.0.0/0 als auch 203.0.113.0/24 existieren, gewinnt /24 für Ziele in 203.0.113.0/24. Das ist korrekt, wird aber im Incident schnell übersehen.

Pod vs. Service: Warum „Service kommt nicht raus“ oft falsch formuliert ist

Ein Kubernetes Service ist kein eigenständiger Netzwerkendpunkt, der „aus der VPC heraus routet“. Er ist eine Abstraktion, die Traffic zu Pods lenkt (z. B. via kube-proxy, iptables oder eBPF). Wenn von „Service-Egress“ gesprochen wird, ist meist einer dieser Fälle gemeint:

• Pod-Egress: Ein Pod versucht, ein Ziel außerhalb der VPC zu erreichen (Internet, Partnernetz, On-Prem).
• Node-Egress: Ein Node oder DaemonSet (z. B. Logging-Agent) macht ausgehende Verbindungen.
• Ingress->Egress-Kette: Ein Request kommt über einen Load Balancer rein und triggert einen ausgehenden Call (z. B. zu einem externen API-Provider).

Für das Verständnis der Kubernetes-Networking-Basics sind die offiziellen Konzepte hilfreich: Kubernetes Services & Networking. Für die CNI-Grundlagen ist die CNI-Spezifikation ein guter Referenzpunkt.

Die häufigsten Ursachen: Warum Pods nicht aus der VPC kommen

In der Praxis wiederholen sich bestimmte Muster. Gute Route-Table-Debugger erkennen sie schnell, weil sie den Pfad immer in „Quelle → Subnet → Route Table → Next Hop → Rückpfad“ zerlegen.

• Falsche Route Table am Subnet: Subnet ist an eine Tabelle gebunden, die keinen Egress-Pfad (z. B. 0.0.0.0/0) oder den falschen Next Hop hat.
• Default Route fehlt oder zeigt ins Leere: Kein Internet-/NAT-/Transit-Attachment vorhanden oder falsch referenziert.
• NAT/IGW falsch platziert: NAT ohne funktionierenden Weg zum Internet Gateway oder ohne öffentliche Erreichbarkeit (je nach Provider-Konzept).
• Rückpfad fehlt: Hinweg klappt, Rückweg ist nicht routbar oder wird über einen anderen Pfad geführt (Asymmetrie).
• Überlappende CIDRs: Zielnetz überlappt mit lokalem Adressraum; Route-Auswahl wird unlogisch oder blockiert Peering.
• Traffic läuft über Inspection/Appliance: Next Hop ist eine Firewall/Appliance, aber deren eigene Routen oder Policies sind nicht vollständig.
• Kubernetes-spezifische SNAT-/Masquerade-Effekte: Das Ziel sieht eine andere Source-IP als erwartet, was Rückwege oder Allowlists bricht.

Route-Table-Debugging als Prozess: Ein reproduzierbares Runbook

Ein gutes Debugging-Runbook beginnt nicht mit Tools, sondern mit einer klaren Frage: „Von welchem konkreten Source-Endpoint zu welchem konkreten Ziel-Endpoint scheitert es?“ Danach folgt ein schrittweises Ausschlussverfahren, das Routing- und Policy-Themen sauber trennt.

Schritt 1: Pfad skizzieren (ohne Annahmen)

• Quelle: Pod-IP oder Node-IP? Namespace/Nodepool/AZ notieren.
• Ziel: exakte Ziel-IP (nicht nur Hostname), Port und Protokoll.
• Zwischenstationen: NAT, Egress-Gateway, Transit/Hub, VPN, Firewall/Proxy, Private Endpoint.

Schritt 2: DNS vom Routing trennen

DNS kann die Fehlersuche verfälschen. Lösen Sie den Hostnamen im Pod auf und testen Sie dann die Ziel-IP direkt. Wenn DNS langsam oder fehlerhaft ist, wirkt es wie ein Routingproblem. Für DNS-Grundlagen eignet sich die Spezifikation unter RFC 1035.

Schritt 3: Node-Layer testen (ist es ein Pod-spezifisches Problem?)

• Test vom Node: Wenn der Node die Ziel-IP erreicht, aber der Pod nicht, ist das oft CNI/Policy/SNAT.
• Test vom Pod: Wenn sowohl Pod als auch Node scheitern, ist Route Table / Gateway / Underlay wahrscheinlicher.

Schritt 4: Route Table identifizieren, die wirklich greift

Der häufigste Denkfehler ist, „die“ Route Table zu prüfen – statt die Route Table, die dem Subnet der Quelle tatsächlich zugeordnet ist. In vielen Clouds existiert eine Main Route Table plus abweichende Tabellen pro Subnet. Prüfen Sie gezielt:

• Subnet-Assoziation: Welche Tabelle ist am Quell-Subnet gebunden?
• Longest Prefix Match: Gibt es eine spezifische Route, die die Default Route überschreibt?
• Next Hop Existenz: Ist das referenzierte Gateway/Attachment aktiv und korrekt verbunden?

Schritt 5: Rückpfad verifizieren (häufigster „unsichtbarer“ Fehler)

Wenn Hinweg-Routing stimmt, aber Antworten nicht zurückfinden, entstehen Timeouts statt klare Fehlermeldungen. Besonders bei NAT, Transit und Inspection ist Return Path Design entscheidend. Eine einfache Denkregel: Das Zielnetz muss eine Route zurück zur Source-IP (oder zur SNAT-IP) haben, die in der Realität genutzt wird.

Kubernetes-spezifische Stolpersteine: SNAT, Pod-CIDRs und Service-Routen

In Kubernetes sind die IP-Quellen nicht immer das, was man intuitiv erwartet. Je nach CNI werden Pod-IPs geroutet, genattet oder über Overlays transportiert. Damit entstehen drei typische Fehlerbilder, die wie Route-Table-Probleme aussehen, aber Kubernetes-spezifische Ursachen haben.

SNAT/Masquerade bricht Allowlists und Rückwege

Viele externe Systeme erlauben nur bestimmte Quell-IP-Ranges. Wenn Pods über NAT oder Masquerade mit einer anderen Quell-IP rausgehen, scheitern Verbindungen trotz korrekter Route Table. Gleichzeitig kann der Rückpfad im Partnernetz nur zur „erwarteten“ Source geroutet sein.

• Indiz: Ziel ist erreichbar, aber TLS/HTTP schlägt nach Connect fehl oder wird serverseitig abgelehnt.
• Route-Table-Bezug: Rückroute ist für Pod-CIDR vorhanden, aber tatsächlich geht Traffic mit Node-/NAT-IP raus.

Pod-CIDR ist nicht im VPC-Routing bekannt

Bei gerouteten CNIs müssen Pod-CIDRs im zugrunde liegenden Routing berücksichtigt werden. Wenn das Underlay/VPC-Routing nicht weiß, wie es Pod-IP-Präfixe erreicht, funktionieren interne Pfade vielleicht noch über Overlay, aber externe oder hybride Pfade brechen.

• Indiz: Pod->Internet scheitert, Node->Internet funktioniert.
• Route-Table-Bezug: Pod-CIDR fehlt in Transit/Hub-Routen oder wird von spezifischeren Routen überschrieben.

Service ist erreichbar, aber Egress aus dem Service-Backend nicht

Ein Service kann intern perfekt funktionieren, während seine Backends beim Outbound scheitern. Dann sieht es wie ein „Service-Egress“-Problem aus, ist aber in Wahrheit ein Pod-Egress- oder Node-Egress-Problem mit Route Table, NAT oder Return Path.

Cloud-typische Fehlerbilder: Route Table wirkt korrekt, aber Traffic geht trotzdem nicht raus

Es gibt Situationen, in denen die Route Table „auf dem Papier“ stimmt, aber der reale Datenpfad trotzdem blockiert ist. Für Route-Table-Debugging ist es wichtig, diese Fälle zu kennen, damit Sie nicht in einer Endlosschleife aus „Routes sehen gut aus“ stecken bleiben.

• Fehlende Gateway-Konnektivität: Internet-/NAT-/Transit-Gateway existiert, aber hängt nicht korrekt am Netz (Attachment/Association fehlt).
• Network ACLs / stateless Filter: Rückverkehr wird blockiert, obwohl Security Groups stateful erlauben (providerabhängig).
• Unerwartete Proxy-/Inspection-Pflicht: Organisation verlangt Egress über Firewall/Proxy; direkte Default Routes werden stillschweigend verworfen oder nicht genutzt.
• Asymmetrisches Routing durch Multi-AZ: Hinweg über AZ A, Rückweg über AZ B; stateful Komponenten verlieren Kontext.

Praktische Checks: Welche Fragen Sie an Route Tables stellen sollten

Statt „Route Table prüfen“ hilft ein fester Fragenkatalog. Damit lassen sich die meisten Fälle schnell strukturieren, unabhängig vom Cloud-Anbieter.

• Welche Route Table gilt wirklich? Subnet-Assoziation, Main Table, mögliche Ausnahmen.
• Welche Route gewinnt? Gibt es spezifische Präfixe, die die Default Route aushebeln?
• Ist der Next Hop erreichbar? Gateway/Attachment/Appliance ist aktiv, korrekt verbunden, in richtiger Zone platziert.
• Wie sieht die Rückroute aus? Zielnetz kennt Route zur Source (Pod-CIDR oder SNAT-Range).
• Gibt es Overlaps? CIDR-Konflikte zwischen VPC/VNet, Peers, On-Prem oder Partnernetzen.

Diagnose-Signale: Wie Sie Routing-Probleme von Policy-Problemen unterscheiden

Route-Table-Debugging wird deutlich schneller, wenn Sie die richtigen Signale beobachten. Routing-Probleme äußern sich oft als „stummes“ Scheitern (Timeout), während Policy-Probleme häufiger reproduzierbar und logisch scoped sind (nur Port X, nur Namespace Y). Transport-Indikatoren helfen dabei, weil sie unabhängig von Applikationslogs sind. Für TCP-Verhalten ist RFC 9293 eine belastbare Quelle.

• Timeout + Retransmissions: spricht eher für fehlenden Pfad, Drops oder Rückwegprobleme.
• Sofortiger Reject/RST: spricht eher für ein explizites Blockieren oder fehlenden Listener.
• Scope nach Topologie: nur bestimmte Subnetze/AZ/Nodepools → häufig Route Table oder Gateway.
• Scope nach Logik: nur Labels/Namespaces/Ports → häufig NetworkPolicy oder Security Rules.

Mitigation, die nicht in neue Schulden führt

Wenn der Incident Druck erzeugt, greifen Teams oft zu „schnellen“ Workarounds: zusätzliche NATs, Proxy-Kaskaden, temporäre Routen oder pauschales Öffnen. Das kann kurzfristig helfen, erzeugt aber langfristig Komplexität. Sinnvoller sind reversible Mitigations, die gleichzeitig Diagnose erleichtern.

• Isolierter Testpfad: ein dediziertes Subnet mit minimaler Route Table, um Hypothesen zu prüfen.
• Gezieltes Rescheduling: Pods in ein bekannt gutes Subnet/Nodepool verschieben, um Scope zu bestätigen.
• Routenänderungen versionieren: Infrastructure-as-Code und klare Rollback-Schritte, statt „Klick-Änderungen“.
• Return Path zuerst: bevor neue Egress-Pfade gebaut werden, Rückwege und erlaubte Source-Ranges klären.

Outbound-Referenzen für vertiefende Informationen

• RFC 4632: CIDR und Präfixkonzept (Longest Prefix Match Kontext)
• RFC 1918: Private IPv4-Adressräume und Overlap-Risiken
• RFC 9293: TCP – Retransmissions, Timeouts und Transport-Indikatoren
• RFC 1035: DNS – Name Resolution als separate Fehlerklasse
• Kubernetes: Services und Networking – Service vs. Pod richtig einordnen
• CNI-Spezifikation: Datenpfade und Verantwortlichkeiten im Cluster
• OpenTelemetry: Observability für Connect-Time, Retransmits und Pfad-Dimensionen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.