GSP016

概要

このハンズオンラボでは、Google Cloud（Compute Engine インスタンスを含む）で基本的なネットワーク タスクを実行する方法と、Google Cloud 環境とオンプレミス環境との違いについて学びます。1 つのネットワークと 3 つのサブネットワークを作成し、最終的に次のような環境にします。

このラボでは、一般的なクラウド デベロッパーが行う手順に沿って、次の順序で演習が用意されています。

1. ラボ環境を設定し、Google Cloud 環境の操作方法を学習します。
2. 一般的なオープンソース ツールを利用してネットワーク（サブネットと複数のリージョンを含む）をデプロイし、どこからでもネットワークを利用できるようにします。
3. ネットワークとインスタンスをテストし、モニタリングします。

学習内容

• Google Cloud ネットワークの基本コンセプトと構造
• デフォルト ネットワークとユーザー作成ネットワークの構成方法
• パフォーマンスとレイテンシの状況の測定
• アクセス、ファイアウォール、ルーティングに関する基本的なセキュリティ構成

前提条件

• Compute Engine の基本的な知識
• ネットワークと TCP/IP に関する基本的な知識
• Unix / Linux コマンドラインに関する基本的な知識

設定と要件

[ラボを開始] ボタンをクリックする前に

こちらの手順をお読みください。ラボの時間は記録されており、一時停止することはできません。[ラボを開始] をクリックするとスタートするタイマーは、Google Cloud のリソースを利用できる時間を示しています。

このハンズオンラボでは、シミュレーションやデモ環境ではなく、実際のクラウド環境を使ってご自身でラボのアクティビティを行うことができます。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。

このラボを完了するためには、下記が必要です。

• 標準的なインターネット ブラウザ（Chrome を推奨）

注: このラボの実行には、シークレット モードまたはシークレット ブラウジング ウィンドウを使用してください。これにより、個人アカウントと受講者アカウント間の競合を防ぎ、個人アカウントに追加料金が発生することを防ぎます。

• ラボを完了するために十分な時間を確保してください。ラボをいったん開始すると一時停止することはできません。

注: すでに個人の Google Cloud アカウントやプロジェクトをお持ちの場合でも、このラボでは使用しないでください。アカウントへの追加料金が発生する可能性があります。

ラボを開始して Google Cloud コンソールにログインする方法

