Site icon bintorosoft.com

Warum „Security Group ist korrekt“, aber Traffic droppt? (Debug-Checkliste)

Red Snapper

Young man engineer making program analyses

„Security Group ist korrekt, aber Traffic droppt“ ist eines der häufigsten und frustrierendsten Troubleshooting-Szenarien in Cloud-Netzwerken. Die Security Group (SG) ist in AWS zwar ein zentraler Control Point, aber sie ist selten der einzige. Selbst wenn Inbound- und Outbound-Regeln auf den ersten Blick stimmen, kann der Datenpfad an vielen anderen Stellen scheitern: falsche Route, falsches Subnetz, NACL blockt Ephemeral Ports, DNS löst auf ein anderes Ziel, eine andere ENI trägt die relevante SG, ein Load Balancer nutzt andere Security-Controls, oder der Traffic wird zwar zugelassen, aber auf Applikationsebene verworfen. Zusätzlich erschweren Caching, asymmetrische Pfade und Multi-AZ-Setups die Diagnose, weil das Problem nur für einen Teil der Requests auftritt. Dieser Artikel liefert eine praxisorientierte Debug-Checkliste, mit der Sie systematisch von Symptom zu Ursache kommen – ohne sich in Vermutungen zu verlieren.

Grundprinzip: Erst klären, ob „Drop“ wirklich ein SG-Drop ist

Bevor Sie Regeln ändern, müssen Sie sauber definieren, was „droppt“ bedeutet. In der Praxis meinen Teams damit alles von TCP-Timeout über sporadische Retries bis hin zu 403/5xx. Diese Symptome haben völlig unterschiedliche Ursachen. Security Groups verursachen typischerweise Timeouts (weil der Traffic still verworfen wird), während ein Load Balancer, ein Proxy oder eine Applikation eher explizite Fehlercodes erzeugt.

Minimaler Wahrheitscheck

Checkliste 1: Sie prüfen die „falsche“ Security Group

Der Klassiker: Die SG-Regel ist korrekt – aber sie hängt nicht an der ENI, die tatsächlich den Traffic verarbeitet. In modernen Setups existieren mehrere Interfaces (Primär-ENI, zusätzliche ENIs, LB-Interfaces, EKS-Node-ENIs, Pod-ENIs, RDS-ENIs). Ebenso kann ein Service über einen Load Balancer laufen, obwohl Sie „direkt“ testen wollten.

Praxis-Tipp: „Wer ist wirklich das Ziel?“

Checkliste 2: Outbound (Egress) ist nicht so offen, wie Sie denken

Viele Teams fokussieren Inbound-Regeln, obwohl Outbound mindestens genauso oft die Ursache ist. Eine Security Group ist stateful, aber das bedeutet nicht, dass Egress automatisch erlaubt ist. Wenn Egress restriktiv ist (was aus Security-Sicht oft richtig ist), scheitern Verbindungen still, obwohl Inbound am Ziel korrekt wäre.

Fehlerbild: „Nur manche Requests“

Wenn Clients mehrere Ziel-IPs (Round Robin DNS) bekommen, kann restriktiver Egress zufällig nur einen Teil der IPs erlauben. Das wirkt wie „intermittierend“.

Checkliste 3: NACLs droppen – und SG kann nichts dafür

Network ACLs (NACLs) sind stateless und gelten auf Subnetz-Ebene. Sie sind eine der häufigsten Ursachen für Timeouts, obwohl Security Groups sauber wirken. Besonders tückisch: NACLs brauchen Inbound- und Outbound-Regeln, inklusive Ephemeral Ports für Rückverkehr.

Quick-Check: Warum Ephemeral Ports so wichtig sind

Bei TCP-Verbindungen nutzt der Client einen temporären Quellport. Wenn NACLs den Bereich dieser Ports nicht passend erlauben, kommt die Antwort nicht zurück. Ergebnis: Timeout, obwohl Server-Port „offen“ ist.

