Cloud Networking Debugging: Security Groups, Routes, NACLs, MTU

Cloud Networking Debugging ist in der Praxis oft der Unterschied zwischen „läuft“ und „fällt zufällig aus“. In klassischen On-Prem-Netzen suchen Teams bei Verbindungsproblemen zuerst an Switchports, VLANs oder Firewalls. In der Cloud sehen Sie dagegen häufig ein gesundes Betriebssystem, eine korrekte IP-Konfiguration und trotzdem scheitern Verbindungen – weil die eigentlichen Steuerpunkte in mehreren, logisch getrennten Ebenen liegen: Security Groups (stateful), Network ACLs (stateless), Routing-Tabellen pro Subnet, zentrale Gateways (Internet, NAT, Transit) und nicht zuletzt MTU/PMTUD-Themen durch Overhead, Tunneling oder Provider-Backbones. Das macht Fehlerbilder tückisch: SSH geht nicht, obwohl Port 22 „offen“ ist; HTTPS klappt sporadisch; ein Service ist nur aus einer Zone erreichbar; oder „Ping geht, aber Downloads brechen ab“. Professionelles Cloud Networking Debugging bedeutet daher, nicht im Kreis zu testen, sondern eine Beweiskette aufzubauen: Identität des Workloads, Pfad (Route), Filter (SG/NACL), Zustand (stateful Rückweg) und Paketgröße (MTU). Dieser Artikel zeigt eine methodische Vorgehensweise, die in AWS, Azure und GCP gleichermaßen funktioniert – mit Fokus auf Security Groups, Routes, NACLs und MTU – und die so aufgebaut ist, dass Sie sie als Runbook im On-Call nutzen können.

Mentales Modell: Vier Fehlerdomänen, die Sie strikt trennen sollten

Die meisten Cloud-Netzwerkprobleme lassen sich schneller lösen, wenn Sie das System in vier Domänen zerlegen und jede Domäne separat beweisen. Das verhindert, dass Sie Security Rules anpassen, obwohl eigentlich die Route fehlt – oder dass Sie Routing debuggen, obwohl ein stateless NACL den Rückverkehr verwirft.

• Identität & Kontext: Welche NIC/ENI/Interface, welche Subnet/Zone, welche IP (private/public), welche Tags/Labels, welche Instanzrolle?
• Routing & Pfad: Welche Route Table greift, wohin zeigt der Default Route, gibt es Transit/NAT/Peering, ist der Rückweg symmetrisch?
• Filtering: Security Groups (stateful) und Network ACLs (stateless) – plus Host-Firewall, Load Balancer Security Policies, WAF, etc.
• MTU & Transportrealität: Fragmentation/PMTUD, MSS-Clamping, Overhead durch VPN/Tunnel, Paketverluste unter Last.

Evidence Pack: Ohne klare Daten wird Debugging in der Cloud teuer

Cloud-Netzwerkprobleme eskalieren häufig, weil Teams nur „Service X ist down“ hören. Sammeln Sie stattdessen ein kleines Evidence Pack, das den betroffenen Flow eindeutig beschreibt. Damit können Sie zielgerichtet prüfen, ob SGs, NACLs, Routes oder MTU die Ursache sind.

• Flow-Definition: Source-IP, Destination-IP, Protokoll (TCP/UDP/ICMP), Zielport, Zeitpunkt, Häufigkeit (immer/sporadisch).
• Workload-Kontext: Instanz/Pod/VM-ID, Subnet, VPC/VNet, Security Group(s), NACL(s), Route Table(s), Zone/Region.
• Pfadkomponenten: NAT Gateway/Instance, Internet Gateway, Transit Gateway, Peering, VPN/Direct Connect/ExpressRoute, Load Balancer.
• Symptomtyp: Timeout vs. RST vs. ICMP unreachable vs. TLS-Handshake-Error.
• Paketgröße: „klein geht, groß nicht“ oder nur bestimmte Anwendungen betroffen (Hinweis auf MTU).

Schritt-für-Schritt-Methodik: In der richtigen Reihenfolge zur wahrscheinlichsten Ursache

Eine feste Reihenfolge spart im Incident Zeit. Die folgenden Schritte sind bewusst so gewählt, dass Sie früh die häufigsten „harten“ Blocker erkennen.

• Schritt 1: Identität prüfen: Ist die Quelle wirklich die erwartete NIC/Subnet/SG? Stimmen private IP und Ziel-IP?
• Schritt 2: Routing vor Filtering: Gibt es überhaupt eine Route zum Ziel? Und gibt es einen plausiblen Rückweg?
• Schritt 3: Security Groups prüfen: Erlaubt der stateful Filter den Flow (inkl. Rückrichtung)?
• Schritt 4: NACLs prüfen: Erlaubt der stateless Filter beide Richtungen (inkl. Ephemeral Ports)?
• Schritt 5: MTU/PMTUD prüfen: Wenn „teilweise“ oder „nur große Pakete“ betroffen sind, ist MTU ein Top-Kandidat.

