🌐

Google CloudのVPCを基礎から始める

Seiji Ariga

2022/12/05に公開

こんにちは。Google Cloudのカスタマーエンジニアの有賀です。

この記事はGoogle Cloud Japan Advent Calendar 2022 の「今から始める Google Cloud」編の4日目の記事です。（3日目はTakayukiさんの「Cloud CDNのキャッシュと動的圧縮でコンテンツ配信のパフォーマンスを向上しよう」でした。）

本記事ではタイトルの通り、Google CloudのVPCの基礎的な内容をご紹介したいと思います。VPCを作ったり、ファイアウォールを設定したり、と Compute Engine VM を作れるようになるまでの下準備をします。（Compute Engineの話題は次の記事で取り上げられます。)

TL;DR

グローバルなVPCを設定できる。カッコイイ！マルチリージョン構成も簡単！
サブネットはリージョン単位。ゾーン単位ではない。
default VPCはちょっとしたお試し以外には不要。削除してもオッケー。
VMでIPv6も使える。パブリックIPだけじゃなくULA（プライベートIP相当）も使える。
ファイアウォールに2種類ある。ファイアウォールポリシーが新しい。
動的ルーティングはグローバルで問題ない。
プライベートサブネット/パブリックサブネットの区別はない。不要。

Virtual Private Cloud

VPCとはVirtual Private Cloudの略です。クラウドサービスの1つなのに「仮想的なプライベートクラウド」と言われても、個人的にはクラウドの中にクラウドを作るの？みたいなイメージになってしまいます。

ですが、何のことはない、実際には1つの隔離されたネットワークを作る、ということを意味してます。（だったらVirtual Private Networkの方が適当な気もしますが、それだとVPNとかぶってしまいますね。)

なお、Wikipediaの記事にはこんな風に書かれていました。パブリッククラウドの中に個別の環境（= プライベートクラウド）を作ってるんだ、と言われるとそんな感じもしますね。

このような分離レベルの導入により、仮想プライベートクラウドのユーザー（企業等）は実質的に（あたかもクラウドのインフラが他のユーザーと共有されていないかのような）「仮想的なプライベート」クラウドを使用していることとなるため、このサービスは「仮想プライベートクラウド」と呼ばれる。

Google CloudのVPC

まあ名前はさておき、Google CloudにおけるVPCは1つのネットワークを表すと思ってください。では、何はともあれVPCの画面を見てみましょう。Google Cloudの Cloud Console の左上の ≡ メニューから「VPCネットワーク - VPCネットワーク」を選びます。

VPCの画面

上のスクリーンショットからわかるように、個別のVPC自体は「VPCネットワーク」や、単に「ネットワーク」と呼ばれています。リソースの名前も「network」です。ただ「VPC」と呼ぶことも多いです。

余談：VPCのAPI

（上のリンク先のAPIリファレンスを見るとわかるように、VPC関連のAPIはCompute Engine APIの一部になってます。AWSでもEC2 APIの一部ですが、Azureではネットワークとして独立したAPIになってるようです。ちょっとした違いですが、考え方の違いが垣間見えます。）

また、このスクリーンショットには出ていないですが、Google Cloudを使い始めたばかりだと default という名前のネットワークがすでにできているかもしれません。default VPCはその名の通りデフォルトで作成されるVPCであり、サブネットの設定やファイアウォールの設定などの基本的な設定が済んでいるVPCです。とりあえずテストでVMを動かしてみたい、などの目的には最適ですが、設定が勝手におこなわれているという意味では、実際の利用にはあまり向いていません。ですので、実際の利用の際には自分でVPCを作成し、default VPCは不要であれば削除してしまいましょう。（名前が default という以外に特別なことはないので、必要になったら再作成すれば大丈夫です。）

なお、default VPCは通常、プロジェクト作成時に合わせて自動的に作成されます。しかし、本番環境などで使わないことが分かってる場合は「組織のポリシーの制約」という機能を使うと作成させないようにできます。（「デフォルトネットワークの作成をスキップ」という制約を設定してください。設定の仕方は「制約の仕様」を参照ください。）

