Cloud VPCを色々いじってみた #GoogleCloud

概要

GCPのサービスの一つであるCloud VPCを色々いじってみたので、その備忘録として実際に手を動かしたことをまとめていきます。
このまとめは、Cloud VPCについて勉強していたときにこの記事のわかりやすさに感化された自分が、実際にいろいろCloud VPCを使ってみたものです。なので説明部分で一部似通っている内容もありますがあしからず。

VPCの作成
vpc同士をVPCネットワークピアリングでつないでみる
推移的ピアリングができないことを確認してみる
内部IPが衝突するようなVPC同士でvpcピアリングをしてみる
vpc同士をCloud VPNでつないでみる
グローバル動的ルーティングを試す
推移的ピアリングができることを確認してみる

VPCの作成

サブネット作成モードにはカスタムと自動の2種類があります。
基本的に、VPCには一つ以上のサブネットを設定することができます。

カスタムモードの場合、自分でサブネットを設定します。
設定内容はリージョンとIPレンジで、IPレンジはもちろんプライベートIPの範囲を指定します。

自動モードを選択した場合、全リージョンにサブネットが自動生成されます。

これからいろいろ試していく上で以下のようにcustom-asia,custom-us,custom-europeの3つのVPCを作成しました。

custom-asiaだけサブネットを２つ作成しましたが、これは後でグローバル動的ルーティングを試すためあえて作成しています。

vpc同士をVPCネットワークピアリングでつないでみる

現状はどのVPCももちろんネットワークが形成されていないため互いに疎通ができません。そこで、VPC同士をVPCネットワークピアリングでつなぐと互いに内部IPで疎通することができるようになります。ということで、試しにcustom-asiaとcustom-usを疎通させてみます。

VPCネットワークピアリングについてはこちら

asia→usとus→asiaの２つのピアリングを作成しました。

２つの作成が完了すると、ステータスが有効になります。
試しに、各VPC上にインスタンスを生成して内部IPで疎通できるか確認してみます。

ちなみに自分でVPCを作成した場合、ファイアウォール設定がないのでsshやpingができない状態です。そのため、作成したVPCに22番ポートとicmpの許可をする設定を事前に追加しています。

instance-asia→instance-us

instance-asia:~$ ping 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=120 ms
64 bytes from 10.0.2.2: icmp_seq=2 ttl=64 time=120 ms
64 bytes from 10.0.2.2: icmp_seq=3 ttl=64 time=120 ms
64 bytes from 10.0.2.2: icmp_seq=4 ttl=64 time=120 ms
64 bytes from 10.0.2.2: icmp_seq=5 ttl=64 time=120 ms
64 bytes from 10.0.2.2: icmp_seq=6 ttl=64 time=120 ms
^C
--- 10.0.2.2 ping statistics ---
7 packets transmitted, 6 received, 0% packet loss, time 17ms
rtt min/avg/max/mdev = 119.528/119.594/119.666/0.323 ms

instance-us→instance-asia

instance-us:~$ ping 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=123 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=122 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=122 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=122 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=122 ms
64 bytes from 10.0.0.2: icmp_seq=6 ttl=64 time=122 ms
^C
--- 10.0.0.2 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 12ms
rtt min/avg/max/mdev = 122.061/122.271/123.063/0.538 ms

どちらも内部IPで疎通できることが確認できました。

推移的ピアリングができないことを確認してみる

VPCネットワークピアリングは推移的ピアリングはサポートされていなません。
図で表すと以下のようなイメージです。

今回は以下のような構築をしてこれを確かめてみたいと思います。
さきほどのピアリングを残して、新たにcustom-asiaとcustom-europeのピアリングを作成します。

インスタンスの情報は以下

custom-europe→custom-asiaはもちろん疎通できます。

instance-europe:~$ ping 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=259 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=258 ms
^C
--- 10.0.0.2 ping statistics ---
3 packets transmitted, 2 received, 33.3333% packet loss, time 5ms
rtt min/avg/max/mdev = 257.555/258.308/259.062/0.908 ms

しかし、custom-europe→custom-usはというと

instance-europe:~$ ping 10.0.2.2
PING 10.0.2.2 (10.0.2.2) 56(84) bytes of data.
^C
--- 10.0.2.2 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 114ms

確かに疎通できないことが確認できました。

内部IPが衝突するようなVPC同士でvpcピアリングをしてみる

VPCネットワークピアリングは、ピアリングする２つのVPCのサブネットの内部IPが衝突している場合は作成できないらしいので、その確認をしてみます。
試しに、custom-usにcustom-asiaと衝突するように10.0.0.0/29のサブネットを追加してみます。

subnet-conflictをcustom-usに作成しました。

VPCネットワークピアリングしてみると

10.0.0.0/29が衝突してるため作成できないことが確認できました。

vpc同士をCloud VPNでつないでみる

