Fehlerbehebung bei häufigen EC2-Instanz-Konnektivitätsproblemen und Fehlern

Wenn eine EC2-Verbindung fehlschlägt, ist die erste nützliche Frage, ob die Instanz unerreichbar ist, die Authentifizierung ablehnt oder nur über den falschen Pfad erreichbar ist. Egal, 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. SSH- und RDP-Fehler verschwimmen oft, aber Permission denied, Connection timed out, Connection refused und ein leerer RDP-Bildschirm deuten auf verschiedene Ebenen hin. Behandeln Sie den Fehlertext als Hinweis und arbeiten Sie von außen nach innen.

Phase 1: Erste Überprüfungen und Instanzzustand

Bevor Sie sich in komplexe Netzwerkkonfigurationen stürzen, stellen Sie sicher, dass die Instanz korrekt läuft und auf grundlegender Ebene erreichbar ist.

1. Instanz-Statusprüfungen

Verwenden Sie die AWS Management Console oder die AWS CLI, um den allgemeinen Zustand der Instanz zu überprüfen. Zwei entscheidende Prüfungen müssen bestanden werden:

System-Statusprüfungen: Fehler hier deuten in der Regel auf zugrunde liegende Hardware- oder Infrastrukturprobleme hin, die einen AWS-Eingriff oder eine Instanzbeendigung/-neuerstellung erfordern.
Instanz-Statusprüfungen: Fehler hier beziehen sich oft auf Probleme beim Betriebssystemstart, Dateisystemkorruption oder Treiberprobleme. Wenn dies fehlschlägt, ist die Instanz wahrscheinlich zu ungesund, um Netzwerkverbindungen zu akzeptieren.

Aktion: Wenn eine der Prüfungen fehlschlägt, sollten Sie erwägen, die Instanz zu stoppen und zu starten (was sie auf neue Hardware verschiebt, wenn die Systemprüfung fehlschlägt) oder das Systemprotokoll auf Hinweise zu überprüfen.

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

Stellen Sie sicher, dass Sie versuchen, eine Verbindung zur richtigen Adresse herzustellen. Wenn Ihre Instanz direkt aus dem Internet erreichbar sein muss, benötigt sie eine öffentliche IPv4-Adresse oder eine Elastic IP und eine Route des öffentlichen Subnetzes über ein Internet-Gateway. Wenn sie sich in einem privaten Subnetz befindet, müssen Sie über einen Bastion-Host oder AWS Systems Manager Session Manager eine Verbindung herstellen.

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

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

Konnektivitätsfehler sind manchmal lokal. Ü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 die Berechtigungen korrekt gesetzt sind (chmod 400 /pfad/zum/schluessel.pem).
Für RDP (Windows): Stellen Sie sicher, dass Sie das richtige Passwort verwenden, das durch Entschlüsseln des Administratorkennworts mit der privaten Schlüsseldatei in der EC2-Konsole erhalten wurde.

Phase 2: Diagnose der 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. Sicherheitsgruppen (SG) -Eingangsregeln

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

Linux (SSH) Anforderungen:

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

Windows (RDP) Anforderungen:

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

Fehlerbehebungsschritt: Ändern Sie vorübergehend die Quelle der erforderlichen Eingangsregel auf 0.0.0.0/0 für den relevanten Port (22 oder 3389). 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) auf 0.0.0.0/0 geöffnet. Verwenden Sie nach Möglichkeit spezifische Quell-IPs oder VPC-Endpunkte.

5. Netzwerk-ACLs (NACLs)

Netzwerk-ACLs sind zustandslose Firewalls auf Subnetzebene. Sie prüfen eingehenden und ausgehenden Datenverkehr unabhängig voneinander. Wenn Datenverkehr eingehend erlaubt ist, muss der Rückverkehr auch ausgehend erlaubt sein.

NACL-Anforderungen für Konnektivität:

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

Ephemere Ports sind entscheidend. Wenn Ihr Client eine Verbindung herstellt (z. B. von Port 54321), antwortet der Server auf einem hochnummerierten ephemeren Port. Wenn die NACL den ausgehenden Datenverkehr auf diesen hohen Ports blockiert, kann der Server die Antwort nicht an Sie zurücksenden, was zu einer Verbindungszeitüberschreitung führt.

Fehlerbehebungsschritt: Überprüfen Sie, ob sowohl der eingehende Port (22/3389) als auch die ausgehenden ephemeren Ports (1024-65535) eine Erlauben-Regel in der zugehörigen NACL haben.

Phase 3: Routing und VPC-Konfiguration

Wenn die Sicherheitsebenen als geöffnet bestätigt wurden, liegt das Problem darin, wie der Datenverkehr zum und vom Subnetz der Instanz geroutet wird.

6. Subnetztyp und Routentabellen

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

Konnektivität im öffentlichen Subnetz

Für den direkten Internetzugriff (SSH/RDP von außen):

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