Checkliste 4: Routing ist falsch (und SG sieht trotzdem „richtig“ aus)

Security Groups entscheiden nur, ob Traffic erlaubt wäre – nicht, ob er den richtigen Weg findet. Routing-Probleme führen zu denselben Symptomen wie ein SG-Drop. Prüfen Sie immer die Route Tables beider Seiten und mögliche transitive Abhängigkeiten.

Warnsignal: „Traceroute zeigt etwas, aber nicht das Erwartete“

In Clouds ist Traceroute nicht immer eindeutig, aber auffällige Pfade (z. B. über Egress-Hub) deuten auf falsche Routen oder Policy-based Routing hin.

Checkliste 5: DNS zeigt auf ein anderes Ziel (Split-Horizon, PrivateLink, Caching)

DNS ist oft der unsichtbare Faktor hinter „SG ist korrekt“. Besonders bei Split-Horizon DNS oder Private Endpoints kann derselbe Hostname intern und extern auf unterschiedliche IPs zeigen. Wenn ein Teil Ihrer Flotte einen anderen Resolver nutzt, sehen Sie unterschiedliche Ziele – und damit unterschiedliche Security Groups.

Praktischer DNS-Check

Checkliste 6: Der Load Balancer ist der eigentliche Gatekeeper

Wenn ein Load Balancer beteiligt ist, gelten zusätzliche Regeln: Der LB hat eigene Security Groups (oder Security Policies) und definiert Health Checks, Idle Timeouts sowie Listener/Target-Group-Ports. Ein Fehler dort erzeugt häufig 502/503/504 oder „sporadische“ Timeouts.

Checkliste 7: Host-Firewall, OS und Agenten droppen lokal

Viele Teams stoppen beim Cloud-Control-Plane, aber der Drop kann lokal auf der Instanz passieren: iptables/nftables, Windows Firewall, Security Agents, Service Mesh Sidecars oder eBPF-basierte Policy Engines. Das sieht wie ein SG-Problem aus, ist aber Host- oder Pod-Policy.

Erkennungsmerkmal

Checkliste 8: Intermittierende Drops durch Kapazität, Conntrack und Limits

Wenn „manchmal geht’s“ und manchmal nicht, ist nicht immer eine Regel falsch. Häufig sind es Limits: zu viele neue Verbindungen, zu wenig Ephemeral Ports, Conntrack-Tabellen voll, SNAT-Port-Exhaustion (bei NAT-Gateways) oder überlastete Zwischenkomponenten.

Einfaches Modell: Warum Retries das Problem verschärfen können

Wenn Clients bei Timeouts aggressiv retrien, steigt die Verbindungsanzahl und damit die Last auf NAT/Conntrack/LB. Das kann eine Feedback-Schleife erzeugen.

Last ∝ Requests × (1+RetryRate)

Checkliste 9: Observability richtig nutzen (Flow Logs, Reachability, Logs)

Wer „Drop“ beweisen will, braucht Telemetrie. In AWS sind VPC Flow Logs besonders hilfreich, weil sie zeigen, ob Traffic am ENI akzeptiert oder verworfen wurde. Ergänzend helfen Reachability Analyzer (Pfadanalyse) und Load-Balancer-Access-Logs. In Azure/GCP gibt es vergleichbare Flow-Log-Mechanismen.

Vertiefung: AWS VPC Flow Logs, AWS Reachability Analyzer, Azure NSG Flow Logs, GCP VPC Flow Logs.

Debug-Runbook: Copy-Paste-Checkliste für den On-Call

Diese Reihenfolge ist so gewählt, dass Sie zuerst häufige, schnelle Ursachen abklären und erst danach in tiefere Details gehen. Sie können sie als Incident-Runbook direkt übernehmen.

Häufige „False Positives“: Fälle, in denen SG wirklich korrekt ist

Outbound-Links für weiterführende Quellen

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