Route Tables in der Cloud troubleshooten (Step-by-Step + Checkliste)

Route Tables in der Cloud troubleshooten ist eine Kernkompetenz für Betrieb, SRE und Security, weil viele „mysteriöse“ Verbindungsprobleme am Ende auf Routing-Logik zurückgehen – nicht auf die Applikation. Wenn ein Service plötzlich nicht mehr erreichbar ist, Deployments hängen, ein Datenbankzugriff sporadisch fehlschlägt oder Egress unerwartet über das Internet statt über private Pfade läuft, ist die Route Table oft der entscheidende Hebel. Gleichzeitig ist Cloud-Routing tückisch: Es wirkt simpel („Destination → Target“), aber Details wie Longest Prefix Match, Subnetz-Assoziationen, Route Propagation, NAT-Engpässe, Peering-Einschränkungen und Rückwege („Return Path“) entscheiden darüber, ob Pakete überhaupt ankommen. Dazu kommt: Route Tables sind keine Firewall. Selbst perfektes Routing hilft nicht, wenn Security Groups, NSGs oder NACLs blocken – und umgekehrt kann eine offene Firewall keine fehlende Route ersetzen. Dieser Leitfaden erklärt Schritt für Schritt, wie Sie Route Tables in AWS, Azure und Google Cloud praxisnah debuggen, welche Checks Sie immer durchführen sollten und wie Sie typische Fehlkonfigurationen schnell identifizieren.

Grundlagen, die Sie beim Troubleshooting immer im Kopf behalten sollten

Bevor Sie in Logs und Dashboards springen, lohnt es sich, drei Prinzipien zu verinnerlichen. Diese drei Punkte erklären die meisten Routing-Probleme in Cloud-Umgebungen und helfen, Hypothesen schnell zu verwerfen.

• Longest Prefix Match: Wenn mehrere Routen passen, gewinnt die spezifischste Route (mit dem längsten Präfix).
• Rückweg zählt: Kommunikation scheitert oft nicht am Hinweg, sondern daran, dass Antworten nicht zurückfinden (asymmetrisches Routing).
• Routing ≠ Security: Route Tables steuern den Pfad, Security Controls entscheiden über Erlaubnis.

Eine solide Basis bieten die offiziellen Dokumentationen, z. B. AWS VPC Route Tables, Azure User Defined Routes und Google Cloud VPC Routes.

Symptom zuerst präzisieren: Was bedeutet „geht nicht“ konkret?

Effektives Route-Table-Troubleshooting beginnt mit einem sauberen Symptom. „Keine Verbindung“ ist zu unscharf. Formulieren Sie stattdessen, welche Phase scheitert: DNS, TCP-Connect, TLS-Handshake oder HTTP-Request. Das verhindert, dass Sie Routing debuggen, obwohl das Problem in Wahrheit DNS oder eine Layer-7-Policy ist.

• DNS-Fehler: Name löst nicht auf, NXDOMAIN/SERVFAIL → zuerst DNS prüfen, nicht Routing.
• TCP Timeout: SYN kommt nicht durch oder Antwort fehlt → Routing/Security/NACL wahrscheinlich.
• TCP RST: Ziel ist erreichbar, lehnt aber ab → oft Security Group/NSG oder Service nicht lauscht.
• HTTP 502/504: Edge/Ingress erreicht Upstream nicht rechtzeitig → Route/SG oder Upstream-Overload möglich.

Step-by-Step: Route Tables in der Cloud troubleshooten

Die folgenden Schritte sind bewusst cloud-agnostisch formuliert, lassen sich aber direkt auf AWS, Azure und GCP übertragen. Arbeiten Sie die Schritte in Reihenfolge ab, weil Sie damit die häufigsten Ursachen zuerst treffen und unnötige „Seitenspuren“ vermeiden.

Schritt 1: Quelle, Ziel und Scope eindeutig festhalten

Notieren Sie für den konkreten Verbindungsversuch:

