Fehlerbehebung bei häufigen RDS-Verbindungsproblemen von EC2-Instanzen

Wenn eine Anwendung auf EC2 keine Verbindung zu RDS herstellen kann, identifizieren Sie zuerst die Art des Fehlers. Ein Timeout bedeutet normalerweise, dass der Datenverkehr irgendwo auf dem Pfad verworfen wird. Ein schnelles connection refused bedeutet, dass der Host erreicht wurde, der Port die Verbindung jedoch nicht akzeptiert hat. Ein Authentifizierungsfehler bedeutet, dass der Netzwerkpfad wahrscheinlich funktioniert und das Problem auf die Datenbankbenutzer, Passwörter, SSL, IAM-Authentifizierung oder Berechtigungen übergegangen ist.

Diese Unterscheidung spart Zeit. Setzen Sie keine Passwörter für ein Netzwerk-Timeout zurück und öffnen Sie keine Sicherheitsgruppen für ein falsches Passwort. Arbeiten Sie von der EC2-Instanz nach außen: DNS, Port-Erreichbarkeit, Sicherheitsgruppen, Subnetz-Routing, NACLs, RDS-Status, dann Datenbank-Authentifizierung.

Voraussetzungen für eine erfolgreiche Verbindung

Bevor Sie mit der Fehlerbehebung beginnen, stellen Sie sicher, dass die folgenden grundlegenden Elemente korrekt konfiguriert sind:

1. VPC-Ausrichtung: Sowohl die EC2-Instanz als auch die RDS-Instanz sollten sich idealerweise in der gleichen VPC befinden, um die einfachste Konfiguration zu gewährleisten, obwohl eine VPC-übergreifende Konnektivität über VPC-Peering möglich ist.
2. Verfügbarkeitszonen (AZs): Stellen Sie sicher, dass Ihre Anwendungsinfrastruktur (EC2) bei Bedarf die Datenbankinfrastruktur (RDS) über AZs hinweg erreichen kann, obwohl das Routing dies normalerweise innerhalb der VPC handhabt.
3. Netzwerkerreichbarkeit: Bestätigen Sie, dass die EC2-Instanz läuft und eine aktive Netzwerkverbindung hat (z. B. kann sie das Internet oder andere interne Dienste erreichen).

Schritt 1: Überprüfen der Sicherheitsgruppenkonfigurationen (Der häufigste Übeltäter)

Sicherheitsgruppen fungieren als virtuelle Firewalls sowohl für Ihre EC2-Instanz als auch für Ihre RDS-Instanz. Eine Fehlkonfiguration hier ist die Ursache der überwältigenden Mehrheit der Verbindungsfehler.

A. Überprüfung der EC2-Sicherheitsgruppe

Ihre EC2-Instanz benötigt Ausgehende Regeln, die Datenverkehr zum Datenbankport verlassen lassen. Standardmäßig erlauben die meisten Sicherheitsgruppen den gesamten ausgehenden Datenverkehr (0.0.0.0/0 auf allen Protokollen/Ports), aber es ist ratsam, dies zu überprüfen.

B. Überprüfung der eingehenden Regeln der RDS-Sicherheitsgruppe

Dies ist der kritische Schritt. Die RDS-Sicherheitsgruppe muss explizit eingehenden Datenverkehr von der EC2-Instanz erlauben.

Überprüfung mit Handlungsanweisung:

1. Navigieren Sie zur RDS-Konsole und wählen Sie Ihre Datenbankinstanz aus.
2. Gehen Sie zum Tab Konnektivität und Sicherheit und suchen Sie die zugehörige(n) Sicherheitsgruppe(n).
3. Bearbeiten Sie die Eingehenden Regeln.
4. Stellen Sie sicher, dass eine Regel vorhanden ist, die Datenverkehr auf dem spezifischen Datenbankport erlaubt (z. B. 3306 für MySQL, 5432 für PostgreSQL).
5. Die Quelle für diese Regel muss die Sicherheitsgruppen-ID Ihrer EC2-Instanz oder der spezifische private IP-Bereich der EC2-Instanz sein, wenn Sie keine Sicherheitsgruppenverweise verwenden.

