Fehlerbehebung bei gängigen EC2-Instanz-Konnektivitätsproblemen und -fehlern

Die Verbindung zu einer Amazon Elastic Compute Cloud (EC2)-Instanz ist für die Verwaltung Ihrer Cloud-Ressourcen von grundlegender Bedeutung. Ob Sie SSH für Linux-Instanzen oder Remote Desktop Protocol (RDP) für Windows-Instanzen verwenden, Konnektivitätsfehler sind häufig und oft frustrierend. Dieser Leitfaden bietet einen systematischen, schrittweisen Ansatz zur Diagnose und Behebung der häufigsten Gründe, warum Sie möglicherweise keine Verbindung zu Ihrer EC2-Instanz herstellen können.

Das Verständnis von Konnektivitätsfehlern erfordert einen Blick über die Instanz selbst hinaus. Probleme entstehen in der Regel durch Fehlkonfigurationen in Sicherheitsebenen (Sicherheitsgruppen, NACLs), falsche Netzwerkkonfigurationen (VPC-Routing) oder Authentifizierungsprobleme. Durch die methodische Überprüfung dieser Komponenten in der richtigen Reihenfolge können Sie die Grundursache schnell isolieren und den Zugriff wiederherstellen.

Phase 1: Erste Prüfungen und Instanzgesundheit

Bevor Sie sich mit komplexen Netzwerkkonfigurationen befassen, stellen Sie sicher, dass die Instanz korrekt ausgeführt wird und auf grundlegender Ebene erreichbar ist.

1. Instanzstatusprüfungen

Verwenden Sie die AWS Management Console oder die AWS CLI, um den Gesamtzustand der Instanz zu überprüfen. Zwei wichtige Prüfungen müssen erfolgreich sein:

Systemstatusprüfungen: Fehler hier weisen normalerweise auf zugrunde liegende Hardware- oder Infrastrukturprobleme hin, die eine Intervention von AWS oder die Beendigung/Neuerstellung der Instanz erfordern.
Instanzstatusprüfungen: Fehler hier beziehen sich häufig auf Probleme beim Booten des Betriebssystems, beschädigte Dateisysteme oder Treiberprobleme. Wenn diese fehlschlagen, ist die Instanz wahrscheinlich nicht mehr gesund genug, um Netzwerkverbindungen zuzulassen.

Aktion: Wenn eine der Prüfungen fehlschlägt, sollten Sie in Erwägung ziehen, die Instanz zu stoppen und neu zu starten (wodurch sie bei einem Fehler der Systemprüfung auf neue Hardware verschoben wird) oder das Systemprotokoll nach Hinweisen zu durchsuchen.

2. Überprüfung der öffentlichen IP-Adresse und des DNS-Namens

Stellen Sie sicher, dass Sie versuchen, eine Verbindung zur richtigen Adresse herzustellen. Wenn sich Ihre Instanz in einem öffentlichen Subnetz befindet, benötigt sie eine öffentliche IPv4-Adresse oder eine Elastic IP. Wenn sie sich in einem privaten Subnetz befindet, müssen Sie sich über einen Bastion-Host verbinden oder den AWS Systems Manager Session Manager verwenden.

Tipp: Wenn die Instanz gestoppt und neu gestartet wurde, kann sich ihre öffentliche IP-Adresse geändert haben, es sei denn, Sie haben eine Elastic IP zugewiesen.

3. Überprüfung der Client-Konfiguration (SSH/RDP)

Konnektivitätsfehler sind manchmal lokal bedingt. Überprüfen Sie, ob Ihre Client-Software korrekt funktioniert.

Für SSH (Linux/macOS): Stellen Sie sicher, dass Sie die richtige private Schlüsseldatei (.pem oder .ppk) verwenden und dass die Berechtigungen korrekt eingestellt sind (chmod 400 /pfad/zum/schlüssel.pem).
Für RDP (Windows): Stellen Sie sicher, dass Sie das richtige Passwort verwenden, das Sie durch Entschlüsseln des Administrator-Passworts mit der privaten Schlüsseldatei in der EC2-Konsole erhalten haben.

Phase 2: Diagnose von Sicherheitsebenen (die häufigsten Fehler)

Fehlkonfigurationen der Sicherheit sind die Hauptursache für Konnektivitätsprobleme. Sowohl Sicherheitsgruppen als auch Netzwerk-ACLs fungieren als Firewalls, und beide müssen den erforderlichen Datenverkehr zulassen.

4. Ingress-Regeln der Sicherheitsgruppe (SG)

Sicherheitsgruppen sind zustandsbehaftete Firewalls, die direkt an die Elastic Network Interface (ENI) der Instanz angehängt sind.

Anforderungen für Linux (SSH):

Protokoll: TCP
Portbereich: 22
Quelle: Ihre öffentliche IP-Adresse (Meine IP) oder 0.0.0.0/0 (für alle IPs, obwohl dies aus Sicherheitsgründen nicht empfohlen wird).

Anforderungen für Windows (RDP):

Protokoll: TCP
Portbereich: 3389
Quelle: Ihre öffentliche IP-Adresse oder 0.0.0.0/0.

Fehlerbehebungsschritt: Ändern Sie vorübergehend die Quelle der erforderlichen Ingress-Regel für den entsprechenden Port (22 oder 3389) zu 0.0.0.0/0. Wenn Sie eine Verbindung herstellen können, lag das Problem daran, dass Ihre spezifische Client-IP-Adresse blockiert oder nicht korrekt identifiziert wurde.

