概要

このラボでは、Virtual Private Cloud（VPC）ネットワークを調査し、ネットワークとインスタンスへのアクセスを許可または拒否するファイアウォール ルールを作成します。

まず、自動 VPC ネットワークと VPC インスタンスをいくつか作成します。default-allow-ssh ファイアウォール ルールが機能することを確認し、default-allow-ssh ファイアウォール ルールとユーザーが作成したカスタム ネットワークを比較して、カスタム ファイアウォール ルールなしで内向きトラフィックが許可されないことを検証します。

デフォルトのネットワークを削除したら、ファイアウォール ルールの優先値を使用して、VM への内向きと外向きの両方のネットワーク トラフィックを許可します。

目標

このラボでは、次の方法について学びます。

• 自動モードのネットワークとサブネットを作成する
• デフォルト ネットワークのファイアウォール ルールを調査した後、デフォルト ネットワークを削除する。
• ファイアウォール ルールの機能を使用して、接続をより細かく柔軟に制御する。

設定と要件

各ラボでは、新しい Google Cloud プロジェクトとリソースセットを一定時間無料で利用できます。

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

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

2. [Google Cloud コンソールを開く] をクリックします（Chrome ブラウザを使用している場合は、右クリックして [シークレット ウィンドウで開く] を選択します）。

   ラボでリソースが起動し、別のタブで [ログイン] ページが表示されます。

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

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

3. 必要に応じて、下のユーザー名をコピーして、[ログイン] ダイアログに貼り付けます。

   {{{user_0.username | "Username"}}}

   [ラボの詳細] パネルでもユーザー名を確認できます。

4. [次へ] をクリックします。

5. 以下のパスワードをコピーして、[ようこそ] ダイアログに貼り付けます。

   {{{user_0.password | "Password"}}}

   [ラボの詳細] パネルでもパスワードを確認できます。

6. [次へ] をクリックします。

   重要: ラボで提供された認証情報を使用する必要があります。Google Cloud アカウントの認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。

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

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

その後、このタブで Google Cloud コンソールが開きます。

注: Google Cloud のプロダクトやサービスのリストを含むメニューを表示するには、左上のナビゲーション メニューをクリックするか、[検索] フィールドにサービス名またはプロダクト名を入力します。

Google Cloud Shell の有効化

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

Google Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。

1. Google Cloud コンソールで、右上のツールバーにある [Cloud Shell をアクティブにする] ボタンをクリックします。

   

2. [続行] をクリックします。

環境がプロビジョニングされ、接続されるまでしばらく待ちます。接続した時点で認証が完了しており、プロジェクトに各自のプロジェクト ID が設定されます。次に例を示します。

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

• 次のコマンドを使用すると、有効なアカウント名を一覧表示できます。

gcloud auth list

出力:

Credentialed accounts: - @.com (active)

出力例:

Credentialed accounts: - google1623327_student@qwiklabs.net

• 次のコマンドを使用すると、プロジェクト ID を一覧表示できます。

gcloud config list project

出力:

[core] project =

出力例:

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

タスク 1. VPC ネットワークとインスタンスの作成

このタスクでは、自動 VPC ネットワークと初期 VPC インスタンスをいくつか作成します。

1. Google Cloud コンソールのタイトルバーで、「Cloud Shell をアクティブにする」アイコン（）をクリックして Cloud Shell を開きます。プロンプトが表示されたら、[続行] をクリックします。
2. 次のコマンドを実行して、自動サブネットを持つネットワーク mynetwork を作成します。

gcloud compute networks create mynetwork --subnet-mode=auto 注: 自動モード VPC ネットワークが作成されると、各リージョンから 1 つのサブネットがネットワーク内に自動的に作成されます。このような自動作成されたサブネットでは、10.128.0.0/9 CIDR ブロックに収まる一連の事前定義された IP 範囲が使用されます。

3. 次のコマンドを実行して、後ですべてのネットワークでのテストに使用するインスタンスをいくつか作成します。

gcloud compute instances create default-vm-1 \ --machine-type e2-micro \ --zone={{{project_0.default_zone | Zone 1}}} --network=default gcloud compute instances create mynet-vm-1 \ --machine-type e2-micro \ --zone={{{project_0.default_zone | Zone 1}}} --network=mynetwork gcloud compute instances create mynet-vm-2 \ --machine-type e2-micro \ --zone={{{project_0.default_zone_2| Zone 2}}} --network=mynetwork

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 VPC ネットワークとインスタンスの作成