Bewährte Methode: Verweisen Sie immer auf die Sicherheitsgruppen-ID der Quellressource (EC2), anstatt spezifische IP-Adressen im Quellfeld zu verwenden. Dadurch bleibt die Verbindung auch dann bestehen, wenn sich die private IP der EC2-Instanz ändert (z. B. während des Skalierens oder Neustarts).

Beispiel für eine eingehende Regel (PostgreSQL):

Typ	Protokoll	Portbereich	Quelle
PostgreSQL	TCP	5432	sg-012345abcdef67890 (Ihre EC2-Sicherheitsgruppen-ID)

Schritt 2: Bestätigen der öffentlichen Zugänglichkeit und des Endpunkts von RDS

Wenn sich Ihre EC2-Instanz nicht in einem privaten Subnetz befindet oder eine Verbindung über das öffentliche Internet erfordert (für die Produktion generell nicht empfohlen), müssen Sie die öffentliche Zugänglichkeit von RDS überprüfen.

A. Einstellung für öffentliche Zugänglichkeit

1. Überprüfen Sie in der RDS-Konsole den Tab Konnektivität und Sicherheit für die RDS-Instanz.
2. Wenn Öffentlich zugänglich auf Nein gesetzt ist, ist die Datenbank nur über private Netzwerkpfade erreichbar, z. B. über Ressourcen in derselben VPC oder verbundene Netzwerke über Peering, Transit Gateway, VPN oder Direct Connect, wenn Routing und Sicherheitsregeln dies zulassen.
3. Wenn Öffentlich zugänglich auf Ja gesetzt ist, behandeln Sie dies nicht als Abkürzung für den Produktionszugriff. Bestätigen Sie, dass der Client eine gültige öffentliche Route hat, und schränken Sie die RDS-Sicherheitsgruppe auf den kleinstmöglichen praktischen Quellbereich ein. Eine EC2-Instanz in derselben VPC sollte normalerweise den privaten Pfad verwenden.

B. Endpunkt-Überprüfung

Stellen Sie sicher, dass die Anwendung auf der EC2-Instanz den korrekten RDS-Endpunkt (DNS-Name) und den korrekten Port verwendet. Abweichungen hier führen zu Timeouts oder Verbindungsablehnungen.

Verwenden Sie das Dienstprogramm telnet oder nc (netcat) von Ihrer EC2-Instanz, um die grundlegende TCP-Erreichbarkeit zum RDS-Endpunkt und -Port zu testen:

# Für MySQL auf Port 3306
telnet your-rds-endpoint.rds.amazonaws.com 3306

# Für PostgreSQL auf Port 5432
nc -zv your-rds-endpoint.rds.amazonaws.com 5432

Eine erfolgreiche Verbindung führt zu einem leeren Bildschirm oder einer sofortigen Verbindungsmeldung. Ein Fehler (Timeout oder Ablehnung) weist auf eine Netzwerkblockade hin, normalerweise Sicherheitsgruppen oder Subnetz-Routing.

Schritt 3: Analysieren der Subnetz- und Routing-Konfiguration

Wenn die Sicherheitsgruppen korrekt erscheinen, liegt das Problem möglicherweise in der Kommunikation der Subnetze.

A. Netzwerk-ACLs (NACLs)

Netzwerk-ACLs sind zustandslose Firewalls, die auf Subnetzebene arbeiten. Wenn Sie benutzerdefinierte NACLs implementiert haben, blockieren diese möglicherweise den für eine Verbindung erforderlichen Rückverkehr.