VPCの作成

さて前置きが長くなってしまいましたが、さっそくVPCを作ってみましょう。「VPCネットワークの作成」をクリックします。いくつかの設定項目があるので、分割して見ていきます。

VPCの作成1
VPC作成の画面（その1）

まず名前を付けます。スクリーンショットにある通り小文字、数字、ハイフンだけが使えます。（大文字やアンダースコアは使えません。）

次に内部IPv6アドレスを使うか否かを 「VPCネットワークULAの内部IPv6範囲」 で設定します。ULAはUnique Local Addressのことで、IPv4のプライベートアドレス（RFC1918で規定）に相当します。VPCで内部IPv6を使いたい場合、つまりVM等に内部IPv6アドレスを付与したい場合は「有効」にします。（後で外部IPv6アドレスがでてきますが、外部IPv6アドレスだけを使う場合は、ここは「無効」でもかまいません。）

つぎにサブネットの設定ですが、初めに 「サブネット作成モード」 を選択します。サブネット作成モードには 「自動」 モードと 「カスタム」 モードがあります。「自動モード」では10.128.0.0/9の範囲から/20の単位で各リージョンに自動でサブネットを作成します。（default VPCではサブネットの設定が済んでると言いましたが、それは「自動」モードが設定されてるためです。）また「カスタムモード」ではユーザーがサブネットを手動で作ります。

通常クラウド内で使うIPアドレスはオンプレミスでのIPアドレスの管理と合わせておこなわれることが多く、アドレスの範囲が勝手に決まってしまう「自動」モードは通常の利用には向かないと思います。そのため 「カスタム」 モードを選択しましょう。

サブネット

では「カスタム」モードでサブネットを作成します。

サブネットの特徴

初めにサブネットの考え方を図で示します。Google CloudのVPCはグローバルに1つのVPCを作れます。そしてその中にサブネットをリージョン単位で作ります。

サブネットの考え方

つまり、VPCの中にはリージョンごとに複数のサブネットを作ることができ、それらのサブネットが全世界にまたがる大きな1つのルーターでつながってるようなものになります。（そしてルーターにはサブネットのアドレス範囲の先頭のIPアドレスが付与されるイメージです。）

ちなみに図の例の通り、VPC内のサブネットのアドレス範囲は自由に設定できます。VPC全体で1つのアドレス範囲があって、その中からサブネットに切り出す、みたいなことは不要です。

このようにVPCをグローバルに作れることで、マルチリージョンのシステムを簡単に作ることができます。たとえば、東京リージョンと大阪リージョンでDR（Disaster Recovery）の構成を組む場合でも、VPCを1つ作って東京リージョンと大阪リージョンにサブネットを作り、それぞれのサブネットに間で冗長関係にあるシステムを組むだけで済みます。

また、サブネットをリージョン単位で作れることにも利点があります。たとえばマルチリージョン構成までは不要でも、単一のリージョン内のゾーン間で冗長構成を作るのは一般的だと思います。その場合、サブネットはリージョン単位で作られるので、同一サブネット内でゾーンをまたがる冗長構成が作れます。（ゾーンごとにサブネットが必要だと、冗長構成を組むために最低2つのサブネットが必要になります）必要とされるサブネットが少なければIPアドレスの節約になりますし、そもそも構成もよりシンプルになります。

サブネットの作成

それでは実際にサブネットを設定します。

VPCの作成2
VPC作成の画面（その2 - サブネット）

各サブネットには、まず名前をつけます。

ちなみにちょっと直感に反するのですが、サブネットの名前はプロジェクト内で一意である必要があります。たとえばVPC "prod"とVPC "test"の両方に"tokyo-subnet1"みたいなサブネットを作りたくなる場合があると思いますが、これはエラーになります。これはサブネットの名前空間がVPC単位ではなく、プロジェクト単位だからです。（そういう意味でも、"prod"と"test"みたいな環境はプロジェクトを分けることをオススメします。）