Warnung: Lassen Sie Sicherheitsgruppen in Produktionsumgebungen niemals für Verwaltungsports (22/3389) offen für 0.0.0.0/0. Verwenden Sie, wo immer möglich, spezifische Quell-IPs oder VPC-Endpunkte.

5. Netzwerk-ACLs (NACLs)

Netzwerk-ACLs sind zustandslose Firewalls auf Subnetz-Ebene. Sie überprüfen sowohl eingehenden als auch ausgehenden Datenverkehr unabhängig voneinander. Wenn Datenverkehr hereingelassen wird, muss auch der Rückverkehr zugelassen werden.

NACL-Anforderungen für Konnektivität:

Richtung	Protokoll	Portbereich	Regelaktion
Eingehend	TCP	22 (SSH) oder 3389 (RDP)	Zulassen
Ausgehend	TCP	Ephemere Ports (1024-65535)	Zulassen

Ephemere Ports sind entscheidend. Wenn Ihr Client eine Verbindung herstellt (z. B. von Port 54321), antwortet der Server auf einem Port mit hoher Nummer aus dem Ephemeral-Bereich. Wenn die NACL den ausgehenden Datenverkehr auf diesen Ports mit hoher Nummer blockiert, kann der Server die Antwort nicht an Sie zurücksenden, was zu einem Verbindungsabbruch führt.

Fehlerbehebungsschritt: Stellen Sie sicher, dass sowohl der eingehende Port (22/3389) als auch die ausgehenden ephemeren Ports (1024-65535) eine Zulassen-Regel in der zugehörigen NACL haben.

Phase 3: Routing und VPC-Konfiguration

Wenn die Sicherheitsebenen bestätigt offen sind, liegt das Problem darin, wie der Datenverkehr zum und vom Subnetz der Instanz geroutet wird.

6. Subnetztyp und Routing-Tabellen

Die Konnektivität hängt vollständig davon ab, ob sich Ihre Instanz in einem öffentlichen Subnetz oder einem privaten Subnetz befindet.

Konnektivität in öffentlichen Subnetzen

Für den direkten Internetzugang (SSH/RDP aus der Außenwelt):

Der Instanz muss eine öffentliche IPv4-Adresse oder eine Elastic IP zugewiesen sein.
Die zugehörige Routing-Tabelle muss eine Route für 0.0.0.0/0 haben, die auf ein Internet Gateway (IGW) zeigt.

Konnektivität in privaten Subnetzen

Instanzen in privaten Subnetzen sind vom Internet aus nicht direkt erreichbar. Die Verbindung erfordert einen Mehrsprungpfad:

Verbindung über Bastion-Host (Jump Box): Sie stellen eine SSH-Verbindung zu einer öffentlichen EC2-Instanz her und dann von der Bastion-Instanz zur privaten Instanz (mit ihrer privaten IP).
Verbindung über VPN/Direct Connect: Bei Verwendung von AWS Site-to-Site VPN oder Direct Connect muss das Routing so konfiguriert sein, dass der Datenverkehr zu Ihrem lokalen Netzwerk geleitet wird, das dann zum privaten Subnetz geroutet wird.

7. Probleme mit der Firewall auf Betriebssystemebene

Wenn die AWS-Sicherheitsprüfungen bestanden werden, blockiert möglicherweise das auf der EC2-Instanz selbst laufende Betriebssystem die Verbindung. Dies ist häufig der Fall, wenn Sie lokale Firewalls manuell installiert oder konfiguriert haben (wie iptables unter Linux oder die Windows Defender Firewall).

**Diagnose (wenn über Konsole oder Session Manager möglich):

Linux: Überprüfen Sie iptables -L oder verwenden Sie firewall-cmd --list-all. Stellen Sie sicher, dass Port 22 explizit zugelassen ist.
Windows: Überprüfen Sie die Einstellungen der Windows Defender Firewall auf eingehende Regeln für Port 3389.

Wiederherstellungstipp: Wenn Sie die gesamte Konnektivität verloren haben, sollten Sie erwägen, die Instanz zu stoppen, das Root-Volume zu trennen, es an eine funktionierende Wiederherstellungsinstanz anzuhängen, die Konfigurationsdateien des Betriebssystems zu ändern, um die Firewall zu deaktivieren, und dann das Volume wieder an die ursprüngliche Instanz-ID anzuhängen.

Zusammenfassung des Fehlerbehebungsablaufs

Wenn die Konnektivität fehlschlägt, befolgen Sie diese priorisierte Checkliste:

Instanzgesundheit: Bestehen die System-/Instanzstatusprüfungen?
Client-Authentifizierung: Ist die Schlüsseldatei korrekt und mit den richtigen Berechtigungen versehen (SSH)?
Sicherheitsgruppe: Erlaubt die SG eingehenden Datenverkehr auf Port 22/3389 von Ihrer IP?
NACLs: Erlaubt die NACL eingehenden (22/3389) UND ausgehenden (1024-65535) Datenverkehr?
Routing: Zeigt die Routing-Tabelle auf ein IGW für öffentliche Subnetze?
OS-Firewall: Erlaubt die lokale Firewall auf der EC2-Instanz die Verbindung?

Durch die systematische Überprüfung dieser sechs Bereiche können Sie die überwiegende Mehrheit der EC2-Konnektivitätsfehler sicher beheben.