別のアカウントの VPC に VPC ピアリング接続を介して通信できないのはなぜですか?

別のアカウントの VPC に VPC ピアリング接続を介して通信できないのはなぜですか?

私は2つのAmazon AWSアカウントを持っています。1つは有料のアカウントで、パブリックウェブサーバーをホストしています(「支払った」)と無料アカウント(「無料それぞれにAmazon Linuxを実行するEC2インスタンスが2つあり、それぞれが独自のVPCで重複のない単一のサブネットを持っています。アカウント間でファイルを簡単に転送できるようにしたいと考えていました。支払ったから無料そこで、VPC ピアリング接続について調べ、ガイドに正しく従って、VPC 間のピアリング接続を作成して受け入れ、セキュリティ グループを変更し、各 VPC でルートを設定して他の VPC のサブネットにアクセスしたと思います。

基本的な設定は次のとおりです。支払ったアカウント:

仮想通貨: 有料VPC

ピアリング接続とルート: 有料ピアリング接続とルート

セキュリティグループ: 有料セキュリティグループ

そして、こちらは同じ情報です無料アカウント:

仮想通貨: 無料のVPC

ピアリング接続とルート: 無料のピアリング接続とルート

セキュリティグループ: 無料のセキュリティグループ

私が見つけたのは、支払ったアカウントでは、無料アカウントのインスタンスに正常に ping を実行できます。

$ ip -f inet addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UP qlen 1000
    inet 10.0.0.12/24 brd 10.0.0.255 scope global eth0
       valid_lft forever preferred_lft forever
$ ping 172.31.30.44
PING 172.31.30.44 (172.31.30.44) 56(84) bytes of data.
64 bytes from 172.31.30.44: icmp_seq=1 ttl=255 time=0.722 ms

しかし、私は無料アカウントに支払ったアカウント:

$ ip -f inet addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UP group default qlen 1000
    inet 172.31.30.44/20 brd 172.31.31.255 scope global dynamic eth0
       valid_lft 3259sec preferred_lft 3259sec
$ ping 10.0.0.12
PING 10.0.0.12 (10.0.0.12) 56(84) bytes of data.
^C
--- 10.0.0.12 ping statistics ---
14 packets transmitted, 0 received, 100% packet loss, time 13308ms

この設定では、なぜホストにpingできないのか説明できますか?支払ったホストからのアカウント無料アカウント?

さらに情報を提供する必要がありますか (必要な場合は、どのような情報ですか)?

答え1

コメントでこの答えネットワークACLに関する無関係な質問支払ったアカウントのVPCで、AWSネットワークACLの使用をLinuxのiptablesコマンドに置き換えたと述べました。10年前にこれをセットアップしたとき、自分のサブネット外のプライベートアドレスと通信することは決して望んでいませんでした。そのため、172.16.0.0/12からの着信接続をドロップしていました。そのため、無料から支払ったただし、その逆はできません。iptables ブロックを削除すると、問題は解決します。

恥ずかしいですね!

関連情報