無法連接到AWS VPC RDS實例（mysql或postgres）

Question

（我在事后發布此問題是因為找到根本原因和解決方案需要花費時間。其他人也很可能會遇到相同的問題）

我有一個RDS實例（在VPC中），我試圖從通過ClassicLink連接的經典EC2實例上運行的應用程序連接到該實例。 安全組和DNS都不是問題。

我能夠建立到RDS實例的套接字連接，但是無法與CLI工具（psql，mysql等）或DB GUI工具（如toad或mysql工作台）連接。

使用telnet或nc的直接套接字連接會導致TCP連接處於“ ESTABLISHED”狀態（netstat的輸出）。

通過DB CLI，GUI工具或應用程序進行的連接會導致超時和TCP連接停留在“ SYN”狀態。

更新 ：就我而言，根本原因是MTU大小和EC2 ClassicLink問題。 如果有人遇到類似的RDS連接問題，我會在下面的答案中發布一些常規的疑難解答信息。

Answer 1

針對可能會嘗試連接到RDS或RedShift的類似問題的人們的其他信息：

1）檢查安全組

驗證RDS實例的安全組是否允許您的源服務器所屬的安全組進行訪問（如果在AWS外部，則直接添加其IP）。 您應該查看的安全組是RDS控制台UI的RDS實例屬性中指定的安全組（名為“安全組”）。

注意 ：數據庫安全組可能與AWS EC2安全組不同。 如果您的RDS實例在經典/公共EC2中，則應簽入RDS UI的“數據庫安全組”部分。 對於VPC用戶，安全組將是普通的VPC安全組（名稱sg-xxx將列在RDS實例的屬性中）。

2）確認DNS不是問題。

亞馬遜使用拆分DNS，因此AWS外部的DNS查找將返回公共IP，而AWS內部的查找將返回私有IP。 如果您懷疑這是DNS問題，是否已確認從不同的可用區域返回了不同的IP？ 如果不同的可用區獲得了不同的IP，則需要聯系AWS支持。

3）通過建立套接字連接來確認網絡連接。

諸如tracepath和traceroute之類的工具可能無濟於事，因為RDS當前會丟棄ICMP流量。

通過嘗試在端口3306（mysql或Postgres的5432）上建立與RDS實例的套接字連接來測試端口連接。 首先找到RDS實例的IP，然后使用telnet或nc（如果從AWS內部連接，請確保使用內部/專用IP）：

telnet x.x.x.x 3306
nc -vz x.x.x.x 3306

a）如果連接嘗試失敗並立即失敗，則說明該端口可能已被阻塞，或者遠程主機未在該端口上運行服務。 您可能需要與AWS支持聯系以進一步進行故障排除。 如果從AWS外部進行連接，請嘗試首先從AWS內部的另一個實例進行連接（因為您的防火牆可能會阻止這些連接）。

b）如果連接不成功並且超時，則說明數據包可能已被防火牆丟棄/忽略，或者數據包在其他網絡路徑上返回。 您可以通過運行netstat -an | grep SYN來確認這一點netstat -an | grep SYN netstat -an | grep SYN （在等待telnet / nc命令超時的同時，來自其他ssh會話）。

處於SYN狀態的連接表示您已發送了連接請求，但未收到任何返回（SYN_ACK或拒絕/阻止）。 通常，這意味着防火牆或安全組正在忽略或丟棄數據包。

NAT路由或來自多個接口的多個路徑也可能是一個問題。 檢查以確保您不在主機和RDS實例之間使用iptables或NAT網關。 如果您使用的是VPC，請確保您允許來自源主機的出站/出站流量。

c）如果套接字連接測試成功，但無法與mysql客戶端（CLI，工作台，應用程序等）連接，請查看netstat的輸出以查看連接所處的狀態（替換xxxx）以及RDS實例的實際IP地址）：

netstat -an | grep xxxx

如果使用telnet或NC時已建立連接，但是使用mysql客戶端時看到“ SYN”狀態，則可能是遇到了MTU問題。

撰寫本文時，RDS可能不支持用於PMTUD的ICMP數據包（ https://en.wikipedia.org/wiki/Path_MTU_Discovery#Problems_with_PMTUD ）。 如果您嘗試通過ClassicLink從經典ec2實例訪問VPC中的RDS或RedShift，則可能會出現問題。 嘗試使用以下方法降低MTU，然后再次進行測試：

sudo ip link show
# take note of the current MTU (likely 1500 or 9001)
sudo ip link set dev eth0 mtu 1400

如果較低的MTU有效，請確保與AWS客戶支持聯系以尋求幫助，並指出嘗試連接到RDS實例時遇到MTU問題。 如果TCP數據包使用封裝進行隧道封裝，則會發生這種情況，從而導致數據包數據/有效負載的可用MTU降低。 降低源服務器上的MTU可使經過打包的數據包在通過隧道網關時仍適合MTU限制。

如果它不起作用，請將您的MTU設置為默認值，並與AWS支持聯系以進行進一步的故障排除。