サブネットワークの使用

サブネットワークを使用すると、クラウド ネットワークの IP 空間が複数のサブネットワークに分割されます。サブネットワークの接頭辞を自動で割り当てるか、カスタム トポロジを作成することができます。

始める前に

サブネットワーク

サブネットワークの主なメリットは次のとおりです。

  • サブネットワークを使用すると、ネットワーク IP 空間をリージョン別にサブネット(接頭辞)に分割し、どのサブネットからインスタンスの内部 IP アドレスを割り当てるかを制御できます。
  • VPN でサブネットワークを使用すると、VPN トンネルのターゲットを特定のリージョンに設定できます。これにより、VPN ルートの設定をさらに細かく制御することが可能になります。また、以前であれば VPN ですべてのリージョンにわたる IP 範囲を想定しなければならなかった状況においてレイテンシが短くなる効果もあります。
  • ネットワーク内のサブネットワークのすべてが同一の上位接頭辞を持つ必要はありません。 たとえば、範囲が 10.0.0.0/8 のサブネットワークと範囲が 192.168.0.0/16 のサブネットワークを一緒に使用することができます。これにより、割り当て済みの既存の IP 範囲を調整しなくても、プライベート IP 空間の未使用の範囲を詳細かつ柔軟に設定することができます。
  • ネットワークの IP 空間全体をプロジェクトの最初の作成時に決定する必要はありません。新しいサブネットワークを必要に応じて追加していくことができます。
  • サブネットワークを使用すると、機能グループや組織の部門に基づいて IP アドレスを集約することができますが、内部ではプライベートな RFC1918 空間を通じて通信が可能です。 これにより、クラウド ネットワークのアドレス空間をより細かく制御できるため、オンプレミス ネットワークとクラウド ネットワークの管理が簡単になります。
  • 複数のサブネットワークを VPN ゲートウェイのターゲットとして使用する場合、ピアルーターによって、正しいサブネットワークにトラフィックがルーティングされます。レガシー ネットワークのようにネットワーク全体にルーティングされることはありません。

このドキュメントでは、サブネットワークを設定して使用する方法について説明します。VPN、インスタンス グループ、負荷分散など、他のネットワーキング機能に対する変更についても説明し、それらがサブネットワークとどのように連携するかを示します。

このドキュメントでは、次のモードで動作するシステムについて説明します。

  • レガシー(非サブネット)モードは、IP アドレスをグローバル ネットワーク レベルで割り当てた従来の形式のネットワークです。これは、ネットワークのアドレス空間がすべてのリージョンにまたがることを意味します。レガシー ネットワークも引き続き作成できますが、代わりにサブネットワークを使用することが推奨され、デフォルトの動作もこのアプローチに変更されています。
  • サブネット モードは、ネットワークをリージョンのサブネットワークに分割した新しい形式のネットワークです。それぞれのサブネットワークで、そのサブネットワークに割り当てられるインスタンスに使用する IP アドレス範囲を制御します。ネットワーク内の異なるサブネットワークの IP 範囲は必ずしも連続していません。サブネットワークには次の 2 種類があります。
    • 自動サブネット ネットワークでは、ネットワーク内の各リージョンにサブネットワークの IP 接頭辞の範囲が自動的に割り当てられます。ネットワーク内の特定のリージョンのゾーンでインスタンスを作成すると、そのリージョンのサブネットワーク範囲から IP が割り当てられます。新しいプロジェクトの default ネットワークは、自動サブネット ネットワークになります。
    • カスタム サブネット ネットワークでは、ネットワーク内の各リージョンのサブネットワーク接頭辞を手動で定義できます。ネットワークの各リージョンに対して作成するサブネットワーク接頭辞の数は、0 個、1 個、または複数個のいずれでも構いません。ゾーンでインスタンスを作成するには、そのリージョンに事前にサブネットワークを少なくとも 1 つ作成しておく必要があります。インスタンスの作成時に、そのインスタンスの IP を割り当てるリージョンのサブネットワークを指定する必要があります。

制限事項

  • ネットワークの作成後に種類を変更することはできません。たとえば、自動サブネット ネットワークをカスタム サブネット ネットワークに変更することはできず、その逆も同様です。
  • レガシー(非サブネット)ネットワークは Cloud Platform Console では作成できません。必要であれば、gcloud コマンドライン ツールを使用してレガシー ネットワークを作成してください。
  • サブネットワークの IP 接頭辞を作成後に変更することはできません。
  • VPN の場合、--local-traffic-selector フィールドに VPN ゲートウェイの IPv4 範囲に属していない IP 範囲を指定することはできません。
  • 他のサービスでサブネットワークを使用する場合は次の制限があります。
  • 割り当て:
    • プロジェクトごとのサブネットワークの割り当ては 100 です。これらのサブネットワークをプロジェクト内でネットワークまたはリージョンにどのように割り当てるかについては制限はありません。
    • VPN トンネル作成時の CIDR 範囲の最大数(--local-traffic-selector フィールドで指定)は 128 です。

レガシー(非サブネット)ネットワーク

従来の Compute Engine ネットワークでは、そのネットワークに接続されるすべてのインスタンスに対して単一のネットワーク IPv4 接頭辞範囲を定義し、そのネットワークで Google Cloud Platform のすべてのリージョンをカバーします。

ネットワーク内の各インスタンスには、グローバル ネットワークの IPv4 範囲から取得した IPv4 アドレスが割り当てられます。インスタンスの IP アドレスがリージョンまたはゾーンでグループ化されることはありません。各 IP アドレスは 1 つのリージョンでしか使用できず、別のリージョンでは別の IP アドレスを使うことになります。ある特定の IP の範囲は全リージョンにまたがることができるため、あるリージョン内で作成された複数のインスタンスの IP アドレスは、必ずしも連続していません。これには次のような欠点があります。

  • IP 空間をリージョンごとにグループ化することができません。
  • インスタンスを個別の IP 空間にグループ化する場合、グループ化メカニズムとしてネットワークを使用する必要があります。これは、ネットワーク間の通信には外部のパブリック IP 空間しか使用できないため、インスタンスのグループ間で相互に通信する際に問題になります。レガシー ネットワークでは、ネットワークが唯一の IP グループ化メカニズムになります。ネットワーク内の IP をグループ化するメカニズムはありません。

以下の図は、現在はレガシー(非サブネット)ネットワークと呼ばれる従来のネットワークを示したものです。インターネットからのトラフィックはネットワーク内のグローバルなスイッチング機能(図の中では仮想スイッチとして示されています)を通過して、個別の各インスタンスへと転送されます。

リージョン内のインスタンスには IP アドレスを割り当てることができますが、なんらかの方法でグループ化されることはありません。例に示されているように、10.240.0.0/16 のアドレスを持つ各インスタンスは、リージョン 1 とリージョン 2 に広がっています。たとえば、10.240.1.4 はリージョン 2 にあり、10.240.1.5 はリージョン 1 にありますが、10.240.1.6 はリージョン 2 にあります。

