Ytterligare information för personer som kan stöta på liknande problem när de försöker ansluta till RDS eller RedShift:
1) Kontrollera säkerhetsgrupper
Verifiera att säkerhetsgruppen för RDS-instansen tillåter åtkomst från säkerhetsgruppen din källserver tillhör (eller dess IP läggs till direkt om den är extern till AWS). Säkerhetsgruppen du bör titta på är den som anges i RDS-instansattributen från RDS-konsolens användargränssnitt (som kallas "säkerhetsgrupp").
OBS :Databassäkerhetsgrupper kan skilja sig från AWS EC2-säkerhetsgrupper. Om din RDS-instans är i klassisk/public EC2, bör du kontrollera i avsnittet "databassäkerhetsgrupp" i RDS-gränssnittet. För VPC-användare kommer säkerhetsgruppen att vara en normal VPC-säkerhetsgrupp (namnet sg-xxx kommer att anges i RDS-instansens attribut).
2) Bekräfta att DNS inte är ett problem.
Amazon använder delad DNS, så en DNS-sökning extern till AWS kommer att returnera den offentliga IP-adressen medan en intern sökning i AWS kommer att returnera en privat IP. Om du misstänker att det är ett DNS-problem, har du bekräftat att olika IP-adresser returneras från olika tillgänglighetszoner? Om olika AZ får olika IP:er måste du kontakta AWS support.
3) Bekräfta nätverksanslutning genom att upprätta en socket-anslutning.
Verktyg som tracepath och traceroute kommer sannolikt inte att hjälpa eftersom RDS för närvarande minskar ICMP-trafik.
Testa portanslutningen genom att försöka upprätta en socketanslutning till RDS-instansen på port 3306 (mysql eller 5432 för postgres). Börja med att hitta IP-adressen för RDS-instansen och använd antingen telnet eller nc (se till att använda den interna/privata IP-adressen om du ansluter från AWS):
telnet x.x.x.x 3306
nc -vz x.x.x.x 3306
a) Om ditt anslutningsförsök inte lyckas och omedelbart misslyckas, är porten troligen blockerad eller så kör inte fjärrvärden en tjänst på den porten. du kan behöva anlita AWS-support för att felsöka ytterligare. Om du ansluter utanför AWS, försök att ansluta från en annan instans inuti AWS först (eftersom din brandvägg kan blockera dessa anslutningar).
b) Om din anslutning inte lyckas och du får en timeout, släpps/ignoreras paket förmodligen av en brandvägg eller så återvänder paket på en annan nätverksväg. Du kan bekräfta detta genom att köra netstat -an | grep SYN (från en annan ssh-session medan du väntar på att telnet/nc-kommandot försvinner).
Anslutningar i SYN-läge betyder att du har skickat en anslutningsbegäran, men inte fått något tillbaka (SYN_ACK eller avvisa/blockera). Vanligtvis betyder detta att en brandvägg eller säkerhetsgrupp ignorerar eller släpper paket.
Det kan också vara ett problem med NAT-routing eller flera vägar från flera gränssnitt. Kontrollera att du inte använder iptables eller en NAT-gateway mellan din värd och RDS-instansen. Om du är i en VPC, se också till att du tillåter utgående/utgående trafik från källvärden.
c) Om ditt socket-anslutningstest lyckades, men du inte kan ansluta till en mysql-klient (CLI, workbench, app, etc.), ta en titt på utdata från netstat för att se vilket tillstånd anslutningen är i (ersätt x.x.x.x med faktiska IP-adressen för RDS-instansen):
netstat -an | grep x.x.x.x
Om du fick en anslutning upprättad när du använde telnet eller NC, men du ser "SYN"-tillståndet när du använder en mysql-klient, kan du stöta på ett MTU-problem.
RDS, när detta skrivs, kanske inte stöder ICMP-paket som används för PMTUD (https:/ /en.wikipedia.org/wiki/Path_MTU_Discovery#Problems_with_PMTUD ). Detta kan vara ett problem om du försöker komma åt RDS eller RedShift som finns i en VPC från en klassisk ec2-instans via ClassicLink. Försök att sänka MTU:n med följande och testa sedan igen:
sudo ip link show
# take note of the current MTU (likely 1500 or 9001)
sudo ip link set dev eth0 mtu 1400
Om den nedre MTU:n fungerade, var noga med att följa upp med AWS kundsupport för hjälp och nämna att du ser ett MTU-problem när du försöker ansluta till din RDS-instans. Detta kan hända om TCP-paket lindas med inkapsling för tunnling, vilket resulterar i en lägre användbar MTU för paketdata/nyttolast. Genom att sänka MTU på källservern får de inslagna paketen fortfarande plats under MTU-gränsen medan de passerar genom tunnelgatewayen.
Om det inte fungerade, ställ tillbaka din MTU till dess standard och koppla in AWS-support för ytterligare felsökning.