Konnektivität im privaten Subnetz

Instanzen in privaten Subnetzen können nicht direkt aus dem Internet erreicht werden. Die Verbindung erfordert einen mehrstufigen Pfad:

Verbindung über Bastion-Host (Jump Box): Sie verbinden sich per SSH mit einer öffentlichen EC2-Instanz und dann per SSH vom Bastion-Host zur privaten Instanz (über ihre private IP).
Verbindung über VPN/Direct Connect: Bei Verwendung von AWS Site-to-Site VPN oder Direct Connect muss das Routing so konfiguriert sein, dass Datenverkehr an Ihr lokales Netzwerk weitergeleitet wird, das dann zum privaten Subnetz routet.

7. Firewall-Probleme auf Betriebssystemebene

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

Diagnose (falls ü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 erlaubt ist.
Windows: Überprüfen Sie die Windows Defender Firewall-Einstellungen auf eingehende Regeln für Port 3389.

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

Öffentliche, private und verwaltete Verbindungsoptionen

Gehen Sie nicht davon aus, dass jede EC2-Instanz SSH oder RDP aus dem Internet akzeptieren sollte. Öffentliche Instanzen benötigen eine öffentliche Adresse, eine Route zu einem Internet-Gateway, durchlässige Sicherheitskontrollen und einen laufenden Listener. Private Instanzen benötigen normalerweise eine andere Zugriffsmethode: einen Bastion-Host, VPN, Direct Connect, EC2 Instance Connect Endpoint oder Systems Manager Session Manager.

Session Manager ist besonders nützlich für Betriebsteams, da es die Notwendigkeit von eingehendem SSH beseitigen kann. Die Instanz benötigt den SSM-Agenten, ein IAM-Instanzprofil mit den richtigen Systems Manager-Berechtigungen und Netzwerkzugriff auf SSM-Endpunkte. In privaten Subnetzen bedeutet dies normalerweise VPC-Schnittstellenendpunkte oder ausgehendes Internet über einen NAT-Pfad. Wenn eines dieser Teile fehlt, wird Session Manager nicht als Option angezeigt, selbst wenn die Instanz selbst gesund ist.

Testen Sie bei einem Bastion-Design beide Beine. Stellen Sie zuerst eine Verbindung von Ihrer Workstation zum Bastion her. Stellen Sie dann eine Verbindung vom Bastion zur privaten IP der Zielinstanz her. Die Sicherheitsgruppe der Zielinstanz sollte SSH normalerweise nur von der Bastion-Sicherheitsgruppe aus zulassen, nicht von Ihrer Heim-IP und nicht vom gesamten VPC-CIDR, es sei denn, Sie haben einen Grund.

Denken Sie bei RDP daran, dass der Windows-Start länger dauern kann als der Linux-SSH-Start, insbesondere nach Patches oder dem ersten Start. Wenn die Instanz-Statusprüfungen gerade bestanden wurden, RDP aber immer noch fehlschlägt, überprüfen Sie das Systemprotokoll und warten Sie einige Minuten, bevor Sie Firewall-Regeln ändern. Das wiederholte Ersetzen von Sicherheitsgruppen kann das eigentliche Start- oder Dienstproblem verschleiern.

Schnelltests von Ihrer Workstation aus

Führen Sie kleine Netzwerktests durch, bevor Sie AWS-Ressourcen ändern. Unter Linux oder macOS testet nc -vz <öffentliche-ip> 22, ob TCP-Port 22 abgeschlossen wird. Verwenden Sie für RDP nc -vz <öffentliche-ip> 3389 oder ein Port-Test-Tool unter Windows. Eine Zeitüberschreitung deutet auf Routing, Sicherheitsgruppen, NACLs oder eine vorgelagerte Firewall hin. Eine verweigerte Verbindung deutet eher auf das Instanz-Betriebssystem oder den Dienst hin.

Wenn DNS involviert ist, lösen Sie es explizit auf:

dig +short ec2-203-0-113-10.compute-1.amazonaws.com

Vergleichen Sie dann das Ergebnis mit der aktuellen öffentlichen IP in der EC2-Konsole. Elastic IPs bleiben stabil, aber automatisch zugewiesene öffentliche IPs können sich nach einem Stopp/Start ändern. Dies ist eine einfache Ursache für defekte Runbooks und gespeicherte RDP-Profile.

Wenn Sie ein Unternehmens-VPN verwenden, testen Sie von einem anderen Netzwerk aus, bevor Sie die VPC bearbeiten. Einige Unternehmensnetzwerke blockieren ausgehendes SSH oder RDP, und einige Heimrouter oder ISPs stören ungewöhnliche Ports. Eine erfolgreiche Verbindung von einem anderen Netzwerk aus sagt Ihnen, dass die Instanz in Ordnung sein könnte.

Der VPC Reachability Analyzer ist nützlich, wenn die Route nicht offensichtlich ist. Er kann einen Pfad zwischen einer Quelle und einem Ziel modellieren und aufzeigen, wo Routing oder Filterung den Datenverkehr blockiert. Er wird keinen schlechten SSH-Schlüssel oder einen gestoppten Dienst im Gast-Betriebssystem beheben, aber er hilft, AWS-Netzwerkdesignprobleme von Betriebssystemproblemen zu trennen.

Flow Logs können ebenfalls helfen, insbesondere wenn NACLs oder Sicherheitsgruppen verdächtig sind. Ein abgelehnter Flow von Ihrer Client-IP zu Port 22 oder 3389 sagt Ihnen, dass das Paket eine überwachte Netzwerkschnittstelle oder ein Subnetz erreicht hat und abgelehnt wurde. Überhaupt kein Flow kann bedeuten, dass der Datenverkehr die VPC nie erreicht hat, die Adresse falsch ist oder Sie die falsche ENI, das falsche Subnetz oder das falsche Zeitfenster betrachten.

Halten Sie für jede Umgebung ein kleines Zugriffs-Runbook bereit: genehmigte Quell-IP-Bereiche, Bastion-Name, SSM-Anforderungen, Standard-Benutzernamen nach AMI und die Wiederherstellungsinstanz-Prozedur. Konnektivitätsvorfälle werden langsamer, wenn jeder Ingenieur diese Details aus der Konsole neu entdecken muss.

Notieren Sie auch, welche Subnetze absichtlich privat sind. Diese eine Notiz verhindert eine Menge verschwendeter Fehlersuche, wenn jemand versucht, sich direkt per SSH mit einer Instanz zu verbinden, die nie für einen Internetpfad ausgelegt war.

Die Fehlermeldung lesen

Connection timed out bedeutet normalerweise, dass Pakete die Reise nicht abschließen. Überprüfen Sie die öffentliche IP, die Routentabelle, das Internet-Gateway, die Sicherheitsgruppenquelle, NACL-Regeln, die Unternehmensfirewall und ob Sie versuchen, ein privates Subnetz direkt zu erreichen.

Connection refused bedeutet normalerweise, dass der Netzwerkpfad die Instanz erreicht hat, aber nichts auf diesem Port lauscht oder das OS ihn abgelehnt hat. Überprüfen Sie unter Linux, ob sshd läuft und auf Port 22 lauscht. Überprüfen Sie unter Windows, ob RDP aktiviert ist und der Remotedesktopdienst läuft.

Permission denied (publickey) ist kein VPC-Problem. Es bedeutet normalerweise den falschen Benutzernamen, den falschen privaten Schlüssel, einen fehlenden öffentlichen Schlüssel in authorized_keys, geänderte Home-Verzeichnisberechtigungen oder eine AMI-Benutzernamen-Diskrepanz, wie die Verwendung von ec2-user für ein Ubuntu-Image anstelle von ubuntu.

Bei Windows RDP resultieren Authentifizierungsfehler oft aus der Verwendung eines alten entschlüsselten Administratorkennworts, nachdem die Instanz ersetzt wurde, der Verbindung zur falschen öffentlichen IP nach einem Stopp/Start oder der Überschreibung lokaler Anmeldeberechtigungen durch die Domänenrichtlinie.

Wiederherstellungspfade, wenn Sie sich nicht anmelden können

Wenn die Instanz den Systems Manager-Agenten installiert hat, ein Instanzprofil mit SSM-Berechtigungen und Netzwerkzugriff auf SSM-Endpunkte oder das Internet hat, ist Session Manager normalerweise der am wenigsten störende Wiederherstellungspfad. Sie können Protokolle einsehen, Firewall-Regeln korrigieren oder authorized_keys reparieren, ohne SSH für die Welt zu öffnen.

Wenn SSM nicht verfügbar ist, verwenden Sie die EC2-Serielle Konsole, wo unterstützt, oder trennen Sie das Root-Volume und hängen Sie es an eine Wiederherstellungsinstanz in derselben Availability Zone an. Mounten Sie es vorsichtig, korrigieren Sie die Netzwerk- oder SSH-Konfiguration, unmounten Sie es und hängen Sie es wieder an die ursprüngliche Instanz an. Erstellen Sie zuerst einen Snapshot, damit ein Reparaturversuch die Wiederherstellung nicht verschlimmert.

Wenn die Konnektivität fehlschlägt, befolgen Sie diese priorisierte Checkliste: Instanzzustand, korrekte Adresse, korrekter Benutzername/Schlüssel oder RDP-Passwort, Sicherheitsgruppe, NACL, Routentabelle, OS-Firewall und Dienstzustand. Diese Reihenfolge verhindert, dass Sie fünf AWS-Steuerelemente ändern, wenn das eigentliche Problem ein alter Schlüssel oder eine fehlende Route ist.