タスク 2. デフォルト ネットワークの調査

このタスクでは、デフォルト ネットワークを調べて、default-allow-ssh ファイアウォール ルールが機能することを検証します。その後不要となる、default-vm-1 インスタンスとデフォルト ネットワークを削除します。

Cloud コンソールに戻り、ファイアウォール ルールを参照します。

1. ナビゲーション メニューで [VPC ネットワーク] > [ファイアウォール] をクリックします。

デフォルト ネットワークのために、次の 4 つのデフォルト ルールが作成されています。

すべてのネットワークには、コンソールに表示されない次の 2 つのルールも適用されることに注意してください。

default-allow-ssh ファイアウォール ルールが機能することを確認するために、デフォルト ネットワークの default-vm-1 インスタンスに SSH 接続してテストします。

2. ナビゲーション メニューで [Compute Engine] > [VM インスタンス] の順にクリックして、VM インスタンスのリストを表示します。

3. default-vm-1 インスタンスの行で、[SSH] をクリックします。

default-allow-ssh ルールが機能していれば、SSH 接続は成功します。www.google.com に ping することで、外向きの接続をテストできます。Ctrl+C キーを押して ping を停止します。

default-vm-1 インスタンスの削除

default-vm-1 インスタンスは必要なくなったため、削除します。

1. ナビゲーション メニューで [Compute Engine] > [VM インスタンス] をクリックし、[default-vm-1] インスタンスを選択して [削除] をクリックします。

2. 確認のボックスで [削除] をクリックします。

デフォルト ネットワークの削除

注: デフォルト ネットワークは比較的オープンなアクセスを許可するため、本番環境のプロジェクトでは削除することを推奨します。

1. Cloud コンソールのナビゲーション メニューで [VPC ネットワーク] > [VPC ネットワーク] をクリックし、VPC ネットワークのリストを表示します。

2. デフォルトのネットワークをクリックして、ネットワークの詳細を参照します。

3. [VPC ネットワークの削除] をクリックします。

4. 確認のボックスで [削除] をクリックします。

5. ネットワークが削除されるまで待ち、デフォルト ネットワークが [VPC ネットワーク] ページに表示されなくなったことを確認します。

タスク 3. ユーザーが作成したネットワークの調査

このタスクでは、ユーザーが作成したネットワークを調べて、カスタム ファイアウォール ルールなしでは内向きトラフィックが許可されないことを検証します。

カスタム ファイアウォール ルールなしでは内向きが許可されないことの検証

すべてのネットワークには、すべての受信トラフィックをブロックし、すべての発信トラフィックを許可するという 2 つのルール（コンソールに表示されない）があるので注意してください。デフォルト ネットワークとは異なり、ユーザーが作成したネットワークにはデフォルトで他のルールが適用されないため、現時点では受信トラフィックが一切許可されていません。

1. ナビゲーション メニューで [Compute Engine] > [VM インスタンス] の順にクリックして、VM インスタンスのリストを表示します。

2. mynet-vm-1 または mynet-vm-2 の行で、[SSH] をクリックします。

SSH 経由でインスタンスに接続することはできません。

次に、Cloud Shell からインスタンスへの SSH 接続を試行します。

3. Cloud Shell に戻るか、再度開きます。

4. 次のコマンドを実行して、mynet-vm-2 インスタンスへの SSH 接続を試行します。

gcloud compute ssh qwiklabs@mynet-vm-2 --zone {{{project_0.default_zone_2| Zone 2}}}

プロンプトが表示されたら「Y」と入力し、Enter キーを 2 回押して続行します。

SSH 経由でインスタンスに接続することはできません。現時点で、受信アクセスは一切許可されていないからです。 エラー メッセージ「ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [255]」は無視します。

タスク 4. カスタム内向きファイアウォール ルールの作成

このタスクでは、クライアント ホストとして Cloud Shell を使用して、インスタンスへの SSH 接続をテストします。Cloud Shell インスタンスの外部 IP アドレスは簡単に取得できます。