レガシー ネットワークの図(クリックすると拡大します)
レガシー ネットワークの図(クリックすると拡大します)

サブネット ネットワーク

サブネット ネットワークには、グローバル ネットワークの IPv4 接頭辞範囲は必要ありません。 代わりに、それぞれが独自の IPv4 接頭辞を持つ複数のサブネットワークをネットワークに含めることができます。単一のネットワークに属するサブネットワークには、重複しない RFC1918 範囲を割り当てる必要があります。 単一のネットワークに属するサブネットワークの IPv4 アドレス接頭辞が連続している必要はありません(10.240.0.0/16192.168.0.0/16 など)。サブネットワークは 1 つのネットワークだけに属し、各インスタンスは 1 つのサブネットワークだけに属することができます。

新しいプロジェクトのデフォルトのネットワークは、自動サブネットのネットワークになります。1 つのプロジェクトでは、最大 4 つのネットワークを追加で作成できます。追加のネットワークは、自動サブネット ネットワーク、カスタム サブネット ネットワーク、レガシー ネットワークのいずれかにすることができます。

プロジェクトでサブネットワークを作成すると、機能や組織の部門ごとにインスタンスをグループ化するのに役立ちます。別のサブネットワーク内のインスタンスは、同じネットワークに属していれば、内部 IP を使用して互いに通信できます。2 つの異なるネットワークに属するインスタンス間では、外部 IP を使用した通信のみが可能です。たとえば、テスト用システムと実働システムのインスタンスが外部 IP 以外で相互に通信しないようにするには、それらのインスタンスを別々のネットワークに配置します。 異なるネットワークに属するインスタンスは完全に切り離され、アドレス範囲が重複していても構いません。そのため、ネットワーク間の通信には外部のパブリック IP 空間しか使用できません。外部の IP 空間を使用した通信では、セキュリティは高くなりますが、追加の費用がかかることがあります。 ただし、特定のサービスを実行しているすべてのインスタンスから別のサービスを実行しているすべてのインスタンスに通信できるようにし、かつ IP アドレスによってそれらのインスタンスをまとめたい場合は、同じネットワーク内で 2 つの異なるサブネットワークを使用できます。

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

以下の図は、サブネット ネットワークを示したものです。新しいインスタンスは、特定のサブネットワークの接頭辞から IP アドレスを取得します。Subnet1 はリージョン 1 にあるため、プライベート IP はすべて 10.240.0.0/24 から割り当てられます(インスタンスの IP は 10.240.0.110.240.0.2)。また、Subnet2 はリージョン 2 にあるため、プライベート IP はすべて 192.168.1.0/24 から割り当てられます(インスタンスの IP は 192.168.1.1192.168.1.2)。さらに、Subnet3 はリージョン内の複数のゾーンにまたがっています。サブネットワークはゾーンによる制限を受けません。リージョンによる制限は受けますが、必要に応じて、あるゾーン内のあるサブネットからインスタンスを作成しながら、別のゾーン内の別のサブネットからもインスタンスを作成することができます。

サブネット ネットワークの図(クリックすると拡大します)
サブネット ネットワークの図(クリックすると拡大します)

サブネットワークの機能

サブネットワークを使用すると、ネットワークが予測可能な IP アドレス範囲に分割されます。 サブネットワークの主な特徴を次に示します。

  • 各サブネットワークに CIDR 範囲が設定されています。そのサブネットワークで作成されるすべてのインスタンスに、CIDR 範囲から内部 IP アドレスが割り当てられます。
  • サブネットワークの範囲は、自動で割り当てる(自動サブネット ネットワークを使用)ことも、独自に指定する(カスタム サブネット ネットワークを使用)こともできます。
  • サブネットワークはそれぞれ 1 つのリージョンに制限されますが、必要に応じてインスタンスを特定のゾーンに制限することもできます。
  • サブネットワークの範囲を独自に指定する場合(カスタム サブネット ネットワークを使用する場合)、ネットワークの特定のリージョンに含めるサブネットワークの CIDR 範囲は 0 個、1 個、または複数個のいずれでも構いません。

サブネットワークの IP 範囲

サブネットワークの範囲は、自動で設定することも手動で設定することもできます。このセクションでは、両方の範囲について説明します。

サブネットごとに次のアドレスが予約されます。

  • ネットワーク アドレス
  • ブロードキャスト アドレス
  • ゲートウェイ IP アドレス(CIDR 範囲の最初のアドレス)
  • 予約アドレス(CIDR 範囲の最後から 2 番目のアドレス)

使用できるサブネットワークの最小サイズは /29 です。

自動サブネットの IP 範囲

自動サブネット ネットワークを使用する場合、そのネットワークのサブネットワークがリージョンごとに 1 つずつ自動的に作成されます。次の表は、自動的に設定される IP 範囲とデフォルトのゲートウェイをリージョン別に示したものです。 これらは、いずれの自動サブネット ネットワークでも使用される共通の範囲です。

リージョン IP 範囲 デフォルト ゲートウェイ
us-west1 10.138.0.0/20 10.138.0.1
us-central1 10.128.0.0/20 10.128.0.1
us-east1 10.142.0.0/20 10.142.0.1
europe-west1 10.132.0.0/20 10.132.0.1
asia-east1 10.140.0.0/20 10.140.0.1
asia-northeast1 10.146.0.0/20 10.146.0.1

カスタム サブネットの IP 範囲

手動で作成したサブネットワークでは、任意の有効な RFC1918 IP 範囲を使用できます。範囲は、必ずしもサブネットワーク間で連続している必要はありません。たとえば、あるサブネットワークでは 10.0.0.0/8 から選んだ範囲を使用しながら、別のサブネットワークでは 192.168.0.0/16 から選んだ範囲を使用できます。ただし、範囲はネットワーク内で一意でなければならず、重複していてはなりません。

サブネットワークのリソースの管理

このセクションでは、サブネットワークを作成する方法を説明します。

この手順で使用するコマンドの詳細については、gcloud ツールガイドをご覧ください。

ネットワークとサブネットワーク

新しいサブネット ネットワークを作成するときは、自動作成されたサブネットの割り当てを使用するか、カスタム サブネット ネットワークを使用して独自に指定するかを選択できます。

既存のサブネットと同じ名前を持つネットワークを同じプロジェクト内で作成することはできません。 また、既存のネットワークと同じ名前を持つサブネットを同じプロジェクト内で作成することもできません。ただし各ネットワークには、親ネットワークと同じ名前を持つサブネットをリージョンごとに 1 つ作成することができます。

自動作成されたサブネットワーク範囲を使用した新しいネットワークの作成

  1. 自動的に割り当てられたサブネットワークを使用して、プロジェクトで新しいネットワークを作成します。 --modeauto が指定されているため、あらかじめ用意された IP ブロックを使用して、サブネットワークが自動的に作成されます。これはサブネット ネットワークであるため、ネットワーク レベルの IPv4 範囲やゲートウェイ IP は存在せず、何も表示されません。

    gcloud compute networks create auto-network1 \
        --mode auto
    

    NAME          MODE IPV4_RANGE GATEWAY_IPV4
    auto-network1 auto

  2. 新しく自動作成されたサブネットワークを一覧表示します。

    gcloud compute networks subnets list
    

    NAME          REGION          NETWORK       RANGE
    auto-network1 asia-east1      auto-network1 10.140.0.0/20
    auto-network1 us-central1     auto-network1 10.128.0.0/20
    auto-network1 europe-west1    auto-network1 10.132.0.0/20

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

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

