EC2 インスタンス i-78a8df00 から、RDS インスタンス mysql.************.us-east-1.rds.amazonaws.com に接続しようとしています。どちらも米国東部リージョンにあります。EC2 インスタンスのセキュリティ グループ (sg-********) を RDS セキュリティ グループに追加しましたが、解決しませんでした。次のコマンドを実行するとタイムアウトになるため、ファイアウォール/DNS の問題のようです。
ubuntu@ip-10-195-189-237:~$ mysql -h mysql.************.us-east-1.rds.amazonaws.com
エラー 2003 (HY000): 「mysql.************.us-east-1.rds.amazonaws.com」の MySQL サーバーに接続できません (110)
上記と同じ行を使用して、ローカル マシンから RDS インスタンスに正常に接続できます。さまざまなフォーラム ソリューションを試しましたが、解決しません。
新しい EC2 インスタンスをスピンしたときに同様の問題が発生しましたが、RDS インスタンスのポート 3306 への接続を許可されたインバウンド IP アドレスの RDS セキュリティ グループの設定を変更しませんでした。
ややこしいのは、セキュリティ グループと呼ばれる RDS ダッシュボードのオプションでした。問題を解決するためにそれは必要ありません。
本当に必要なものは次のとおりです。
これにより、新しいブラウザ タブまたはウィンドウが開き、セキュリティ グループの詳細が表示されます。下部にあるいくつかのタブを見つけて、[ Inbound rules ] タブを選択し、[ Edit ] ボタンをクリックします。
値を EC2 インスタンスの IP アドレスまたは IPv4 CIDR ブロックに変更します。
174.33.0.0/16
この値を取得するには、インスタンスに ssh してip addrを実行するか、ブラウザで EC2 Manager を実行して、インスタンスの詳細でプライベート IPの値を見つけます。
RDS または RedShift に接続しようとして同様の問題が発生する可能性があるユーザー向けの追加情報:
1) セキュリティグループを確認する
RDS インスタンスのセキュリティ グループが、ソース サーバーが属するセキュリティ グループ (または AWS の外部の場合は直接追加されたその IP) からのアクセスを許可していることを確認します。確認する必要があるセキュリティ グループは、RDS コンソール UI の RDS インスタンス属性で指定されたものです (「セキュリティ グループ」という名前)。
注: データベース セキュリティ グループは、AWS EC2 セキュリティ グループとは異なる場合があります。RDS インスタンスがクラシック/パブリック EC2 にある場合は、RDS UI の「データベース セキュリティ グループ」セクションを確認する必要があります。VPC ユーザーの場合、セキュリティ グループは通常の VPC セキュリティ グループになります (RDS インスタンスの属性に sg-xxx という名前が表示されます)。
2) DNS に問題がないことを確認します。
Amazon はスプリット DNS を使用しているため、AWS の外部の DNS ルックアップはパブリック IP を返し、AWS の内部のルックアップはプライベート IP を返します。DNS の問題であると思われる場合は、異なるアベイラビリティ ゾーンから異なる IP が返されることを確認しましたか? 異なる AZ が異なる IP を取得する場合は、AWS サポートに連絡する必要があります。
3) ソケット接続を確立して、ネットワーク接続を確認します。
RDS は現在 ICMP トラフィックをドロップしているため、tracepath や traceroute などのツールはおそらく役に立ちません。
ポート 3306 (mysql、または postgres の場合は 5432) で RDS インスタンスへのソケット接続を確立して、ポート接続をテストします。まず、RDS インスタンスの IP を見つけ、telnet または nc を使用します。
telnet x.x.x.x 3306
nc -vz x.x.x.x 3306
a)接続試行が成功せず、すぐに失敗する場合は、ポートがブロックされているか、リモート ホストがそのポートでサービスを実行していない可能性があります。さらにトラブルシューティングを行うには、AWS サポートを利用する必要がある場合があります。AWS の外部から接続する場合は、最初に AWS 内の別のインスタンスから接続してみてください (ファイアウォールがそれらの接続をブロックしている可能性があるため)。
b)接続が成功せず、タイムアウトが発生した場合は、パケットがファイアウォールによってドロップ/無視されているか、パケットが別のネットワーク パスに返されている可能性があります。これは、実行することで確認できますnetstat -an | grep SYN(実行中に別の CLI ウィンドウ/セッションから実行し、telnet/nc コマンドがタイムアウトするのを待っています)。SYN 状態の接続は、接続要求を送信したが、何も返されていないことを意味します (SYN_ACK または拒否/ブロック)。通常、これは、ファイアウォールまたはセキュリティ グループがパケットを無視またはドロップしていることを意味します。
ホストと RDS インスタンスの間で iptables または NAT ゲートウェイを使用していないことを確認してください。VPC にいる場合は、送信元ホストからの送信/送信トラフィックを許可することも確認してください。
c)ソケット接続テストは成功したが、mysql クライアント (CLI、ワークベンチ、アプリなど) に接続できない場合は、netstat の出力を見て、接続の状態を確認します (xxxx を置き換えます)。 RDS インスタンスの実際の IP アドレスを使用):
netstat -an | grep x.x.x.x
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 をデフォルトに戻し、さらなるトラブルシューティングのために AWS サポートに連絡してください。
どうやら、マルチ AZ はすべてを台無しにします。デフォルトのマルチ AZ 設定では、データベースがリージョン us-east-1d に配置され、EC2 インスタンスがリージョン us-east-1a に配置されていたため、DNS が正しくルーティングされていませんでした。RDS インスタンスを非マルチ AZ として再作成し、us-east-1a でライブにしました。すべて問題ありません。
RDS、ELB、およびマルチ AZ 機能を備えた AWS での DNS ルーティングに関して超天才がいる場合、これを行う方法を知っていることは非常に素晴らしいことです。なぜなら、これはアマゾン ウェブ サービスのドキュメントのどこにも記載されていないからです。 .