サブネット作成時のエラー
サブネットの名前が重複した場合のエラー

次にサブネットを作るリージョンを選びます。（ゾーンを選ぶのではなくリージョンを選ぶのは先述の通りです。）

そしてIPスタックタイプをIPv4だけ（シングルスタック）にするか、IPv4とIPv6の両方（デュアルスタック）にするかを選びます。

デュアルスタックを選んだ場合は、さらにIPv6のアドレス範囲を外部（いわゆるグローバルアドレス）にするか内部（ULA）にするかを選びます。（「内部」を選ぶ場合は、先の「VPCネットワークULAの内部IPv6範囲」を「有効」にしておきます。）

外部か内部を選ぶということはつまり、VMに外部IPv6アドレスと内部IPv6アドレスの両方を付けることはできないということになります。IPv4では内部IPv4アドレスは必ず付いていて、外部IPv4アドレスを付けるかどうかを選択できましたが、IPv6ではどちらかの選択になります。

内部IPと外部IP

外部IPv6アドレスを選択した場合は、（IPv4の外部IPアドレスとは違い）VMのインタフェースに直接、外部IPv6アドレスが付与されます。

次に限定公開のGoogleアクセスのオン/オフを選択します。これをオンにしておかないと外部IPアドレスを持たないVMがGoogle CloudのAPIサービスにアクセスできなくなります。（たとえば、Cloud Storageからファイルをダウンロードしたりできません。）ですので、通常はオンにしておくとよいでしょう。

そして、VPCフローログの利用を選択します。（VPCフローログを使うと、VPC内のトラフィックのログが取得でき、どこへの通信が多いか？などのトラフィックの分析が簡単にできるようになります。）

ちなみに一度作ったサブネットのIPv4範囲を広げることもできます。たとえば/24のサブネットを/23にするような例です。ただし、広げる先のアドレス範囲が使われていないことが条件となります。具体的な例としては、192.168.1.0/24を192.168.0.0/23に広げたい場合、前半の192.168.0.0/24を使っていないことが条件です。

ファイアウォールルール

VPCの作成3
VPC作成の画面（その3）

ファイアウォールルールにセクションには、よく使われるファイアウォールルールが4つほどデフォルトとして提示されています。（5番目と6番目はデフォルトで必ず暗に設定されるルールです。暗に設定されるのでリストには出てきません。）

同一VPC内の各サブネットからの通信をすべて許可（「フィルタ」のIP範囲に設定したすべてのサブネット範囲が設定され、「プロトコル/ポート」がallになっています。）
ICMP（ping等）の通信をすべて許可（「フィルタ」のIP範囲が0.0.0.0/0で、「プロトコル/ポート」がicmp。）
RDP（リモートデスクトップ）の通信をすべて許可（「フィルタ」のIP範囲が0.0.0.0/0で、「プロトコル/ポート」がtcp:3389。）
SSHの通信をすべて許可（「フィルタ」のIP範囲が0.0.0.0/0で、「プロトコル/ポート」がtcp:22。）
外向きの通信をすべて許可
（他のルールが適用されない）内向きの通信をすべてブロック

1番目のルールは比較的よく使われると思いますが、2〜4番目のルールはセキュリティポリシーによって利用が分かれると思います。お試しの環境とかであれば全部有効にしておくと楽だと思いますが、実際の環境では使わないことが多いかもしれません。（ここではどれも選択せず、別途ファイアウォールの設定をするというのも普通です。）

動的ルーティングモード

VPCの動的ルーティングモードには「リージョン」と「グローバル」があります。（オンプレミス環境など、VPC外と接続する場合だけ影響があります。）

リージョンルーティングモードの場合、外部と接続されているリージョンのサブネットの経路だけアナウンスされます。結果として接続があるリージョンのVM等とだけ通信ができます。

グローバルルーティングモードの場合、VPC内のすべてのリージョンのサブネットの経路がアナウンスされます。そのため、リージョンによらずVPC内のすべてのVM等と、Google Cloudのバックボーンを経由して通信ができます。

