同じ AZ の同じアカウントに 2 つの EC2 インスタンスを作成しました。これらは異なるセキュリティ グループを使用します。インスタンス A が特定のポートでインスタンス B からの接続のみを受け入れるようにしたいと思います。
これらのインスタンスは VPC ではないと思いますが、確認方法がわかりません。セキュリティ グループを変更できなかったため、VPC ではないと思われます。
たとえば、セキュリティ グループでは、インスタンス AI がポートのルールを追加し、ソースにインスタンス B のパブリック IP /32 を使用しました。次に、インスタンス A のパブリック IP を使用してインスタンス B から接続しようとしましたが、接続の試行はすぐに失敗します。
各インスタンスのプライベート IP で同じ手順を試しました。何が足りないのでしょうか?
同様の質問に答える記事がこちらにありますが、VPC が関係しています。VPC (Amazon AWS) 内の EC2 インスタンスに接続できない。
両方のインスタンスは同じ VPC ID とサブネット ID を持ちます。
また、ソースをインスタンス B のセキュリティ グループに設定しようとしましたが、これも機能しませんでした。
私はこれを mysql で試しています。インスタンス B で実行されている mysql クライアントは、次のエラーですぐに失敗しました:
エラー 2003 (HY000): '54.xx.xx.xx' の MySQL サーバーに接続できません (113)
mysqld の設定に問題がないことを確認するために、ICMP エコー応答でも同じことを試しましたが、これも機能しませんでした。
編集 最初の回答のおかげで、これら 2 つのインスタンスが VPC で実行されていることを確認できました (VPC コンソールにアクセスして)。したがって、私の質問はリンクされた記事と非常に似ています。ただし、その場合の問題は、インスタンスがデフォルトのインスタンスではなかったため、適切なルートとサブネットが作成されていなかったことです。私の VPC の設定方法は次のとおりです。VPC はデフォルトで、ルート テーブルが関連付けられています。ルート テーブルは、VPC に関連付けられたサブネットに暗黙的に関連付けられています。ルート テーブルには単一のルートがあり、ターゲットは「ローカル」です。
これらはすべてデフォルトで作成されます。ドキュメントでは 2 つのインスタンスが相互に接続できるようにする必要があると理解しているからです。まだ何が足りないのでしょうか?
答え1
私は AWS テクニカル サポートの助けを借りてこの問題を解決しました。私のような将来の初心者のための情報は次のとおりです。
問題は、インスタンスBでiptablesが実行されていて、トラフィックを許可していなかったことです。EC2インスタンスには、セキュリティグループ（AWSコンソールで管理）とiptables（ホストで管理）の2つのレベルのファイアウォールがあることを知りました。iptablesを使用する理由は、たとえば次のとおりです。 https://wincent.com/wiki/IPtables の使用
ほとんどの場合、Amazon EC2 を実行するときに iptables などのホストレベルのファイアウォールの使用について心配する必要はありません。Amazon では、「セキュリティ グループ」内でインスタンスを実行できるためです。これは実質的に、外部からインスタンスへの接続を許可する接続を指定するために使用するファイアウォール ポリシーです。ただし、これは「ホワイトリスト」アプローチであり、実行中のインスタンスで「ブラックリスト」目的で使用するのは簡単ではありません。
私の場合はホストレベルのファイアウォールは必要ないので、iptables をオフにしました。
sudo service chkconfig stop
sudo chkconfig iptables off
この質問に投稿されたコメントに関連して私が得た結果をいくつか示します。
- プライベートIPでの接続は機能しました
- プライベートDNS名での接続が機能しました
- パブリックIPでの接続は機能しました
- パブリックEIPへの接続が機能しました
- パブリックDNSへの接続は機能しましたが、Chad Smithが回答で述べたように、DNSはプライベートこの名前のIP
別のインスタンスでこれが機能した理由は、そのインスタンスで使用したイメージが iptables を実行していなかったためです。イメージはそれぞれ異なります。この場合に使用したイメージは、iptables を使用して SSH 以外のすべての接続を禁止していました。
答え2
少し話題から外れますが、これがこの問題に関する唯一の検索結果です。
私たちも同様の問題を抱えていましたが、既存のインスタンスが再起動され、突然通信できなくなりました。セキュリティ グループにルールが多すぎることが判明したので、許可された通信をいくつか削除するだけで再開できました。ルールは API への自動呼び出しによって時間の経過とともに追加されるため、再起動前はまだ機能していました。
これが将来誰かの役に立つことを願っています。
答え3
実行中のインスタンスのセキュリティ設定を変更できない場合、インスタンスは VPC に起動されません。
VPCにないインスタンスでも、EC2は相互接続されたプライベートネットワークにインスタンスを起動します。そのため、プライベートIPアドレスインスタンス A のセキュリティ グループ内のインスタンス B の。
答え4
AWS には VPC インスタンスと非 VPC インスタンス用の別々のセキュリティ グループがあるため、VPC を使用しているかどうかを何らかの方法で確認する必要があります (VPC コンソールに移動して、インスタンスが表示されているかどうかを確認します)。次に、作成したセキュリティ グループが同じコンテキストにあることを確認します。次に、セキュリティ グループ A をセキュリティ グループ B に信頼できるものとして追加し、その逆も実行します。この方法では、2 つのホスト間のすべてのトラフィックを個別のポートで許可するだけです (これが意図したものだと思います)。