ただし、Cloud Shell インスタンスの IP アドレスは、クローズして再オープンした場合や、一定期間操作がなかったためリサイクルされたことによって変化する可能性があります。このラボでこれが問題となることはありません。実際のプロジェクトでは SSH クライアント ホストの IP アドレスを許可してください。これにより、問題がなくなります。

注: 先ほど検証したとおり、VM インスタンスに接続するために使用されるブラウザベースのコンソール SSH 機能は現時点で機能しません。VM インスタンスへの接続を許可するには、ソース IP アドレスを許可するファイアウォール ルールが必要になります。ただし、ブラウザベースの SSH セッションのソース IP アドレスは、Cloud コンソールによって動的に割り振られるため、セッションごとに異なる場合があります。

この機能を動作させるには、任意の IP アドレスからの接続、またはパブリック SPF レコードを使用して取得できる Google の IP アドレス範囲からの接続を許可する必要があります。要件によっては、これらのいずれかのオプションを使用することで、許容できないリスクが発生することがあります。そこで、接続に使用する SSH クライアントの IP アドレスを許可すると、このリスクを回避できます。

Cloud Shell からの SSH アクセスを許可する

1. Cloud Shell に戻るか、再度開きます。

2. 次のコマンドを実行し、Cloud Shell インスタンスの外部 IP アドレスを取得します。

