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

Wenn Ihre EC2-Instanz läuft, aber SSH, RDP oder App-Traffic zeitüberschreitet, liegt das Problem normalerweise im Netzwerkpfad um die Instanz. Diagnostizieren Sie EC2-Konnektivität, indem Sie zuerst die Routentabelle, dann die Subnetz-Netzwerk-ACL und dann die Instanz-Sicherheitsgruppe überprüfen.

Das Verständnis der Hierarchie und Funktion dieser Kontrollen ist entscheidend. Sicherheitsgruppen fungieren als zustandsbehaftete Firewalls auf Instanzebene, während NACLs als zustandslose Firewalls auf Subnetzebene fungieren. Fehlkonfigurationen in einer dieser Komponenten oder falsche Routing-Pfade blockieren sofort den erwarteten Traffic, was zu frustrierenden Verbindungszeitüberschreitungen führt.

Die drei Säulen der EC2-Konnektivitätskontrolle

Bevor wir uns mit spezifischen Konfigurationen befassen, ist es entscheidend, die Rolle jeder Komponente im Traffic-Pfad zu Ihrer EC2-Instanz zu verstehen:

Routentabellen: Bestimmen, wohin der Netzwerkverkehr 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 Konnektivität fehl.
Netzwerk-ACLs (NACLs): Wenden Regeln auf ein gesamtes Subnetz an. Sie sind zustandslos, was bedeutet, dass sowohl eingehender als auch ausgehender Traffic explizit erlaubt sein muss. Sie verarbeiten Regeln in der Reihenfolge, von der niedrigsten bis zur höchsten Regelnummer, und stoppen beim ersten Treffer.
Sicherheitsgruppen (SGs): Wenden Regeln direkt auf die Elastic Network Interface (ENI) der EC2-Instanz an. Sie sind zustandsbehaftet, was bedeutet, dass wenn Sie eingehenden Traffic erlauben, der zurückgehende ausgehende Traffic automatisch erlaubt ist.

Schritt 1: Überprüfen der VPC-Routentabellen

Die erste diagnostische Überprüfung sollte immer bestätigen, dass ein Pfad für den Traffic existiert, um überhaupt das Subnetz zu erreichen, in dem sich die EC2-Instanz befindet.

Überprüfen des eingehenden Routings

Für eine Instanz, die vom öffentlichen Internet erreichbar ist (z.B. über SSH/RDP):

Ziel: Sicherstellen, dass das Subnetz, das eine öffentliche Instanz enthält, eine Standardroute zu einem Internet-Gateway (IGW) hat.
Aktion: Navigieren Sie zur VPC-Konsole, wählen Sie Routentabellen und überprüfen Sie die Routentabelle, die mit dem Subnetz Ihrer Instanz verbunden ist. Suchen Sie nach einem Eintrag wie:
```
Ziel: 0.0.0.0/0 | Ziel: igw-xxxxxxxx
```

Überprüfen des ausgehenden Routings (Für zustandsbehaftete Probleme)

Obwohl SGs zustandsbehaftet sind, ist die Überprüfung des ausgehenden Pfades entscheidend, insbesondere für Rückverkehr oder Instanzen, die Verbindungen zu externen Diensten initiieren.

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

Tipp: Traffic zwischen Subnetzen im selben VPC verwendet normalerweise die implizite local-Route. Wenn dieser Traffic fehlschlägt, überprüfen Sie Sicherheitsgruppen, NACLs, Host-Firewalls und ob das Ziel ICMP erlaubt, bevor Sie die Routentabelle beschuldigen.

Schritt 2: Überprüfen von Netzwerk-ACLs (Subnetzebene)

NACLs werden oft übersehen, weil sie auf Subnetzebene operieren und zustandslos sind. Ein häufiger Fehler ist, eingehenden Traffic zu erlauben, aber zu vergessen, den zurückgehenden ausgehenden Traffic explizit zu erlauben.

Überprüfung der eingehenden Regeln

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

Identifizieren Sie die NACL, die mit dem Subnetz der Instanz verbunden ist.
Überprüfen Sie die Eingehenden Regeln.
Stellen Sie sicher, dass eine Regel existiert, die den spezifischen Port und das Protokoll, das Sie verwenden, erlaubt (z.B. Regel 100: Typ: SSH (22), Protokoll: TCP, Quelle: 0.0.0.0/0).

