OK、3つのアプリサーバーとRDSのPostgresのインスタンスを備えたVPCがあります。
「app-elb-staging」というセキュリティグループからのポート5432でのインバウンド接続を許可する「rds-staging」というセキュリティグループがあります。
'app-elb-staging'は、すべてのEC2インスタンスに適用されるセキュリティグループであり、発信トラフィックがどこにでも移動できるようにします。
RDSインスタンスはAZus-east-1eにあります。 us-east-1e(10.0.3。*)のEC2インスタンスからは接続できますが、us-east-1a(10.0.1。*)またはus-east-1c(10.0)のEC2インスタンスからは接続できません。 .2。*):
deploy@ip-10-0-3-220:~$ nc -zv xxx.us-east-1.rds.amazonaws.com 5432
Connection to xxx.us-east-1.rds.amazonaws.com 5432 port [tcp/postgresql] succeeded!
deploy@ip-10-0-1-155:~$ nc -zv xxx.us-east-1.rds.amazonaws.com 5432
nc: connect to xxx.us-east-1.rds.amazonaws.com port 5432 (tcp) failed: No route to Host
deploy@ip-10-0-2-90:~$ nc -zv xxx.us-east-1.rds.amazonaws.com 5432
nc: connect to xxx.us-east-1.rds.amazonaws.com port 5432 (tcp) failed: No route to Host
誰かがこれを見たことがありますか? DNSを確認しましたが、各マシンはホスト名を同じIP(10.0.3.x)に解決しています。
OK、ついにこの問題の根本原因を突き止めました。私が使用していたAMIは、サブネットのIPと衝突するために接続の問題を引き起こすブリッジを作成していました。影響を受けるインスタンスでは、Sudo route -n
からの出力は次のようになりました。
ubuntu@ip-10-0-1-92:~$ Sudo route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.1.1 0.0.0.0 UG 0 0 0 eth0
10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 lxcbr0
10.0.2。*への接続はすべて失敗します。
deploy@ip-10-0-1-92:~$ nc -zv 10.0.2.53 22
nc: connect to 10.0.2.53 port 22 (tcp) failed: No route to Host
Sudo ifconfig lxcbr0 down
でブリッジを削除すると問題は解決しましたが、そもそもこのブリッジを設定しないAMIを使用すると、ルートが修正されました。
私は2つの理由の1つによって引き起こされるこの種の問題を見てきました:
サブネットごとにルートを定義する必要はありません。ルートはテーブルに暗黙的に含まれています。 DNSエントリが他のAZインスタンスで解決されるIPアドレスを再確認すると、それがVPCにあることが確認されます。
ネットワークACLが機能する可能性がありますが、それらを設定する必要があります。デフォルトでは、それらは広く開かれています。これが私がそれをありそうもないとタグ付けした理由ですが、それはこのような問題を引き起こす可能性があります。とはいえ、「ホストへのルートがありません」というエラーは、これが問題ではないことを示唆しています。