• Überprüfen Sie die NACLs sowohl für das EC2-Subnetz als auch für das RDS-Subnetz.
• Stellen Sie sicher, dass sowohl eingehende als auch ausgehende Regeln Datenverkehr auf dem Datenbankport und dem ephemeren Portbereich (1024-65535) für den Rückverkehr zulassen.

B. VPC-übergreifendes oder Hybrid-Routing

RDS-Datenbankverbindungen verwenden normalerweise normales VPC-Routing, keinen S3-ähnlichen Gateway-Endpunkt. Wenn sich EC2 und RDS in verschiedenen VPCs befinden oder aus On-Premises-Netzwerken verbunden sind, überprüfen Sie die vollständige private Route in beide Richtungen. VPC-Peering, Transit Gateway, VPN und Direct Connect erfordern alle Routentabelleneinträge sowie kompatible Sicherheitsgruppen- und NACL-Regeln.

Schritt 4: Überprüfungen der Datenbankinstanzkonfiguration

Wenn die Netzwerkkonnektivität bestätigt ist (Schritt 2 erfolgreich), liegt das Problem innerhalb der Datenbank-Engine selbst.

A. Datenbank-Anmeldeinformationen und Autorisierung

Überprüfen Sie den Benutzernamen, das Passwort und den Datenbanknamen, die von der Anwendung verwendet werden, die von der EC2-Instanz aus eine Verbindung herstellt. RDS-Dienste wie MySQL und PostgreSQL erzwingen eine strenge Benutzerauthentifizierung.

B. Parametergruppen und Datenbankstatus

1. Datenbankstatus: Stellen Sie sicher, dass der Status der RDS-Instanz Verfügbar ist. Wenn sie geändert, gesichert oder neu gestartet wird, schlagen Verbindungen fehl.
2. Parametergruppen: Überprüfen Sie alle benutzerdefinierten Parametergruppen, die auf die RDS-Instanz angewendet werden. Bestimmte Einstellungen (wie skip-networking in einigen MySQL-Konfigurationen, obwohl in verwaltetem RDS weniger üblich) können Verbindungen verhindern.

C. IAM-Datenbankauthentifizierung (falls verwendet)

Wenn Sie IAM für die Datenbankauthentifizierung anstelle von Passwörtern verwenden, stellen Sie sicher, dass die der EC2-Instanz zugeordnete IAM-Rolle (oder das Benutzerprofil, das die Anwendung ausführt) die korrekten Berechtigungen (rds-db:connect) hat und dass die Verbindungszeichenfolge die erforderlichen Authentifizierungstoken korrekt enthält.

Fehlerbehebungsablauf

Verwenden Sie diese priorisierte Checkliste, um Probleme schnell zu lösen:

1. Port-Überprüfung: Kann EC2 den RDS-Port mit telnet oder nc erreichen? Verlassen Sie sich nicht auf ICMP-Ping; RDS ist kein normaler Server, den Sie auf diese Weise zur Fehlerbehebung verwenden können.
2. RDS-Sicherheitsgruppe: Erlaubt die eingehende Regel Datenverkehr von der EC2-Sicherheitsgruppe zum RDS-Port?
3. NACLs: Sind sowohl eingehende als auch ausgehende Regeln für die erforderlichen Ports (Datenbankport + Ephemere Ports) geöffnet?
4. Endpunkt/Anmeldeinformationen: Ist die Verbindungszeichenfolge korrekt und sind die Anmeldeinformationen gültig?
5. DB-Status: Ist die RDS-Instanz Verfügbar?

Wenn der Port-Test fehlschlägt, bleiben Sie in der Netzwerkschicht, bis er erfolgreich ist. Wenn der Port-Test erfolgreich ist, der Datenbank-Client jedoch fehlschlägt, hören Sie auf, VPC-Regeln zu ändern, und lesen Sie den Datenbankfehler genau. Die meisten EC2-zu-RDS-Vorfälle werden viel einfacher, wenn Netzwerkerreichbarkeit und Datenbankauthentifizierung als separate Fragen behandelt werden.