Aanvullende informatie voor mensen die soortgelijke problemen kunnen ondervinden bij het proberen verbinding te maken met RDS of RedShift:
1) Controleer beveiligingsgroepen
Controleer of de beveiligingsgroep voor het RDS-exemplaar toegang toestaat vanaf de beveiligingsgroep waartoe uw bronserver behoort (of het IP-adres dat rechtstreeks is toegevoegd indien extern aan AWS). De beveiligingsgroep waarnaar u moet kijken, is de groep die is opgegeven in de RDS-instantiekenmerken van de gebruikersinterface van de RDS-console (genaamd "beveiligingsgroep").
OPMERKING :Databasebeveiligingsgroepen kunnen verschillen van AWS EC2-beveiligingsgroepen. Als uw RDS-instantie zich in classic/public EC2 bevindt, moet u de sectie 'databasebeveiligingsgroep' van de RDS-gebruikersinterface controleren. Voor VPC-gebruikers is de beveiligingsgroep een normale VPC-beveiligingsgroep (de naam sg-xxx wordt vermeld in de kenmerken van de RDS-instantie).
2) Bevestig dat DNS geen probleem is.
Amazon gebruikt gesplitste DNS, dus een externe DNS-lookup van AWS zal het openbare IP-adres retourneren, terwijl een interne lookup van AWS een privé-IP zal retourneren. Als u vermoedt dat het een DNS-probleem is, heeft u dan bevestigd dat verschillende IP's worden geretourneerd uit verschillende beschikbaarheidszones? Als verschillende AZ's verschillende IP's krijgen, moet u contact opnemen met AWS-ondersteuning.
3) Bevestig de netwerkverbinding door een socketverbinding tot stand te brengen.
Tools zoals tracepath en traceroute zullen waarschijnlijk niet helpen, aangezien RDS momenteel ICMP-verkeer stopt.
Test de poortverbinding door te proberen een socketverbinding tot stand te brengen met de RDS-instantie op poort 3306 (mysql of 5432 voor postgres). Begin met het vinden van het IP-adres van de RDS-instantie en gebruik telnet of nc (gebruik het interne/private IP-adres als u verbinding maakt vanuit AWS):
telnet x.x.x.x 3306
nc -vz x.x.x.x 3306
a) Als uw verbindingspoging niet succesvol is en onmiddellijk mislukt, is de poort waarschijnlijk geblokkeerd of voert de externe host geen service uit op die poort. u moet mogelijk AWS-ondersteuning inschakelen om problemen verder op te lossen. Als u verbinding maakt van buiten AWS, probeer dan eerst verbinding te maken vanaf een andere instantie binnen AWS (aangezien uw firewall deze verbindingen mogelijk blokkeert).
b) Als uw verbinding niet succesvol is en u een time-out krijgt, worden pakketten waarschijnlijk verwijderd/genegeerd door een firewall of keren pakketten terug via een ander netwerkpad. U kunt dit bevestigen door netstat -an | grep SYN (van een andere ssh-sessie in afwachting van de time-out van het telnet/nc-commando).
Verbindingen in de SYN-status betekenen dat je een verbindingsverzoek hebt verzonden, maar niets terug hebt ontvangen (SYN_ACK of weigeren/blokkeren). Meestal betekent dit dat een firewall of beveiligingsgroep pakketten negeert of laat vallen.
Het kan ook een probleem zijn met NAT-routering of meerdere paden van meerdere interfaces. Controleer of u geen iptables of een NAT-gateway gebruikt tussen uw host en de RDS-instantie. Als je in een VPC zit, zorg er dan ook voor dat je uitgaand/uitgaand verkeer van de bronhost toestaat.
c) Als je socketverbindingstest succesvol was, maar je kunt geen verbinding maken met een mysql-client (CLI, workbench, app, enz.), kijk dan in de uitvoer van netstat om te zien in welke staat de verbinding zich bevindt (vervang x.x.x.x door de werkelijke IP-adres van de RDS-instantie):
netstat -an | grep x.x.x.x
Als u een verbinding tot stand kreeg bij het gebruik van telnet of NC, maar u de 'SYN'-status ziet wanneer u een mysql-client gebruikt, loopt u mogelijk tegen een MTU-probleem aan.
Op het moment dat dit wordt geschreven, ondersteunt RDS mogelijk geen ICMP-pakketten die worden gebruikt voor PMTUD (https:/ /en.wikipedia.org/wiki/Path_MTU_Discovery#Problems_with_PMTUD ). Dit kan een probleem zijn als u via ClassicLink toegang probeert te krijgen tot RDS of RedShift in een VPC van een klassieke ec2-instantie. Probeer de MTU als volgt te verlagen en test opnieuw:
sudo ip link show
# take note of the current MTU (likely 1500 or 9001)
sudo ip link set dev eth0 mtu 1400
Als de lagere MTU werkte, neem dan contact op met de AWS-klantenondersteuning voor hulp en vermeld dat u een MTU-probleem ziet terwijl u probeert verbinding te maken met uw RDS-instantie. Dit kan gebeuren als TCP-pakketten worden ingepakt met inkapseling voor tunneling, wat resulteert in een lagere bruikbare MTU voor pakketgegevens/payload. Door de MTU op de bronserver te verlagen, kunnen de verpakte pakketten nog steeds onder de MTU-limiet passen terwijl ze door de tunneling-gateway gaan.
Als het niet werkt, stelt u uw MTU weer in op de standaardwaarde en schakelt u AWS-ondersteuning in voor verdere probleemoplossing.