1. [ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるポップアップでお支払い方法を選択してください。 左側の [ラボの詳細] パネルには、以下が表示されます。

   • [Google コンソールを開く] ボタン
   • 残り時間
   • このラボで使用する必要がある一時的な認証情報
   • このラボを行うために必要なその他の情報（ある場合）

2. [Google コンソールを開く] をクリックします。 ラボでリソースが起動し、別のタブで [ログイン] ページが表示されます。

   ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。

   注: [アカウントの選択] ダイアログが表示されたら、[別のアカウントを使用] をクリックします。

3. 必要に応じて、[ラボの詳細] パネルから [ユーザー名] をコピーして [ログイン] ダイアログに貼り付けます。[次へ] をクリックします。

4. [ラボの詳細] パネルから [パスワード] をコピーして [ようこそ] ダイアログに貼り付けます。[次へ] をクリックします。

   重要: 認証情報は左側のパネルに表示されたものを使用してください。Google Cloud Skills Boost の認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。

5. その後次のように進みます。

   • 利用規約に同意してください。
   • 一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
   • 無料トライアルには登録しないでください。

その後このタブで Cloud Console が開きます。

注: 左上にある [ナビゲーション メニュー] をクリックすると、Google Cloud のプロダクトやサービスのリストが含まれるメニューが表示されます。

Cloud Shell をアクティブにする

Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。

1. Google Cloud コンソールの上部にある「Cloud Shell をアクティブにする」アイコン をクリックします。

接続した時点で認証が完了しており、プロジェクトに各自の PROJECT_ID が設定されます。出力には、このセッションの PROJECT_ID を宣言する次の行が含まれています。

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。

2. （省略可）次のコマンドを使用すると、有効なアカウント名を一覧表示できます。

gcloud auth list

3. [承認] をクリックします。

4. 出力は次のようになります。

出力:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. （省略可）次のコマンドを使用すると、プロジェクト ID を一覧表示できます。

gcloud config list project

出力:

[core] project = <project_ID>

出力例:

[core] project = qwiklabs-gcp-44776a13dea667a6 注: Google Cloud における gcloud ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。

リージョンとゾーンについて

一部の Compute Engine リソースは、リージョンまたはゾーンに属します。リージョンとは、リソースを実行できる特定の地理的位置です。各リージョンには、1 つまたは複数のゾーンがあります。たとえば、リージョン us-central1 は米国中部のリージョンを指し、ゾーン us-central1-a、us-central1-b、us-central1-c、us-central1-f が含まれています。

リージョン	ゾーン
米国西部	us-west1-a、us-west1-b
米国中部	us-central1-a、us-central1-b、us-central1-d、us-central1-f
米国東部	us-east1-b、us-east1-c、us-east1-d
西ヨーロッパ	europe-west1-b、europe-west1-c、europe-west1-d
東アジア	asia-east1-a、asia-east1-b、asia-east1-c

ゾーン内にあるリソースをゾーンリソースと呼びます。仮想マシン インスタンスと永続ディスクはゾーンに属します。永続ディスクを仮想マシン インスタンスにアタッチするには、両方のリソースを同じゾーン内に配置する必要があります。同様に、インスタンスに静的 IP アドレスを割り当てるには、インスタンスが静的 IP と同じリージョンに存在している必要があります。

Compute Engine ページのリージョンとゾーンのドキュメントで、リージョンとゾーンの詳細と一覧をご確認ください。

Google Cloud ネットワークの概念

Google Cloud Platform では、ネットワークがクラウド リソース（主に Compute Engine インスタンス）とのデータ接続を提供します。データの安全を確保し、リソースへのアクセスを制御するためには、ネットワークの保護が不可欠です。

Google Cloud Platform では、相互に関連のないリソースが、プロジェクト、ネットワーク、サブネットワークによって柔軟かつ論理的に分離されます。

プロジェクトは最も外側のコンテナで、同じ信頼境界を共有しているリソースのグループ分けに使用されます。プロジェクトごとに個別のアクセス ポリシー（IAM）とメンバーリストが割り当てられるため、デベロッパーの多くはプロジェクトをチームにマッピングします。リソース消費が反映される課金情報と割り当ての詳細も、プロジェクトごとに示されます。プロジェクトには、サブネットワーク、ファイアウォール ルール、ルートを含むネットワークが含まれます（下のアーキテクチャ図をご覧ください）。

ネットワークは、リソースを他のリソースや外部と直接接続し、ファイアウォールを使用して、着信接続と発信接続に関するアクセス ポリシーを実装します。ネットワークは、グローバル（複数のリージョンにまたがる水平方向のスケーラビリティを提供する）、リージョン別（単一のリージョンで低レイテンシを提供する）のいずれの実装も可能です。

サブネットワークを使用すれば、関連するリソース（Compute Engine インスタンス）を RFC1918 プライベート アドレス空間にグルーピングできます。サブネットワークはリージョン単位でのみ利用でき、自動モードまたはカスタムモードに設定可能です。

• 自動モードのネットワークはリージョンごとに 1 つのサブネットを持ち、それぞれにあらかじめ決められた IP 範囲とゲートウェイが割り当てられます。自動モードのネットワークを作成するとこのようなサブネットが自動的に作成され、各サブネットの名前はネットワーク全体と同じ名前になります。
• カスタムモードのネットワークでは、ネットワークの作成時にサブネットが作成されません。カスタムモードのネットワーク内にインスタンスを作成するには、まずそのリージョンでサブネットワークを作成し、IP 範囲を指定する必要があります。カスタムモードのネットワークでは、リージョンごとに 0 から複数個のサブネットを作成できます。

リージョンとゾーンを設定する

一部の Compute Engine リソースは、リージョン内やゾーン内に存在します。リージョンとは、リソースを実行できる特定の地理的なロケーションです。1 つのリージョンには 1 つ以上のゾーンがあります。

Google Cloud コンソールで次の gcloud コマンドを実行して、ラボのデフォルトのリージョンとゾーンを設定します。

gcloud config set compute/zone "{{{project_0.startup_script.primary_zone | Zone}}}" export ZONE=$(gcloud config get compute/zone) gcloud config set compute/region "{{{project_0.startup_script.primary_region | Region}}}" export REGION=$(gcloud config get compute/region)

タスク 1. デフォルト ネットワークを確認する

新しいプロジェクトを作成すると、デフォルトのネットワーク構成として、リージョンごとに自動サブネット ネットワークが 1 つ作成されます。1 つのプロジェクトに、最大 4 つのネットワークを追加作成できます。追加するネットワークは、自動サブネット ネットワーク、カスタム サブネット ネットワーク、レガシー ネットワークから選択できます。

サブネットワーク内で作成された各インスタンスには、そのサブネットワークの範囲から取得した IPv4 アドレスが割り当てられます。

• ネットワークを確認します。ナビゲーション メニュー > [VPC ネットワーク] をクリックします。

ファイアウォール

ファイアウォール ルールを使用してサブネットワークを分離する方法の詳細については、サブネットワークおよびファイアウォール ルールをご覧ください。

各ネットワークのデフォルトのファイアウォールは、インスタンスに向かうすべての受信トラフィックをブロックします。インスタンスに向かう受信トラフィックを許可するには、ファイアウォールの「許可」ルールを作成する必要があります。また、「下り（外向き）」ファイアウォール構成が外部接続をブロックするように構成されていない限り、インスタンスからのトラフィックは許可されます。そのため、デフォルトとして、上り（内向き）のアクセスを許可するトラフィックに「許可」ルールを作成し、下り（外向き）のアクセスを制限するトラフィックに「拒否」ルールを作成するとよいでしょう。デフォルトの下り（外向き）拒否ポリシーを作成し、外部接続を完全に禁止することもできます。

一般的には、許可するトラフィックの種類に対応した、できるだけ制限の厳しいファイアウォール ルールを構成することをおすすめします。たとえば、一部のインスタンスに到達するトラフィックを許可する一方で、他のインスタンスに到達するトラフィックを制限する必要がある場合、対象のインスタンスのみへのトラフィックを許可するルールを作成します。制限を厳しく構成することで、すべてのインスタンスへのトラフィックを許可する大規模なファイアウォール ルールよりも予測可能性が高まります。特定の「許可」ルールよりも優先される「拒否」ルールが必要な場合は、ルールごとに優先度レベルを設定できます。最も番号の小さい優先度のルールが最初に評価されます。ただし、大規模で複雑な優先ルールを作成すると、意図しないトラフィックが許可されたり、ブロックされたりすることがあります。

デフォルト ネットワークでは、以下に示すようなファイアウォール ルールが自動的に作成されます。ネットワークの種類を問わず、手動で作成したネットワークでファイアウォール ルールが自動的に作成されることはありません。デフォルト ネットワークを除くすべてのネットワークでは、必要に応じてファイアウォール ルールを作成する必要があります。

デフォルト ネットワーク用に自動的に作成される上り（内向き）ファイアウォール ルールを次に示します。

default-allow-internal	ネットワーク上のインスタンス間で行われる、任意のプロトコルとポートでのネットワーク接続を許可します。
default-allow-ssh	任意の送信元からネットワーク上の任意のインスタンスへの、TCP ポート 22 を介した SSH 接続を許可します。
default-allow-rdp	任意の送信元からネットワーク上の任意のインスタンスへの、TCP ポート 3389 を介した RDP 接続を許可します。
default-allow-icmp	任意の送信元からネットワーク上の任意のインスタンスへの ICMP トラフィックを許可します。

• デフォルトのファイアウォール ルールを確認するには、コンソールでナビゲーション メニュー > [VPC ネットワーク] > [ファイアウォール] をクリックします。

ネットワーク ルート

すべてのネットワークでは、インターネットへのルート（デフォルト ルート）とネットワーク内の IP 範囲へのルートが自動的に作成されます。ルート名は自動的に生成され、プロジェクトごとに違う名前になります。

• デフォルト ルートを確認するには、ナビゲーション メニュー > [VPC ネットワーク] > [ルート] をクリックします。

タスク 2. カスタム ネットワークを作成する

カスタム サブネット範囲を持つ新しいネットワークの作成

サブネットワークの範囲を手動で割り当てる場合は、まずカスタム サブネット ネットワークを作成してから、リージョンに配置するサブネットワークを作成します。サブネットワークは、すべてのリージョンに対して直ちに指定する必要はなく、指定しなくてもかまいません。ただし、サブネットワークが定義されていないリージョンにインスタンスを作成することはできません。

新しいサブネットワークを作成するときは、ネットワークが異なっても、リージョンが同じ場合はプロジェクト内で一意の名前にする必要があります。リージョンが異なる場合は、プロジェクト内で同じ名前を使用できます。サブネットワークにはネットワーク レベルの IPv4 範囲やゲートウェイ IP がないため、これらの情報は表示されません。

カスタム ネットワークは、コンソールまたは Cloud Shell で作成できます。両方の方法を説明しますが、このラボでどちらを使用するかを決めておく必要があります。コンソールの手順に沿ってセクションを進めているのに、gcloud コマンドラインを使用することはできません。

タスク 3. コンソールでカスタム ネットワークを作成する

注: コマンドラインを使用する場合は、このセクションをスキップして、Cloud Shell でカスタム ネットワークを作成するに進んでください。

1. カスタム ネットワークを作成するには、ナビゲーション メニュー > [VPC ネットワーク] をクリックします。

2. [VPC ネットワークを作成] をクリックし、「taw-custom-network」という名前を付けます。

3. [カスタム] タブで次のように入力します。

   • サブネット名: subnet-
   • リージョン:
   • IP アドレス範囲: 10.0.0.0/16

4. [完了] をクリックします。

   

5. 次に [サブネットを追加] をクリックし、次の 2 つのサブネットをそれぞれのリージョンに追加します。

   • subnet-, , 10.1.0.0/16
   • subnet-, , 10.2.0.0/16

6. [作成] をクリックして完了します。

この時点でネットワークには、インターネットへのルートと、今後作成するインスタンスへのルートが用意されています。ただし、インスタンスへのアクセスを許可するファイアウォール ルールが存在しないため、他のインスタンスからのものも含め、アクセスは許可されません。アクセスを許可するには、ファイアウォール ルールを作成する必要があります。

ファイアウォール ルールの追加セクションに進みます。

タスク 4. Cloud Shell でカスタム ネットワークを作成する

注: コンソールを使ってネットワークを作成した場合は、Cloud Shell を使って同じ演習を行わないでください。gcloud コマンドラインの使い方を練習するには、ラボを再度受講してください。

• Cloud Shell に次のコマンドを入力して、カスタム ネットワークを作成します。

gcloud compute networks create taw-custom-network --subnet-mode custom

出力:

NAME MODE IPV4_RANGE GATEWAY_IPV4 taw-custom-network custom このネットワーク上のインスタンスは、ファイアウォール ルールが作成されるまでアクセスできません。 たとえば、以下を実行して、インスタンス間のすべての内部トラフィック、SSH、RDP、ICMP を許可できます。 $ gcloud compute firewall-rules create --network taw-custom-network --allow tcp,udp,icmp --source-ranges $ gcloud compute firewall-rules create --network taw-custom-network --allow tcp:22,tcp:3389,icmp

次に新しいカスタム ネットワークにサブネットを作成します。3 つのサブネットが作成されます。

1. IP 接頭辞を指定して、subnet-を作成します。

gcloud compute networks subnets create subnet-{{{project_0.startup_script.primary_region | Region}}} \ --network taw-custom-network \ --region {{{project_0.startup_script.primary_region | Region}}} \ --range 10.0.0.0/16

出力:

Created [https://www.googleapis.com/compute/v1/projects/cloud-network-module-101/regions/{{{project_0.startup_script.primary_region | Region}}}/subnetworks/subnet-{{{project_0.startup_script.primary_region | Region}}}]. NAME REGION NETWORK RANGE subnet-{{{project_0.startup_script.primary_region | Region}}} {{{project_0.startup_script.primary_region | Region}}} taw-custom-network 10.0.0.0/16

2. IP 接頭辞を指定して、subnet-を作成します。

gcloud compute networks subnets create subnet-{{{project_0.startup_script.secondary_region | Region}}} \ --network taw-custom-network \ --region {{{project_0.startup_script.secondary_region | Region}}} \ --range 10.1.0.0/16

出力:

Created [https://www.googleapis.com/compute/v1/projects/cloud-network-module-101/regions/{{{project_0.startup_script.secondary_region | Region}}}/subnetworks/subnet-{{{project_0.startup_script.secondary_region | Region}}}]. NAME REGION NETWORK RANGE subnet-{{{project_0.startup_script.secondary_region | Region}}} {{{project_0.startup_script.secondary_region | Region}}} taw-custom-network 10.1.0.0/16

3. IP 接頭辞を指定して、subnet-を作成します。

gcloud compute networks subnets create subnet-{{{project_0.startup_script.third_region | Region}}} \ --network taw-custom-network \ --region {{{project_0.startup_script.third_region | Region}}} \ --range 10.2.0.0/16

出力:

Created [https://www.googleapis.com/compute/v1/projects/cloud-network-module-101/regions/{{{project_0.startup_script.third_region | Region}}}/subnetworks/subnet-{{{project_0.startup_script.third_region | Region}}}]. NAME REGION NETWORK RANGE subnet-{{{project_0.startup_script.secondary_region | Region}}} {{{project_0.startup_script.secondary_region | Region}}} taw-custom-network 10.2.0.0/16

4. ネットワークを一覧表示します。

gcloud compute networks subnets list \ --network taw-custom-network

前のセクションの自動サブネット ネットワークを作成した場合は、そのサブネットも一覧表示されます。

出力:

NAME REGION NETWORK RANGE subnet-{{{project_0.startup_script.third_region | Region}}} {{{project_0.startup_script.third_region | Region}}} taw-custom-network 10.1.0.0/16 subnet-{{{project_0.startup_script.secondary_region | Region}}} {{{project_0.startup_script.secondary_region | Region}}} taw-custom-network 10.2.0.0/16 subnet-{{{project_0.startup_script.primary_region | Region}}} {{{project_0.startup_script.primary_region | Region}}} taw-custom-network 10.0.0.0/16

この時点でネットワークには、インターネットへのルートと、今後作成するインスタンスへのルートが用意されています。ただし、インスタンスへのアクセスを許可するファイアウォール ルールが存在しないため、他のインスタンスからのものも含め、アクセスは許可されません。アクセスを許可するには、ファイアウォール ルールを作成する必要があります。

タスク 5. ファイアウォール ルールを追加する

VM インスタンスへのアクセスを許可するには、ファイアウォール ルールを適用する必要があります。ファイアウォール ルールを VM インスタンスに適用するには、インスタンス タグを使用します。ファイアウォール ルールは同じインスタンス タグを持つすべての VM に適用されます。

注: インスタンス タグはネットワークとファイアウォールで使用され、タグの付いた VM インスタンスに特定のファイアウォール ルールが適用されます。たとえば、同じタスク（大規模なウェブサイトへのサービス提供など）を実行する複数のインスタンスが存在する場合は、共通の用語を使ってインスタンスにタグを付け、そのタグを使用してそれらのファイアウォール付きインスタンスに対する HTTP アクセスを許可できます。

タグはメタデータ サーバーにも反映されるため、インスタンス上で実行中のアプリケーションにも使用できます。

• まず、HTTP インターネット リクエストを許可するためにファイアウォールを開いてから、ファイアウォール ルールを追加します。ファイアウォール ルールの追加には、コンソールまたは Cloud Shell を使用します。

コンソールを使用してファイアウォール ルールを追加する

1. コンソールで [VPC ネットワーク] メニューに進み、taw-custom-networking ネットワークをクリックします。

2. [ファイアウォール] タブをクリックし、次に [ファイアウォール ルールを追加] をクリックします。

3. 次の情報を入力します。

フィールド	値	コメント
名前	nw101-allow-http	新しいルールの名前
ターゲット	指定されたターゲットタグ	ファイアウォール ルールの適用先のインスタンス
ターゲットタグ	http	作成したタグ
ソースフィルタ	IPv4 範囲	インターネットのどの IP アドレスに対してもファイアウォールを開きます
送信元 IPv4 範囲	0.0.0.0/0	インターネットのどの IP アドレスに対してもファイアウォールを開きます
プロトコルとポート	[指定したプロトコルとポート]、[tcp] の順にチェックボックスをオンにし、「80」と入力します	HTTP のみ

画面は次のようになります。

4. [作成] をクリックし、コマンドが成功するまで待ちます。次に、必要に応じて追加のファイアウォール ルールを作成します。

Cloud Shell を使用してファイアウォール ルールを追加する

注: コンソールを使ってネットワークを作成した場合は、Cloud Shell を使って同じ演習を行わないでください。gcloud コマンドラインの使い方を練習するには、ラボを再度受講してください。

• Cloud Shell でファイアウォール ルールを作成するには、次のコマンドを実行します。

gcloud compute firewall-rules create nw101-allow-http \ --allow tcp:80 --network taw-custom-network --source-ranges 0.0.0.0/0 \ --target-tags http

出力:

追加のファイアウォール ルールを作成する

追加で作成するこれらのファイアウォール ルールによって、ICMP、内部通信、SSH、RDP が許可されます。これらはコンソール（または Cloud Shell）を使用して作成できます。ファイアウォール ルールの種類ごとに、どちらか一方の方法を使用してください。両方は使用できません。

• ICMP

フィールド	値	コメント
名前	nw101-allow-icmp	新しいルールの名前
ターゲット	指定されたターゲットタグ	[ターゲット] プルダウンから選択します
ターゲットタグ	rules	タグ
ソースフィルタ	IPv4 範囲	このリストにあるどの IP アドレスに対してもファイアウォールを開きます
送信元 IPv4 範囲	0.0.0.0/0	インターネットのどの IP アドレスに対してもファイアウォールを開きます
プロトコルとポート	[指定したプロトコルとポート]、[その他のプロトコル] の順にチェックボックスをオンにし、「icmp」と入力します	ファイアウォールが適用されるプロトコルとポート

（Cloud Shell コマンド）

gcloud compute firewall-rules create "nw101-allow-icmp" --allow icmp --network "taw-custom-network" --target-tags rules

• 内部通信

フィールド	値	コメント
名前	nw101-allow-internal	新しいルールの名前
ターゲット	ネットワーク上のすべてのインスタンス	[ターゲット] プルダウンから選択します
ソースフィルタ	IPv4 範囲	ルールを特定のトラフィック ソースに適用するために使用するフィルタ
送信元 IPv4 範囲	10.0.0.0/16, 10.1.0.0/16, 10.2.0.0/16	インターネットのどの IP アドレスに対してもファイアウォールを開きます
プロトコルとポート	[指定したプロトコルとポート]、[tcp] の順にチェックボックスをオンにし、「0-65535」と入力します。[udp] をオンにし、「0-65535」と入力します。[その他のプロトコル] をオンにし、「icmp」と入力します	Tcp:0-65535、udp:0-65535、icmp を許可します

（Cloud Shell コマンド）

gcloud compute firewall-rules create "nw101-allow-internal" --allow tcp:0-65535,udp:0-65535,icmp --network "taw-custom-network" --source-ranges "10.0.0.0/16","10.2.0.0/16","10.1.0.0/16"

• SSH

フィールド	値	コメント
名前	nw101-allow-ssh	新しいルールの名前
ターゲット	指定されたターゲットタグ	ssh
ターゲットタグ	ssh	ファイアウォール ルールを適用するインスタンス
ソースフィルタ	IPv4 範囲	ルールを特定のトラフィック ソースに適用するために使用するフィルタ
送信元 IPv4 範囲	0.0.0.0/0	インターネットのどの IP アドレスに対してもファイアウォールを開きます
プロトコルとポート	[指定したプロトコルとポート]、[tcp] の順にチェックボックスをオンにし、「22」と入力します	tcp:22 を許可します

（Cloud Shell コマンド）

gcloud compute firewall-rules create "nw101-allow-ssh" --allow tcp:22 --network "taw-custom-network" --target-tags "ssh"

• RDP

フィールド	値	コメント
名前	nw101-allow-rdp	新しいルールの名前
ターゲット	ネットワーク上のすべてのインスタンス	[ターゲット] プルダウンから選択します
ソースフィルタ	IPv4 範囲	IP アドレスをフィルタリングします
送信元 IPv4 範囲	0.0.0.0/0	インターネットのどの IP アドレスに対してもファイアウォールを開きます
プロトコルとポート	[指定したプロトコルとポート]、[tcp] の順にチェックボックスをオンにし、「3389」と入力します	tcp:3389 を許可します

（Cloud Shell コマンド）

gcloud compute firewall-rules create "nw101-allow-rdp" --allow tcp:3389 --network "taw-custom-network"

• コンソールを使用してネットワーク内のファイアウォール ルールを確認します。次のようになります。

注: ネットワーク コンソールに表示されるルートについて

Google Cloud ネットワーキングは、サブネットワーク間で、またはインターネットにパケットを振り向けるためにルートを使用します。ネットワーク内にサブネットワークが新規に作成（または事前に作成）されると、サブネットワーク間でのパケットのルーティングを可能にするために、リージョンごとに自動的にルートが作成されます。これは変更できません。

ただし、インスタンス、VPN ゲートウェイ、デフォルトのインターネット ゲートウェイにトラフィックを送信するために、追加ルートを作成することができます。このルートは、希望のネットワーク アーキテクチャに合わせて変更できます。ルートとファイアウォールは連携して、トラフィックを送信先へ確実に届けます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。

カスタム ネットワーク、サブネットワーク、ファイアウォール ルールを作成する

タスク 6. ラボ用 VM に接続してレイテンシを確認する

• 左側のメニューで [VPC ネットワーク] をクリックすると、ネットワーク全体が表示されます。「taw-custom-network」には 3 つのサブネットワークがあり、ファイアウォール ルールが適用されています。

次のようになっているはずです。

次に、サブネットごとに VM を作成し、接続できることを確認します。

ゾーンごとに VM を作成する

ラボのこのセクションでは、Cloud Shell を使用します。

1. 次のコマンドを実行して us-test-01 というインスタンスを subnet- サブネットに作成します。

gcloud compute instances create us-test-01 \ --subnet subnet-{{{project_0.startup_script.primary_region | Region}}} \ --zone {{{project_0.startup_script.primary_zone | ZONE}}} \ --machine-type e2-standard-2 \ --tags ssh,http,rules

外部 IP を必ずメモしてください。このラボで後ほど使用します。

出力:

Created [https://www.googleapis.com/compute/v1/projects/cloud-network-module-101/zones/{{{project_0.startup_script.primary_zone | ZONE}}}/instances/us-test-01]. NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS us-test-01 {{{project_0.startup_script.primary_zone | ZONE}}} e2-standard-2 10.0.0.2 104.198.230.22 RUNNING

2. 次のように us-test-02 と us-test-03 の各 VM を関連付けられたサブネットに作成します。

gcloud compute instances create us-test-02 \ --subnet subnet-{{{project_0.startup_script.secondary_region | REGION}}} \ --zone {{{project_0.startup_script.secondary_zone | ZONE}}} \ --machine-type e2-standard-2 \ --tags ssh,http,rules gcloud compute instances create us-test-03 \ --subnet subnet-{{{project_0.startup_script.third_region | REGION}}} \ --zone {{{project_0.startup_script.third_zone | ZONE}}} \ --machine-type e2-standard-2 \ --tags ssh,http,rules

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。

traceroute とパフォーマンス テストを目的として、指定されたゾーンに 3 つのインスタンスを作成する

VM に接続できることを確認する

次に、いくつかの操作を実行して VM に接続できるかテストします。

1. コンソールに戻り、[Compute Engine] に進みます。

2. us-test-01 インスタンスに対応する [SSH] ボタンをクリックします。新しいウィンドウにインスタンスへの SSH 接続が表示されます。

3. us-test-01 の SSH ウィンドウで次のコマンドを入力し、VM の外部 IP アドレスを加えて、us-test-02 に対して ICMP エコーを実行します。

ping -c 3 <us-test-02-external-ip-address> 注: 仮想マシンの外部 IP アドレスは、[Compute Engine] ブラウザタブの [外部 IP] フィールドで確認できます。

実際の IP アドレスは、画像とは異なります。

4. VM の外部 IP アドレスを加えて次のコマンドを実行し、us-test-03 に対して ICMP エコーを実行します。

ping -c 3 <us-test-03-external-ip-address>

出力例:

PING 35.187.149.67 (35.187.149.67) 56(84) bytes of data. 64 bytes from 35.187.149.67: icmp_seq=1 ttl=76 time=152 ms 64 bytes from 35.187.149.67: icmp_seq=2 ttl=76 time=152 ms 64 bytes from 35.187.149.67: icmp_seq=3 ttl=76 time=152 ms

5. 次に、インスタンス us-test-02 と us-test-03 にも SSH 接続できることを確認します。us-test-01 に対して ICMP エコーを実行してみてください。

ping でレイテンシを測定する

ping を使用して、すべてのリージョンのインスタンス間レイテンシを測定します。

• US Central リージョンから Europe West リージョンへのレイテンシを確認するには、us-test-01 で SSH ウィンドウを開き、次のコマンドを実行します。

ping -c 3 us-test-02.{{{project_0.startup_script.secondary_zone | ZONE}}}

コマンド出力:

PING us-test-02.{{{project_0.startup_script.secondary_zone | ZONE}}}.c.cloud-network-module-101.internal (10.2.0.2) 56(84) bytes of data. 64 bytes from us-test-02.{{{project_0.startup_script.secondary_zone | ZONE}}}.c.cloud-network-module-101.internal (10.2.0.2): icmp_seq=1 ttl=64 time=105 ms 64 bytes from us-test-02.{{{project_0.startup_script.secondary_zone | ZONE}}}.c.cloud-network-module-101.internal (10.2.0.2): icmp_seq=2 ttl=64 time=104 ms 64 bytes from us-test-02.{{{project_0.startup_script.secondary_zone | ZONE}}}.c.cloud-network-module-101.internal (10.2.0.2): icmp_seq=3 ttl=64 time=104 ms

出力されるレイテンシは、「ラウンド トリップ時間」（RTT）、つまり、us-test-01 から us-test-02 にパケットが到達するまでに要する時間です。

接続をテストするために、ping は ICMP エコー リクエストおよびエコー応答メッセージを使用します。

注: 考察のポイント

リージョン間のレイテンシはどの程度でしたか。理想的にはどの程度であるべきでしょうか。「us-test-02」から「us-test-03」への接続で他と異なる点は何ですか。 注: 内部 DNS: DNS は VM インスタンスにどのように提供されるか

各インスタンスにはメタデータ サーバーがあり、そのインスタンスの DNS リゾルバとしても機能します。DNS ルックアップはインスタンス名に対して実行されます。メタデータ サーバー自体は、ローカル ネットワークのすべての DNS 情報を保持します。ローカル ネットワーク外のアドレスについては、Google のパブリック DNS サーバーに問い合わせます。

インスタンスの内部完全修飾ドメイン名（FQDN）は、hostName.[ZONE].c.[PROJECT_ID].internal のような形式です。

あるインスタンスから別のインスタンスには、常にこの FQDN を使用して接続できます。ただし、hostName などの情報だけを使用してインスタンスに接続する場合は、Compute Engine に含まれる内部 DNS リゾルバからの情報が必要になります。

タスク 7. traceroute とパフォーマンス テスト

追加の演習（任意）

traceroute は 2 台のホスト間のパスをトレースするツールです。ネットワークに関するさまざまな問題を明らかにするための最初のステップとして役立ちます。traceroute は、ネットワークに関する問題を診断する際にサポート エンジニアやネットワーク エンジニアによく利用されています。

注: 機能

traceroute は、ホスト間のすべてのレイヤ 3（ルーティング レイヤ）ホップを表示します。これは TTL（有効期間）値を 1 から開始して増やしながら、リモート宛先にパケットを送信することで行われます。TTL フィールドは IP パケットのフィールドのひとつで、ルーターを通過するごとに 1 つずつ値が減ります。TTL がゼロになるとパケットは廃棄され、「TTL exceeded」という ICMP メッセージが送信者に返されます。この方法は、ルーティングのループを回避するために使用されます（TTL フィールドは最終的に 0 まで減るため、パケットがループし続けることがありません）。デフォルトでは、OS は TTL 値を大きな値（64、128、255 など）に設定するため、0 に達するのは異常な状態の場合のみです。

traceroute は TTL 値が 1 のパケット、TTL 値が 2 のパケットと順に送信するので、これらのパケットはパス内の最初のルーター、2 番目のルーターで順に期限切れとなります。その後、返された TTL exceeded メッセージから ICMP のソース IP とホストが取得され、中間ホップの名前と IP が表示されます。TTL が十分に大きくなると、パケットは宛先に到達し、宛先から応答があります。

送信されるパケットの種類は実装によって異なります。Linux では、UDP パケットが上位の未使用ポートに送信されます。したがって、最終宛先からは ICMP Port Unreachable が返されます。Windows と mtr ツールはデフォルトで ICMP エコー要求（ping など）を使用するので、最終宛先から ICMP エコー応答が返されます。

仮想マシンのいずれかに traceroute を設定して動作を確かめてみましょう。

1. このステップでは、もう一度 us-test-01 VM と us-test-02 VM を使用します。どちらにも SSH で接続します。

2. us-test-01 の SSH ウィンドウで次のパフォーマンス ツールをインストールします。

sudo apt-get update sudo apt-get -y install traceroute mtr tcpdump iperf whois host dnsutils siege traceroute www.icann.org

3. 次のように宛先や送信元を変えて試してみましょう。

   • 同じリージョンまたは別のリージョンの VM（eu1-vm、asia1-vm、w2-vm）
   • www.wikipedia.org
   • www.adcash.com
   • bad.horse（最大 TTL 値を大きくした場合にうまく動作するので traceroute -m 255 bad.horse とします）
   • その他、任意の宛先や送信先

4. traceroute を停止する場合は、SSH ウィンドウで Ctrl+C キーを押してコマンドラインに戻ります。

注: 考察のポイント

異なる traceroute について、どのようなことがわかりますか。

タスク 8. iperf を使ってパフォーマンスをテストする

2 台のホスト間

追加の演習（任意）

iperf を使用して 2 台のホスト間のパフォーマンスをテストする場合は、接続を受け入れるために、一方のホストを iperf サーバーとして設定する必要があります。

注: 次のコマンドを実行すると、リージョン間でギガバイト単位のトラフィックが転送されます。これにはインターネット下り（外向き）料金がかかります。このコマンドを使用するときは、この点に注意してください。許可リスト登録済みプロジェクトで作業していない場合や、無料トライアル中でない場合は、このセクションをスキップするか目を通すだけにしてもかまいません（見込まれる料金は 1 米ドル未満です）。

とてもシンプルなテストを実行してみましょう。

1. us-test-02 に SSH 接続し、次のようにパフォーマンス ツールをインストールします。

sudo apt-get update sudo apt-get -y install traceroute mtr tcpdump iperf whois host dnsutils siege

2. us-test-01 に SSH 接続し、次を実行します。

iperf -s #サーバーモードで実行

3. us-test-02 SSH で、次の iperf を実行します。

iperf -c us-test-01.{{{project_0.startup_script.primary_zone | ZONE}}} #クライアント モードで実行

以下のような出力が表示されます。

Client connecting to eu-vm, TCP port 5001 TCP window size: 45.0 KByte (default) [ 3] local 10.20.0.2 port 35923 connected with 10.30.0.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 298 MBytes 249 Mbits/sec

4. 完了したら、us-test-01 で Ctrl+C キーを押してサーバー側セッションを終了します。

リージョン内の VM 間

追加の演習（任意）

次に、別のインスタンス（us-test-04）を us-test-01 以外のゾーンにデプロイします。リージョン内では、帯域幅の下り（外向き）上限がコアあたり 2 Gbpsに制限されています。

1. Cloud Shell で us-test-04 を作成します。

gcloud compute instances create us-test-04 \ --subnet subnet-{{{project_0.startup_script.primary_region | REGION}}} \ --zone {{{project_0.startup_script.primary_zone_1 | ZONE}}} \ --tags ssh,http

2. us-test-04 に SSH 接続し、次のようにパフォーマンス ツールをインストールします。

sudo apt-get update sudo apt-get -y install traceroute mtr tcpdump iperf whois host dnsutils siege

リージョン間の上限はさらに低くなっています。これは主に、TCP ウィンドウ サイズとシングル ストリームのパフォーマンスにおける制限が原因です。UDP などの他のパラメータを使用すると、ホスト間の帯域幅を増やすことができます。

3. us-test-02 の SSH で次を実行します。

iperf -s -u #iperf サーバー側

4. us-test-01 の SSH で次を実行します。

iperf -c us-test-02.{{{project_0.startup_script.secondary_zone | ZONE}}} -u -b 2G #iperf クライアント側 - 2 Gbps で送信

このコマンドで EU と US の間の速度が上がります。大量の TCP iperfs を並列実行するとさらにスピードを上げることができます。これをテストしてみましょう。

5. us-test-01 の SSH ウィンドウで次を実行します。

iperf -s

6. us-test-02 の SSH ウィンドウで次を実行します。

iperf -c us-test-01.{{{project_0.startup_script.primary_zone | ZONE}}} -P 20

組み合わせた帯域幅は、達成可能な最大帯域幅にかなり近くなっているはずです。

7. さらにいくつかの組み合わせをテストします。ノートパソコンで Linux を使用している場合、このノートパソコンに対してもテストを実行できます（多くの OS で利用可能な iperf3 も試すことができますが、このラボでは扱いません）。

最大帯域幅に到達するには、シングル TCP ストリーム（ファイルコピーなど）を実行するだけでは不十分です。複数の TCP セッションを並列に確立する必要があります。理由としては、Window Size などの TCP パラメータや、Slow Start などの機能があげられます。

詳細情報とその他すべての TCP/IP トピックについては、TCP/IP Illustrated を参照してください。

bbcp などのツールを使用すると、転送の並列化や構成可能なウィンドウ サイズを利用して迅速にファイルをコピーできます。

タスク 9. 理解度テスト

ラボを終了する

ラボが完了したら、[ラボを終了] をクリックします。ラボのプラットフォームから、アカウントと使用したリソースが削除されます。

ラボの評価を求めるダイアログが表示されたら、星の数を選択してコメントを入力し、[送信] をクリックします。

星の数は、それぞれ次の評価を表します。

• 星 1 つ = 非常に不満
• 星 2 つ = 不満
• 星 3 つ = どちらともいえない
• 星 4 つ = 満足
• 星 5 つ = 非常に満足

フィードバックを送信しない場合は、ダイアログ ボックスを閉じてください。

フィードバックやご提案の送信、修正が必要な箇所をご報告いただく際は、[サポート] タブをご利用ください。

次のラボを受講する

「複数の VPC ネットワーク」に進んで Google Cloud のネットワーキングについての学習を続けるか、以下のおすすめのラボをご確認ください。

• Cloud KMS のスタートガイド
• Kubernetes を使った Cloud のオーケストレーション

準備ができたら、ぜひ「Networking in the Google Cloud」クエストをお試しください。

Google Cloud トレーニングと認定資格

Google Cloud トレーニングと認定資格を通して、Google Cloud 技術を最大限に活用できるようになります。必要な技術スキルとベスト プラクティスについて取り扱うクラスでは、学習を継続的に進めることができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、バーチャル参加など、多忙なスケジュールにも対応できるオプションが用意されています。認定資格を取得することで、Google Cloud テクノロジーに関するスキルと知識を証明できます。

マニュアルの最終更新日: 2023 年 9 月 11 日

ラボの最終テスト日: 2023 年 9 月 11 日

Copyright 2024 Google LLC All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。