ip=$(curl -s https://api.ipify.org) echo "My External IP address is: $ip"

出力例（実際の IP アドレスは異なります）:

My External IP address is: 35.229.72.135

3. 次のコマンドを実行し、Cloud Shell IP アドレスからのポート 22（SSH）のトラフィックを許可するファイアウォール ルールを追加します。

gcloud compute firewall-rules create \ mynetwork-ingress-allow-ssh-from-cs \ --network mynetwork --action ALLOW --direction INGRESS \ --rules tcp:22 --source-ranges $ip --target-tags=lab-ssh

このファイアウォール ルールには lab-ssh というターゲットタグも付けられます。これにより、このファイアウォール ルールは lab-ssh タグが付いたインスタンスにのみ適用されます。

4. ナビゲーション メニューで [VPC ネットワーク] > [ファイアウォール] の順にクリックし、Cloud コンソールでファイアウォール ルールを参照します。

次のように表示されますが、実際の IP アドレスは異なります。

このファイアウォール ルールは、lab-ssh タグが付いたインスタンスにのみ適用されます。現時点では、いずれのインスタンスにも適用されていません。

注: 先ほど、タグを使用してファイアウォール ルールを作成、適用しました。タグはインスタンスにも追加する必要があり、誤って追加または削除されることも考えられます。ファイアウォール ルールのインスタンスへの適用は、使用しているサービス アカウントごとに行うことも可能です。これらのルールは、指定されたサービス アカウントを使用するすべてのインスタンスに自動的に適用されます。

5. Cloud Shell で次のコマンドを実行し、lab-ssh ネットワーク タグを mynet-vm-2 インスタンスと mynet-vm-1 インスタンスに追加します。

gcloud compute instances add-tags mynet-vm-2 \ --zone {{{project_0.default_zone_2| Zone 2}}} \ --tags lab-ssh gcloud compute instances add-tags mynet-vm-1 \ --zone {{{project_0.default_zone | Zone 1}}} \ --tags lab-ssh

ステートフル ファイアウォール

VPC ネットワークでは、ファイアウォール ルールはステートフルです。このため、ある方向を許可するルールによって追跡されている、開始済み接続のそれぞれの戻りトラフィックは、その他のルールに関係なく自動的に許可されます。

1. Cloud Shell で次のコマンドを実行し、mynet-vm-2 インスタンスに SSH 接続します。

gcloud compute ssh qwiklabs@mynet-vm-2 --zone {{{project_0.default_zone_2| Zone 2}}}

SSH 認証鍵とのネゴシエーションに数秒かかりますが、接続は成功します。これにより、ファイアウォール ルールでトラフィックが許可されることを確認できます。

2. 「exit」と入力して mynet-vm-2 インスタンスからログオフします。

3. Cloud Shell で次のコマンドを実行し、mynet-vm-1 インスタンスに SSH 接続します。

gcloud compute ssh qwiklabs@mynet-vm-1 --zone {{{project_0.default_zone | Zone 1}}}

この接続も成功します。これは、mynet-vm-1 インスタンスが同じネットワークにあり、かつ、作成したファイアウォール ルールがすべてのインスタンスへのアクセスを許可するためです。

同じネットワークのすべてのインスタンスが ping を介して通信することを許可する

1. mynet-vm-1 インスタンスにログインしたままで次のコマンドを実行し、mynet-vm-2 インスタンスへの ping を試行します。

ping mynet-vm-2.{{{project_0.default_zone_2| Zone 2}}}

ping コマンドは失敗します。mynet-vm-1 インスタンスと mynet-vm-2 インスタンスが同じ VPC ネットワーク内にあっても、トラフィックを許可するファイアウォール ルールがなければ、すべてのトラフィックはデフォルトでブロックされます。

2. 必要に応じて、Ctrl+C キーを押して ping を停止します。まだ mynet-vm-1 インスタンスからログアウトしないでください。

3. [新しいタブを開く]（+）をクリックして新しい Cloud Shell ウィンドウを開きます。

4. 次のコマンドを実行し、mynetwork VPC のすべてのインスタンスが相互に ping することを許可するファイアウォール ルールを追加します。

gcloud compute firewall-rules create \ mynetwork-ingress-allow-icmp-internal --network \ mynetwork --action ALLOW --direction INGRESS --rules icmp \ --source-ranges 10.128.0.0/9 注: このファイアウォール ルールはターゲットタグを使用しないため、デフォルトでネットワーク内のすべてのインスタンスに適用されます。このファイアウォールを機能させるためにインスタンスにタグ付けする必要はありません。この種のファイアウォール ルールは、ネットワーク内のすべてのインスタンスが同じルールを必要とする場合に役立ちますが、すべてのインスタンスに影響を及ぼすため、慎重に使用する必要があります。

5. mynet-vm-1 に接続された最初の Cloud Shell セッションに戻り、再度 ping を実行します。今回は成功します。

ping mynet-vm-2.{{{project_0.default_zone_2| Zone 2}}}

ホスト名 mynet-vm-2 がインスタンスの内部 IP アドレスに解決されています。この内部 IP アドレスは 10.132.0 で始まります（10.132.0.2 など）。Google Cloud によって内部ホスト名が解決されます。

6. Ctrl+C キーを押して ping を停止します。

7. また、内部 IP アドレスに対して直接 ping することもでき、成功します。Ctrl+C キーを押して ping を停止します。

8. mynet-vm-2 の外部 IP アドレスを見つけるため、ナビゲーション メニューで [Compute Engine] > [VM インスタンス] の順にクリックします。

9. mynet-vm-2 をクリックし、インスタンスの外部 IP アドレスを見つけてコピーします。

10. mynet-vm-1 に接続された Cloud Shell セッションから、mynet-vm-2 インスタンスの外部 IP アドレスへの ping を試行します。

ping

これは失敗します。外部 IP アドレスに対して ping すると、リクエストがインターネット ゲートウェイを通過するため NAT 変換されます。この段階で、リクエストは mynet-vm-1 インスタンスの外部 IP アドレスから届いていますが、ファイアウォール ルールが許可するのは内部 IP アドレスからの ICMP リクエストのみです。

11. Ctrl+C キーを押して ping を停止します。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 カスタム内向きファイアウォール ルールの作成

タスク 5. ファイアウォール ルールの優先値の設定

このタスクでは、ICMP トラフィックを拒否するファイアウォール ルールの優先値を設定します。その後、ルールの優先値と一致しないすべてのトラフィックが拒否されることを検証します。

これまでに作成したすべてのルールは内向きを許可するルールだったため、優先値は重要でありませんでした。ファイアウォール ルールでは、許可と拒否の両方を行うことができます。内向きと外向きの指定のほか、0 から 65,535 までの優先値の設定が可能です。優先値を指定しない場合は、1,000 というデフォルト値が使用されます。ルールは優先値の小さいものから順に評価され、最初に一致したルールが適用されます。

1. 最初の Cloud Shell セッションで、mynet-vm-1 インスタンスに接続していることを確認します。このことは、qwiklabs@mynet-vm-1:~$ というプロンプトからわかります。

接続していない場合は、次のコマンドを実行して再接続します。

gcloud compute ssh qwiklabs@mynet-vm-1 --zone {{{project_0.default_zone | Zone 1}}}

2. まだ mynet-vm-2 インスタンスに ping できることを確認します。

ping mynet-vm-2.{{{project_0.default_zone_2| Zone 2}}}

3. Ctrl+C キーを押して ping を停止します。

4. 2 番目の Cloud Shell ウィンドウに切り替えます（または新しいウィンドウを開きます）。

5. 2 番目の Cloud Shell で、すべての IP からの ICMP トラフィックを拒否するファイアウォール内向きルールを作成し、優先値を 500 とします。

gcloud compute firewall-rules create \ mynetwork-ingress-deny-icmp-all --network \ mynetwork --action DENY --direction INGRESS --rules icmp \ --priority 500

6. mynet-vm-1 インスタンスに接続された最初の Cloud Shell に戻り、mynet-vm-2 インスタンスへの ping を試行します。

ping mynet-vm-2.{{{project_0.default_zone_2| Zone 2}}}

成功しなくなりました。この新しいルールの優先値は 500 であるのに対し、許可ルールの優先値は 1,000 だからです。

7. Ctrl+C キーを押して ping を停止します。

次に、拒否ルールの優先値を 2,000 に変更します。

8. 2 番目の Cloud Shell で、作成したばかりのファイアウォール ルールの優先値を 2000 に変更します。

gcloud compute firewall-rules update \ mynetwork-ingress-deny-icmp-all \ --priority 2000

9. mynet-vm-1 インスタンスに接続された最初の Cloud Shell に戻り、mynet-vm-2 インスタンスへの ping を再度試行します。

ping mynet-vm-2.{{{project_0.default_zone_2| Zone 2}}}

今度は成功します。これは拒否ルールの優先値のほうが大きくなり、許可ルールが最初に一致するルールとなったためです。

10. Ctrl+C キーを押して ping を停止します。

タスク 6. 外向きファイアウォール ルールの構成

このタスクでは、外向きファイアウォール ルールを作成し、優先値を 10,000 に設定します。その後、トラフィックが内向きと外向きの両方のルールにより許可されることを検証します。

1. 2 番目の Cloud Shell ウィンドウを使って、現在のすべてのファイアウォール ルールのリストを表示します。

gcloud compute firewall-rules list \ --filter="network:mynetwork"

現時点で、VM はまだ相互に ping できます。これは、ICMP を拒否するルールの優先値が ICMP を許可するルールよりも大きいためです。

次に、外向きルールを試します。

2. すべての IP からの ICMP トラフィックをブロックする、ファイアウォール外向きルールを作成します。ここでは、優先値を 10000 とします。

gcloud compute firewall-rules create \ mynetwork-egress-deny-icmp-all --network \ mynetwork --action DENY --direction EGRESS --rules icmp \ --priority 10000

3. 再度、現在のすべてのファイアウォール ルールのリストを表示します。

gcloud compute firewall-rules list \ --filter="network:mynetwork"

外向きルールの優先値が、前に作成したルールよりも大幅に大きい 10,000 に設定されていることに注意してください。

4. mynet-vm-1 インスタンスに接続された最初の Cloud Shell に戻り、mynet-vm-2 インスタンスへの ping を試行します。

ping mynet-vm-2.{{{project_0.default_zone_2| Zone 2}}}

成功しなくなりました。外向きルールが 10,000 という大幅に大きい優先値を持つにもかかわらず、依然としてトラフィックはブロックされています。これは、内向きと外向きの両方のルールがそのトラフィックを許可する必要があるためです。内向きルールの優先値は外向きルールの優先値に影響しません。

5. Ctrl+C キーを押して ping を停止します。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 優先値を持つファイアウォール ルールと外向きファイアウォール ルールの作成

お疲れさまでした

このラボでは次の作業を行いました。

• 自動モードのネットワーク、カスタムモードのネットワーク、関連するサブネットワークを作成する
• デフォルト ネットワークのファイアウォール ルールを調査した後、デフォルト ネットワークを削除する
• ファイアウォール ルールの機能を使用して、接続をより細かく柔軟に制御する

ラボを終了する

ラボが完了したら、[ラボを終了] をクリックします。ラボで使用したリソースが Google Cloud Skills Boost から削除され、アカウントの情報も消去されます。

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

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

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

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

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

Copyright 2025 Google LLC All rights reserved. Google および Google のロゴは、Google LLC の商標です。その他すべての社名および製品名は、それぞれ該当する企業の商標である可能性があります。