この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
VPCピアリングからAWS Transit Gatewayに切り替えたら通信できなくなったのだが
こんにちは、自称Transit Gatewayおじさんの のんピ(@non____97)です。
皆さんはTransit Gateway好きですか? 私は好きです。
以前の記事でVPCピアリングからAWS Transit Gatewayに切り替える方法を紹介しました。
今回、VPCピアリングからAWS Transit Gatewayに切り替えた際に、Transit Gatewayで接続したVPC上のEC2インスタンス間で通信できなくなる事象に遭遇しました。
原因はタイトルにある通り、「セキュリティグループのインバウンドルールでセキュリティグループIDを使って通信を制御していた」ためでした。具体的にどういった構成を取った時にこの事象が発生したのか紹介します。
いきなりまとめ
- VPCピアリングでVPC間を接続している場合はセキュリティグループIDで通信を制御できる
- AWS Transit GatewayでVPC間を接続している構成で、対向VPCのセキュリティグループIDを指定している場合に通信できない
検証してみた
VPCピアリングでVPC間を接続している場合
まず、VPCピアリングでVPC間を接続している構成で、セキュリティグループIDを用いて通信を制御できるか確認してみます。
構成は以下の通りです。各VPC上のEC2インスタンスにアタッチしているセキュリティグループのインバウンドルールで、対向のEC2インスタンスにアタッチしているセキュリティグループIDからのICMPを許可した状態で、互いにpingを実行します。
VPC AのEC2インスタンスのセキュリティグループのインバウンドルール
VPC BのEC2インスタンスのセキュリティグループのインバウンドルール
それぞれのpingの実行結果は以下の通りです。正常に全てのICMPパケットが到達できることが確認できました。
VPC AのEC2インスタンスからVPC BのEC2インスタンスへのping実行結果
# 自分のIPアドレス確認
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
link/ether 0e:05:15:2c:4b:ef brd ff:ff:ff:ff:ff:ff
inet 10.0.0.183/24 brd 10.0.0.255 scope global dynamic eth0
valid_lft 2030sec preferred_lft 2030sec
inet6 fe80::c05:15ff:fe2c:4bef/64 scope link
valid_lft forever preferred_lft forever
# VPC AのEC2インスタンスからVPC BのEC2インスタンスへping
$ ping 10.0.1.245 -c 4
PING 10.0.1.245 (10.0.1.245) 56(84) bytes of data.
64 bytes from 10.0.1.245: icmp_seq=1 ttl=64 time=0.825 ms
64 bytes from 10.0.1.245: icmp_seq=2 ttl=64 time=0.887 ms
64 bytes from 10.0.1.245: icmp_seq=3 ttl=64 time=0.846 ms
64 bytes from 10.0.1.245: icmp_seq=4 ttl=64 time=0.858 ms
--- 10.0.1.245 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3068ms
rtt min/avg/max/mdev = 0.825/0.854/0.887/0.022 msVPC BのEC2インスタンスからVPC AのEC2インスタンスへのping実行結果
# 自分のIPアドレス確認
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
link/ether 0a:4b:30:d9:62:73 brd ff:ff:ff:ff:ff:ff
inet 10.0.1.245/24 brd 10.0.1.255 scope global dynamic eth0
valid_lft 3272sec preferred_lft 3272sec
inet6 fe80::84b:30ff:fed9:6273/64 scope link
valid_lft forever preferred_lft forever
# VPC BのEC2インスタンスからVPC AのEC2インスタンスへping
$ ping 10.0.0.183 -c 4
PING 10.0.0.183 (10.0.0.183) 56(84) bytes of data.
64 bytes from 10.0.0.183: icmp_seq=1 ttl=64 time=0.891 ms
64 bytes from 10.0.0.183: icmp_seq=2 ttl=64 time=0.840 ms
64 bytes from 10.0.0.183: icmp_seq=3 ttl=64 time=0.855 ms
64 bytes from 10.0.0.183: icmp_seq=4 ttl=64 time=0.864 ms
--- 10.0.0.183 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3017ms
rtt min/avg/max/mdev = 0.840/0.862/0.891/0.034 ms片方のVPCをVPCピアリング、もう一方のVPCをTransit Gatewayで接続している場合
次に、片方のVPCをVPCピアリング、もう一方のVPCをTransit Gatewayで接続している構成で、セキュリティグループIDを用いて通信を制御できるか確認してみます。
構成は以下の通りです。先の検証と同じように各VPC上のEC2インスタンスにアタッチしているセキュリティグループのインバウンドルールで、対向のEC2インスタンスにアタッチしているセキュリティグループIDからのICMPを許可した状態で、互いにpingを実行します。
それぞれのpingの実行結果は以下の通りです。Transit Gatewayを通る「VPC A -> VPC B」の経路でICMPパケットが到達できなくなりました。どうやら通信がTransit Gatewayを通る構成で、対向VPCのセキュリティグループIDを指定している場合に通信できないようですね。
VPC AのEC2インスタンスからVPC BのEC2インスタンスへのping実行結果
# VPC AのEC2インスタンスからVPC BのEC2インスタンスへping
$ ping 10.0.1.245 -c 4
PING 10.0.1.245 (10.0.1.245) 56(84) bytes of data.
--- 10.0.1.245 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3075msVPC BのEC2インスタンスからVPC AのEC2インスタンスへのping実行結果
# VPC BのEC2インスタンスからVPC AのEC2インスタンスへping
$ ping 10.0.0.183 -c 4
PING 10.0.0.183 (10.0.0.183) 56(84) bytes of data.
64 bytes from 10.0.0.183: icmp_seq=1 ttl=63 time=1.41 ms
64 bytes from 10.0.0.183: icmp_seq=2 ttl=63 time=1.01 ms
64 bytes from 10.0.0.183: icmp_seq=3 ttl=63 time=1.25 ms
64 bytes from 10.0.0.183: icmp_seq=4 ttl=63 time=0.988 ms
--- 10.0.0.183 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 0.988/1.168/1.416/0.177 msTransit GatewayでVPC間を接続している場合
最後にTransit GatewayでVPC間を接続している構成で、セキュリティグループIDを用いて通信を制御できるか確認してみます。
構成は以下の通りです。同様に各VPC上のEC2インスタンスにアタッチしているセキュリティグループのインバウンドルールで、対向のEC2インスタンスにアタッチしているセキュリティグループIDからのICMPを許可した状態で、互いにpingを実行します。
それぞれのpingの実行結果は以下の通りです。やはり「VPC A -> VPC B」の経路に加えて「VPC B -> VPC A」の経路でも通信できなくなりました。
VPC AのEC2インスタンスからVPC BのEC2インスタンスへのping実行結果
# VPC AのEC2インスタンスからVPC BのEC2インスタンスへping
$ ping 10.0.1.245 -c 4
PING 10.0.1.245 (10.0.1.245) 56(84) bytes of data.
--- 10.0.1.245 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3067msVPC BのEC2インスタンスからVPC AのEC2インスタンスへのping実行結果
# VPC BのEC2インスタンスからVPC AのEC2インスタンスへping
$ ping 10.0.0.183 -c 4
PING 10.0.0.183 (10.0.0.183) 56(84) bytes of data.
--- 10.0.0.183 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3064ms以上の検証からTransit Gatewayを使用した構成では、互いのVPC上のセキュリティグループIDを使って通信を制御するように設計してはならないと判断できます。
VPCピアリングからAWS Transit Gatewayに切り替える場合はセキュリティグループのルールをチェックしよう
AWS Transit GatewayでVPC間を接続しているとセキュリティグループIDで通信を制御できない事象を紹介しました。
VPCピアリングからAWS Transit Gatewayを使った構成に変更する場合は、セキュリティグループのルールでTransit Gatewayを介して接続しているVPC上のセキュリティグループIDを使っていないかどうかを確認する必要があります。もし使用している場合は、セキュリティグループIDではなく、CIDRブロックやプレフィックスリストを使って制御する必要があります。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
4
