Diagnose von EC2-Instance-Konnektivitätsproblemen: Sicherheitsgruppen und Netzwerk-ACLs

Die Verbindung zu einer Amazon Elastic Compute Cloud (EC2)-Instance ist ein grundlegender Vorgang, doch Konnektivitätsfehler gehören zu den häufigsten Szenarien bei der Fehlerbehebung für AWS-Benutzer. Wenn eine Instance korrekt zu laufen scheint, aber unerreichbar bleibt – sei es über SSH, RDP oder Anwendungs-Traffic –, liegt das Problem fast immer in den umgebenden Netzwerksicherheitsebenen. Dieser umfassende Leitfaden beschreibt den systematischen Ansatz zur Diagnose und Behebung von Konnektivitätsproblemen, indem er sich auf die drei kritischen Netzwerk-Kontrollpunkte konzentriert: Sicherheitsgruppen (SGs), Netzwerk-Zugriffssteuerungslisten (NACLs) und VPC-Routing-Tabellen.

Das Verständnis der Hierarchie und Funktion dieser Kontrollen ist entscheidend. Sicherheitsgruppen fungieren als zustandsbehaftete (stateful) Firewalls auf Instance-Ebene, während NACLs als zustandslose (stateless) Firewalls auf Subnetz-Ebene agieren. Fehlkonfigurationen in einer dieser Komponenten oder falsche Routing-Pfade blockieren den erwarteten Traffic sofort, was zu frustrierenden Verbindungs-Timeouts führt.

Die drei Säulen der EC2-Konnektivitätskontrolle

Bevor wir uns in spezifische Konfigurationen vertiefen, ist es entscheidend, die Rolle zu verstehen, die jede Komponente auf dem Traffic-Pfad zu Ihrer EC2-Instance spielt:

1. Route Tables (Routing-Tabellen): Bestimmen, wohin der Netzwerk-Traffic basierend auf seiner Ziel-IP-Adresse geleitet wird. Wenn Traffic, der für das Internet oder Ihre Client-IP bestimmt ist, das richtige Subnetz-Gateway nicht erreichen kann, schlägt die Verbindung fehl.
2. Network ACLs (NACLs): Wenden Regeln auf ein gesamtes Subnetz an. Sie sind zustandslos (stateless), was bedeutet, dass sowohl eingehender als auch ausgehender Traffic explizit zugelassen werden muss. Sie verarbeiten Regeln der Reihe nach, von der niedrigsten zur höchsten Regelnummer, und stoppen bei der ersten Übereinstimmung.
3. Security Groups (SGs): Wenden Regeln direkt auf die Elastic Network Interface (ENI) der EC2-Instance an. Sie sind zustandsbehaftet (stateful), was bedeutet, dass, wenn Sie eingehenden Traffic zulassen, der zurückkehrende ausgehende Traffic automatisch erlaubt wird.

Schritt 1: Überprüfung der VPC Route Tables

Der erste Diagnoseschritt sollte immer bestätigen, dass ein Pfad für den Traffic existiert, um das Subnetz, in dem sich die EC2-Instance befindet, überhaupt zu erreichen.

Überprüfung des eingehenden Routings

Für eine Instance, die über das öffentliche Internet erreichbar ist (z. B. über SSH/RDP):

• Ziel: Stellen Sie sicher, dass das Subnetz, das die Instance enthält, eine Route zum Internet Gateway (IGW) für Traffic von 0.0.0.0/0 (oder Ihrem spezifischen Client-IP-Bereich) hat.
• Aktion: Navigieren Sie zur VPC-Konsole, wählen Sie Route Tables und untersuchen Sie die Routing-Tabelle, die dem Subnetz Ihrer Instance zugeordnet ist. Suchen Sie nach einem Eintrag wie:
  Destination: 0.0.0.0/0 | Target: igw-xxxxxxxx

Überprüfung des ausgehenden Routings (Bei Stateful-Problemen)

Obwohl SGs zustandsbehaftet sind, ist die Überprüfung des ausgehenden Pfades entscheidend, insbesondere für den Rück-Traffic oder Instances, die Verbindungen zu externen Diensten initiieren.

• Aktion: Wenn sich Ihre Instance in einem privaten Subnetz befindet, stellen Sie sicher, dass sie eine Route zu einem NAT Gateway oder einer NAT Instance hat, um das Internet zu erreichen. Befindet sie sich in einem öffentlichen Subnetz, sollte sie 0.0.0.0/0 zum IGW routen.

Tipp: Wenn Sie eine Instance von einem anderen Subnetz innerhalb derselben VPC aus nicht anpingen können, handelt es sich mit ziemlicher Sicherheit um eine falsch konfigurierte Routing-Tabelle, die den Traffic an das falsche lokale Gateway oder die falsche VPC-Peering-Verbindung leitet.

Schritt 2: Überprüfung der Network ACLs (Subnetz-Ebene)