ルーティングモードの違い

Google Cloud開始当初からのデフォルトが「リージョン」ルーティングモードなため、現在でもデフォルトは「リージョン」ルーティングモードになっていますが、特別な理由がなければ 「グローバル」ルーティングモードを選ぶのがよいと思います。（また、VPC作成後でも変更できます。）

たとえば東京と大阪の二箇所でVPCと接続し、どちらかの接続が落ちた場合に、もう一方の接続で迂回したい場合は、「グローバル」ルーティングモードにしておく必要があります。

ないルーティングモードの詳細と、それによるオンプレミスとの通信への影響については以前「Google Cloud の VPC とオンプレミスの間のルーティングの仕組み」という記事で紹介しているので、合わせてご参照ください。

DNSポリシー

「VPC作成の画面（その3）」のスクリーンショットをよく見ると「DNSポリシーを選択するには、DNS APIを有効にしてください。」と表示されています。これはCloud DNSの機能を使うにはCloud DNSのAPIを有効にしてください、という意味です。（Google Cloudではセキュリティなどの理由から、色々なサービスのAPIがデフォルトでは無効になっており、サービスを利用する場合は最初に有効化する必要があります。）

Cloud DNSのサーバーポリシーを設定すると、以下の機能が使えるようになります。

クエリログの有効化（VPC内のDNSクエリや、VPC外から送られてくるDNSクエリなどを記録します。）
受信クエリの有効化（Cloud DNSで管理する内部ゾーンへの、オンプレミスからのDNSクエリを受け付けます。）
代替ネームサーバーの設定（VPC内の名前解決はデフォルトで169.254.169.254のメタデータサーバーが担ってます。これを異なるDNSサーバーへ変更したい場合、代替ネームサーバーの設定をします。）

DNSポリシーの設定もファイアウォールの設定と同じく、ここで設定する必要は必ずしもなく、あとで設定するのでもオッケーです。

MTU

最後にMTU (Maximum Transmission Unit)の設定があります。デフォルトのMTUは1460バイトになっており、それ以外に1500バイトと8896バイトが選べます。（コマンドライン（gcloudコマンド）やAPIでVPCを作れば、1300バイト〜8892バイトの間の任意のMTUを指定できます。）

なお、MTUの値はIPパケット（データグラム）のサイズを表しており、イーサネットヘッダーは含みません。

こちらも動的ルーティングモードと同じで、当初1460バイトがデフォルトだったためそのままになっていますが、オンプレミスと接続する場合などを想定すると、一般的なMTUである1500バイトにしておくのがよいと思います。また、VPC外との通信が無く、できるだけスループットを出したい場合（たとえばHPC（High Performance Computing）の用例など）は、MTUを8896バイトに設定するとよいでしょう。

なお、既存のVPCのMTUを変更することもできます。しかしVPCのMTUの設定は各VMが認識するMTUとそろえる必要があり、そのためにはVMの停止が必要となります。このようにMTUの変更操作には注意が必要であり、気軽に実施することを推奨していないため、設定変更はコマンドラインやAPIのみでおこなえるようになっています。

余談：MRU

VPCの設定にはありませんが、インターフェイス（や実装）によってはMTUに対してMRU（Maximum Receive Unit）という設定がある場合もあります。その場合、MTUを大きくしてもMRUが小さいと大きなデータを受け取れなかったりします。

VPCの確認

以上の設定をすべておこない、「作成」ボタンを押してしばらく待つと晴れてVPCが作成されます。（ちなみにコマンドラインでVPCを作成する場合、もろもろの設定がデフォルトでよければ、必須の設定は「名前」だけです。）

作成されたVPC

VPC名をクリックするとVPCの詳細が見られます。

VPCの詳細

赤枠で囲んだところのタブをクリックすると、それぞれの詳細をさらに確認できます。

VPCのルート

たとえば「ルート」の項目を見ると、以下のようになっています。

デフォルトで設定されるVPCのルート