• Quelle: Instanz/Pod/Service, Subnetz, AZ/Zone, IP-Adresse, Security Domain
• Ziel: IP/Hostname, Port, Protokoll (TCP/UDP/ICMP), privat oder öffentlich?
• Richtung: Inbound, East-West (intern), Outbound/Egress
• Betroffene Segmente: nur eine Zone? nur ein Subnetz? nur bestimmte Clients?

Warum das wichtig ist: Routing ist kontextabhängig. Eine Route Table gilt typischerweise pro Subnetz oder pro Netzwerkscope – wenn Sie das falsche Subnetz betrachten, debuggen Sie das falsche Problem.

Schritt 2: Subnetz-Assoziation prüfen (Route Table „wirkt“ wirklich?)

Der Klassiker: Die Route Table ist korrekt konfiguriert, aber nicht mit dem Subnetz assoziiert, in dem die betroffene Workload läuft. Prüfen Sie daher zuerst:

• AWS: Welche Route Table ist dem Subnet zugeordnet? Gibt es eine „Main“ Route Table, die unerwartet greift?
• Azure: Ist die Route Table (UDR) am Subnetz verknüpft? Greift zusätzlich System Routing?
• GCP: Routen gelten auf VPC-Ebene, aber Priorität und Tags/Service Accounts können Scope definieren.

Schritt 3: Effektive Route bestimmen (nicht nur „was konfiguriert ist“)

In der Praxis zählt die effektive Route: Welche Route wird für das konkrete Ziel tatsächlich verwendet? Dazu müssen Sie Longest Prefix Match berücksichtigen und bei Bedarf auch Propagation/Systemrouten einbeziehen.

• Starten Sie mit der Zieladresse (z. B. 10.20.30.40) und prüfen Sie, welche Destination-Präfixe passen.
• Wählen Sie die Route mit dem längsten Präfix (z. B. /24 schlägt /16).
• Kontrollieren Sie, ob eine Route „blackhole“/invalid ist oder auf ein nicht verfügbares Target zeigt.

Longest Prefix Match als schnelle Entscheidungsregel

$\mathrm{Route}{\mathrm{winner}}_{}=\text{max}\left(\mathrm{prefixLength}\right)$

Wenn Sie beim Troubleshooting feststellen, dass eine unerwartete /32- oder /24-Route existiert (z. B. für einen Service-Endpunkt oder eine Spezialstrecke), ist das häufig die Erklärung für „Warum geht der Traffic nicht wie gedacht?“

Schritt 4: Target prüfen (Next Hop ist erreichbar und korrekt?)

Eine Route kann syntaktisch korrekt sein, aber semantisch falsch: Der Next Hop existiert, ist aber nicht geeignet oder nicht erreichbar. Prüfen Sie je nach Target:

• Internet Gateway / Internet Route: Ist das Subnetz wirklich „public“? Gibt es öffentliche IPs oder einen Load Balancer, der Inbound terminieren soll?
• NAT: Ist NAT korrekt angebunden (z. B. in einem public Subnetz)? Gibt es Kapazitätsprobleme (Ports, Connections)?
• Peering: Sind Routen auf beiden Seiten gesetzt? Gibt es CIDR-Überlappung? Sind DNS-Optionen korrekt?
• VPN/Private Link: Ist die Route propagiert? Sind BGP/Propagation aktiv? Greifen passende Prefixes?
• Transit/Hub: Wird der Traffic im Hub weitergeroutet oder „verschluckt“?

Schritt 5: Rückweg verifizieren (Return Path und Asymmetrie)

Sehr viele Cloud-Routing-Issues sind Rückwegprobleme. Typische Auslöser sind: einseitig gesetzte Peering-Routen, falsche Default Routes, oder unterschiedliche Pfade pro Subnetz. Prüfen Sie daher immer auch vom Ziel zurück zur Quelle.