NACLs werden oft übersehen, da sie auf Subnetz-Ebene arbeiten und zustandslos sind. Ein häufiger Fehler ist, eingehenden Traffic zuzulassen, aber zu vergessen, den zurückkehrenden ausgehenden Traffic explizit zu erlauben.

Überprüfung der Inbound-Regel (Eingehend)

Für eingehende Verbindungsversuche (z. B. SSH auf Port 22):

1. Identifizieren Sie die NACL, die dem Subnetz der Instance zugeordnet ist.
2. Untersuchen Sie die Inbound Rules (eingehende Regeln).
3. Stellen Sie sicher, dass eine Regel existiert, die den spezifischen Port und das verwendete Protokoll zulässt (z. B. Regel 100: Typ: SSH (22), Protokoll: TCP, Quelle: 0.0.0.0/0).

Überprüfung der Outbound-Regel (Die Stateless-Falle)

Hier treten die meisten NACL-Verbindungsprobleme auf.

1. Untersuchen Sie die Outbound Rules (ausgehende Regeln).
2. Wenn Sie eingehendes SSH (Port 22) zugelassen haben, muss die Instance den Traffic über einen Hohen Port (Ephemerer Port)-Bereich, typischerweise 1024-65535, an Ihren Client zurücksenden.
3. Aktion: Stellen Sie sicher, dass eine Outbound-Regel den Traffic zum relevanten Ziel-Portbereich (oft 1024-65535, wenn der Client die Verbindung initiiert) explizit zulässt.

Beispiel-NACL-Regelsatz für eingehenden SSH-Zugriff:

Warnung: NACLs werten Regeln numerisch aus. Wenn Regel 90 ALLE VERWEIGERN (DENY ALL) lautet, wird Ihre nachfolgende Regel 100 SSH ZULASSEN (ALLOW SSH) niemals erreicht. Stellen Sie sicher, dass Ihre expliziten ZULASSEN-Regeln niedrigere Nummern haben als alle allgemeinen VERWEIGERN-Regeln, oder verlassen Sie sich auf die abschließende implizite Regel ALLE VERWEIGERN.

Schritt 3: Überprüfung der Sicherheitsgruppen (Instance-Ebene)

Sicherheitsgruppen sind die letzte Verteidigungslinie und werden direkt auf die Instance angewendet. Sie sind einfacher zu verwalten, da sie zustandsbehaftet (stateful) sind.

Überprüfung der Inbound-Regel

Verifizieren Sie, dass die der EC2-Instance zugeordnete SG den Traffic auf den erforderlichen Ports von der erwarteten Quelle zulässt:

• Für SSH (Linux): Inbound-Regel, die TCP Port 22 von Ihrer öffentlichen IP oder 0.0.0.0/0 (falls erforderlich) zulässt.
• Für RDP (Windows): Inbound-Regel, die TCP Port 3389 von Ihrer öffentlichen IP oder 0.0.0.0/0 zulässt.
• Für Web-Traffic: Inbound-Regel, die TCP Port 80 und/oder 443 von 0.0.0.0/0 zulässt.

Überprüfung der Outbound-Regel (Normalerweise Standardeinstellung)

Da SGs zustandsbehaftet sind, sind die Outbound-Regeln normalerweise so konfiguriert, dass sie JEGLICHEN Traffic ZULASSEN (ALLOW ALL Traffic) (0.0.0.0/0 auf allen Ports). Wenn Sie die Outbound-Regeln angepasst haben, stellen Sie sicher, dass sie Antworten zurück zum ephemeren Portbereich des Clients zulassen.

Best Practice: Sofern keine strikten Sicherheitsanforderungen bestehen, belassen Sie die Outbound Rules der Sicherheitsgruppe bei der Standardeinstellung: Gesamten Traffic zu allen Zielen zulassen. Dies vereinfacht die Fehlerbehebung erheblich, da Sie Probleme mit NACL oder Routing-Tabellen isolieren können.

Zusammenfassung: Die Checkliste für den Konnektivitätsfluss

Wenn eine EC2-Verbindung fehlschlägt, folgen Sie dieser Diagnose-Reihenfolge:

1. Route Table Check: Kann der Traffic-Pfad (eingehend und ausgehend) das richtige Subnetz-Gateway (IGW/VPC Peering/NAT) erreichen?
2. NACL Check (Stateless): Ist der Traffic auf dem spezifischen eingehenden Port explizit ZUGELASSEN UND ist der Rück-Traffic (oft hohe ephemere Ports) explizit ausgehend ZUGELASSEN?
3. Security Group Check (Stateful): Ist der Traffic auf dem spezifischen eingehenden Port explizit ZUGELASSEN? (Ausgehender Traffic sollte generell offen sein).

Indem Sie systematisch von der breiten Netzwerkschicht (Routing) zur Subnetz-Ebene (NACLs) und schließlich zur Instance-Ebene (SGs) vorgehen, können Sie schnell isolieren, ob der blockierende Mechanismus eine zustandslose Filterung, eine zustandsbehaftete Filterung oder ein Routing-Fehler ist.