インターネット向きのデフォルトルートがIPv4用（0.0.0.0/0）とIPv6用（::/0）それぞれ「デフォルトインターネットゲートウェイ」向けに設定されています。
サブネット「my-first-subnet」に設定された内部IPv4範囲と外部IPv6範囲のルートがそれぞれ設定されています。

なお、サブネットのルートは下図の通り削除できませんが、IPv4/IPv6のデフォルトルートは不要であれば削除できます。

サブネットルートの削除は不可

ちなみにデフォルトインターネットゲートウェイは常に存在しており、個別に作ってVPCにアタッチしたりする必要はなく、逆に削除することもできません。

また「デフォルトで設定されるVPCのルート」をよく見ると分かりますが、「ルート」はVPC単位の設定になっています。（つまり、サブネット単位の設定ではありません。）そのため、単一のルーティングが、すべてのリージョンのすべてのサブネットのすべてのVMで共有されることになります。

これは、サブネットの特徴の「サブネットの考え方」の図を参照しながら、VPCの「ルート」の設定とは「仮想的なルータ（VPCルータ）」のルーティングテーブルの設定である、と考えれば分かりやすいのではないでしょうか。

余談：プライベートサブネットとパブリックサブネット

AWSにはプライベートサブネットとパブリックサブネットという考え方があります。これはサブネットごとにルートの設定を変更できることを利用し、インターネットゲートウェイ宛てのルートの有無によって分ける考え方です。Google Cloudでは上述の通り、サブネットごとのルートの設定はないため、両者を混在させて作ることはできません。（どちらか一方にすることはできます。）

一方、パブリックサブネットはALBやNATゲートウェイの利用に必要ですが、Google Cloudの外部ロードバランサーや、Cloud NATには不要です。したがって、デフォルトルートを削除してVPC全体をプライベートサブネットサブネット状態にしても何も問題ありません。

また、デフォルトルートを削除せずにAWSで言うところのパブリックサブネットのままにしておいたとしても、そもそもVMに外部IPアドレスを付与しなければインターネットからの通信もインターネットへの通信もできなくなるので、「パブリックインターネットに到達できない」というプライベートサブネットサブネットの目的をほぼ達成してると言えるんじゃないかと思います。（VM の外部 IP アクセスの無効化という「組織ポリシーの制約」を使うことでVMに外部IPアドレスを付与しないよう強制することもできます。）

というわけで、Google Cloudではプライベートサブネットとパブリックサブネットの両方を1つのVPCに作ることはできないですが、そもそもそのような構成にする必要がないため、外部（インターネット）との通信の必要性の有無にしたがってデフォルトルートの要否、VMの外部IPアドレスの要否、そして適切なファイアウォールの設定をおこなっていただけるとよいかと思います。

ブロックされているトラフィック

「作成されたVPC」のスクリーンショットを見ると「このプロジェクトではSMTPポート25が許可されていません」と書かれています。

実はGoogle CloudのVPCではセキュリティ上の理由や不正な利用を防ぐために、特定のトラフィックをブロックまたは制限しています。

その中でも典型的なものの1つが（Google Cloudの内外を問わず）外部IPアドレスのTCPポート25（SMTP)宛ての通信のブロックになります。（ただしプロジェクトによってはデフォルトで許可されている場合もあります。）

これは昔、各組織のメールサーバー（のTCPポート25）に直接スパム（迷惑メール）を送りつける例が多かったため、ホスティングサービスやクラウドサービスではTCPポート25宛ての通信をブロックするのが一般的になっているからです。

VM等からメールサーバー経由でメールを送信したい場合はTCPポート587（Submission）宛てに送信しましょう。また、多くのメールを配信するなどのビジネス要件がある場合、マーケットプレイス経由でサードパーティのサービスを利用できます。（たとえば、SendGrid Email APIサービス。）

VPCのファイアウォール

VPCファイアウォールの種類

実はGoogle Cloudのファイアウォールは本記事執筆時点の2022年末において微妙に過渡期にあり、大きく分けて2種類のファイアウォールがあります。