新しいサブネットワークを作成するときは、ネットワークが異なる場合であっても、リージョンが同じ場合はプロジェクト内で一意のサブネットワーク名にする必要があります。リージョンが異なる場合は、プロジェクト内で同じ名前を繰り返し使用することができます。

これはサブネット ネットワークであるため、ネットワーク レベルの IPv4 範囲やゲートウェイ IP は存在せず、何も表示されません。

  1. プロジェクトで、新しいカスタム サブネット ネットワークを作成します。

    gcloud compute networks create custom-network1 \
        --mode custom
    

    NAME            MODE   IPV4_RANGE GATEWAY_IPV4
    custom-network1 custom

  2. 最初のリージョンに対応するサブネットワーク接頭辞を指定します。この例では、リージョン us-central1192.168.1.0/24 を割り当てています。

    gcloud compute networks subnets create subnet-us-central-192 \
        --network custom-network1 \
        --region us-central1 \
        --range 192.168.1.0/24
    

    NAME                  REGION      NETWORK         RANGE
    subnet-us-central-192 us-central1 custom-network1 192.168.1.0/24

  3. 2 番目のリージョンに対応するサブネットワーク接頭辞を指定します。この例では、リージョン europe-west1192.168.5.0/24 を割り当てています。

    gcloud compute networks subnets create subnet-europe-west-192 \
        --network custom-network1 \
        --region europe-west1 \
        --range 192.168.5.0/24
    

    NAME                   REGION       NETWORK         RANGE
    subnet-europe-west-192 europe-west1 custom-network1 192.168.5.0/24

  4. 3 番目のリージョンに対応するサブネットワーク接頭辞を指定します。この例では、リージョン asia-east110.1.1.0/24 を割り当てています。

    gcloud compute networks subnets create subnet-asia-east-192 \
       --network custom-network1 \
       --region asia-east1 \
       --range 10.1.1.0/24
    

    NAME                 REGION     NETWORK         RANGE
    subnet-asia-east-192 asia-east1 custom-network1 10.1.1.0/24

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

    gcloud compute networks subnets list
    

    NAME                           REGION          NETWORK         RANGE
    subnet-europe-west-192         europe-west     custom-network1 192.168.5.0/24
    subnet-us-central-192          us-central1     custom-network1 192.168.1.0/24
    subnet-asia-east-192           asia-east1      custom-network1 10.1.1.0/24

レガシー ネットワークの作成

レガシー(非サブネット)ネットワークも引き続き作成できます。レガシー ネットワークは、単一のグローバル IP 範囲を持ちます。レガシー ネットワークでサブネットワークを作成したり、レガシー ネットワークから自動またはカスタムのサブネット ネットワークに切り替えたりすることはできません。

プロジェクトで新しいレガシー ネットワークを作成するには:

gcloud compute networks create legacy-network1 \
    --mode legacy \
    --range 10.240.0.0/16