Überprüfung der ausgehenden Regeln (Die zustandslose Falle)

Hier treten die meisten NACL-Verbindungsprobleme auf.

Überprüfen Sie die Ausgehenden Regeln.
Wenn Sie eingehenden SSH (Port 22) erlaubt haben, muss die Instanz Traffic zurück zu Ihrem Client auf einem Hohen Port (Ephemeraler Port)-Bereich senden, typischerweise 1024-65535.
Aktion: Stellen Sie sicher, dass eine ausgehende Regel explizit Traffic zum relevanten Zielportbereich erlaubt (oft 1024-65535, wenn der Client die Verbindung initiiert).

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

Eingehende Regeln:

Regel #	Typ	Protokoll	Portbereich	Quelle	Erlauben/Verweigern
100	SSH	TCP	22	Ihre Client-IP/CIDR	ALLOW
*	*	*	*	*	DENY (Standard)

Ausgehende Regeln:

Regel #	Typ	Protokoll	Portbereich	Ziel	Erlauben/Verweigern
100	Benutzerdefiniertes TCP	TCP	1024-65535	Ihre Client-IP/CIDR	ALLOW
*	*	*	*	*	DENY (Standard)

Warnung: NACLs werten Regeln numerisch aus. Wenn Regel 90 DENY ALL ist, wird Ihre nachfolgende Regel 100 ALLOW SSH nie erreicht. Stellen Sie sicher, dass Ihre expliziten ALLOW-Regeln niedrigere Nummern haben als alle breiten DENY-Regeln, oder verlassen Sie sich auf die endgültige implizite DENY ALL-Regel.

Schritt 3: Überprüfen von Sicherheitsgruppen (Instanzebene)

Sicherheitsgruppen sind die letzte Verteidigungslinie, die direkt auf die Instanz angewendet werden. Sie sind einfacher zu verwalten, da sie zustandsbehaftet sind.

Überprüfung der eingehenden Regeln

Überprüfen Sie, ob die SG, die an die EC2-Instanz angehängt ist, Traffic auf den erforderlichen Ports von der erwarteten Quelle erlaubt:

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

Überprüfung der ausgehenden Regeln (Normalerweise standardmäßig)

Da SGs zustandsbehaftet sind, sind die ausgehenden Regeln normalerweise so konfiguriert, dass sie ALLEN Traffic erlauben (0.0.0.0/0 auf allen Ports). Wenn Sie die ausgehenden Regeln angepasst haben, stellen Sie sicher, dass sie Antworten zurück zum ephemeralen Portbereich des Clients erlauben.

Bewährte Methode: Sofern keine strengen Sicherheitsanforderungen bestehen, lassen Sie die Ausgehenden Regeln der Sicherheitsgruppe auf dem Standardwert: Allen Traffic zu allen Zielen erlauben. Dies vereinfacht die Fehlerbehebung erheblich, da Sie NACL- oder Routentabellenprobleme isolieren können.

Konnektivitäts-Checkliste

Wenn eine EC2-Verbindung fehlschlägt, befolgen Sie diese diagnostische Reihenfolge:

Routentabellen-Überprüfung: Kann der Traffic-Pfad (eingehend und ausgehend) das richtige Subnetz-Gateway (IGW/VPC-Peering/NAT) erreichen?
NACL-Überprüfung (Zustandslos): Ist der Traffic auf dem spezifischen eingehenden Port explizit ERLAUBT UND ist der Rückverkehr (oft hohe ephemere Ports) explizit ausgehend ERLAUBT?
Sicherheitsgruppen-Überprüfung (Zustandsbehaftet): Ist der Traffic auf dem spezifischen eingehenden Port explizit ERLAUBT? (Ausgehend sollte im Allgemeinen offen sein).

Indem Sie systematisch von der breiten Netzwerkebene (Routing) über die Subnetzebene (NACLs) bis zur Instanzebene (SGs) vorgehen, können Sie schnell isolieren, ob der blockierende Mechanismus zustandsloses Filtern, zustandsbehaftetes Filtern oder ein Routing-Fehler ist.