Site icon bintorosoft.com

Azure/AWS Netzwerkprobleme: Security Groups, NACLs und Routen debuggen

Red Snapper

Azure/AWS Netzwerkprobleme zeigen sich in der Praxis oft gleich: Eine VM/EC2 ist „up“, aber nicht erreichbar. Ein Service funktioniert intern, aber nicht von außen. Oder nur bestimmte Subnetze können miteinander sprechen. Die Ursache liegt jedoch selten „im Internet“, sondern fast immer in drei Bereichen, die sich gegenseitig beeinflussen: Security Groups/NSGs (stateful Regeln am Workload), NACLs bzw. subnetzbasierte Filter (stateless in AWS) und Routen (Route Tables/UDRs, Gateways, Peering, Transit). Genau diese Kombination macht Cloud-Netzwerke so mächtig – und beim Troubleshooting so fehleranfällig: Eine einzige fehlende Rückroute, ein zu enger Ephemeral-Port-Bereich, eine falsche Next-Hop-Auswahl oder eine deny-Regel mit höherer Priorität reicht aus, um „alles“ kaputt wirken zu lassen. Dieser Leitfaden liefert einen systematischen Debug-Ansatz, mit dem Sie in AWS und Azure schnell klären, ob das Problem an Security-Regeln, NACLs oder Routing liegt, und wie Sie es mit Bordmitteln (Flow Logs, Reachability Analyzer, Network Watcher) belegbar nachweisen.

Das mentale Modell: Datenpfad immer in beide Richtungen denken

Cloud-Troubleshooting scheitert häufig daran, dass nur der Hinweg betrachtet wird („Ich erlaube Port 443 inbound“), der Rückweg aber vergessen wird. Besonders bei stateless Filtern und bei Routenänderungen ist der Rückweg der entscheidende Teil. Notieren Sie für jeden Testfall immer:

Praxisregel: Wenn nur eine Richtung funktioniert (z. B. Ping geht raus, Antwort kommt nicht zurück), ist es oft Routing-Asymmetrie, stateless Filter oder NAT.

AWS vs. Azure: Begriffe, die Sie sauber zuordnen sollten

Die Konzepte sind ähnlich, aber die Namen unterscheiden sich. Wenn Sie beides betreiben, hilft eine klare Zuordnung:

Der Standardablauf: Drei Fragen, die 80% der Fälle lösen

Bevor Sie tief in Tools gehen, beantworten Sie diese drei Fragen. Das ist der schnellste Weg zur richtigen Problemklasse.

Routing debuggen: Der häufigste Root Cause bei „geht nicht“

Routing-Probleme wirken besonders irritierend, weil Security-Regeln oft korrekt aussehen – trotzdem kommt nichts an. Prüfen Sie Routing immer an den entscheidenden Bindungspunkten: Route Table am Subnetz (AWS) bzw. UDR Association am Subnetz (Azure), plus alle Transit-/Peering-Pfade.

AWS Route Tables: Typische Fehler

Azure UDR/Route Tables: Typische Fehler

Security Groups und NSGs: Warum „Inbound erlaubt“ trotzdem nicht reicht

Security Groups (AWS) und NSGs (Azure) sind meist stateful: Wenn eine Session erlaubt ist, ist der Rückverkehr in der Regel automatisch erlaubt. Trotzdem gibt es typische Stolperfallen:

Der Klassiker: Load Balancer und „falsche Quell-IP“

Wenn ein Client über einen Load Balancer kommt, sieht die VM/Instance nicht zwingend die originale Client-IP. Je nach LB-Typ (L4/L7) und Konfiguration kann die Quelle die IP des Load Balancers sein oder ein anderes Gateway. Dann greifen SG/NSG-Regeln, die „nur Corporate IPs“ erlauben, nicht wie gedacht.

Health Checks vergessen

Load Balancer Health Checks brauchen eigene Regeln. Wenn Health Checks geblockt sind, ist der Backend-Pool „unhealthy“, und der Service wirkt down, obwohl die App läuft.

NACLs und subnetzbasierte Filter: Stateless macht Rückwege zum Problem

AWS NACLs sind stateless: Sie müssen Inbound und Outbound explizit erlauben – inklusive Rückverkehr. Genau hier entstehen viele „es geht nur manchmal“-Fehler, besonders bei TCP.

Ephemeral Ports: Warum Rückverkehr oft blockiert wird

Wenn ein Client eine TCP-Verbindung zu 443 aufbaut, nutzt er auf der Clientseite einen dynamischen Quellport (Ephemeral Port). Die Antwort kommt zurück zu diesem Ephemeral Port. Wenn Ihre NACL nur „Inbound 443“ erlaubt, aber nicht die Ephemeral Ports, kann die Antwort geblockt werden.

Azure: NSG auf Subnetz vs. NIC

Azure NSGs sind stateful, aber es kann mehrere NSGs geben (am Subnetz und am NIC). Effektiv gilt: Der Verkehr muss durch beide Ebenen. Eine blockierende Regel auf einer Ebene reicht aus.

Die Debug-Tools: So bekommen Sie Beweise statt Vermutungen

Cloud-Plattformen bieten heute starke Bordmittel, mit denen Sie „warum“ sichtbar machen. Nutzen Sie diese Tools konsequent, statt nur Regeln zu raten.

AWS: VPC Reachability Analyzer, Flow Logs und Route-Checks

Azure: Network Watcher, NSG Flow Logs und Effective Security Rules

Praxis-Workflow: „Service in der Cloud ist nicht erreichbar“

Dieser Ablauf funktioniert für AWS und Azure gleichermaßen, unabhängig davon, ob es um SSH/RDP, HTTPS oder APIs geht.

Schritt: Minimaltest definieren

Schritt: DNS und Zielobjekt verifizieren

Schritt: Routing in beide Richtungen prüfen

Schritt: Security Layer abarbeiten

Schritt: Flow Logs/Analyzer nutzen

Sonderfälle, die häufig Zeit kosten

Asymmetrisches Routing über zwei Gateways

In Hybrid-Setups mit zwei VPNs, zwei Direct-Links oder mehreren NVAs entsteht schnell Asymmetrie. Das ist für stateful Firewalls und NAT problematisch.

MTU/PMTUD: „Klein geht, groß hängt“

VPN/Encapsulation reduziert die effektive MTU. Große TLS-Handshakes oder große Antworten können hängen bleiben, wenn ICMP blockiert ist oder MSS nicht passt.

Mehrere Security-Ebenen in Azure

Azure hat häufig mehrere Sicherheitslagen: NSG am Subnetz, NSG am NIC, Azure Firewall, WAF. Eine einzige deny-Regel mit hoher Priorität reicht, um alles zu blocken.

Best Practices: So vermeiden Sie wiederkehrende Fehler

Outbound-Links zur Vertiefung

Checkliste: Azure/AWS Netzwerkprobleme mit Security Groups, NACLs und Routen debuggen

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:

Lieferumfang:

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.

 

Exit mobile version