Security Groups: Warum „Port offen“ trotzdem nicht reicht

Security Groups (oder vergleichbare stateful Filter) wirken simpel: Ingress-Regeln für eingehenden Traffic, Egress-Regeln für ausgehenden Traffic. In der Praxis führen drei Punkte zu den meisten Fehlern: falsche Bindung, falscher Scope und falsche Erwartung an den Rückweg.

Falsche Bindung: Die falsche NIC hat die falsche Security Group

In der Cloud ist ein Workload oft an mehrere Interfaces angebunden (z. B. mehrere ENIs, Sidecars, separate Management-Interfaces). Häufig wird die richtige SG an die falsche NIC gebunden oder eine Instanz wird in ein anderes Subnet verschoben und erbt andere Regeln. Ergebnis: Konfiguration sieht „ähnlich“ aus, ist aber nicht identisch.

• Indiz: Nur ein Teil der Instanzen einer Auto-Scaling-Gruppe ist erreichbar.
• Nachweis: Vergleich der effektiven SGs pro NIC und des tatsächlichen Source/Destination Flow.
• Fix-Richtung: SG-Bindung standardisieren (IaC), Drift-Checks, Tags/Policies nutzen.

Scope-Fehler: CIDR passt, aber nicht zu NAT oder Load Balancer

Viele Regeln erlauben z. B. „nur aus dem Corporate CIDR“. Wenn der Traffic aber über NAT, VPN, Load Balancer oder Proxy kommt, sieht das Ziel nicht mehr die ursprüngliche Client-IP. Dann matcht die Regel nicht.

• Indiz: Zugriff geht aus dem Büro über VPN, aber nicht aus Mobile oder umgekehrt.
• Nachweis: Backend-Logs/Flow-Logs zeigen eine andere Source-IP als erwartet.
• Fix-Richtung: Trust-Boundary und Source-IP-Sicht klären; ggf. über Security Group Referenzen statt CIDRs arbeiten.

Rückweg-Mythos: Stateful heißt nicht „jede Asymmetrie ist egal“

Stateful Filtering hilft, weil Rückverkehr zu einer erlaubten Session automatisch zugelassen wird. Das setzt aber voraus, dass Rückverkehr über dieselbe Security-Domäne läuft und dass Routing nicht komplett am Filter vorbei führt. In hybriden Setups (mehrere Exits, Transit, Appliances) ist Asymmetrie weiterhin ein häufiger Killer.

• Indiz: SYN geht raus, aber SYN-ACK kommt nicht zurück oder wird an anderer Stelle gedroppt.
• Fix-Richtung: Rückweg symmetrisieren, zentrale Egress-Architektur, eindeutige Routes.

NACLs: Stateless Filter, der sehr oft Ephemeral Ports „vergisst“

Network ACLs (oder ähnliche Subnet-Filter) sind stateless: Sie müssen Ingress und Egress separat erlauben. Das führt zu einem typischen Fehler: Teams erlauben zwar den Zielport (z. B. 443), vergessen aber, dass die Rückrichtung oft auf Ephemeral Ports läuft. Dann sieht es aus wie „Security Group erlaubt, aber Verbindung hängt“.

Ephemeral Ports korrekt denken

Bei einem TCP-Flow von Client → Server nutzt der Client in der Regel einen Ephemeral Source Port (dynamisch) und der Server den bekannten Zielport (z. B. 443). Rückverkehr geht vom Server-Port 443 zum Client-Ephemeral-Port. In stateless Filtern müssen Sie also die Rückrichtung berücksichtigen.

• Indiz: Verbindungsaufbau hängt im Handshake oder „nur manchmal“ bei hoher Parallelität.
• Nachweis: Flow-Logs zeigen „ACCEPT“ in einer Richtung, „REJECT“ in der anderen.
• Fix-Richtung: NACL-Regeln für Ephemeral Port Ranges korrekt setzen, Regeln nach Priorität prüfen.

Regelreihenfolge: „Allow“ existiert, aber „Deny“ gewinnt

NACLs arbeiten oft mit numerischer Reihenfolge. Ein früheres Deny kann ein späteres Allow überschreiben. Das ist besonders bei „Default Deny“-Patterns und bei Copy-Paste zwischen Subnets relevant.