ファイアウォールルール
ファイアウォールポリシー
- 階層型ファイアウォールポリシー
- ネットワークファイアウォールポリシー
  - グローバルネットワークファイアウォールポリシー
  - リージョナルネットワークファイアウォールポリシー

まず当初よりずっとあったファイアウォールルールと、新しく作られたファイアウォールポリシーの2種類があり、ファイアウォールポリシーには階層型のものとそうでないものがあり、さらに階層型ではないものにはグローバルとリージョナルの区別があります。

（なお、VPCの作成画面で提示されていたのはファイアウォールルールの方です。）

いずれもVMの通信を送信元や送信先、プロトコルなどで制限する、という目的は同じですが、これまであったファイアウォールルールをより運用しやすくしたものがファイアウォールポリシーです。

したがって、今後ともファイアウォールルールは使い続けられますが、必要に応じてファイアウォールポリシーを使うようにしていただくと、より柔軟なファイアウォールの設定を簡単にきめ細かくおこなっていただけるようになると思います。

VPCファイアウォールルールの作成

というわけで、本当はファイアウォールポリシーについて書きたいところなんですが、それだけで一本の記事になってしまうので、ここではいったんファイアウォールルールについてご紹介をしたいと思います。

VPCの作成時のファイアウォールルールの項目で少し触れましたが、VPCのファイアウォールはデフォルトで外向きの通信はすべて許可、内向きの通信はすべてブロックされています。したがって、通常は必要な内向きの通信を許可するというファイアウォールルールを設定することになります。

そこで例として、自宅からのSSHの通信を許可する、というファイアウォールルールを設定してみます。Cloud Consoleの≡メニューから「VPCネットワーク - ファイアウォール」を選択します。

VPCファイアウォール

画面上部の右側「ファイアウォールルールの作成」をクリックします。

ファイアウォールルールの作成（その1）

まず名前を付けます。

ファイアウォールルールのロギングのオン・オフを選択します。

どのVPCに設定するかを選択します。（逆に言うとVPCが複数ある場合、「自宅からのSSHの通信を許可する」というルールをVPCごとにそれぞれ設定する必要があります。ファイアウォールポリシーでは1つのルールを複数のVPCで共用できます。ここでは先に作ったVPCを選択しておきます。）

優先度を設定します。（値が小さいほど優先順位が高くなります）

ファイアウォールルールの作成（その2）

ファイアウォールルールを適用するトラフィックの向きを選択します。（上り = 内向き/ingress、下り = 外向き/egress）

一致したときのアクションを選択します。（通常、内向きの場合はデフォルトが拒否（ブロック）なので個別のルールでは「許可」を選び、外向きの場合はその逆になります。）

ターゲットを設定します。（ターゲットには「すべてのインスタンス」「ターゲットタグ」「サービスアカウント」が選択できます。「ターゲットタグ」の場合は、設定した「ネットワークタグ」が設定されたVMだけにルールが適用され、「サービスアカウント」の場合は、設定した「サービスアカウント」が設定されたVMだけにルールが適用されます。ここでは簡単にするため「すべてのインスタンス」にしておきます。）

ファイアウォールの適用の仕方の違い

上記の通り、Google Cloudのファイアウォールルールは、ファイアウォールルール自体に「どんなVMに対して適用するか」という設定がおこなわれており、VM側で「どのファイアウォールルール」を適用するか？といった設定はおこないません。（ネットワークタグを設定することで間接的に選択することはできます。）

AWSでは逆に、セキュリティグループ自体には適用対象の設定はなく、EC2インスタンス作成時にどのセキュリティグループを提供するかを選択します。

Azureはその中間のようなところがあり、VM作成時にネットワークセキュリティグループを選ぶこともできますし、選択したサブネットにすでにネットワークセキュリティグループが設定されていた場合は、それも合わせて適用されます。

ファイアウォールの設定自体（許可・不許可の設定）はどのサービスでも大差ありませんが、ファイアウォールの適用の仕方には割と差異が見られておもしろいですね。