vpc同士をCloud VPNで疎通させることもできます。しかし、

VPCネットワークピアリングよりも管理・作成にコストがかかる
VPCネットワークピアリングと違って公共のネットワークを利用する(IPsec VPN)

以上の理由から、Cloud VPN同士の疎通の場合はVPCネットワークピアリングが推奨されてます。
なので一般的にはオンプレミス環境や他プロバイダのVPCとCloud VPCをつなぐものとして利用するのが適切なサービスとなりますが、後述するメリットもありますので実際に構築してみます。

Cloud VPNについてはこちら

今回は試しに作ってみるだけなので、HA構成ではなくClassic構成で作成します。

ここから先の作成方法はこの記事に詳しく載ってますのでここでは割愛します。

というわけでcustom-asia/asia-northeast←→custom-europe/europe-northのVPNを作成しました。

実際に疎通確認してみると

instance-asia:~$ ping 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=62 time=260 ms
64 bytes from 10.0.3.2: icmp_seq=2 ttl=62 time=257 ms
64 bytes from 10.0.3.2: icmp_seq=3 ttl=62 time=257 ms
^C
--- 10.0.3.2 ping statistics ---
4 packets transmitted, 3 received, 25% packet loss, time 4ms
rtt min/avg/max/mdev = 257.054/257.956/259.645/1.330 ms

instance-europe:~$ ping 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=260 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=62 time=257 ms
^C
--- 10.0.0.2 ping statistics ---
3 packets transmitted, 2 received, 33.3333% packet loss, time 5ms
rtt min/avg/max/mdev = 257.115/258.422/259.730/1.402 ms

互いに問題なく疎通ができました。

先程しれっとcustom-asiaのasia-eastのサブネットにもインスタンスを作成しましたので、そのインスタンスとeuropeの疎通ができるか確認してみます。

instance-asia-2:~$ ping 10.0.3.2
PING 10.0.3.2 (10.0.3.2) 56(84) bytes of data.
^C
--- 10.0.3.2 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 33ms

先ほど作成したVPNはasia-northeastとeeurope-northのトンネルなのでasia-eastに作成したインスタンスとは疎通はできません。ただ、後述するグローバル動的ルーティングをオンにするとそれができるようになります。

グローバル動的ルーティングを試す

custom-asiaにグローバル動的ルーティングをオンにすると、Cloud RouterがVPCのネットワーク全体をアドバタイズするようになるので、asia-east←→europe-northの疎通もできるようになるはずなので試してみます。
グローバル動的ルーティングについてはこちら

変更内容はこの部分だけです。
VPN作成時に、使用可能なすべてのサブネットをアドバタイズするように設定していれば、勝手にコンソールにも反映されるようになります。

グローバル動的ルーティングがオフの時

グローバル動的ルーティングがオンになった後

asia-east←→europe-northが疎通できるか確認してみます。

instance-asia-2:~$ ping 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=62 time=295 ms
64 bytes from 10.0.3.2: icmp_seq=2 ttl=62 time=292 ms
64 bytes from 10.0.3.2: icmp_seq=3 ttl=62 time=292 ms
^C
--- 10.0.3.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 292.264/293.142/294.775/1.313 ms

instance-europe:~$ ping 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=295 ms
64 bytes from 10.0.1.2: icmp_seq=2 ttl=62 time=292 ms
64 bytes from 10.0.1.2: icmp_seq=3 ttl=62 time=292 ms
^C
--- 10.0.1.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 292.277/293.267/295.118/1.451 ms

双方向で疎通できました。

Cloud VPNで推移的ピアリングができることを確認してみる

※設定してみてもどうもうまくいかなかったので、あまり参考にしないほうが良いかもです。
ここがgcpのvpc同士をCloud VPNで接続するメリットらしいです。Cloud VPNで疎通させると推移的ピアリングが可能になるため、スター型のネットワークを構築することで、離れているVPC同士でも疎通ができるようになります。メッシュ状にピアリングを張り巡らせなければいけないVPCネットワークピアリングよりもラクに作成できます。

パブリックIPを隠してるので分かりづらいかもしれませんが、

custom-asia←→custom-europe
custom-asia←→custom-us

の２つのVPNが張られている状態で、それぞれにVPNトンネルがあります。

asiaからそれぞれus,europeに向いてるトンネルは一つのCloud Routerから伸びていて、本来であればこの時点でcustom-europe←→custom-us の疎通ができるはずなのですが自分はこれができず、詰まってしまいました。わかる方いましたら教えていただきたいです。

まとめ

共有VPCについても触れたかったのですが、組織の作成がシュッとできるものではなかったのでパスしてます。
個人開発ではVPC周りはなかなか触れない箇所なので一通りやってみて結構面白かったです。
家のネットワークとVPNでつないで色々やってみたいなぁ。