• Indiz: Ein Subnet funktioniert, ein anderes (scheinbar identisch) nicht.
• Nachweis: Side-by-side Vergleich der gesamten NACL-Regelliste inklusive Reihenfolge und Richtung.
• Fix-Richtung: NACL-Templates, weniger Regeln, klare Prioritäten, IaC-Review.

Routing: Die häufigste Ursache für „Timeout“ in Cloud-Netzen

Wenn ein Paket den Filter passiert, aber trotzdem nicht ankommt, ist Routing oft der nächste Verdächtige. In der Cloud ist Routing nicht nur „Default Route ins Internet“, sondern hängt an Subnet-Route-Tables, Transit-Topologien, Peering-Regeln, propagierten Routen und speziellen Gateways.

Route Tables: Welche Tabelle greift wirklich?

In vielen Clouds sind Route Tables pro Subnet gebunden. Ein Workload kann in einem Subnet laufen, das eine andere Route Table hat als das „benachbarte“ Subnet. Das ist besonders häufig nach Migrationen oder wenn neue Subnets per Template erstellt werden.

• Indiz: Nur Workloads in einem Subnet können ein Ziel erreichen, andere nicht.
• Nachweis: Effective Route Table pro Subnet prüfen (Default Route, spezifische Prefixes, Propagation).
• Fix-Richtung: Route-Table-Association standardisieren, drift vermeiden, Routen klar dokumentieren.

NAT Gateways und Egress: Wenn Outbound geht, aber Rückverkehr „anders“ ist

Private Subnets nutzen häufig NAT für Internetzugriffe. Hier sind zwei Fehlerklassen typisch: Der Workload hat keine Route zum NAT, oder der Workload geht zwar raus, aber Antworten/Return Path laufen über eine andere Instanz oder ein anderes Gateway, wodurch stateful Komponenten Probleme bekommen.

• Indiz: DNS geht, aber HTTPS nicht; oder einzelne Ziele funktionieren, andere nicht (abhängig von Pfad).
• Fix-Richtung: Default Route korrekt zum NAT, Egress konsolidieren, klare Rückweg-Architektur.

Peering und Overlaps: Warum „VPC Peering“ nicht einfach „Internet im LAN“ ist

Peering funktioniert nur, wenn CIDRs nicht überlappen und Routen auf beiden Seiten gesetzt sind. Überlappende CIDRs sind eine der häufigsten Ursachen für „geht nicht“, weil Traffic nicht eindeutig geroutet werden kann.

• Indiz: Einige Prefixes erreichbar, andere nicht; oder nur in eine Richtung.
• Fix-Richtung: Adressplan (IPAM) diszipliniert, Overlaps vermeiden, notfalls NAT/renumbering.

MTU: Der unterschätzte Grund für „klein geht, groß nicht“

MTU-Probleme sind in Cloud-Netzen besonders häufig, weil Overhead überall lauert: VXLAN/Geneve in der Provider-Fabric, IPsec-VPN, GRE/ENCAP, Service Mesh Tunnels oder schlicht unterschiedliche Link-MTUs zwischen Komponenten. Ein klassisches Muster: Ping geht, TLS-Handshake hängt, große Uploads brechen ab. Das ist oft kein Security-Problem, sondern ein PMTUD-Problem (Path MTU Discovery) oder Fragmentation, die im Pfad gedroppt wird.

PMTUD Blackholes: Wenn ICMP blockiert und niemand die Paketgröße anpasst

PMTUD funktioniert, indem Geräte bei zu großen Paketen ICMP „Fragmentation Needed“ (IPv4) oder „Packet Too Big“ (IPv6) senden. Wenn diese ICMP-Nachrichten gefiltert werden, weiß der Sender nicht, dass er kleinere Pakete schicken soll. Ergebnis: Retransmissions, Timeouts, „mysteriöse“ TLS-Probleme.

• Indiz: Kleine Requests ok, große brechen; besonders über VPN oder zwischen Regionen.
• Nachweis: Capture/Logs zeigen Retransmissions ohne Fortschritt; gezielte MTU-Tests zeigen harte Grenze.
• Fix-Richtung: ICMP für PMTUD gezielt erlauben, MTU konsistent setzen, MSS-Clamping für TCP nutzen.

Für PMTUD-Hintergrund sind RFC 1191 (IPv4) und RFC 8201 (IPv6) hilfreiche Referenzen.

MSS-Clamping: Pragmatiker-Lösung für TCP

Wenn Sie MTU im Underlay nicht schnell ändern können, ist MSS-Clamping oft der schnellste Fix: Der TCP MSS-Wert wird so reduziert, dass TCP-Segmente gar nicht erst zu groß werden. Das löst keine UDP-Probleme, hilft aber vielen HTTP/TLS-Workloads kurzfristig.