次にソースフィルタを選択します。（ソースフィルタにはIPv4範囲、IPv6範囲、ソースタグ、サービスアカウントを選べます。ターゲットはファイアウォールの適用先の設定でしたが、ソースフィルタは（上り/内向きの場合）「どこからのトラフィックに適用するか」を設定するものです。（下り/外向きの場合は「送信先フィルタ」になります。）「自宅から」の通信を許可するので、ここには自宅のIPアドレスを指定します。）

ファイアウォールルールの作成（その3）

最後にプロトコルとポートを設定し、どんなトラフィックを対象とするかを選択します。（上で選択した送信元から、もしくは送信席への「すべて」のトラフィックを対象とするか、プロトコル・ポート番号を指定して、個別のトラフィックを対象とするかを選択します。今回はSSHなので、TCPのポート22のトラフィックを対象とします。）

すべてできたら「作成」します。

Compute Engine VMの作成

それでは最後にここまで作ったVPCに、実際にCompute Engine VMを作成してみます。

Cloud Consoleの≡メニューから「Compute Engine - VMインスタンス」を選択します。

VMの作成（その1）

「インスタンスの作成」をクリックします。

VMの作成（その2）

色々な設定がありますが、とりあえず大半はデフォルトのままでオッケーです。ただし、リージョンだけは、サブネットの作成で選んだサブネットのリージョンを選択します。

VMの作成（その3）

そして肝心のVPCの選択ですが、メニューのわりと深いところにあります。

VM作成画面の一番下にある「詳細オプション」をクリック
ネットワーキングをクリック
ネットワークインターフェースの少し下をクリック（default VPCがある場合はそれが選ばれてます）

ここで先に作ったVPCを選択します。（サブネットが複数ある場合はサブネットも選べます）合わせてIPv6アドレスを付与するか否か、外部IPv4アドレスを付与するか否か、なども設定できます。

選択できたら「作成」します。

VMの確認

VMはすぐにできるので、VPC（ネットワーク）が選択したものになっているか確認しましょう。また、設定した送信元からSSHできるか試すためにSSHボタンをクリックしてみましょう…と言いたいところなんですが、このSSHボタンを使った場合の送信元はGoogleのアドレス範囲になるため、先のように自宅のアドレスを設定してる場合はそのまま接続できません。

「SSHボタンを使った場合の送信元はGoogleのアドレス範囲になる」

ドキュメント「ブラウザからの SSH」のセクション「「Unable to connect on port 22」エラーメッセージへの対処」に「ブラウザベースのSSHセッションの送信元IPアドレスは、Cloud Consoleによって動的に割り当てられ、セッションごとに異なることがあります。この機能を動作させるには、任意の IP アドレスからの接続、または公開 SPF レコードを使用して取得できる Google の IP アドレス範囲からの接続を許可する必要があります。」とあります。ちょっと惜しいですね。

そこで、IAPのアドレス範囲をファイアウォールに追加してブラウザからのSSHを使う方法と、SSHコマンドを使って自宅からログインする方法の両方を試してみます。

IAP経由でブラウザからSSH接続

Identity-Aware Proxy（IAP）という仕組みを使うと、ブラウザからIAPを経由してVMへアクセスすることになります。すると、VMへのアクセスがIAP用のアドレス範囲（35.235.240.0/20）からになるので、この送信元を1つファイアウォールへ追加するだけで済みます。

さっそく先ほど作ったファイアウォールルールを編集して、送信元IPv4範囲に35.235.240.0/20を追加します。

ファイアウォールルールの更新

保存して更新が完了するのをまって、SSHボタンを試してみましょう。いかがでしょう？ログインできたでしょうか？ログインできたらwhoコマンドなどでログイン元のIPアドレスがIAPのアドレス範囲35.235.240.0/20になっている確認してみましょう。

$ who
user     pts/0        2022-12-04 20:11 (35.235.242.49)