• Hat das Ziel eine Route zurück ins Quellnetz?
• Greift auf dem Rückweg eine andere, unerwartete Route (z. B. Default Route zu einem Hub)?
• Gibt es „Hairpinning“ über NAT oder einen Gateway-Pfad, der Security Policies triggert?

Praxisindikator: Wenn Sie SYN rausgehen sehen, aber keine SYN-ACK zurückkommt, ist Rückweg oder Security auf dem Rückweg sehr wahrscheinlich.

Schritt 6: Security Controls parallel prüfen (ohne Routing zu verwechseln)

Auch wenn der Fokus Route Tables ist: Es ist ineffizient, Security komplett auszublenden. Prüfen Sie minimal:

• Security Groups/NSGs: erlauben sie Port/Protokoll? Inbound und Outbound?
• NACLs: blockieren sie ephemeral Ports oder Rückverkehr (zustandsloses Verhalten beachten)?
• Firewall/Appliance: gibt es Regeln im Hub oder in einem zentralen Egress, die den Traffic blocken?

Der häufigste Fehler bei NACLs: Inbound ist erlaubt, aber Outbound (oder Rückports) fehlen. Dann wirkt es wie Routing, ist aber Policy.

Schritt 7: Flow Logs und „Denied“-Signale auswerten

Cloud Flow Logs sind ein hervorragendes Werkzeug, um Routing- und Security-Fragen zu objektivieren. Sie beantworten: Hat Traffic das Subnetzinterface erreicht? Wurde er akzeptiert oder verworfen? Kommt Rückverkehr an?

• AWS: VPC Flow Logs können „ACCEPT/REJECT“ zeigen und helfen bei SG/NACL-Fehlern.
• Azure: NSG Flow Logs zeigen, welche Regel matched und ob erlaubt/verworfen wurde.
• GCP: VPC Flow Logs liefern Metadaten zu Verbindungen, nützlich für Pfad- und Policychecks.

Hinweis: Flow Logs zeigen nicht immer „warum“ Routing falsch ist, aber sie zeigen, ob Traffic überhaupt an einem Punkt vorbeikommt. Damit schließen Sie Hypothesen schnell aus.

Schritt 8: Edge-Fälle prüfen: Überlappende CIDRs, Spezialrouten, Service Endpoints

Wenn die Basics stimmen, sind häufig „Design-Ecken“ schuld. Diese sind in Multi-VPC-/Multi-VNet-Umgebungen besonders häufig.

• CIDR-Überlappung: Peering/Transit wird unzuverlässig oder unmöglich, Routen werden nicht akzeptiert.
• Zu spezifische Routen: /32-/24-Routen lenken Traffic unerwartet über Appliances oder falsche Targets.
• Private Endpoints/Service Endpoints: führen zu speziellen Präfixen und DNS-Abhängigkeiten.
• Route Propagation: dynamische Routen ändern „über Nacht“ effektive Pfade, wenn Propagation aktiv ist.

Typische Troubleshooting-Szenarien (mit konkreten Checks)

Die folgenden Szenarien decken einen Großteil realer Incidents ab. Sie können sie als Mustererkennung verwenden: Symptom → wahrscheinlichster Routing-Fehler → schnelle Checks.

Szenario: Private Subnet erreicht Internet nicht

• Wahrscheinlich: Default Route fehlt oder zeigt nicht auf NAT; NAT ist nicht in public Subnet; IGW-Route im NAT-Subnet fehlt.
• Checks:
  • Private Subnet Route Table: 0.0.0.0/0 → NAT?
  • NAT-Subnet Route Table: 0.0.0.0/0 → Internet Gateway?
  • Security: Outbound erlaubt, NACLs erlauben Rückverkehr?

Szenario: Public Subnet „public“, aber Inbound kommt nicht an

• Wahrscheinlich: Kein Internet Gateway Route; keine öffentliche IP; Security Group blockt; Load Balancer falsch platziert.
• Checks:
  • Route Table: 0.0.0.0/0 → Internet Gateway vorhanden?
  • Workload: hat sie öffentliche IP oder ist ein LB davor?
  • SG/NSG: Inbound Port offen? Source korrekt?

