はじめに
フューチャーAdvent Calendar 2022の21日目担当の筋肉エンジニアの渡邉です。年末にかけて爆食しまくっていまして腹筋が見る影もなくなっています・・・
今まで私はパブリッククラウドはAWSを主に利用してきましたが、今年下半期からGoogle Cloudを利用しているプロジェクトに参画しています。主にネットワーク関係の業務を行なってきましたのでその中でVPC同士の接続（VPCネットワークピアリングとHA VPN）に焦点を当てて実際にVM間の疎通を実施した結果や挙動などをまとめて行こうと思います。
本記事はGoogle Cloudのネットワークの基礎をある程度理解している方向けになっております。
全体図
本記事で登場するGoogle Cloudのプロジェクトとネットワーク、VMの構成になります。
構築自体は筆者が使い慣れているTerraformで構築しております。
AWSと異なり、Google CloudではVPCはCIDR範囲の指定もなく箱のような役割をし、サブネットのみCIDR範囲とどのリージョンに配置するかを指定します。
内部インターネットの全てのVM同士が疎通できるようにすべてのプロジェクトでfirewallはソースIPレンジ：10.0.0.0/8からのtcp/udp/icmpのプロトコルを許可しています。
| プロジェクト名 | サブネット名 | リージョン | CIDRレンジ | VM名 | IPアドレス |
|---|---|---|---|---|---|
| test-network-project01 | tky-subnet01 | 東京 | 10.0.0.0/24 | test-tky-vm01 | 10.0.0.2 |
| test-network-project01 | vir-subnet01 | 北バージニア | 10.0.1.0/24 | test-vir-vm01 | 10.0.1.2 |
| test-network-project02 | tky-subnet02 | 東京 | 10.0.2.0/24 | test-tky-vm02 | 10.0.2.2 |
| test-network-project02 | frk-subnet02 | フランクフルト | 10.0.3.0/24 | test-frk-vm02 | 10.0.3.2 |
| test-network-project03 | lon-subnet03 | ロンドン | 10.0.4.0/24 | test-lon-vm03 | 10.0.4.2 |
| test-network-project03 | sgp-subnet03 | シンガポール | 10.0.5.0/24 | test-sgp-vm03 | 10.0.5.2 |
同一VPC内でのVMの疎通確認
まず初めに、同一VPC内に存在するVM間の疎通を試してみましょう。
この同一VPC内でのVM間の疎通確認では、「test-network-project01」を利用しています。
東京リージョンのサブネット(tky-subnet01：10.0.0.0/24)に存在するtest-tky-vm01(10.0.0.2)から北バージニアリージョンのサブネット(vir-subnet01：10.0.1.0/24)に存在するtest-vir-vm01(10.0.1.2)に対して疎通確認を実施してみます。
xxxxxxxxxxxxxx@test-tky-vm01:~$ ping -c 5 10.0.1.2
PING 10.0.1.2 (10.0.1.2) 56(84) bytes of data.
64 bytes from 10.0.1.2: icmp_seq=1 ttl=64 time=145 ms
64 bytes from 10.0.1.2: icmp_seq=2 ttl=64 time=146 ms
64 bytes from 10.0.1.2: icmp_seq=3 ttl=64 time=146 ms
64 bytes from 10.0.1.2: icmp_seq=4 ttl=64 time=146 ms
64 bytes from 10.0.1.2: icmp_seq=5 ttl=64 time=146 ms
--- 10.0.1.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4008ms
rtt min/avg/max/mdev = 145.411/145.611/145.693/0.104 ms
疎通を確認することができました。
次に、北バージニアリージョンのサブネット(vir-subnet01：10.0.1.0/24)に存在するtest-vir-vm01(10.0.1.2)から東京リージョンのサブネット(tky-subnet01：10.0.0.0/24)に存在するtest-tky-vm01(10.0.0.2)に対して疎通確認を実施してみます。
xxxxxxxxxxxxxx@test-vir-vm01:~$ ping -c 5 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=144 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=146 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=146 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=146 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=146 ms
--- 10.0.0.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 144.445/145.600/145.951/0.579 ms
こちらも疎通を確認することができました。以下、サマリになります。
| 送信元プロジェクト名 | 送信元VM名 | 送信元IPアドレス | 送信先プロジェクト名 | 送信先VM名 | 送信先IPアドレス | 疎通確認 |
|---|---|---|---|---|---|---|
| test-network-project01 | test-tky-vm01 | 10.0.0.2 | test-network-project01 | test-vir-vm01 | 10.0.1.2 | ○ |
| test-network-project01 | test-vir-vm01 | 10.0.1.2 | test-network-project01 | test-tky-vm01 | 10.0.0.2 | ○ |
なぜ疎通ができたのか？
Google Cloudでは、VPC内にサブネットを作成した時点で、Google Cloud側によって自動的にサブネットルートが作成されます。
test-vpc01に、tky-subnet01(10.0.0.0/24)とvir-subnet01(10.0.1.0/24)のサブネットを
作成したタイミングでそれぞれのサブネットに定義したCIDRに対応するサブネットルートが作成されるため、同一VPC内に所属するtest-tky-vm01とtest-vir-vm01は互いに疎通することが可能になります。
VPC間でのVMの疎通確認
次に、異なるプロジェクトの異なるVPCに所属するVM間で疎通確認を実施してみます。
この疎通確認では、「test-network-project01のtest-vpc01」と「test-network-project02のtest-vpc02」を利用しています。
test-vpc01 -> test-vpc02への疎通確認
test-vpc01の東京リージョンのサブネット(tky-subnet01：10.0.0.0/24)に存在するtest-tky-vm01(10.0.0.2)からtest-vpc02の東京リージョンのサブネット(tky-subnet02：10.0.2.0/24)に存在するtest-tky-vm02(10.0.2.2)に対して疎通確認を実施してみます。
xxxxxxxxxxxxxx@test-tky-vm01:~$ ping -c 5 10.0.2.2
PING 10.0.2.2 (10.0.2.2) 56(84) bytes of data.
--- 10.0.2.2 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4073ms
タイムアウトしてしまいました。
次に、test-vpc01の東京リージョンのサブネット(tky-subnet01：10.0.0.0/24)に存在するtest-tky-vm01(10.0.0.2)からtest-vpc02のフランクフルトリージョンのサブネット(fkr-subnet02：10.0.3.0/24)に存在するtest-frk-vm02(10.0.3.2)に対して疎通確認を実施してみます。
xxxxxxxxxxxxxx@test-tky-vm01:~$ ping -c 5 10.0.3.2
PING 10.0.3.2 (10.0.3.2) 56(84) bytes of data.
--- 10.0.3.2 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4086ms
こちらもタイムアウトしてしまいました。
次に、test-vpc01の北バージニアリージョンのサブネット(vir-subnet01：10.0.1.0/24)に存在するtest-vir-vm01(10.0.1.2)からtest-vpc02の東京リージョンのサブネット(tky-subnet02：10.0.2.0/24)に存在するtest-tky-vm02(10.0.2.2)に対して疎通確認を実施してみます。
xxxxxxxxxxxxxx@test-vir-vm01:~$ ping -c 5 10.0.2.2
PING 10.0.2.2 (10.0.2.2) 56(84) bytes of data.
--- 10.0.2.2 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4080ms
こちらもタイムアウトしてしまいました。
次に、test-vpc01の北バージニアリージョンのサブネット(vir-subnet01：10.0.1.0/24)に存在するtest-vir-vm01(10.0.1.2)からtest-vpc02のフランクフルトリージョンのサブネット(frk-subnet02：10.0.3.0/24)に存在するtest-frk-vm02(10.0.3.2)に対して疎通確認を実施してみます。
xxxxxxxxxxxxxx@test-vir-vm01:~$ ping -c 5 10.0.3.2
PING 10.0.2.2 (10.0.2.2) 56(84) bytes of data.
--- 10.0.2.2 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4080ms
こちらもタイムアウトしてしまいました。
test-vpc02 -> test-vpc01への疎通確認
test-vpc02の東京リージョンのサブネット(tky-subnet02：10.0.2.0/24)に存在するtest-tky-vm02(10.0.2.2)からtest-vpc01の東京リージョンのサブネット(tky-subnet01：10.0.0.0/24)に存在するtest-tky-vm01(10.0.0.2)に対して疎通確認を実施してみます。
xxxxxxxxxxxxxx@test-tky-vm02:~$ ping -c 5 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
--- 10.0.0.2 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4089ms
タイムアウトしてしましました。
次に、test-vpc02の東京リージョンのサブネット(tky-subnet02：10.0.2.0/24)に存在するtest-tky-vm02(10.0.2.2)からtest-vpc01の北バージニアリージョンのサブネット(vir-subnet01：10.0.1.0/24)に存在するtest-vir-vm01(10.0.1.2)に対して疎通確認を実施してみます。
xxxxxxxxxxxxxx@test-tky-vm02:~$ ping -c 5 10.0.1.2
PING 10.0.1.2 (10.0.1.2) 56(84) bytes of data.
--- 10.0.1.2 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4103ms
こちらもタイムアウトしてしまいました。
次に、test-vpc02のフランクフルトリージョンのサブネット(frk-subnet02：10.0.3.0/24)に存在するtest-frk-vm02(10.0.3.2)からtest-vpc01の東京リージョンのサブネット(tky-subnet01：10.0.0.0/24)に存在するtest-tky-vm01(10.0.0.2)に対して疎通確認を実施してみます。
xxxxxxxxxxxxxx@test-frk-vm02:~$ ping -c 5 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
--- 10.0.0.2 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4102ms
こちらもタイムアウトしてしまいました。
次に、test-vpc02のフランクフルトリージョンのサブネット(frk-subnet02：10.0.3.0/24)に存在するtest-frk-vm02(10.0.3.2)からtest-vpc01の北バージニアリージョンのサブネット(vir-subnet01：10.0.1.0/24)に存在するtest-vir-vm01(10.0.1.2)に対して疎通確認を実施してみます。
xxxxxxxxxxxxxx@test-frk-vm02:~$ ping -c 5 10.0.1.2
PING 10.0.1.2 (10.0.1.2) 56(84) bytes of data.
--- 10.0.1.2 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4081ms
こちらもタイムアウトしてしまいました。
以下、サマリになります。
| 送信元プロジェクト名 | 送信元VM名 | 送信元IPアドレス | 送信先プロジェクト名 | 送信先VM名 | 送信先IPアドレス | 疎通確認 |
|---|---|---|---|---|---|---|
| test-network-project01 | test-tky-vm01 | 10.0.0.2 | test-network-project02 | test-tky-vm02 | 10.0.2.2 | × |
| test-network-project01 | test-tky-vm01 | 10.0.0.2 | test-network-project02 | test-frk-vm02 | 10.0.3.2 | × |
| test-network-project01 | test-vir-vm01 | 10.0.1.2 | test-network-project02 | test-tky-vm02 | 10.0.2.2 | × |
| test-network-project01 | test-vir-vm01 | 10.0.1.2 | test-network-project02 | test-frk-vm02 | 10.0.3.2 | × |
| test-network-project02 | test-tky-vm02 | 10.0.2.2 | test-network-project01 | test-tky-vm01 | 10.0.0.2 | × |
| test-network-project02 | test-tky-vm02 | 10.0.2.2 | test-network-project01 | test-vir-vm01 | 10.0.1.2 | × |
| test-network-project02 | test-frk-vm02 | 10.0.3.2 | test-network-project01 | test-tky-vm01 | 10.0.0.2 | × |
| test-network-project02 | test-frk-vm02 | 10.0.3.2 | test-network-project01 | test-vir-vm01 | 10.0.1.2 | × |
なぜ疎通ができなかったのか？
test-vpc01とtest-vpc02のそれぞれのルートを確認してみましょう。
test-vpc01のルート
test-vpc01のルートには、test-tky-vm02(10.0.2.2)、test-frk-vm02(10.0.3.2)が存在する10.0.2.0/24と10.0.3.0/24へのルートがありません。
ルートがない場合は通信が届くことはありませんので、疎通することはできません。
test-vpc02のルート
test-vpc02のルートには、test-tky-vm01(10.0.0.2)、test-vir-vm01(10.0.1.2)が存在する10.0.0.0/24と10.0.1.0/24へのルートがありません。
ルートがない場合は通信が届くことはありませんので、疎通することはできません。
VPCネットワークピアリング
現状それぞれのVPCには疎通を行いたいVMが存在するサブネットのルートを持っていないので、どうにかして疎通を行いたいVMが存在するサブネットのCIDRを自身のVPCのルートに追加して内部通信を実現したいです。
その時に利用するのがVPCネットワークピアリングです。
VPC ネットワーク ピアリングを使用すると、異なる VPC ネットワーク内のワークロードが内部で通信できるように、VPC ネットワークを接続できます。トラフィックは Google のネットワーク内に留まり、公共のインターネットを経由することはありません。
VPCネットワークピアリングは以下のメリットがあります。
- 内部通信のため、外部アドレスを使用するよりもネットワークレイテンシが低くなる
- 外部通信をしないためセキュリティが高い
- 内部通信のため、下り（外向き）通信コストがかかからない。
VPC Peeringを実施した時の構成図になります。
VPCネットワークピアリングをしてみる
VPCネットワークピアリングもTerraformで適用しました。
test-vpc01
test-vpc02とVPCネットワークピアリングをすることで、「インポート済みのルート」にtest-vpc02内のtky-subnet02(10.0.2.0/24)とfrk-subnet02(10.0.3.0/24)が追加されています。
test-vpc01のルートにもインポートしたtest-vpc02内のtky-subnet02(10.0.2.0/24)とfrk-subnet02(10.0.3.0/24)が追加されています。
test-vpc02
test-vpc01とVPCネットワークピアリングをすることで、「インポート済みのルート」にtest-vpc01内のtky-subnet01(10.0.0.0/24)とvir-subnet01(10.0.1.0/24)のが追加されています。
test-vpc02のルートにもインポートしたtest-vpc01内のtky-subnet01(10.0.0.0/24)とvir-subnet01(10.0.1.0/24)のが追加されています。
再度疎通をしてみる
それぞれのルートに疎通を行いたいVMが存在するサブネットルートが追加されたので再度疎通を実施してみます。
test-vpc01 -> test-vpc02への疎通確認
test-vpc01の東京リージョンのサブネット(tky-subnet01：10.0.0.0/24)に存在するtest-tky-vm01(10.0.0.2)からtest-vpc02の東京リージョンのサブネット(tky-subnet02：10.0.2.0/24)に存在するtest-tky-vm02(10.0.2.2)に対して疎通確認を実施してみます。
xxxxxxxxxxxxxx@test-tky-vm01:~$ ping -c 5 10.0.2.2
PING 10.0.2.2 (10.0.2.2) 56(84) bytes of data.
64 bytes from 10.0.2.2: icmp_seq=1 ttl=64 time=2.19 ms
64 bytes from 10.0.2.2: icmp_seq=2 ttl=64 time=0.286 ms
64 bytes from 10.0.2.2: icmp_seq=3 ttl=64 time=0.323 ms
64 bytes from 10.0.2.2: icmp_seq=4 ttl=64 time=0.339 ms
64 bytes from 10.0.2.2: icmp_seq=5 ttl=64 time=0.321 ms
--- 10.0.2.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4062ms
rtt min/avg/max/mdev = 0.286/0.691/2.189/0.748 ms
無事疎通することができました。
次に、test-vpc01の東京リージョンのサブネット(tky-subnet01：10.0.0.0/24)に存在するtest-tky-vm01(10.0.0.2)からtest-vpc02のフランクフルトリージョンのサブネット(fkr-subnet02：10.0.3.0/24)に存在するtest-frk-vm02(10.0.3.2)に対して疎通確認を実施してみます。
xxxxxxxxxxxxxx@test-tky-vm01:~$ ping -c 5 10.0.3.2
PING 10.0.3.2 (10.0.3.2) 56(84) bytes of data.
64 bytes from 10.0.3.2: icmp_seq=1 ttl=64 time=232 ms
64 bytes from 10.0.3.2: icmp_seq=2 ttl=64 time=229 ms
64 bytes from 10.0.3.2: icmp_seq=3 ttl=64 time=229 ms
64 bytes from 10.0.3.2: icmp_seq=4 ttl=64 time=229 ms
64 bytes from 10.0.3.2: icmp_seq=5 ttl=64 time=229 ms
--- 10.0.3.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 229.208/229.746/231.541/0.899 ms
こちらも無事疎通することができました。
次に、test-vpc01の北バージニアリージョンのサブネット(vir-subnet01：10.0.1.0/24)に存在するtest-vir-vm01(10.0.1.2)からtest-vpc02の東京リージョンのサブネット(tky-subnet02：10.0.2.0/24)に存在するtest-tky-vm02(10.0.2.2)に対して疎通確認を実施してみます。
xxxxxxxxxxxxxx@test-vir-vm01:~$ ping -c 5 10.0.2.2
PING 10.0.2.2 (10.0.2.2) 56(84) bytes of data.
64 bytes from 10.0.2.2: icmp_seq=1 ttl=64 time=145 ms
64 bytes from 10.0.2.2: icmp_seq=2 ttl=64 time=143 ms
64 bytes from 10.0.2.2: icmp_seq=3 ttl=64 time=144 ms
64 bytes from 10.0.2.2: icmp_seq=4 ttl=64 time=143 ms
64 bytes from 10.0.2.2: icmp_seq=5 ttl=64 time=143 ms
--- 10.0.2.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 143.422/143.765/144.942/0.589 ms
こちらも無事疎通することができました。
次に、test-vpc01の北バージニアリージョンのサブネット(vir-subnet01：10.0.1.0/24)に存在するtest-vir-vm01(10.0.1.2)からtest-vpc02のフランクフルトリージョンのサブネット(frk-subnet02：10.0.3.0/24)に存在するtest-frk-vm02(10.0.3.2)に対して疎通確認を実施してみます。
xxxxxxxxxxxxxx@test-vir-vm01:~$ ping -c 5 10.0.3.2
PING 10.0.3.2 (10.0.3.2) 56(84) bytes of data.
64 bytes from 10.0.3.2: icmp_seq=1 ttl=64 time=89.1 ms
64 bytes from 10.0.3.2: icmp_seq=2 ttl=64 time=87.0 ms
64 bytes from 10.0.3.2: icmp_seq=3 ttl=64 time=87.0 ms
64 bytes from 10.0.3.2: icmp_seq=4 ttl=64 time=86.9 ms
64 bytes from 10.0.3.2: icmp_seq=5 ttl=64 time=86.9 ms
--- 10.0.3.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 86.904/87.373/89.064/0.845 ms
こちらも無事疎通することができました。
test-vpc02 -> test-vpc01への疎通確認
test-vpc02の東京リージョンのサブネット(tky-subnet02：10.0.2.0/24)に存在するtest-tky-vm02(10.0.2.2)からtest-vpc01の東京リージョンのサブネット(tky-subnet01：10.0.0.0/24)に存在するtest-tky-vm01(10.0.0.2)に対して疎通確認を実施してみます。
xxxxxxxxxxxxxx@test-tky-vm02:~$ ping -c 5 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=1.73 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.423 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.341 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=0.311 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=0.314 ms
--- 10.0.0.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4070ms
rtt min/avg/max/mdev = 0.311/0.624/1.734/0.556 ms
無事疎通することができました。
次に、test-vpc02の東京リージョンのサブネット(tky-subnet02：10.0.2.0/24)に存在するtest-tky-vm02(10.0.2.2)からtest-vpc01の北バージニアリージョンのサブネット(vir-subnet01：10.0.1.0/24)に存在するtest-vir-vm01(10.0.1.2)に対して疎通確認を実施してみます。
xxxxxxxxxxxxxx@test-tky-vm02:~$ ping -c 5 10.0.1.2
PING 10.0.1.2 (10.0.1.2) 56(84) bytes of data.
64 bytes from 10.0.1.2: icmp_seq=1 ttl=64 time=146 ms
64 bytes from 10.0.1.2: icmp_seq=2 ttl=64 time=144 ms
64 bytes from 10.0.1.2: icmp_seq=3 ttl=64 time=143 ms
64 bytes from 10.0.1.2: icmp_seq=4 ttl=64 time=143 ms
64 bytes from 10.0.1.2: icmp_seq=5 ttl=64 time=143 ms
--- 10.0.1.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 143.467/143.907/145.579/0.836 ms
こちらも無事疎通することができました。
次に、test-vpc02のフランクフルトリージョンのサブネット(frk-subnet02：10.0.3.0/24)に存在するtest-frk-vm02(10.0.3.2)からtest-vpc01の東京リージョンのサブネット(tky-subnet01：10.0.0.0/24)に存在するtest-tky-vm01(10.0.0.2)に対して疎通確認を実施してみます。
xxxxxxxxxxxxxx@test-frk-vm02:~$ ping -c 5 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=230 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=229 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=229 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=229 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=229 ms
--- 10.0.0.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 229.146/229.384/230.108/0.365 ms
こちらも無事疎通することができました。
次に、test-vpc02のフランクフルトリージョンのサブネット(frk-subnet02：10.0.3.0/24)に存在するtest-frk-vm02(10.0.3.2)からtest-vpc01の北バージニアリージョンのサブネット(vir-subnet01：10.0.1.0/24)に存在するtest-vir-vm01(10.0.1.2)に対して疎通確認を実施してみます。
xxxxxxxxxxxxxx@test-frk-vm02:~$ ping -c 5 10.0.1.2
PING 10.0.1.2 (10.0.1.2) 56(84) bytes of data.
64 bytes from 10.0.1.2: icmp_seq=1 ttl=64 time=89.5 ms
64 bytes from 10.0.1.2: icmp_seq=2 ttl=64 time=86.9 ms
64 bytes from 10.0.1.2: icmp_seq=3 ttl=64 time=86.9 ms
64 bytes from 10.0.1.2: icmp_seq=4 ttl=64 time=87.0 ms
64 bytes from 10.0.1.2: icmp_seq=5 ttl=64 time=87.0 ms
--- 10.0.1.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 86.874/87.450/89.530/1.041 ms
こちらも無事疎通することができました。
よってVPCネットワークピアリングにより、それぞれのVPCのルートに接続したいVMが所属するサブネットルートが追加されたため無事疎通を確認することができました。
以下、サマリです。
| 送信元プロジェクト名 | 送信元VM名 | 送信元IPアドレス | 送信先プロジェクト名 | 送信先VM名 | 送信先IPアドレス | 疎通確認 |
|---|---|---|---|---|---|---|
| test-network-project01 | test-tky-vm01 | 10.0.0.2 | test-network-project02 | test-tky-vm02 | 10.0.2.2 | ○ |
| test-network-project01 | test-tky-vm01 | 10.0.0.2 | test-network-project02 | test-frk-vm02 | 10.0.3.2 | ○ |
| test-network-project01 | test-vir-vm01 | 10.0.1.2 | test-network-project02 | test-tky-vm02 | 10.0.2.2 | ○ |
| test-network-project01 | test-vir-vm01 | 10.0.1.2 | test-network-project02 | test-frk-vm02 | 10.0.3.2 | ○ |
| test-network-project02 | test-tky-vm02 | 10.0.2.2 | test-network-project01 | test-tky-vm01 | 10.0.0.2 | ○ |
| test-network-project02 | test-tky-vm02 | 10.0.2.2 | test-network-project01 | test-vir-vm01 | 10.0.1.2 | ○ |
| test-network-project02 | test-frk-vm02 | 10.0.3.2 | test-network-project01 | test-tky-vm01 | 10.0.0.2 | ○ |
| test-network-project02 | test-frk-vm02 | 10.0.3.2 | test-network-project01 | test-vir-vm01 | 10.0.1.2 | ○ |
VPCネットワークピアリングでの制限
VPCネットワークピアリングは以下の構成のような制限があります。
- 推移的ピアリングでは通信することができない（あるVPCを跨いで、別のVPCと接続できない）。
- VPCネットワークピアリング1:1のダイレクトピアリングのみしかサポートされていないので、3つ以上のVPCと接続するにはフルメッシュで接続する必要がある。
- 接続するVPC内のCIDR範囲が重複してはいけない。
推移的ピアリングの構成では、test-vpc01のルートにtest-vpc03のサブネットのCIDR範囲は広報されていなく、test-vpc03のルートにtest-vpc01のサブネットのCIDR範囲も広報されていないため、test-vpc01とtest-vpc03は互いに通信することができない。
推移的ピアリングの構成ではなく、フルメッシュ構成（test-vpc01とtest-vpc03間でVPCネットワークピアリング）を実施すれば、互いに通信することは可能であるが、今回はVPCネットワークピアリングではなく、HA VPN接続を利用してtest-vpc01とtest-vpc03間の通信を実現してみようと思います。
HA VPNでの接続
HA VPN
HA VPNはIPsec VPN接続を利用して、GCP内のVPC同士や、GCP内のVPCをオンプレミス同士、GCP内のVPCとAWS内のVPCなどと接続できるサービスです。IPsecを利用しているため、インターネット上の通信は暗号化されています。HAはHigh Availabilityの略で、2本のVPNトンネル（SLA99.9%）か4本のVPNトンネル（SLA99.99%）かで構成されています。
HA VPNとVPCネットワークピアリングでの構成
test-vpc01とtest-vpc02をHA VPNで接続し、test-vpc02とtest-vpc03をVPCネットワークピアリングで接続した時の構成になります。
各VPCでの設定値について記載します。
test-vpc01
HA VPNゲートウェイ
test-vpc02とHA VPN接続を実現するために、test-vpc01にHA VPNゲートウェイを作成します。
HA VPNゲートウェイは特定のリージョン内のIPsec VPN接続を実現するために特定のリージョンを指定する必要があります。今回は、「asia-northeast1」を指定して構築します。
HA VPN Tunnel
test-vpc02とHA VPN接続を実現するために、test-vpc01にHA VPNゲートウェイで使用するVPNトンネルを2つ構築します。
VPNトンネルでは、接続先(test-vpc02)のVPNゲートウェイのパブリックIPアドレスや、Cloud Router、BGPセッションなどトンネリングに必要な情報や、暗号化の設定を行います。
Cloud Router
Cloud Routerでは、test-vpc02へ自身のサブネットルート(10.0.0.0/24, 10.0.1.0/24)を広報するように設定しています。この設定により、test-vpc02のルートにtest-vpc01のサブネットルート(10.0.0.0/24, 10.0.1.0/24)が追加されます。また、test-vpc02とのBGPセッションの確立を行います。
BGPセッションの確立では、接続先（test-vpc02）のCloud RouterのASNや、ピアBGPIP設定などを行い接続設定をしていきます。
test-vpc02
HA VPNゲートウェイ
test-vpc01とHA VPN接続を実現するために、test-vpc02にHA VPNゲートウェイを作成します。
こちらも、HA VPNゲートウェイは特定のリージョン内のIPsec VPN接続を実現するために特定のリージョンを指定する必要があります。test-vpc01と同様に、「asia-northeast1」を指定して構築します。
HA VPN Tunnel
test-vpc01とHA VPN接続を実現するために、test-vpc02にHA VPNゲートウェイで使用するVPNトンネルを2つ構築します。
VPNトンネルでは、接続先(test-vpc01)のVPNゲートウェイのパブリックIPアドレスや、Cloud Router、BGPセッションなどトンネリングに必要な情報や、暗号化の設定を行います。
test-vpc01で作成したVPN Tunnel（ha-vpn-test-vpc01-tky-tunnel-0/ha-vpn-test-vpc01-tky-tunnel-1）とtest-vpc02で作成したVPN Tunnel（ha-vpn-test-vpc02-tky-tunnel-0/ha-vpn-test-vpc02-tky-tunnel-1）がそれぞれ対応してVPN Tunnelを構成します。
Cloud Router
Cloud Routerでは、test-vpc01へ自身のサブネットルート(10.0.2.0/24, 10.0.3.0/24)を広報するように設定しています。この設定により、test-vpc02のルートにtest-vpc01のサブネットルート(10.0.2.0/24, 10.0.3.0/24)が追加されます。また、test-vpc01とtest-vpc03間でも接続できるようにしたいので、test-vpc03のサブネットルート(10.0.4.0/24, 10.0.5.0/24) もtest-vpc01へ広報します。test-vpc01とのBGPセッションの確立を行います。
BGPセッションの確立では、接続先（test-vpc01）のCloud RouterのASNや、ピアBGPIP設定などを行い接続設定をしていきます。
各VPCのルート
test-vpc01
test-vpc02とHA VPN接続を行なったことにより、test-vpc02のサブネット（10.0.2.0/24,10.0.3.0/24）とtest-vpc03のサブネットルート(10.0.4.0/24, 10.0.5.0/24)が追加されていることがわかります。
これにより、test-vpc01からtest-vpc02とtest-vpc03へ通信が行えることになりました。
test-vpc02
test-vpc01とHA VPN接続を行なったことにより、test-vpc01のサブネット（10.0.0.0/24,10.0.1.0/24）とtest-vpc03とVPCネットワークピアリングを行ったことにより、test-vpc03のサブネットルート(10.0.4.0/24, 10.0.5.0/24)が追加されていることがわかります。
これにより、test-vpc02からtest-vpc01とtest-vpc03へ通信が行えることになりました。
test-vpc03
test-vpc02とVPCネットワークピアリングを行なったことにより、test-vpc02のサブネットルート(10.0.2.0/24, 10.0.3.0/24)が追加されていることがわかります。また、VPCネットワークピアリングの詳細を見ると、test-vpc02のVPCネットワークピアリングの設定のカスタムルートの交換の設定を「カスタムルートのエクスポート」に変更したため、test-vpc01のCloud Routerから広報されてきたCIDR(10.0.0.0/24, 10.0.1.0/24)をtest-vpc03に広報します。
また、test-vpc03のVPCネットワークピアリングの設定のカスタムルートの交換の設定を「カスタムルートのインポート」に変更したため、test-vpc03はtest-vpc02のCloud Routerがtest-vpc01のCloud Routerから受け取ったルート（10.0.0.0/24,10.0.1.0/24）をインポートしていることがわかります。これにより、test-vpc03からtest-vpc01とtest-vpc02へ通信が行えることになりました。
疎通確認の実施
各VPCにそれぞれの接続先のルートが追加されたので、最後にtest-vpc01からtest-vpc03、test-vpc03からtest-vpc01の疎通確認を実施してみましょう。
test-vpc01からtest-vpc03への疎通確認
test-vpc01の東京リージョンのサブネット(tky-subnet01：10.0.0.0/24)に存在するtest-tky-vm01(10.0.0.2)からtest-vpc03のロンドンリージョンのサブネット(lon-subnet03：10.0.4.0/24)に存在するtest-lon-vm03(10.0.4.2)に対して疎通確認を実施してみます。
xxxxxxxxxxxxxx@test-tky-vm01:~$ ping -c 5 10.0.4.2
PING 10.0.4.2 (10.0.4.2) 56(84) bytes of data.
64 bytes from 10.0.4.2: icmp_seq=1 ttl=62 time=224 ms
64 bytes from 10.0.4.2: icmp_seq=2 ttl=62 time=218 ms
64 bytes from 10.0.4.2: icmp_seq=3 ttl=62 time=218 ms
64 bytes from 10.0.4.2: icmp_seq=4 ttl=62 time=218 ms
64 bytes from 10.0.4.2: icmp_seq=5 ttl=62 time=218 ms
--- 10.0.4.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 217.915/219.258/224.251/2.497 ms
無事疎通することができました。
次に、test-vpc01の東京リージョンのサブネット(tky-subnet01：10.0.0.0/24)に存在するtest-tky-vm01(10.0.0.2)からtest-vpc03のシンガポールリージョンのサブネット(sgp-subnet03：10.0.5.0/24)に存在するtest-sgp-vm03(10.0.5.2)に対して疎通確認を実施してみます。
xxxxxxxxxxxxxx@test-tky-vm01:~$ ping -c 5 10.0.5.2
PING 10.0.5.2 (10.0.5.2) 56(84) bytes of data.
64 bytes from 10.0.5.2: icmp_seq=1 ttl=62 time=87.3 ms
64 bytes from 10.0.5.2: icmp_seq=2 ttl=62 time=78.8 ms
64 bytes from 10.0.5.2: icmp_seq=3 ttl=62 time=78.4 ms
64 bytes from 10.0.5.2: icmp_seq=4 ttl=62 time=78.3 ms
64 bytes from 10.0.5.2: icmp_seq=5 ttl=62 time=78.3 ms
--- 10.0.5.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 78.285/80.230/87.338/3.558 ms
こちらも無事疎通することができました。
次に、test-vpc01の北バージニアリージョンのサブネット(vir-subnet01：10.0.1.0/24)に存在するtest-vir-vm01(10.0.1.2)からtest-vpc03のロンドンリージョンのサブネット(lon-subnet03：10.0.4.0/24)に存在するtest-lon-vm03(10.0.4.2)に対して疎通確認を実施してみます。
xxxxxxxxxxxxxx@test-vir-vm01:~$ ping -c 5 10.0.4.2
PING 10.0.4.2 (10.0.4.2) 56(84) bytes of data.
64 bytes from 10.0.4.2: icmp_seq=1 ttl=62 time=365 ms
64 bytes from 10.0.4.2: icmp_seq=2 ttl=62 time=361 ms
64 bytes from 10.0.4.2: icmp_seq=3 ttl=62 time=361 ms
64 bytes from 10.0.4.2: icmp_seq=4 ttl=62 time=361 ms
64 bytes from 10.0.4.2: icmp_seq=5 ttl=62 time=361 ms
--- 10.0.4.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 361.241/362.055/365.151/1.547 ms
こちらも無事疎通することができました。
次に、test-vpc01の北バージニアリージョンのサブネット(vir-subnet01：10.0.1.0/24)に存在するtest-vir-vm01(10.0.1.2)からtest-vpc03のシンガポールリージョンのサブネット(sgp-subnet03：10.0.5.0/24)に存在するtest-sgp-vm03(10.0.5.2)に対して疎通確認を実施してみます。
xxxxxxxxxxxxxx@test-vir-vm01:~$ ping -c 5 10.0.5.2
PING 10.0.5.2 (10.0.5.2) 56(84) bytes of data.
64 bytes from 10.0.5.2: icmp_seq=1 ttl=62 time=232 ms
64 bytes from 10.0.5.2: icmp_seq=2 ttl=62 time=228 ms
64 bytes from 10.0.5.2: icmp_seq=3 ttl=62 time=228 ms
64 bytes from 10.0.5.2: icmp_seq=4 ttl=62 time=228 ms
64 bytes from 10.0.5.2: icmp_seq=5 ttl=62 time=228 ms
--- 10.0.5.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 227.993/228.867/231.931/1.533 ms
こちらも無事疎通することができました。
test-vpc03からtest-vpc01への疎通確認
test-vpc03のロンドンリージョンのサブネット(lon-subnet03：10.0.4.0/24)に存在するtest-lon-vm03(10.0.4.2)からtest-vpc01の東京リージョンのサブネット(tky-subnet01：10.0.0.0/24)に存在するtest-tky-vm01(10.0.0.2)に対して疎通確認を実施してみます。
xxxxxxxxxxxxxx@test-lon-vm03:~$ ping -c 5 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=62 time=224 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=62 time=216 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=62 time=216 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=62 time=216 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=62 time=216 ms
--- 10.0.0.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 216.305/217.810/223.688/2.938 ms
無事疎通することができました。
次に、test-vpc03のロンドンリージョンのサブネット(lon-subnet03：10.0.4.0/24)に存在するtest-lon-vm03(10.0.4.2)からtest-vpc01のバージニアリージョンのサブネット(vir-subnet01：10.0.1.0/24)に存在するtest-vir-vm01(10.0.1.2)に対して疎通確認を実施してみます。
xxxxxxxxxxxxxx@test-lon-vm03:~$ ping -c 5 10.0.1.2
PING 10.0.1.2 (10.0.1.2) 56(84) bytes of data.
64 bytes from 10.0.1.2: icmp_seq=1 ttl=62 time=363 ms
64 bytes from 10.0.1.2: icmp_seq=2 ttl=62 time=359 ms
64 bytes from 10.0.1.2: icmp_seq=3 ttl=62 time=359 ms
64 bytes from 10.0.1.2: icmp_seq=4 ttl=62 time=359 ms
64 bytes from 10.0.1.2: icmp_seq=5 ttl=62 time=359 ms
--- 10.0.1.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 358.627/359.565/363.064/1.750 ms
こちらも無事疎通することができました。
次に、test-vpc03のシンガポールリージョンのサブネット(sgp-subnet03：10.0.5.0/24)に存在するtest-sgp-vm03(10.0.5.2)からtest-vpc01の東京リージョンのサブネット(tky-subnet01：10.0.0.0/24)に存在するtest-tky-vm01(10.0.0.2)に対して疎通確認を実施してみます。
xxxxxxxxxxxxxx@test-sgp-vm03:~$ ping -c 5 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=62 time=76.4 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=62 time=77.9 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=62 time=77.9 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=62 time=77.8 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=62 time=77.9 ms
--- 10.0.0.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 76.417/77.585/77.939/0.585 ms
こちらも無事疎通することができました。
test-vpc03のシンガポールリージョンのサブネット(sgp-subnet03：10.0.5.0/24)に存在するtest-sgp-vm03(10.0.5.2)からtest-vpc01の北バージニアリージョンのサブネット(vir-subnet01：10.0.1.0/24)に存在するtest-vir-vm01(10.0.1.2)に対して疎通確認を実施してみます。
xxxxxxxxxxxxxx@test-sgp-vm03:~$ ping -c 5 10.0.1.2
PING 10.0.1.2 (10.0.1.2) 56(84) bytes of data.
64 bytes from 10.0.1.2: icmp_seq=1 ttl=62 time=221 ms
64 bytes from 10.0.1.2: icmp_seq=2 ttl=62 time=225 ms
64 bytes from 10.0.1.2: icmp_seq=3 ttl=62 time=225 ms
64 bytes from 10.0.1.2: icmp_seq=4 ttl=62 time=225 ms
64 bytes from 10.0.1.2: icmp_seq=5 ttl=62 time=225 ms
--- 10.0.1.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 220.935/224.428/225.417/1.748 ms
こちらも無事疎通することができました。
以下、サマリです。
| 送信元プロジェクト名 | 送信元VM名 | 送信元IPアドレス | 送信先プロジェクト名 | 送信先VM名 | 送信先IPアドレス | 疎通確認 |
|---|---|---|---|---|---|---|
| test-network-project01 | test-tky-vm01 | 10.0.0.2 | test-network-project03 | test-lon-vm03 | 10.0.4.2 | ○ |
| test-network-project01 | test-tky-vm01 | 10.0.0.2 | test-network-project03 | test-sgp-vm03 | 10.0.5.2 | ○ |
| test-network-project01 | test-vir-vm01 | 10.0.1.2 | test-network-project03 | test-lon-vm03 | 10.0.4.2 | ○ |
| test-network-project01 | test-vir-vm01 | 10.0.1.2 | test-network-project03 | test-sgp-vm03 | 10.0.5.2 | ○ |
| test-network-project03 | test-lon-vm03 | 10.0.4.2 | test-network-project01 | test-tky-vm01 | 10.0.0.2 | ○ |
| test-network-project03 | test-lon-vm03 | 10.0.4.2 | test-network-project01 | test-vir-vm01 | 10.0.1.2 | ○ |
| test-network-project03 | test-sgp-vm03 | 10.0.5.2 | test-network-project01 | test-tky-vm01 | 10.0.0.2 | ○ |
| test-network-project03 | test-sgp-vm03 | 10.0.5.2 | test-network-project01 | test-vir-vm01 | 10.0.1.2 | ○ |
最後に
今回は、Google Cloud内でのVPC同士の接続に焦点を当ててVM間での疎通確認を実施しました。VPC Peeringでの経路広報とHA VPNのCloud Routerを用いた経路広報の違いや、推移的ピアリングなどの制約事項など実際に手を動かして挙動を確認することができたのはいい経験になりました。また、AWSとGoogle Cloudではネットワークの考え方が違ったりして苦戦したところもありましたが、業務や今回の記事にまとめることで理解を深められた気がします。
皆さんもぜひ実際に手を動かしてGCP内でのネットワークについて理解を深めてみてください。
明日は@a_frchさんの記事になります。お楽しみに！！