Created
[https://www.googleapis.com/compute/latest/projects/[PROJECT_ID]/global/networks/legacy-network1].
NAME            MODE   IPV4_RANGE    GATEWAY_IPV4
legacy-network1 legacy 10.240.0.0/16 10.240.0.1

既存のサブネットワークの表示

既存のプロジェクトのすべてのサブネットワークを一覧表示することができます。

すべてのサブネットワークについて、一般的な詳細情報が表示されます。

gcloud compute networks subnets list
NAME                      REGION          NETWORK         RANGE
auto-network1             europe-west1    auto-network1   10.132.0.0/20
subnet-europe-west-192    europe-west     custom-network1 192.168.5.0/24
auto-network1             us-central1     auto-network1   10.128.0.0/20
subnet-us-central-192     us-central1     custom-network1 192.168.1.0/24
subnet-asia-east-192      asia-east1      custom-network1 10.1.1.0/24
auto-network1             asia-east1      auto-network1   10.140.0.0/20

一覧表示される内容は、次のパラメータを追加することで変更できます。

  • --regions REGION,[REGION,...] 一覧表示されるサブネットを特定のリージョンに限定します。
  • --network NETWORK 一覧表示されるサブネットを特定のネットワーク内のものだけに限定します。

既存のサブネットワークの記述

describe コマンドを実行すると、指定したサブネットワークの詳細が表示されます。

gcloud compute networks subnets describe subnet-asia-east-192 \
  --region asia-east1
creationTimestamp: '2015-10-21T15:58:35.271-07:00'
gatewayAddress: 192.168.7.1
id: '2048026325272602228'
ipCidrRange: 192.168.7.0/24
kind: compute#subnetwork
name: subnet-asia-east-192
network: https://www.googleapis.com/compute/latest/projects/[PROJECT_ID]/global/networks/custom-network1
region: https://www.googleapis.com/compute/latest/projects/[PROJECT_ID]/regions/asia-east1
selfLink: https://www.googleapis.com/compute/latest/projects/[PROJECT_ID]/regions/asia-east1/subnetworks/subnet-asia-east-192

自動からカスタムへのネットワークの切り替え

ネットワークを自動サブネット モードからカスタム サブネット モードに切り替えることができます。

カスタム サブネット モードに変更したネットワークのサブネット名と IP 範囲は、元の自動サブネット モードのネットワークと同じです。

切り替え後、カスタム サブネット モードのネットワークに新しいサブネットを追加できます。カスタム サブネット範囲を使用した新しいネットワークの作成の手順 2 をご覧ください。ネットワーク内のサブネットを削除することもできます(元の自動サブネットを含む)。

gcloud compute networks switch-mode NETWORK_NAME --mode custom

カスタム サブネットの拡大

カスタム サブネット モードのネットワークでは、サブネットの IP 範囲を拡大できます。縮小はできません。

新しいサブネットのサイズを設定するには、新しいネットマスクを指定します。たとえば、元の IP 範囲が 10.128.131.0/24 の場合、--prefix-length 20 を指定して新しい IP 範囲を 10.128.128.0/20 に設定します。新しいネットワーク範囲は元の範囲より大きくする必要があります。これは、接頭辞長を小さくすることを意味します。リージョンに関係なく、新しいサブネットは同じネットワーク内の他のサブネットと重ならないようにしてください。新しいサブネットは、RFC1918 アドレス空間内に存在する必要があります。

サブネットはリージョンと名前で識別されます。コマンドでは、これらのリージョンと名前を指定する必要があります。

既存のネットワークのサイズと IP の割り当てによっては、このコマンドが完了するまでに数秒から数分かかる場合があります。この間、新しいインスタンスは作成できませんが、既存のインスタンスに影響はありません。拡大中も既存のインスタンスにはアクセス可能で、トラフィックが通過します。

gcloud compute networks subnets expand-ip-range [SUBNET_NAME]
  --network [NETWORK_NAME]
  --region [REGION]
  --prefix-length [PREFIX_LENGTH]
  • --prefix-length - サブネットの新しい接頭辞長(数値)。既存の接頭辞長よりも小さくする必要があります。たとえば、現在のサブネットが /24 の場合、新しい接頭辞長は 23 以下にする必要があります。

サブネットワークまたはネットワークの削除

プロジェクト内の任意のサブネットワークを削除することができます。また、ネットワーク全体を削除することもできます。ただし、インスタンスまたはリソースを持つネットワークまたはサブネットワークを削除することはできません。

サブネットワークの削除

削除できるのは、手動で作成したサブネットワークだけです。自動的に作成されたサブネットワークを個別に削除することはできません。ネットワーク全体を削除する必要があります。

インスタンスを持つサブネットワークや、それを使用している手動で作成したルートなどのリソースを削除することはできません。

gcloud compute networks subnets delete subnet-asia-east-192 \
    --region asia-east1
The following subnetworks will be deleted:
 - [subnet-asia-east-192] in [asia-east1]
Do you want to continue (Y/n)?  y
Deleted [https://www.googleapis.com/compute/latest/projects/[PROJECT_ID]/regions/asia-east1/subnetworks/subnet-asia-east-192].

ネットワークの削除

レガシー ネットワークでは、どのリソースでも使用されていない場合に限り、ネットワーク リソースを明示的に削除することができます。

自動サブネット ネットワークでは、次に示す両方の条件が満たされている場合に限り、ネットワーク リソースを明示的に削除することができます。

  • ネットワーク内のどの子サブネットワークも、他のリソースで使用されていない。
  • そのネットワーク リソースが、他のリソースで使用されていない。

使用されている場合に上記のような削除の妨げとなるリソースの例としては、ファイアウォール、カスタムルート、インスタンス、ターゲット VPN ゲートウェイ、ルーターなどが挙げられます。

カスタム サブネット ネットワークでは、すべての子サブネットワークを削除している場合に限り、ネットワークを削除することができます。

ネットワークを削除するには:

gcloud compute networks delete auto-network1
The following networks will be deleted:
 - [auto-network1]
Do you want to continue (Y/n)?  y
Deleted [https://www.googleapis.com/compute/latest/projects/[PROJECT_ID]/global/networks/auto-network1].

サブネットワークとその他のリソース

このセクションでは、サブネットワークとそれに依存する他の Google Cloud Platform リソースの関係について説明します。

サブネットワークとインスタンス

サブネットワークの作成時は、そのリージョン内のすべてのゾーンにまたがるサブネットワークが作成されます。 一方、インスタンスを作成するときは、作成先のゾーンとサブネットワークを指定します。そのため、region1 の subnetwork1 と zone1 の一連のインスタンスと、region1 の subnetwork2 と zone2 のインスタンスを別々に作成することができます。

サブネットワークでのインスタンスの作成

次のコマンドを実行すると、指定したゾーンの指定したサブネットワークにインスタンスが作成されます。このコマンドでは、--network パラメータと --subnet パラメータの両方を指定することはできないことに注意してください。 非サブネット関連インスタンスのその他のパラメータについては、Cloud SDK ドキュメントの gcloud compute instances create をご覧ください。

gcloud compute instances create instance1 \
   --zone us-central1-a \
   --subnet subnet-us-central-192
Created [https://www.googleapis.com/compute/latest/projects/[PROJECT_ID]/zones/us-central1-a/instances/instance1].
NAME      ZONE          MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP   STATUS
instance1 us-central1-a n1-standard-1             192.168.1.4 70.32.154.181 RUNNING

サブネットワークと負荷分散

負荷分散のターゲットであるインスタンス グループは、1 つのサブネットワークに属している必要があります。

非管理対象インスタンス グループをバックエンド サービスに関連付けると、すべてのインスタンスが同じサブネットワークに属しているかどうかが確認されます。すべてが同じサブネットワークに属していないと、エラーが返されて処理は失敗します。

HTTP(S)負荷分散管理対象インスタンス グループを作成する場合、管理対象インスタンス グループによって使用されるインスタンス テンプレートでサブネットワークを指定できます。サブネットワークは、自動サブネット モードのネットワークの場合は省略可能です。カスタムモードのネットワークの場合は必ず指定する必要があります。

サブネットワークにまたがるインスタンス グループを作成した場合、そのインスタンス グループはバックエンド サービスで使用できません。

また、ネットワークまたはサブネットワークが最初に定義したものと異なるインスタンス テンプレートを使用するように管理対象インスタンス グループを更新することはできません。

サブネットワークを指定したインスタンス テンプレートの作成

インスタンス テンプレートのコマンドにオプションの --subnet フラグと --region フラグが追加され、新しいインスタンスの作成時に配置先のサブネットワークを指定できるようになりました。ただし、インスタンス テンプレートで指定したサブネットは、インスタンス テンプレートの作成後は変更できないことに注意してください。--subnet フラグは --region フラグと一緒に使用する必要があります。 インスタンス テンプレートに含めるサブネットワークは事前に用意しておく必要があります。

この例では、subnet-us-qa サブネットにのみインスタンスを作成する template-qa という名前のテンプレートを作成しています。

gcloud compute instance-templates create template-qa \
    --region us-central1 \
    --subnet subnet-us-qa
Created [https://www.googleapis.com/compute/latest/projects/[PROJECT_ID]/global/instanceTemplates/template-qa].
NAME        MACHINE_TYPE  PREEMPTIBLE CREATION_TIMESTAMP
template-qa n1-standard-1             2015-10-23T20:34:00.791-07:00

このテンプレートを使用してマネージド インスタンス グループのインスタンスを作成すると(自動スケーリングの設定は任意)、指定したリージョンの指定したサブネットワークにインスタンスが自動的に作成されます。これにより、負荷分散のために新規に作成するインスタンスのサブネットワークを制御できます。

サブネットワークとファイアウォール ルール

ファイアウォールは、リージョン リソースではなく、1 つのネットワークに関連付けられるグローバル リソースです。ファイアウォール ルールはネットワーク内のすべてのインスタンスに適用されます。つまり、同じネットワーク内であれば、サブネットワークをまたぐ場合であっても、インスタンス間のトラフィックを許可するファイアウォール ルールを追加することができます。

デフォルトのネットワークに適用されるデフォルトのファイアウォール ルールは変更されません。 また、作成済みの既存のファイアウォール ルールも変更されません。プロジェクトで以降に作成するネットワークには、デフォルトのファイアウォール ルールは含まれません。 ファイアウォール ルールがない場合、デフォルトではすべての通信の受信がブロックされます。デフォルト以外のネットワークのインスタンスへのトラフィックを許可する場合は、ファイアウォール ルールを作成する必要があります。

ユーザーが作成したネットワークには、デフォルトのファイアウォール ルールは含まれません。作成するサブネットワーク間のトラフィックを許可するには、具体的なファイアウォール ルールを作成する必要があります。

2 つのサブネットワーク間でトラフィックを交換するには、双方向の「許可」権限を設定する必要があります。

詳細については、ファイアウォールの管理についてのドキュメントをご覧ください。

サブネットワークの分離

デフォルトのネットワークでは、上記のデフォルトのファイアウォール ルールにより、ネットワーク内のすべての仮想マシン インスタンス間での相互通信がデフォルトで許可されます。一方、ユーザーが作成したネットワークにはデフォルトのファイアウォール ルールがないため、適切なファイアウォール ルールを定義しない限り、他のインスタンスからもインスタンスと通信することはできません。

通常は、いずれのファイアウォール ルールもネットワーク内のすべてのインスタンスに適用されます。ただし、特定のインスタンスにタグを追加すれば、そのタグをファイアウォール ルールで使用することで、特定のインスタンスにのみ適用されるルールを作成できます。インスタンスへのタグの追加は、個別に設定することも、インスタンス テンプレートで設定することもできます。 これらのタグを使用することで、特定のインスタンスのみに通信を許可するなど、サブネットワーク間の分離をさらに細かく制御できます。サブネットワーク内のすべてのインスタンスで同じタグを共有する場合は、そのタグをファイアウォール ルールで指定して各サブネットワークのファイアウォールをシミュレートします。たとえば、subnet-a のすべてのインスタンスに tag-subnet-a というタグを付けて、そのタグをファイアウォール ルールの target-tags で使用することができます。ファイアウォール ルールでは source-ranges も使用できます。

ネットワーク my-network に次の 3 つのサブネットワークがあるとします。

  • subnet-a、IP 接頭辞 192.168.2.0/24
  • subnet-b、IP 接頭辞 10.128.0.0/16
  • subnet-c、IP 接頭辞 10.240.0.0/16
サブネットワークを分離した図
サブネットワークを分離した図

このネットワークで、subnet-a と他のサブネットの間の通信は許可し、subnet-bsubnet-c の間の通信はブロックするように設定します。

この場合の設定手順は次のとおりです。

  1. サブネットワーク内のインスタンスにタグを付けます。サブネットワーク内のすべてのインスタンスに共通のタグを設定します。たとえば、サブネットワーク subnet-a には tag-subnet-a というタグを付けます。

    gcloud compute instances add-tags example-instance-subnet-a \
        --tags tag-subnet-a --zone us-central1-b
    

    Updated [https://www.googleapis.com/compute/latest/projects/[PROJECT_ID]/zones/us-central1-b/instances/example-instance-subnet-a].

    example-instance-subnet-b にタグを付けます。

    gcloud compute instances add-tags example-instance-subnet-b \
       --tags tag-subnet-b
    

    Updated [https://www.googleapis.com/compute/latest/projects/[PROJECT_ID]/zones/us-central1-b/instances/example-instance-subnet-b].

    example-instance-subnet-c にタグを付けます。

    gcloud compute instances add-tags example-instance-subnet-c \
       --tags tag-subnet-c
    

    Updated [https://www.googleapis.com/compute/latest/projects/[PROJECT_ID]/zones/us-central1-b/instances/example-instance-subnet-c].

    タグは、インスタンスの作成時に gcloud compute instances create コマンドの --tags パラメータを使用して付けることができます。

    サブネットワーク内のインスタンスの種類がすべて同じであれば、インスタンスを管理対象インスタンス グループとしてグループ化し、インスタンス テンプレートを使用してすべてのインスタンスに同じタグを自動で設定することができます。

  2. subnet-asubnet-b の間の通信と subnet-asubnet-c の間の通信を有効にするファイアウォール ルールを作成します。

    subnet-a の CIDR(192.168.2.0/24)から subnet-b(タグ tag-subnet-b)と subnet-c(タグ tag-subnet-c)に属するすべてのインスタンスへのトラフィックを許可します。

    gcloud compute firewall-rules create allow-subnet-a \
         --allow tcp,udp,icmp \
         --source-ranges 192.168.2.0/24 \
         --target-tags tag-subnet-b,tag-subnet-c
    

    Created [https://www.googleapis.com/compute/latest/projects/[PROJECT_ID]/global/firewalls/allow-subnet-a].
    NAME           NETWORK    SRC_RANGES    RULES        SRC_TAGS TARGET_TAGS
    allow-subnet-a my-network 19.168.2.0/24 tcp,udp,icmp          tag-subnet-a,tag-subnet-c

  3. subnet-b の CIDR(10.128.0.0/16)から subnet-a(タグ tag-subnet-a)のみに属するすべてのインスタンスへのトラフィックを許可します。

    gcloud compute firewall-rules create allow-subnet-b \
       --allow tcp,udp,icmp \
       --source-ranges 10.128.0.0/16 \
       --target-tags tag-subnet-a
    

    Created [https://www.googleapis.com/compute/latest/projects/[PROJECT_ID]/global/firewalls/allow-subnet-b].
    NAME           NETWORK    SRC_RANGES    RULES        SRC_TAGS TARGET_TAGS
    allow-subnet-b my-network 10.128.0.0/16 tcp,udp,icmp          tag-subnet-a

  4. subnet-c の CIDR(10.240.0.0/16)から subnet-a(タグ tag-subnet-a)のみに属するすべてのインスタンスへのトラフィックを許可します。

    gcloud compute firewall-rules create allow-subnet-c \
       --allow tcp,udp,icmp \
       --source-ranges 10.240.0.0/16 \
    

    Created [https://www.googleapis.com/compute/latest/projects/[PROJECT_ID]/global/firewalls/allow-subnet-c].
    NAME           NETWORK    SRC_RANGES    RULES        SRC_TAGS TARGET_TAGS
    allow-subnet-c my-network 10.240.0.0/16 tcp,udp,icmp          tag-subnet-a

サブネットワーク B と C の間のトラフィックの交換を明示的に許可していないため、それらのサブネットワークが相互に分離された状態になります。

サブネットワークとルート

ルートは、リージョン リソースではなく、1 つのネットワークに関連付けられるグローバル リソースです。ユーザーが作成したルートは、ネットワーク内のすべてのインスタンスに適用されます。つまり、同じネットワーク内であれば、サブネットワークをまたぐ場合であっても外部 IP アドレスを必要とすることなく、インスタンス間でトラフィックを転送するルートを追加することができます。 デフォルトでは、ルートはサブネットワーク間に存在することになります。

デフォルトのルート

サブネットワークまたはレガシー ネットワークを作成すると、一定のルートが作成されます。

サブネット ネットワークの場合

次のルートが作成されます。

  • ネットワークを作成すると、インターネット トラフィック(0/0)に対応したデフォルトのルートが作成されます。
  • サブネットワークを作成すると、サブネットワークごとに 1 つのルートが作成されます。 このようなルートは、ネットワーク内のローカル トラフィックに対応したものであるため、任意のサブネットワーク内のインスタンスが、そのネットワーク内の他のサブネットワークまたは同一のサブネットワーク内にあるインスタンスにトラフィックを送信することを許可します。このルートは、ルート割り当て全体に対してカウントされます。プロジェクトの全体的なルート割り当ては現在のところ 100 であり、サブネットを作成するたびに割り当てに対して 1 つのルートが消費されます。ユーザーが作成したネットワークではファイアウォール ルールが作成されていないため、インスタンスを宛先とするルートが存在する場合であっても、ファイアウォール ルールを追加しない限り、インスタンスへのトラフィックの送信がファイアウォールによって遮断されてしまう点に注意してください。
レガシー ネットワークの場合

ネットワーク作成時に 2 つのルートが作成されます。

  • ネットワークを作成すると、インターネット トラフィック(0/0)に対応したデフォルトのルートが作成されます。
  • ネットワークの IPv4 範囲内の宛先 IP 範囲については、仮想ネットワーク ルートが定義されています。デフォルトのレガシー ネットワークでは、デフォルトのファイアウォール ルールも自動的に作成されるため、インスタンス間のトラフィックが最初から許可されます。手動で作成したレガシー ネットワークについては、インスタンスに向かう受信トラフィックを許可するファイアウォール ルールを作成する必要があります。

追加のルートを作成する手順については、gcloud compute routes create コマンドをご覧ください。

ルートと VPN トンネル

特定のサブネットワークだけにルートを適用する場合は、そのサブネットワークに含まれるインスタンスに対して明示的にルートを適用する必要があります。

ネットワークに subnet-asubnet-b という 2 つのカスタム サブネット ネットワークがあるとします。このネットワークで、subnet-a からのトラフィックは VPN トンネル経由でピア ネットワークにルーティングし、subnet-b のトラフィックは VPN tunnel-a 経由でルーティングしないように設定します。

1 つのサブネットワークから VPN トンネルへのトラフィックのルーティングの図
 class=1 つのサブネットワークから VPN トンネルへのトラフィックのルーティングの図" class="l10n-absolute-url-src">

このシナリオで subnet-a のみにルートを適用する手順は次のとおりです。

  1. subnet-a 内のすべてのインスタンスに共通のタグを設定します(例: tag-subnet-a)。

    gcloud compute instances add-tags example-instance-subnet-a \
        --tags tag-subnet-a
    

    Updated [https://www.googleapis.com/compute/latest/projects/[PROJECT_ID]/zones/us-central1-b/instances/example-instance-subnet-a].

    タグは、インスタンスの作成時に gcloud compute instances コマンドの --tags パラメータを使用して付けることができます。

  2. subnet-a 内のすべてのインスタンスに静的ルートを追加します。このルートは、送信先のピアの接頭辞 192.168.1.0/24tunnel-a のネクストホップで構成されます。

    gcloud compute routes create route-via-tunnel \
        --destination-range 192.168.1.0/24 \
        --network my-network \
        --tags tag-subnet-a \
        --next-hop-vpn-tunnel tunnel-a
    

サブネットワークと VPN

サブネットワークでは、インスタンスを共通の IP 接頭辞でグループ化できます。この方法でグループ化すると、ポリシー(静的ルート)ベースの VPN を設定するときに便利です。Cloud VPN でサブネットワークを使用すれば、オンプレミスの VPN 端末でサブネットワークの接頭辞に基づいてルーティング ポリシーを設定できるため、ポリシーベースの VPN でどの IP 接頭辞を通知する必要があるかを制御して、オンプレミスとクラウドのネットワーク間のレイテンシを短縮することができます。

次のような構成について考えてみましょう。サブネットワークを使用しない場合、2 つのリージョンでインスタンスを実行するには次のようなトポロジが必要になります。

サブネットワークを使用しない場合の VPN の図(クリックすると拡大します)
 class=サブネットワークを使用しない場合の VPN の図(クリックすると拡大します)" class="l10n-absolute-url-src">

レガシー ネットワークの場合、IP 割り当てを制御できないため、IP 接頭辞が米国東部とヨーロッパの両リージョンに分断されます。オンサイトの VPN ゲートウェイでルーティングを決定するときは、ECMP で両方のリンクにパケットを振り分けるしかありません。

オンプレミス ネットワークのホストからヨーロッパ リージョンのインスタンスにパケットを送信しようとしても、それらのパケットの約 50% が米国東部リージョンを経由することになるため、VPN のレイテンシが長くなる可能性があります。

サブネットワークを使用すれば、10.240.1.0/24 は米国東部で 10.240.2.0/24 はヨーロッパのように 2 つのサブネットワークを定義できるため、トポロジは次の図のようになります。

サブネットワークを使用した場合の VPN の図(クリックすると拡大します)
 class=サブネットワークを使用した場合の VPN の図(クリックすると拡大します)" class="l10n-absolute-url-src">

この方法では、ピア VPN ゲートウェイのルーティング テーブルを使用してインスタンスの場所に基づく正しいリージョンにパケットを送信できるため、平均レイテンシが短くなります。

サブネットワークを使用すると、インスタンスを共通の IP 接頭辞でリージョン別にグループ化できます。リージョン別にグループ化した IP 接頭辞は、VPN トンネルの作成時に静的に通知できます。そのため、ピア VPN エンドポイントに通知するサブネットワークの接頭辞を VPN トンネルの作成時に柔軟に選択することができます。

Compute Engine VPN ゲートウェイの作成

Compute Engine VPN ゲートウェイの作成手順は、サブネットワークを使用する場合も変わりません。Cloud SDK ドキュメントの gcloud compute target-vpn-gateways create をご覧ください。

VPN トンネルの作成

VPN トンネルを作成するには、トンネルの IP 範囲を指定し、そのトラフィックをトンネルにルーティングします。

トラフィック セレクタとは、指定したアドレスに一致するトラフィックをトンネルを通じてやり取りするように IKE ピア間で規定した取り決めのことです。 サブネットワークを使用する場合は、Google Cloud Platform のどの CIDR 範囲を VPN トンネルに対して有効にするかを指定する必要があります。これらの範囲は、Cloud Platform Console では [ローカル IP 範囲] フィールド、gcloud コマンドライン ツールでは --local_traffic_selector フィールドで指定します。 これらの範囲はトンネルの作成時に設定され、接続時の IKE ハンドシェイクで使用されるため以降に変更することはできません。

トラフィック セレクタで指定される CIDR 範囲の最大数は 128 です。

VPN の設定によっては、トラフィック セレクタで指定していないトラフィックの通過が IKE ハンドシェイクで許可されることがあります。VPN の動作が予測可能で一貫した動作になるように、トンネルの作成時に指定した接頭辞と一致するルートを指定してください。

トラフィック セレクタと自動サブネット ネットワーク

VPN ゲートウェイのネットワークが自動サブネット ネットワークの場合、VPN ゲートウェイと同じリージョンにあるサブネットワークの CIDR 範囲がピア VPN に自動的に通知されます。そのサブネットでのみトンネルを使用する場合は、トラフィック セレクタを手動で指定する必要はありません。ルートについては、以下に示す手順に従って指定してください。

自動サブネット ネットワークで、ゲートウェイを含むサブネット以外のサブネットでトンネルを使用する場合は、それらの範囲を指定して対応するルートを作成する必要があります。このフィールドを使用する場合、ゲートウェイのローカルのサブネットも指定する必要があります。

自動サブネット ネットワークで、トラフィック セレクタを指定していない場合は、デフォルトの動作として、Cloud VPN ゲートウェイのローカルのサブネットを使用してトンネルが作成されます。

トラフィック セレクタとカスタム サブネット ネットワーク

VPN ゲートウェイのネットワークがカスタム サブネット ネットワークの場合、デフォルトではピア VPN に IP 接頭辞は通知されません。トラフィック セレクタを使用して、トンネル経由でルーティングするサブネットワークの IP 接頭辞を指定する必要があります。また、トンネルまでのトラフィックのルートも指定する必要があります。

トラフィック セレクタとレガシー ネットワーク

レガシー ネットワークの場合、デフォルトではネットワーク全体がトンネルに通知されます。この通知の範囲を制限する場合は、トラフィック セレクタを使用してインスタンスを限定することができます。ただし、レガシー ネットワークの IP アドレスはリージョンでどのように割り当てられるか予測できないため、上記の例のように複数のリージョンを使用する場合、ECMP の影響で VPN のパフォーマンスが低下する可能性があります。

各種ネットワークでの VPN の設定

自動サブネット ネットワーク
VPN ゲートウェイが配置されたリージョンのサブネットワークで使用する VPN の設定

自動サブネット ネットワークでは、事前定義された CIDR 範囲を使用して、ネットワーク内のリージョンごとに 1 つずつ自動的にサブネットワークが作成されます。自動サブネット ネットワークに関連付けられた VPN トンネルの --local-traffic-selector パラメータを省略した場合、VPN ゲートウェイと同じリージョンにあるサブネットワークの IP 接頭辞だけがリモートピアに通知されます。

次のような自動サブネット ネットワークについて考えてみましょう。このネットワークでは、VPN と同じリージョンにある subnetwork-b にのみトンネルの使用を許可し、それ以外のリージョンにある他のサブネットワークには許可していません。

VPN ゲートウェイが配置されたリージョンのサブネットワークで使用する VPN の設定図(クリックすると拡大します)
VPN ゲートウェイが配置されたリージョンのサブネットワークで使用する VPN の設定(クリックすると拡大します)

自動作成されたサブネットワークで VPN トンネルを作成するには、通常の VPN 作成手順に従いますが、一部の手順を次のように変更します。

手順 2: ネットワーク my-autosubnet-network のリージョン region-bVPN ゲートウェイを作成します。

gcloud compute target-vpn-gateways create target-vpn-gateway-b \
    --network my-autosubnet-network \
    --region region-b

手順 7: tunnel-b という VPN トンネルを作成します。

    gcloud compute vpn-tunnels create tunnel-b \
       --peer-address [PEER_IP_ADDRESS] \
       --region region-b \
       --shared-secret [SHARED_SECRET] \
       --target-vpn-gateway target-vpn-gateway-b

--local-traffic-selector を省略しているため、トンネルの作成時に subnetwork-b の CIDR 10.130.0.0/16 だけが通知されます。つまり、subnetwork-b のインスタンスからのトラフィックのみが VPN tunnel-b の通過を許可されます。

手順 8: subnetwork-b のすべてのインスタンスへの静的ルートを追加します。このルートは、送信先のピアの接頭辞 192.168.0.0/16tunnel-b のネクストホップで構成されます。

gcloud compute routes create route-via-tunnel \
    --destination-range 192.168.0.0/16 \
    --network my-autosubnet-network \
    --next-hop-vpn-tunnel-region region-b \
    --next-hop-vpn-tunnel tunnel-b
他のリージョンのサブネットワークで使用する VPN の設定

自動サブネット ネットワークでは、ハンドシェイクの実行時に通知する IP 接頭辞を指定できます。これにより、ローカル以外の接頭辞を指定して、それらの接頭辞を使用するサブネットでもトンネルを使用できるように設定することができます。

たとえば、region-a のサブネットワークで region-b にあるトンネルを介してトラフィックを送受信できるようにするには、tunnel-b の IKE 交換で範囲 10.128.0.0/16 を使用するように設定します。

次のシナリオでは、region-b にある VPN トンネルを region-a の subnetwork-a で使用できるように許可しています。

任意のリージョンの任意のサブネットワークで使用する VPN の設定図(クリックすると拡大します)
任意のリージョンの任意のサブネットワークで使用する VPN の設定(クリックすると拡大します)

自動作成されたサブネットワークで --local-traffic-selector を指定して VPN トンネルを作成するには、通常の VPN 作成手順に従いますが、一部の手順を次のように変更します。--local-traffic-selector parameter を使用しているため、トンネルのローカルのネットワークを含むすべての必要なネットワークを指定する必要があるので注意してください。

手順 2: ネットワーク my-autosubnet-network のリージョン region-bVPN ゲートウェイを作成します。

gcloud compute target-vpn-gateways create target-vpn-gateway-b \
     --network my-autosubnet-network \
     --region region-b

手順 7: tunnel-b という VPN トンネルを作成します。

gcloud compute vpn-tunnels create tunnel-b \
     --peer-address PEER_IP_ADDRESS \
     --region region-b \
     --shared-secret SHARED_SECRET \
     --local-traffic-selector 10.128.0.0/16,10.130.0.0/16 \
     --target-vpn-gateway target-vpn-gateway-b

--local-traffic-selector を追加して subnetwork-a10.128.0.0/16)と subnetwork-b10.128.0.0/16)の CIDR を指定しているため、それらのサブネットワーク内のすべてのインスタンスからのトラフィックがトンネルの通過を許可されます。

手順 8: subnetwork-asubnetwork-b のすべてのインスタンスに共通のタグを追加します。

gcloud compute instances add-tags example-instance-subnet-a \
    --tags tag-subnet-a
gcloud compute instances add-tags example-instance-subnet-b \
    --tags tag-subnet-b

手順 9: subnetwork-asubnetwork-b のすべてのインスタンスに静的ルートを追加します。このルートは、送信先のピアの接頭辞 192.168.0.0/16tunnel-b のネクストホップで構成されます。

gcloud compute routes create route-via-tunnel \
    --destination-range 192.168.0.0/16 \
    --network my-autosubnet-network \
    --next-hop-vpn-tunnel-region region-b \
    --next-hop-vpn-tunnel tunnel-b \
    --tags tag-subnet-a,tag-subnet-b
カスタム サブネット ネットワーク
特定のサブネットワークで使用する VPN の設定

カスタム サブネット ネットワークでは、リージョンのネットワークに対して 1 つ以上のサブネットワークを含めることができますが、それらのサブネットワークに関連付ける IP 範囲はユーザーが手動で設定します。そのため、通知する IP 接頭辞を --local-traffic-selector で必ず設定する必要があります。カスタム サブネット ネットワークの VPN トンネルで --local-traffic-selector が設定されていないとエラーが返されます。

次のようなカスタム サブネット ネットワークについて考えてみましょう。このネットワークには、CIDR 範囲 172.16.0.0/16 の region-a の subnetwork-a と CIDR 範囲 10.21.0.0/16 の region-b の subnetwork-b があり、region-b にある VPN の使用を subnetwork-b のみに許可しています。

任意のリージョンのカスタム サブネットワークで使用する VPN の設定図(クリックすると拡大します)
 class=任意のリージョンのカスタム サブネットワークで使用する VPN の設定図(クリックすると拡大します)" class="l10n-absolute-url-src">

カスタム サブネットで VPN トンネルを作成するには、通常の VPN 作成手順に従いますが、一部の手順を次のように変更します。

手順 2: ネットワーク my-custom-network のリージョン region-bVPN ゲートウェイを作成します。

gcloud compute target-vpn-gateways create target-vpn-gateway-b \
    --network my-custom-network \
    --region region-b

手順 7: tunnel-b という VPN トンネルを作成します。

    gcloud compute vpn-tunnels create tunnel-b \
       --peer-address [PEER_IP_ADDRESS] \
       --region region-b \
       --shared-secret [SHARED_SECRET] \
       --local-traffic-selector 10.21.0.0/16 \
       --target-vpn-gateway target-vpn-gateway-b

必ず --local-traffic-selector を追加して subnetwork-b の CIDR を指定する必要があります。 カスタム サブネット ネットワークの VPN トンネルで --local-traffic-selector が設定されていないとエラーが返されます。

手順 8: subnetwork-b のすべてのインスタンスに共通のタグを追加します。

gcloud compute instances add-tags example-instance-subnet-b \
    --tags tag-subnet-b

手順 9: subnetwork-b のすべてのインスタンスに静的ルートを追加します。このルートは、送信先のピアの接頭辞 192.168.0.0/16tunnel-b のネクストホップで構成されます。

gcloud compute routes create route-via-tunnel \
    --destination-range 192.168.0.0/16 \
    --network my-custom-network \
    --tags tag-subnet-b \
    --next-hop-vpn-tunnel-region region-b \
    --next-hop-vpn-tunnel tunnel-b

よくある質問

アドレス指定

Q: レガシー ネットワークからサブネット ネットワークに切り替えることはできますか?

A: レガシー ネットワークをサブネット ネットワークに変換することはできません。

Q: サブネットワークの有効な IP 接頭辞を教えてください。

A: サブネットワークの有効な IP 接頭辞は、RFC 1918 で定義されているプライベート アドレス空間です。

Q: サブネットワークの IP 接頭辞は重複していても構いませんか?

A: 1 つのネットワーク内では、サブネットワークの IP 接頭辞の重複は許容されません。2 つの異なるネットワークにあるサブネットワークであれば、IP 接頭辞が重複していても構いません。

Q: 単一のネットワークでは、サブネットワークの IP 接頭辞が連続している必要がありますか?

A: 単一のネットワーク内のサブネットワークが連続している必要はなく、IP 接頭辞がつながっていなくても構いません。たとえば、lab-subnetwork(10.240.1.0/24)と prod-subnetwork(192.168.1.0/24)のようなサブネットワークの構成は有効です。

Q: すべてのインスタンスを 1 つのゾーンと 1 つのサブネットワークに制限したいと考えています。ゾーンの範囲を限定するにはどうすればよいですか?

A: インスタンスを作成するときに、毎回同じゾーンとサブネットワークを選択します。

Q: 自動作成されるサブネットワークの各リージョンの IP 範囲は必ず同じになるのですか?

A: はい。自動設定される IP 範囲をご覧ください。

ルートとファイアウォール

Q: 同じネットワーク内のサブネットワークのインスタンスはデフォルトで相互に通信できますか?

A: はい。同じネットワーク内のインスタンスであれば、サブネットワークが異なる場合であっても、内部 IP アドレスを使用して相互に通信が可能です。ただし、手動で作成したネットワークの場合は、通信を許可するファイアウォール ルールの作成が必要になります。

Q: ネットワーク内の 2 つのサブネット間の通信を禁止することはできますか?

A: はい。ネットワークのサブネット間でのトラフィックの交換は、ファイアウォール ルールを使用してブロックできます。サブネットワークの分離をご覧ください。

VPN

Q: 自動サブネット ネットワークの VPN を作成しましたが、デフォルトでは同じリージョンにあるサブネットからしか使用できません。レガシー ネットワークのときのように、VPN を自動サブネット ネットワークでグローバルに使用することはできますか?

A: 自動サブネット ネットワークの VPN の設定をご覧ください。

シナリオ

Q: 自動サブネット ネットワークのおすすめのシナリオを教えてください。

A: 自動サブネット ネットワークを使用すると、簡単な設定だけですぐに作業を開始できるため、ネットワーク トポロジや IP アドレスの定義に時間をかけずにアプリケーションの展開に集中したい方におすすめです。

Q: 多層(ウェブ、API、DB)アプリケーションを単一のネットワークに展開して、必要に応じて各層を分離できるようにするにはどうすればよいですか?

A: ネットワークの作成時にカスタム サブネット ネットワークを作成し、層ごとに 1 つずつ、3 つのサブネットワークを作成します。たとえば、10.240.10.0/24(ウェブ)、10.240.30.0/24(API)、10.240.50.0/24(DB)のように作成できます。ウェブと DB のサブネットワークなど、各サブネットワークを分離する方法については、サブネットワークの分離をご覧ください。

Q: アプリケーション用の開発環境、テスト環境、実働環境を単一のネットワークに展開し、各環境を相互に分離できるようにするにはどうすればよいですか?

A: ネットワークの作成時にカスタム サブネット ネットワークを作成し、環境ごとに 1 つずつ、3 つのサブネットワークを作成します。たとえば、10.240.10.0/24(開発)、192.168.10.0/24(テスト)、172.16.10.0/24(実働)のように作成できます。各環境を相互に分離する方法については、サブネットワークの分離をご覧ください。

Q: マルチテナント アプリケーションのインスタンスを展開して分離する方法を教えてください。

A: サブネットワークが導入されるまでは、マルチテナント アプリケーションのテナントごとに 1 つのネットワークを作成し、さらに共有のサービス/アプリケーション(ライセンスや請求など)用に 1 つのネットワークを作成していました。共有のサービス アプリケーションには、他のネットワークのテナント アプリケーションと通信するために外部 IP が必要でした。

サブネットワークを使用すると、マルチテナント アプリケーションの展開モデルがシンプルになります。テナントごとに 1 つのカスタム サブネットワークを作成し、各サブネットワーク内のテナント アプリケーションを相互に分離することができます。 また、共有のサービス / アプリケーションは別のサブネットワークに配置し、そこからすべてのテナントのサブネットワークにアクセスできます。

外出先でもリソースをモニタリング

Google Cloud Console アプリを入手して、プロジェクトの管理にお役立てください。

フィードバックを送信...

Compute Engine ドキュメント