• Vorteil: schnelle Stabilisierung für TCP-basierte Apps.
• Risiko: Nicht als „Dauerpflaster“ ohne Dokumentation; UDP/QUIC bleibt separat zu behandeln.

Typische Debugging-Fallen in der Cloud

Einige Fehler passieren so oft, dass sie in jedes Runbook gehören.

• „Security Group erlaubt 443, also muss es gehen“: NACL oder Route fehlt, oder SNI/TLS/MTU ist das Problem.
• „Ping geht, also ist alles ok“: ICMP ist nicht TCP; MTU und PMTUD bleiben unsichtbar.
• „Von meiner Bastion geht’s“: Bastion sitzt oft in einem anderen Subnet/SG/NACL und hat andere Routen.
• „Nur diese Region kaputt“: Geo-Routing, unterschiedliche Route Propagation oder regionale NACL/SG-Templates.

Observability: Welche Telemetrie Cloud-Netzwerkprobleme wirklich aufklärt

Cloud-Netze sind ohne Telemetrie schwer zu debuggen, weil Sie kein „Kabel“ anfassen können. Die folgenden Datenquellen sind besonders hilfreich:

• Flow Logs: Zeigen ACCEPT/REJECT und 5-Tuple. Sie sind oft der schnellste Nachweis, ob Security Group/NACL blockt oder ob Traffic gar nicht erst läuft.
• Load Balancer Logs: Trennen Client↔LB und LB↔Backend, zeigen Timeouts, Target selection, Health Status.
• VPC/VNet Route Diagnostics: Effective routes und Next-Hop-Auswahl (wo verfügbar).
• Packet Captures am Host: Besonders bei MTU/PMTUD, TLS-Edge-Cases und „nur eine Richtung“ extrem hilfreich.

Für Paket- und Protokollanalyse sind die Wireshark Dokumentation und die tcpdump Manpage gute Einstiege, um Retransmissions, ICMP-PTB und Handshake-Fehler sichtbar zu machen.

Runbook-Baustein: Cloud Networking Debugging in 15 Minuten

• Minute 0–3: Flow und Kontext erfassen: Source/Dest/Port/Proto, Subnet, SGs, NACLs, Route Table, Zone/Region. Timeout vs. RST unterscheiden.
• Minute 3–6: Routing prüfen: gibt es eine Route zum Ziel und einen plausiblen Rückweg? NAT/Transit/Peering korrekt?
• Minute 6–9: Security Groups prüfen: Ingress/Egress passend? Richtige SG an richtiger NIC? Scope/CIDRs passen zur realen Source-IP?
• Minute 9–12: NACLs prüfen: beide Richtungen erlaubt? Ephemeral Ports berücksichtigt? Regelreihenfolge korrekt?
• Minute 12–15: MTU prüfen: „klein geht, groß nicht“? PMTUD/ICMP möglich? MSS-Clamping als kurzfristige Stabilisierung? Danach mit demselben Flow verifizieren.

Nachhaltige Stabilisierung: Baselines, die Cloud-Netzwerkprobleme seltener machen

• IaC und Drift-Checks: SG/NACL/Route Tables als Code, peer-reviewed, mit automatisierten Konsistenzprüfungen.
• Klare Subnet-Patterns: Public/Private/Transit Subnets mit eindeutigen Route Tables und dokumentierten Gateways.
• Minimale NACL-Komplexität: NACLs schlank halten, SGs als primären Filter nutzen, Ephemeral-Port-Policy standardisieren.
• MTU-Policy: Overhead einkalkulieren (VPN/Encap), MSS-Clamping dokumentieren, ICMP für PMTUD gezielt erlauben.
• Observability standardisieren: Flow Logs, LB Logs, Alarmierung auf REJECT-Spikes, Dropped-Flow-Top-N, Latenz/Jitter-KPIs.
• Change-Disziplin: Änderungen an Routes und Security Rules immer mit Canary-Tests und Rückwegprüfung (Symmetrie) ausrollen.

Weiterführende Quellen

• AWS Security Groups für stateful Filtering in VPCs
• AWS Network ACLs für stateless Subnet-Filter und Regelreihenfolge
• Azure Network Security Groups als Referenz für Security-Policy-Modelle in VNets
• Google Cloud VPC Firewall Rules als Referenz für Cloud-Firewalling und Rule-Scoping
• RFC 1191 und RFC 8201 für PMTUD (MTU-Fehlerbilder und Blackholes)
• Wireshark Dokumentation und tcpdump Manpage für Capture-basierte Beweise bei SG/NACL/MTU-Problemen

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.