Szenario: VPC/VNet Peering existiert, aber Services sind nicht erreichbar

• Wahrscheinlich: Route nur einseitig; CIDR-Überlappung; Security Policies erlauben nicht; DNS/Private Zones nicht konsistent.
• Checks:
  • Auf beiden Seiten: Route zum jeweils anderen CIDR via Peering gesetzt?
  • Keine Overlaps zwischen den Adressräumen?
  • SG/NSG: East-West erlaubt?
  • DNS: wird der richtige private Name aufgelöst?

Szenario: Verbindung geht manchmal, manchmal nicht (intermittierend)

• Wahrscheinlich: Nur eine AZ/Subnet betroffen; NAT erschöpft; Routing unterscheidet sich pro Subnet; asymmetrische Pfade über Hub.
• Checks:
  • Segmentierung nach AZ/Subnet: tritt es nur in einer Zone auf?
  • NAT-Metriken/Connections: sind Limits erreicht?
  • Effektive Routen pro Subnet vergleichen (nicht nur „globale Annahme“).

Checkliste: Route Tables in der Cloud systematisch prüfen

Diese Checkliste ist so aufgebaut, dass Sie sie direkt in ein Runbook kopieren können. Sie beginnt mit den häufigsten Ursachen und führt dann in die „schwierigen“ Fälle.

• Scope: Betroffenes Subnetz, AZ/Zone, Quelle/Ziel, Port/Protokoll dokumentiert?
• Subnetz-Assoziation: korrekte Route Table dem Subnetz zugeordnet (oder greift „Main“)?
• Effektive Route: Longest Prefix Match geprüft, gewinnt die erwartete Route?
• Default Route: 0.0.0.0/0 korrekt (IGW für public, NAT/Firewall für private)?
• Next Hop: Target existiert, ist „available“, korrekt angeschlossen (NAT im public Subnet etc.)?
• Rückweg: Route vom Ziel zurück zur Quelle vorhanden, keine asymmetrische Umleitung?
• Peering/Transit: Routen auf beiden Seiten, keine CIDR-Überlappung, Propagation korrekt?
• Security parallel: SG/NSG/NACL erlauben Inbound/Outbound und Rückports?
• Flow Logs: Traffic sichtbar? ACCEPT/REJECT? In welcher Richtung fehlt er?
• Spezialrouten: /32-/24-Ausnahmen, Service Endpoints/Private Endpoints, policy routing?
• Kapazität: NAT/Firewall/Appliance Sättigung, Conntrack/Ports, Limits erreicht?
• Änderungen: letzte Deployments/Netzwerkänderungen, IaC-Drift, Propagation-Events?

Praxis-Tipps: So vermeiden Sie häufige Fehler schon im Design

Troubleshooting wird deutlich leichter, wenn das Netzwerkdesign „debuggbar“ ist. Das bedeutet: klare Segmentierung, konsistente Namensgebung, deterministische Routing-Patterns und saubere Observability.

• Standardmuster: pro AZ gleiche Subnetztypen und gleiche Routing-Logik (weniger Überraschungen).
• Klare Default Routes: public nur dort, wo wirklich nötig; private über kontrollierten Egress.
• Keine Overlaps: IP-Planung zentral, damit Peering/Hub später nicht scheitert.
• Runbook-Links: Route Table, Subnet, SG/NSG, Flow Logs und NAT/Firewall-Dashboards verlinken.
• Change-Disziplin: Routing-Änderungen wie Code behandeln (IaC, Review, progressive Rollouts).

Outbound-Links für vertiefende Referenzen

• AWS: Route Tables in Amazon VPC
• AWS: Überblick Amazon VPC
• Azure: User Defined Routes (Route Tables)
• Azure: Virtual Network Überblick
• Google Cloud: VPC Routes
• RFC 1918: Private IPv4-Adressbereiche
• RFC 4632: CIDR (Classless Inter-Domain Routing)

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.