ソリューション アーキテクトは、AWS のクラウド インフラストラクチャの柱の一つがネットワークであることを理解しています。さまざまなリソースを接続する方法、ネットワーク セグメンテーションを実現する方法、セキュリティを確保する方法などが、Google Cloud で作業する際のクラウド アーキテクトの主な関心事です。
AWS には、他のリソースとともに、1 つ以上の Amazon Virtual Private Cloud(VPC)があります。これは、AWS アカウント専用の分離された仮想ネットワークです。Amazon VPC を使用すると、リソースを安全な仮想ネットワークに起動できます。
AWS の VPC は、範囲がリージョンに依存し、単一のリージョン内でのみ存在できます。AWS アカウントを作成すると、構成を必要とせずに AWS リージョンごとにデフォルトの VPC が 1 つ作成されます。
複数のリージョンにあるアプリやリソースを接続する場合、VPC ピアリングまたはトランジット ゲートウェイを使用できます。
AWS VPC では、可用性とフォールト トレランスを向上させるために、異なるアベイラビリティ ゾーンにプライベート サブネットとパブリック サブネットを設定します。ベスト プラクティスに従い、セキュリティ グループ、ルートテーブル、AWS Network Firewall ルールを作成することで、ネットワーク セキュリティを強化できます。
以上の内容を念頭に置いたうえで、堅牢なアーキテクチャをデプロイできる Google Cloud のネットワーキング サービスについて学んでいきましょう。
概要
Google Cloud Virtual Private Cloud(VPC)は、Compute Engine 仮想マシン(VM)インスタンス、Kubernetes Engine コンテナ、App Engine フレキシブル環境にネットワーキング機能を提供しています。つまり、VPC ネットワークがなければ VM インスタンス、コンテナ、App Engine アプリケーションを作成することはできません。そのため、新しい Google Cloud プロジェクトには、すぐに使えるように default ネットワークが用意されています。
VPC ネットワークは、Google Cloud 内で仮想化されているという点を除き、物理ネットワークと同様のものと考えることができます。VPC ネットワークは、複数のデータセンター内のリージョン仮想サブネットワーク(サブネット)のリストで構成されるグローバル リソースであり、すべてグローバルな広域ネットワーク(WAN)で接続されています。VPC ネットワークは、Google Cloud 内で互いに論理的に分離されています。
このラボでは、ファイアウォール ルールを含む自動モードの VPC ネットワークと、2 つの VM インスタンスを作成します。その後、自動モードのネットワークをカスタムモードのネットワークに変換し、さらに以下のネットワーク図の例に示すカスタムモード ネットワークを追加で作成します。また、ネットワーク間の接続性もテストします。
目標
このラボでは、次のタスクの実行方法について学びます。
デフォルトの VPC ネットワークについて確認する
ファイアウォール ルールを含む自動モードのネットワークを作成する
自動モードのネットワークをカスタムモードのネットワークに変換する
ファイアウォール ルールを含むカスタムモードの VPC ネットワークを作成する
Compute Engine を使用して VM インスタンスを作成する
VPC ネットワーク間の VM インスタンスの接続性を調べる
各ラボでは、新しい Google Cloud プロジェクトとリソースセットを一定時間無料で利用できます。
Qwiklabs にシークレット ウィンドウ でログインします。
ラボのアクセス時間(例: 1:15:00
)に注意し、時間内に完了できるようにしてください。
一時停止機能はありません。必要な場合はやり直せますが、最初からになります。
準備ができたら、[ラボを開始 ] をクリックします。
ラボの認証情報(ユーザー名 とパスワード )をメモしておきます。この情報は、Google Cloud Console にログインする際に使用します。
[Google Console を開く ] をクリックします。
[別のアカウントを使用 ] をクリックし、この ラボの認証情報をコピーしてプロンプトに貼り付けます。
他の認証情報を使用すると、エラーが発生したり、料金の請求 が発生したりします。
利用規約に同意し、再設定用のリソースページをスキップします。
タスク 1. デフォルト ネットワークについて確認する
各 Google Cloud プロジェクトは default ネットワークを備えています。このネットワークには、サブネット、ルート、ファイアウォール ルールが含まれています。
サブネットを確認する
default ネットワークには、各 Google Cloud リージョン のサブネットが含まれています。
Cloud コンソールのナビゲーション メニュー ( )で [VPC ネットワーク ] > [VPC ネットワーク ] の順にクリックします。
default ネットワークとそのサブネットが表示されます。
各サブネットはそれぞれ 1 つの Google Cloud リージョンとプライベート RFC 1918 CIDR ブロックに関連付けられています。この CIDR ブロックは内部 IP アドレス範囲 とゲートウェイ に使用されます。
ルートを表示する
ルートは、VM インスタンスと VPC ネットワークに対して、インスタンスから宛先(ネットワーク内部または Google Cloud の外部)にトラフィックを送信する方法を指定するものです。各 VPC ネットワークにはいくつかのデフォルト ルートが用意されており、サブネット間でのトラフィックのルーティングや、条件を満たすインスタンスからインターネットへのトラフィックの送信に使用されます。
左側のペインで [ルート ] をクリックします。
各サブネットのルートと、デフォルト インターネット ゲートウェイ (0.0.0.0/0)のルートが表示されます。
これらのルートは自動的に管理されますが、カスタムの静的ルートを作成して一部のパケットを特定の宛先に送信することもできます。たとえば、NAT ゲートウェイとして構成されたインスタンスにすべての送信トラフィックを送るルートを作成することも可能です。
ファイアウォール ルールを表示する
各 VPC ネットワークには、構成可能な分散仮想ファイアウォールが実装されています。ファイアウォール ルールを使用すると、どのパケットをどの宛先に送信できるようにするかをコントロールできます。また、あらゆる VPC ネットワークには、すべての受信接続をブロックし、すべての送信接続を許可するという 2 つの暗黙ファイアウォール ルールが存在します。
左側のペインで、[ファイアウォール ] をクリックします。
default ネットワークには、次の 4 つの上り(内向き) のファイアウォール ルールがあります。
default-allow-icmp
default-allow-rdp
default-allow-ssh
default-allow-internal
これらのファイアウォール ルールにより、任意の送信元(0.0.0.0/0)からの ICMP 、RDP 、SSH の上り(内向き)トラフィックと、このネットワーク(10.128.0.0/9)内の TCP 、UDP 、ICMP のすべてのトラフィックが許可されます。[ターゲット ]、[フィルタ ]、[プロトコル / ポート ]、[アクション ] の各列でこれらのルールの設定がわかります。
ファイアウォール ルールを削除する
左側のペインで、[ファイアウォール ] をクリックします。
デフォルト ネットワークのファイアウォール ルールをすべて選択します。
[削除 ] をクリックします。
[削除 ] をもう一度クリックして、ファイアウォール ルールの削除を確定します。
デフォルト ネットワークを削除する
左側のペインで [VPC ネットワーク ] をクリックします。
default ネットワークを選択します。
[VPC ネットワークの削除 ] をクリックします。
[削除 ] をクリックして、default ネットワークの削除を確定します。
ネットワークが削除されるまで待ってから次に進みます。
左側のペインで [ルート ] をクリックします。
ルートが表示されていないことを確認します。
左側のペインで、[ファイアウォール ] をクリックします。
ファイアウォール ルールが表示されていないことを確認します。
注: VPC ネットワークがない場合は、ルートもありません。
VM インスタンスを作成してみる
VPC ネットワークがない場合は VM インスタンスを作成できないことを確認します。
ナビゲーション メニュー で、[Compute Engine] > [VM インスタンス] をクリックします。
[インスタンスを作成 ] をクリックします。
デフォルト値をそのまま使用して [作成 ] をクリックします。
エラーが表示されます。
[インスタンスを作成 ] をクリックします。
[ネットワーキング ] をクリックします。[ネットワーク インターフェース ] に「使用できるその他のネットワークがありません 」というエラーが表示されます。
[キャンセル ] をクリックします。
注: 想定どおり、VM インスタンスの作成には VPC ネットワークが必要です。
タスク 2. 自動モードのネットワークを作成する
ラボの冒頭で述べたように、自動モードのネットワークと 2 つの VM インスタンスを作成します。自動モードのネットワークは各リージョン内にサブネットを自動的に作成するため、簡単に設定して使用できます。ただし、VPC ネットワーク内で作成されるサブネットを完全に制御することはできません(使用するリージョンや IP アドレス範囲などを自由に設定することはできません)。
自動モードのネットワークを選択する際の考慮事項 の詳細については、Google VPC ドキュメントをご覧ください。このラボでは、プロトタイピングを目的として自動モードのネットワークを使用することを想定します。
ファイアウォール ルールを含む自動モードの VPC ネットワークを作成する
ナビゲーション メニュー ( )で、[VPC ネットワーク ] > [VPC ネットワーク ] をクリックします。
[VPC ネットワークを作成 ] をクリックします。
[名前 ] に「mynetwork 」と入力します。
[サブネット作成モード ] で [自動 ] をクリックします。
自動モードのネットワークは、各リージョンのサブネットを自動的に作成します。
[ファイアウォール ルール ] で、選択可能なすべてのルールのチェックボックスをオンにします。
これらのルールは、デフォルト ネットワークに含まれている標準のファイアウォール ルールと同じです。deny-all-ingress ルールと allow-all-egress ルールも表示されますが、これらは暗黙のルールなので、選択したり無効にしたりすることはできません。この 2 つのルールは優先度 が低いため(値が大きいほど優先度が低い)、ICMP、カスタム、RDP、SSH の許可ルールが先に検討されます。
[作成 ] をクリックします。
新しいネットワークの準備ができたら、[mynetwork ] をクリックします。 と のサブネットの IP アドレス範囲を書き留めておいてください。
注: デフォルト ネットワークを削除しても、上述のように自動モードのネットワークを作成すればすぐに作り直すことができます。
に VM インスタンスを作成する
リージョンに VM インスタンスを作成します。リージョンとゾーンを選択するとサブネットが決まり、そのサブネットの IP アドレス範囲から内部 IP アドレスが割り当てられます。
Cloud コンソール のナビゲーション メニュー (☰)で、[Compute Engine ] > [VM インスタンス ] をクリックし、[インスタンスを作成 ] をクリックします。
以下のフィールドを次のように指定し、他のフィールドはデフォルト値のままにします。
[マシンの構成 ] を参照します。
以下の値を選択します。
プロパティ
値(値を入力するか、指定されたオプションを選択)
名前
mynet-vm-1
リージョン
ゾーン
シリーズ
E2
マシンタイプ
e2-micro(2 vCPU、1 GB メモリ)
[OS とストレージ ] をクリックします。
[変更 ] をクリックし、ブートディスクの構成を始めます。
[ブートディスク ] が Debian GNU/Linux 12 (bookworm) に構成されていることを確認します。
[選択 ] をクリックします。
[作成 ] をクリックします。
に VM インスタンスを作成する
リージョンに VM インスタンスを作成します。
[インスタンスを作成 ] をクリックします。
[マシンの構成 ] を参照します。
以下の値を選択します。
プロパティ
値(値を入力するか、指定されたオプションを選択)
名前
mynet-vm-2
リージョン
ゾーン
シリーズ
E2
マシンタイプ
e2-micro(2 vCPU、1 GB メモリ)
[OS とストレージ ] をクリックします。
[変更 ] をクリックし、ブートディスクの構成を始めます。
[ブートディスク ] が Debian GNU/Linux 12 (bookworm) に構成されていることを確認します。
[選択 ] をクリックします。
[作成 ] をクリックします。
注: どちらの VM インスタンスでも、[外部 IP ] のアドレスは一時的なもの(エフェメラル)です。インスタンスが停止すると、インスタンスに割り当てられているエフェメラル外部 IP アドレスは解放されて汎用の Compute Engine プールに戻され、他のプロジェクトで使用できるようになります。
停止したインスタンスが再起動されると、インスタンスに新しいエフェメラル外部 IP アドレスが割り当てられます。または、静的な外部 IP アドレスを予約して、明示的に解放するまで無期限でプロジェクトに割り当てることもできます。
VM インスタンスの接続性を確認する
mynetwork で作成したファイアウォール ルールでは、mynetwork の外部(外部 IP)からと内部(内部 IP)での、SSH および ICMP の上り(内向き)トラフィックが許可されます。
ナビゲーション メニュー で、[Compute Engine] > [VM インスタンス] をクリックします。
mynet-vm-2 の外部 IP アドレスと内部 IP アドレスをメモしておきます。
mynet-vm-1 で [SSH ] をクリックし、ターミナルを起動して接続します。
注: allow-ssh ファイアウォール ルールによって、tcp:22 に対する内向きトラフィックがすべて許可(送信元は任意: 0.0.0.0/0)されているため、SSH でインスタンスに接続できます。また、Compute Engine が SSH 認証鍵を自動的に作成して次のいずれかの場所に保存するため、SSH 接続はシームレスに機能します。
デフォルトでは、生成された鍵はプロジェクトまたはインスタンスのメタデータに追加されます。
OS Login を使用するようにアカウントが構成されている場合、生成された鍵はユーザー アカウントとともに保存されます。
SSH 認証鍵を作成し、公開 SSH 認証鍵のメタデータを編集することで、Linux インスタンスへのアクセスを制御することもできます。
次のコマンドを実行して、mynet-vm-2 の内部 IP アドレスへの接続性をテストします。コマンドのプレースホルダは、mynet-vm-2 の内部 IP アドレスに置き換えます。
ping -c 3 <mynet-vm-2 の内部 IP をここに入力>
allow-custom ファイアウォール ルールで許可されているため、mynet-vm-2 の内部 IP に ping を実行できます。
次のコマンドを実行して、mynet-vm-2 の外部 IP アドレスへの接続性をテストします。コマンドのプレースホルダは、mynet-vm-2 の外部 IP アドレスに置き換えます。
ping -c 3 <mynet-vm-2 の外部 IP をここに入力>
注: 想定どおり、mynet-vm-1 に SSH で接続し、mynet-vm-2 の内部 IP アドレスと外部 IP アドレスに対して ping を実行できます。同様に、mynet-vm-2 に SSH で接続し、mynet-vm-1 の内部 IP アドレスと外部 IP アドレスに対して ping を実行することもできます。
カスタムモードのネットワークに変換する
これまでのところ、自動モードのネットワークは正常に機能しています。次のタスクでは、これをカスタムモードのネットワークに変換し、新しいリージョンが利用可能になっても自動的にサブネットが作成されないようにします。サブネットが自動的に作成されると、手動で作成したサブネットや静的ルートで使用される IP アドレスとの重複が発生したり、ネットワーク計画全体に影響したりする可能性があります。
ナビゲーション メニュー ( )で、[VPC ネットワーク] > [VPC ネットワーク] をクリックします。
[mynetwork ] をクリックしてネットワークの詳細を表示します。
[編集 ] をクリックします。
[サブネット作成モード ] で [カスタム ] を選択します。
[保存 ] をクリックします。
[VPC ネットワーク ] ページに戻ります。
mynetwork の [モード ] が [カスタム ] に変わるまで待ちます。
待機中に [更新 ] をクリックして、現在の状態を確認することもできます。
[進行状況を確認 ] をクリックして、目標に沿って進行していることを確認します。
VPC ネットワークと VM インスタンスを作成する
注: 自動モードのネットワークは簡単にカスタムモードのネットワークに変換できます。この変換を行うことで、より柔軟にネットワークを構成できるようになります。本番環境ではカスタムモードのネットワークを使用することをおすすめします。
タスク 3. カスタムモードのネットワークを作成する
このタスクでは、以下のサンプル図のように SSH 、ICMP 、RDP の上り(内向き)トラフィックを許可するファイアウォール ルールを含む 2 つのカスタム ネットワーク(managementnet と privatenet )と、VM インスタンス(vm-appliance 以外)を作成します。
これらのネットワークの IP CIDR 範囲は重複していないため、ネットワーク間に VPC ピアリングなどのメカニズムを設定できます。お使いのオンプレミス ネットワークとは異なる IP CIDR 範囲を指定すると、VPN または Cloud Interconnect を使用したハイブリッド接続の構成も可能になります。
managementnet ネットワークを作成する
Cloud コンソールを使用して managementnet ネットワークを作成します。
Cloud コンソールのナビゲーション メニュー ( )で [VPC ネットワーク] > [VPC ネットワーク] の順にクリックします。
[VPC ネットワークを作成 ] をクリックします。
[名前 ] に「managementnet 」と入力します。
[サブネット作成モード ] で [カスタム ] をクリックします。
次のように指定し、残りの設定はデフォルトのままにします。
プロパティ
値(値を入力するか、指定されたオプションを選択)
名前
managementsubnet-1
リージョン
IPv4 範囲
10.240.0.0/20
[完了 ] をクリックします。
[同等のコマンドライン ] をクリックします。
これらのコマンドは、gcloud
コマンドラインを使用してネットワークとサブネットを作成できることを示しています。このようなコマンドに同様のパラメータを指定して、privatenet ネットワークを作成します。
[閉じる ] をクリックします。
[作成 ] をクリックします。
privatenet ネットワークを作成する
gcloud
コマンドラインを使用して privatenet ネットワークを作成します。
Google Cloud コンソールで、Cloud Shell をアクティブにする アイコン( )をクリックします。
プロンプトが表示されたら、[続行 ] をクリックします。
次のコマンドを実行して privatenet ネットワークを作成します。[承認 ] をクリックします(求められた場合)。
gcloud compute networks create privatenet --subnet-mode=custom
次のコマンドを実行して privatesubnet-1 サブネットを作成します。
gcloud compute networks subnets create privatesubnet-1 --network=privatenet --region={{{project_0.default_region|Region 1}}} --range=172.16.0.0/24
次のコマンドを実行して privatesubnet-2 サブネットを作成します。
gcloud compute networks subnets create privatesubnet-2 --network=privatenet --region={{{ project_0.default_region_2|Region 2}}} --range=172.20.0.0/20
次のコマンドを実行して、使用可能な VPC ネットワークを一覧表示します。
gcloud compute networks list
出力は次のようになります。
NAME SUBNET_MODE BGP_ROUTING_MODE IPV4_RANGE GATEWAY_IPV4
managementnet CUSTOM REGIONAL
mynetwork CUSTOM REGIONAL
privatenet CUSTOM REGIONAL
次のコマンドを実行して、使用可能な VPC サブネットを(VPC ネットワーク別に並べ替えて)一覧表示します。
gcloud compute networks subnets list --sort-by=NETWORK
注: managementnet ネットワークと privatenet ネットワークはカスタムモードのネットワークであるため、作成したサブネットのみが含まれます。mynetwork もカスタムモードのネットワークですが、最初に自動モードのネットワークとして開始したため、各リージョンにサブネットが作成されています。
Cloud コンソールのナビゲーション メニュー ( )で [VPC ネットワーク] > [VPC ネットワーク] の順にクリックします。
Cloud コンソールにも同じネットワークとサブネットが一覧表示されることを確認します。
managementnet 用のファイルウォール ルールを作成する
managementnet ネットワーク上の VM インスタンスに対する SSH 、ICMP 、および RDP の上り(内向き)トラフィックを許可するように、ファイアウォール ルールを作成します。
Cloud コンソールのナビゲーション メニュー ( )で、[VPC ネットワーク] > [ファイアウォール] をクリックします。
[ファイアウォール ルールを作成 ] をクリックします。
次のように指定し、残りの設定はデフォルトのままにします。
プロパティ
値(値を入力するか、指定されたオプションを選択)
名前
managementnet-allow-icmp-ssh-rdp
ネットワーク
managementnet
ターゲット
ネットワーク上のすべてのインスタンス
ソースフィルタ
IPv4 範囲
送信元 IPv4 範囲
0.0.0.0/0
プロトコルとポート
指定したプロトコルとポート
注: すべてのネットワークを指定するために、[ソース IPv4 の範囲 ] には /0 を含めます。
[tcp ] を選択し、ポート「22 」と「3389 」を指定します。
[その他のプロトコル ] を選択して、icmp プロトコルを指定します。
[同等のコマンドライン ] をクリックします。
これらのコマンドは、gcloud
コマンドラインでもファイアウォール ルールを作成できることを示しています。これらのコマンドに同様のパラメータを指定して、privatenet のファイアウォール ルールを作成します。
[閉じる ] をクリックします。
[作成 ] をクリックします。
privatenet 用のファイアウォール ルールを作成する
gcloud
コマンドラインを使用して privatenet ネットワーク用のファイアウォール ルールを作成します。
Cloud Shell に戻ります。必要に応じて、Cloud Shell をアクティブにする アイコン( )をクリックします。
次のコマンドを実行して、privatenet-allow-icmp-ssh-rdp ファイアウォール ルールを作成します。
gcloud compute firewall-rules create privatenet-allow-icmp-ssh-rdp --direction=INGRESS --priority=1000 --network=privatenet --action=ALLOW --rules=icmp,tcp:22,tcp:3389 --source-ranges=0.0.0.0/0
出力は次のようになります。
NAME NETWORK DIRECTION PRIORITY ALLOW DENY
privatenet-allow-icmp-ssh-rdp privatenet INGRESS 1000 icmp,tcp:22,tcp:3389
次のコマンドを実行して、すべてのファイアウォール ルールを(VPC ネットワーク別に並べ替えて)一覧表示します。
gcloud compute firewall-rules list --sort-by=NETWORK
出力は次のようになります。
NAME NETWORK DIRECTION PRIORITY ALLOW
managementnet-allow-icmp-ssh-rdp managementnet INGRESS 1000 icmp,tcp:22,tcp:3389
mynetwork-allow-icmp mynetwork INGRESS 1000 icmp
mynetwork-allow-internal mynetwork INGRESS 65534 all
mynetwork-allow-rdp mynetwork INGRESS 1000 tcp:3389
mynetwork-allow-ssh mynetwork INGRESS 1000 tcp:22
privatenet-allow-icmp-ssh-rdp privatenet INGRESS 1000 icmp,tcp:22,tcp:3389
mynetwork ネットワークのファイアウォール ルールはあらかじめ作成されています。複数のプロトコルとポートを、1 つのファイアウォール ルール(privatenet や managementnet )に定義することも、複数のルール(default と mynetwork )間で分けることも可能です。
Cloud コンソールのナビゲーション メニュー ( )で、[VPC ネットワーク] > [ファイアウォール] をクリックします。
Cloud コンソールにも同じファイアウォール ルールが一覧表示されることを確認します。
[進行状況を確認 ] をクリックして、目標に沿って進行していることを確認します。
ファイアウォール ルールを含むカスタムモードの VPC ネットワークを作成する
次に、2 つの VM インスタンスを作成します。
managementsubnet-1 内に managementnet-vm-1
privatesubnet-1 内に privatenet-vm-1
managementnet-vm-1 インスタンスを作成する
Cloud コンソールを使用して managementnet-vm-1 インスタンスを作成します。
Cloud コンソール のナビゲーション メニュー (☰)で、[Compute Engine ] > [VM インスタンス ] をクリックし、[インスタンスを作成 ] をクリックします。
以下のフィールドを次のように指定し、他のフィールドはデフォルト値のままにします。
[マシンの構成 ] を参照します。
以下の値を選択します。
プロパティ
値(値を入力するか、指定されたオプションを選択)
名前
managementnet-vm-1
リージョン
ゾーン
シリーズ
E2
マシンタイプ
e2-micro(2 vCPU、1 GB メモリ)
[OS とストレージ ] をクリックします。
[変更 ] をクリックし、ブートディスクの構成を始めます。
[ブートディスク ] が Debian GNU/Linux 12 (bookworm) に構成されていることを確認します。
[選択 ] をクリックします。
[ネットワーキング ] をクリックします。
[ネットワーク インターフェース ] で、プルダウンをクリックして編集モードにします。
次のように指定し、残りの設定はデフォルトのままにします。
プロパティ
値(値を入力するか、指定されたオプションを選択)
ネットワーク
managementnet
サブネットワーク
managementsubnet-1
注: 選択可能なサブネットは、選択したリージョンのサブネットに限定されます。
[完了 ] をクリックします。
[同等のコード ] をクリックします。
これらのコマンドは、gcloud
コマンドラインでも VM インスタンスを作成できることを示しています。これらのコマンドに同様のパラメータを指定して、privatenet-vm-1 インスタンスを作成します。
[閉じる ] をクリックします。
[作成 ] をクリックします。
privatenet-vm-1 インスタンスを作成する
gcloud
コマンドラインを使用して privatenet-vm-1 インスタンスを作成します。
Cloud Shell に戻ります。必要に応じて、Cloud Shell をアクティブにする アイコン( )をクリックします。
次のコマンドを実行して privatenet-vm-1 インスタンスを作成します。
gcloud compute instances create privatenet-vm-1 --zone={{{project_0.default_zone|Zone 1}}} --machine-type=e2-micro --subnet=privatesubnet-1 --image-family=debian-12 --image-project=debian-cloud --boot-disk-size=10GB --boot-disk-type=pd-standard --boot-disk-device-name=privatenet-vm-1
次のコマンドを実行して、(ゾーン別に並び替えた)すべての VM インスタンスを一覧表示します。
gcloud compute instances list --sort-by=ZONE
Cloud コンソールのナビゲーション メニュー ( )で、[Compute Engine] > [VM インスタンス] をクリックします。
VM インスタンスが Cloud コンソールに一覧表示されることを確認します。
[列 ] で [ゾーン ] を選択します。
にはインスタンスが 3 つ、 にはインスタンスが 1 つあります。ただし、これらのインスタンスは 3 つの VPC ネットワーク(managementnet 、mynetwork 、privatenet )に分散されており、どのインスタンスも他のインスタンスと同じゾーンまたはネットワーク内にありません。次のタスクでは、これが内部の接続性に及ぼす影響について調べます。
[進行状況を確認 ] をクリックして、目標に沿って進行していることを確認します。
VM インスタンスを作成する
注: 各 VM インスタンスのネットワーク情報を詳しく調べるには、[内部 IP ] 列にある [nic0 ] リンクをクリックします。表示されるネットワーク インターフェースの詳細ページに、サブネットと IP CIDR 範囲、そのインスタンスに適用されるファイアウォール ルールとルート、およびその他のネットワーク分析情報が示されます。
タスク 4. ネットワーク間の接続性を調べる
VM インスタンス間の接続性を調べます。具体的には、VM インスタンスが同じゾーン内にある場合と、同じ VPC ネットワーク内にある場合についてそれぞれの影響を確認します。
外部 IP アドレスに ping する
VM インスタンスの外部 IP アドレスに ping して、公共のインターネットからインスタンスにアクセスできるかどうかを調べます。
Cloud コンソールのナビゲーション メニュー で、[Compute Engine] > [VM インスタンス] の順にクリックします。
mynet-vm-2 、managementnet-vm-1 、privatenet--vm-1 の外部 IP アドレスをメモします。
mynet-vm-1 で [SSH ] をクリックし、ターミナルを起動して接続します。
次のコマンドを実行して、mynet-vm-2 の外部 IP アドレスへの接続性をテストします。コマンドのプレースホルダは、mynet-vm-2 の外部 IP アドレスに置き換えます。
ping -c 3 <mynet-vm-2 の外部 IP をここに入力>
応答があるはずです。
次のコマンドを実行して、managementnet-vm-1 の外部 IP アドレスへの接続性をテストします。コマンドのプレースホルダは、managementnet-vm-1 の外部 IP アドレスに置き換えます。
ping -c 3 <managementnet-vm-1 の外部 IP をここに入力>
応答があるはずです。
次のコマンドを実行して、privatenet-vm-1 の外部 IP アドレスへの接続性をテストします。コマンドのプレースホルダは、privatenet-vm-1 の外部 IP アドレスに置き換えます。
ping -c 3 <privatenet-vm-1 の外部 IP をここに入力>
応答があるはずです。
注: VM インスタンスが異なるゾーンや VPC ネットワークにある場合でも、すべての VM インスタンスの外部 IP アドレスに ping を通すことができます。これにより、これらのインスタンスへの公開アクセスが、先ほど設定した ICMP ファイアウォール ルールによってのみ制御されていることを確認できます。
内部 IP アドレスに ping する
VM インスタンスの内部 IP アドレスに ping して、VPC ネットワーク内からインスタンスにアクセスできるかどうかを調べます。
Cloud コンソールのナビゲーション メニュー で、[Compute Engine] > [VM インスタンス] の順にクリックします。
mynet-vm-2 、managementnet-vm-1 、privatenet-vm-1 の内部 IP アドレスをメモします。
mynet-vm-1 の SSH ターミナルに戻ります。
次のコマンドを実行して、mynet-vm-2 の内部 IP アドレスへの接続性をテストします。コマンドのプレースホルダは、mynet-vm-2 の内部 IP アドレスに置き換えます。
ping -c 3 <mynet-vm-2 の内部 IP をここに入力>
注: mynet-vm-1 の内部 IP アドレスは ping のソース(mynet-vm-1 )と同じ VPC ネットワークにあるため、両方の VM インスタンスのゾーン、リージョン、大陸が異なっていても、ping を通すことができます。
次のコマンドを実行して、managementnet-vm-1 の内部 IP アドレスへの接続性をテストします。コマンドのプレースホルダは、managementnet-vm-1 の内部 IP アドレスに置き換えます。
ping -c 3 <managementnet-vm-1 の内部 IP を入力>
注: 100% パケットロスで、ping に対する応答はありません。
次のコマンドを実行して、privatenet-vm-1 の内部 IP アドレスへの接続性をテストします。コマンドのプレースホルダは、privatenet-vm-1 の内部 IP アドレスに置き換えます。
ping -c 3 <privatenet-vm-1 の内部 IP を入力>
注: この場合も 100% パケットロスで、ping に対する応答はありません。managementnet-vm-1 と privatenet-vm-1 の内部 IP アドレスに ping を通すことはできません。これらの IP アドレスは同じゾーンにありますが、ping のソース(mynet-vm-1 )とは別の VPC ネットワーク内にあるためです。
タスク 5. まとめ
このラボでは、デフォルト ネットワークについて確認し、VPC ネットワークが VM インスタンスの作成に不可欠であることを確かめました。そのために、サブネット、ルート、ファイアウォール ルールを含む新しい自動モードの VPC ネットワークと 2 つの VM インスタンスを作成し、VM インスタンスの接続性をテストしました。本番環境には自動モードのネットワークの使用は推奨されないため、自動モードのネットワークをカスタムモードのネットワークに変換しました。
次に、Cloud コンソールと gcloud コマンドラインを使用して、ファイアウォール ルールを含む 2 つのカスタムモード VPC ネットワークと VM インスタンスを追加で作成しました。その後、VPC ネットワーク間の接続性をテストして、外部 IP アドレスに対しては ping が通るものの、内部 IP アドレスに対しては ping が通らないことを確認しました。
デフォルトでは、VPC ネットワークは分離されたプライベート ネットワーク ドメインです。そのため、内部 IP アドレスによるネットワーク間通信は、VPC ピアリングや VPN などのメカニズムを設定しない限り許可されません。
AWS と Google Cloud の類似点について見ていきましょう。
AWS と Google Cloud のどちらでも、アカウントを作成すると、すぐに使用できる事前構成済みのデフォルト VPC が用意されています。また、サブネットのサイズなど、より具体的なニーズに合わせて独自のカスタム VPC を作成して構成することもできます。AWS ではこれをデフォルト以外の VPC と呼びます。
ネットワークの安全性を確保するために、さまざまなアプローチやベスト プラクティスを取ることができます。一つの方法として、VPC ファイアウォール ルール セットを作成し、指定した構成に基づいて、仮想マシン(VM)または EC2 インスタンスへの接続を許可または拒否できます。各ファイアウォール ルールは、受信(上り、内向き)接続または送信(下り、外向き)接続に適用されます。さらに、各ファイアウォール ルールはトラフィックを許可または拒否することができ、ステートフルであるため、ネットワーク接続の状態を追跡します。
Google Cloud と AWS の相違点を理解することも重要です。
Google Cloud VPC はグローバルなサービスであり、AWS VPC のようなリージョン単位のサービスとは異なります。Google Cloud VPC は、さまざまなリージョンにまたがり、さまざまな地域のリソースをシームレスに接続できます。
Google Cloud では、クラスレス ドメイン間ルーティング(CIDR)ブロックは VPC レベルではなくサブネット レベルで定義されます。
サブネットもスコープが異なります。Google Cloud では、リージョン全体およびゾーン全体にわたりますが、AWS では 1 つのアベイラビリティ ゾーンのみに制限されます。
Amazon VPC と Google Cloud VPC のもう一つの重要な相違点は、VPC をデプロイするモードです。AWS では、デフォルト VPC とは別に、デフォルト以外の VPC を作成できます。つまり、使用するサブネットやアベイラビリティ ゾーンなど、VPC を詳細にセットアップして構成できます。Google Cloud では VPC を自動 モードまたはカスタム モードで作成できます。Google Cloud で自動モードの VPC ネットワークを作成すると、サブネット用に事前定義された IPv4 範囲セットを使用して、各リージョンに 1 つのサブネットが自動的に作成されます。カスタムモードの VPC では、サブネットは自動的に作成されず、ユーザー側でサブネットと IP 範囲を完全に制御できます。選択したリージョン内で、指定した IP 範囲を使用して、作成するサブネットを決定します。
ラボを終了する
ラボが完了したら、[ラボを終了 ] をクリックします。ラボで使用したリソースが Google Cloud Skills Boost から削除され、アカウントの情報も消去されます。
ラボの評価を求めるダイアログが表示されたら、星の数を選択してコメントを入力し、[送信 ] をクリックします。
星の数は、それぞれ次の評価を表します。
星 1 つ = 非常に不満
星 2 つ = 不満
星 3 つ = どちらともいえない
星 4 つ = 満足
星 5 つ = 非常に満足
フィードバックを送信しない場合は、ダイアログ ボックスを閉じてください。
フィードバックやご提案の送信、修正が必要な箇所をご報告いただく際は、[サポート ] タブをご利用ください。
Copyright 2020 Google LLC All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。