IAPを使ってログインする方法は強固な認証にもとづくゼロトラストのアクセスモデルの1つの実装になりますが、一方、IAPのアドレス範囲はGoogle Cloudのユーザーであれば誰でも使える範囲なので、送信元の制限としてはあまり意味をなしません。

（そもそもIAPが実現しようとしているゼロトラストの考え方と、送信元IPアドレス制限という方法がミスマッチなのでしかたありませんが。）

そこで、自宅から普通にSSHコマンドを使ってのログインも試してみましょう。

自宅からSSHコマンドで接続

ブラウザからのSSHの場合、裏で自動的にSSHの公開鍵をVMへ送り込むことでログイン認証はシームレスにおこなわれますが、SSHコマンドでのログインの場合、手動で公開鍵をVMへ送り込む必要があります。

VMへの公開鍵の送付はプロジェクトのメタデータ経由でおこないます。（リンク先のドキュメントにもある通り、メタデータを使ったSSHの公開鍵の管理は実はオススメできず、OS Loginという別のユーザー管理の仕組みを使った方法がオススメです。が、今回は簡単にするため、メタデータを使います。）

SSHの鍵ペアを作成します。（-Cの引数がユーザー名です）

$ ssh-keygen -t rsa -f ~/.ssh/advent -C agira -b 2048
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/agira/.ssh/advent
Your public key has been saved in /Users/agira/.ssh/advent.pub
The key fingerprint is:
SHA256:aixAzHFVKWuTJK8SViQvaQT8n9xKLojqMtEM4BOrttk agira
The key's randomart image is:
+---[RSA 2048]----+
|o.+.o.....       |
|.* *o o .        |
|o @..+ +         |
|.*oo  *          |
|.=o.ooo.S        |
|o.+..* o         |
|o.=.+ =          |
|++ E =           |
|=o  .            |
+----[SHA256]-----+

Cloud Consoleで「Compute Engine - メタデータ」へ行きます。

メタデータの編集

「編集」をクリックします。
「SSH認証鍵」をクリックし、「項目を追加」をクリックします。
テキストボックスに作成したSSHの鍵ペアの公開鍵をペーストします。（上の例では ~/.ssh/advent.pubの中身をコピペします。)

SSH公開鍵の追加

保存します。

なお、一度この手順をやれば、他のVMも同じSSHの鍵でログインできます。（逆に言うと、そこら辺の細かい管理ができないので、OS Loginの方がオススメになっています。）

それではSSHコマンドでのログインを試してみましょう。VMインスタンスのページから外部IPアドレスをコピーしておきます。

ユーザー名はSSHの鍵ペア作成時に -C で指定した名前
秘密鍵（-iの引数）は作成した鍵ペアのうち .pubの付かない方

$ ssh agira@34.146.177.235 -i ~/.ssh/advent
The authenticity of host '34.146.177.235 (34.146.177.235)' cant be established.
ED25519 key fingerprint is SHA256:RQ61DwYHOqOaTA10Qtwm0ASAoLiIQR/kiGW10dCFam0.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '34.146.177.235' (ED25519) to the list of known hosts.
Linux instance-2 5.10.0-19-cloud-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
agira@instance-1:~$

いかがでしょう？ログインできたでしょうか？

終わりに

というわけで、VPCの作成から、Compute Engineへのログインまで一連の説明は以上となります。デフォルトの設定をそのまま使うのではなく、個別の設定での作成をおこなうことで各種パラメーターについても触れることになるため、結果として少しでもVPCについての理解が深まってたらとても嬉しいです。

本記事では触れられなかったファイアウォールポリシーや、Google Cloudのサービスを安全に使うには欠かせないVPC Service Controlsなど、まだまだご紹介し足りない機能・サービスはあるのですが、際限がないのでいったんここまでとしたいと思います。

次の「今から始める Google Cloud」編はCompute Engineです。ぜひ合わせてご覧ください。

Google Cloud JapanPublication

Google Cloud Japan のエンジニアを中心に情報発信をしている Publication です。Google Cloud サービスの技術情報を中心に公開しています。各記事の内容は個人の意見であり、企業を代表するものではございません。