ネットワークとファイアウォールの使用

Google Cloud Platform(GCP)ネットワークにより、インスタンスを相互接続またはインターネットに接続します。ネットワークはセグメント化することができます。また、インスタンス上の特定のポートへのアクセスを許可するファイアウォール ルールや、トラフィックを特定の宛先に転送する静的ルートを作成できます。

始める前に

ネットワーク

すべての仮想マシン インスタンスは、ネットワークのメンバーとして作成されます。レガシー ネットワークでは単一のグローバル IP 範囲のメンバーとなります。サブネット ネットワークでは、ネットワークに属する単一のサブネットワークのメンバーとなります。ネットワークとサブネットワークはインスタンス間の通信を処理し、インスタンスと他のネットワーク間のゲートウェイとして機能します。ネットワークは単一のプロジェクトにのみ属することができ、複数のプロジェクトで共有することはできません。ただし、プロジェクトには複数のネットワークを設定できます。

各インスタンスには、そのインスタンスが作成されたサブネットワークまたはネットワークの IP 範囲から取得した内部 IP アドレスが割り当てられます。また、各インスタンスには外部 IP アドレスを割り当てることも可能で、インターネット経由でルーティングできます。外部 IP アドレスは、エフェメラルまたは静的のいずれかになります。エフェメラル アドレスはインスタンス間で移動できず、そのアドレスが割り当てられたインスタンスを削除するまでの間のみ存続します。静的アドレスは独立したシステム リソースとして存在し、任意のインスタンスに割り当てることができます。また、必要に応じて移動できます。静的アドレスは、インスタンスに割り当てられていない場合でも、任意の期間保持できます。ただし、予約済み IP アドレスの保持には費用がかかります。異なるネットワークのインスタンス間で通信する場合は、同一のプロジェクト内であっても外部 IP アドレスを経由する必要があります。

ネットワークの種類

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

Subnetworks for Google Cloud のリリースに伴い、ほとんどのネットワークはサブネット ネットワークになっています。ただし、必要に応じてレガシー ネットワークも引き続き作成できます。

レガシーの Compute Engine ネットワークは、ネットワーク全体に対応する単一のネットワーク IPv4 接頭辞範囲と単一のゲートウェイ 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 接頭辞を持ちます。サブネット ネットワークはスコープの面でリージョン的であり、グローバルなスコープを持つレガシー ネットワークとは異なります。ネットワーク内のサブネットは必ずしも連続している必要はありません。たとえば、あるサブネットの IP 範囲を 10.240.0.0/16 とし、別のサブネットの IP 範囲を 192.168.0.0/16 にすることができます。このように、サブネット ネットワークには全体的なネットワーク IP 範囲やゲートウェイ アドレスは存在しません。その代わりに、各サブネットワークが IP 範囲とゲートウェイ アドレスを持ちます。単一のネットワークに属するサブネットワークには、重複しない RFC1918 範囲を割り当てる必要があります。サブネットワークは 1 つのネットワークだけに属し、各インスタンスは 1 つのサブネットワークだけに属することができます。

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

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

サブネットワーク内で作成された各インスタンスには、そのサブネットワークの範囲から取得した 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 はリージョン内の複数のゾーンにまたがっています。サブネットワークはゾーンによる制限を受けず、リージョンによる制限だけを受けます。そのため、必要であれば、あるゾーン内のあるサブネットからインスタンスを作成し、別のゾーン内の別のサブネットからもインスタンスを作成できます。

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

ネットワーク環境

割り当て量と制限

1 つの GCP ネットワークには、最大 7,000 個までの仮想マシン インスタンスが存在できます。この数は増やすことができません。

他のリソースと割り当ての詳細については、割り当てページをご覧ください。これらの割り当ての多くは、ページにある [増加をリクエスト] ボタンを押すと増やすことができます。

IP 範囲

自動サブネット ネットワークでは、リージョンごとに以下の IP 範囲とゲートウェイを持つ 1 つのサブネットワークが設定されます。すべてのプロジェクトには、default という単一のネットワークが用意されています。これは自動サブネット ネットワークです。default は自動サブネット ネットワークであるため、常に以下のような範囲を持ちます。

リージョン 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

カスタム サブネット ネットワークでは、任意の有効な RFC1918 IP 範囲を使用できます。範囲は必ずしもサブネットワーク間で連続している必要はありません。たとえば、あるサブネットワークでは 10.0.0.0/8 から範囲を選択し、別のサブネットワークでは 192.168.0.0/16 から範囲を選択できます。ただし、範囲はネットワーク内で一意でなければならず、重複することはできません。また、カスタム サブネットワークは少なくとも /29 の IPv4 範囲を持っていなければなりません。

レガシー ネットワークは単一の RFC1918 範囲のみを持つことができ、ネットワークの作成時にこの範囲を指定します。

ネットワーク ルート

すべてのネットワークでは、インターネットへのルート(デフォルト ルート)とネットワーク内の IP 範囲へのルートが自動的に作成されます。ルート名は自動的に生成され、毎回違う名前になります。default ネットワークを含む自動サブネット ネットワークの範囲は次のようになります。

gcloud compute routes list
NAME                           NETWORK   DEST_RANGE    NEXT_HOP                 PRIORITY
default-route-02a98b9a14f7edc4 default   10.128.0.0/20                          1000
default-route-081fa300345dd52a default   0.0.0.0/0     default-internet-gateway 1000
default-route-93a38d78c77eac66 default   10.132.0.0/20                          1000
default-route-999664b72dd247e7 default   10.140.0.0/20                          1000
default-route-a1f15d0858cd51e1 default   10.142.0.0/20                          1000

カスタム サブネット ネットワークにはデフォルト ルートに加え、作成した各サブネットへのルートが設定されます。

レガシー ネットワークの場合、最初から用意されているルートは、デフォルト ルートと IP 範囲全体へのルートの 2 種類だけです。

これらのルートが存在するため、ネットワークはインターネットおよび作成された全インスタンスにトラフィックをどのように送信すればよいかを最初から知っています。ただし、適切なファイアウォール ルールを設定しない限り、トラフィックは各インスタンスに到達しません。

ファイアウォール ルール

各ネットワークには、インスタンスへのアクセスを制御する独自のファイアウォールが用意されています。

インスタンスへのすべてのトラフィックは、他のインスタンスからのトラフィックであっても、それを許可するファイアウォール ルールが作成されていない限りファイアウォールでブロックされます。

default ネットワークでは、以下に示すようなファイアウォール ルールが自動的に作成されます。手動で作成したネットワークの場合は、どのような種類のものであっても、ファイアウォール ルールは自動的に作成されません。default ネットワークを除くすべてのネットワークでは、必要に応じて任意のファイアウォール ルールを作成する必要があります。

ファイアウォール ルールは「allow」ルールだけです。「deny」ルールを作成することはできません。特定のインスタンスにトラフィックが到達しないようにする必要がある場合は、その他のインスタンスへのトラフィックを許可するルールを作成してから、すべてのインスタンスへのトラフィックを許可するファイアウォール ルールを削除します。

default ネットワーク用に自動的に作成されるファイアウォール ルールを次に示します。

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

内部 DNS と resolv.conf

インスタンスの内部完全修飾ドメイン名(FQDN)は次のとおりです。

hostName.c.[PROJECT_ID].internal

あるインスタンスから別のインスタンスには、常にこの FQDN を使用して接続できます。ただし、hostName などの情報だけを使用してインスタンスに接続する場合は、Compute Engine に含まれる内部 DNS リゾルバからの情報が必要になります。Compute Engine のインスタンスは、DHCP リースの一部として内部 DNS の解決情報を受け取ります。RFC3442 で規定されたローカル サブネット ルート機能をサポートしているインスタンスでは、任意の DNS リゾルバを使用できます。

デフォルトでは、多くの Linux ディストリビューションが resolv.conf に DHCP 情報を格納します。そのため、このセクションでは、インスタンスがこのファイルに情報を格納することを前提として説明を進めます。Compute Engine の各インスタンスは、DHCP リースを 24 時間ごとに更新するように設定されています。このファイルは DHCP の更新によって上書きされるため、手動で変更を加えても元に戻ります。

説明を書き加えた resolv.conf のサンプル

# Local domain name. Computed from your project name.
domain c.[PROJECT_ID].internal
# Search list for hostname lookup. Starting with entries that represent
# your project and ending with google.internal to facilitate metadata server requests.
# Note: Older projects might have a projectNumber.google.internal
# (eg. 1234.google.internal).
# Note: Compute Engine provides up to a maximum of 3 entries for the search path.
search c.[PROJECT_ID].internal google.internal.
# Address of the DNS server to resolve project specific, and global domain names.
nameserver 169.254.169.254
nameserver 10.128.0.1

説明を書き加えた dhcp.lease のサンプル

lease {
  # What interface we are using for the network
 interface "eth0";
 fixed-address 10.128.0.3;
 option subnet-mask 255.255.255.255;
 option routers 10.128.0.1;
 # Lease timeout, older VM instances will have this value set to infinite.
 option dhcp-lease-time 86400;
 option dhcp-message-type 5;
 option domain-name-servers 169.254.169.254,10.128.0.1;
 option dhcp-server-identifier 169.254.169.254;
 option interface-mtu 1430;
 # Search path options that are copied into the resolv.conf
 option domain-search "c.[PROJECT_ID].internal.", "google.internal.";
 option ntp-servers 169.254.169.254;
 option rfc3442-classless-static-routes 32,10,128,0,1,0,0,0,0,0,10,128,0,1;
 option host-name "vm1.c.[PROJECT_ID].internal";
 option domain-name "c.[PROJECT_ID].internal.";
 renew 4 2016/02/25 04:38:57;
 rebind 4 2016/02/25 16:00:08;
 expire 4 2016/02/25 19:00:08;
}

このファイルを変更する必要がある場合は、次の点に注意してください。

  • 検索パスが処理できるレコード数は 6 件までであり、そのうちの 3 件は Compute Engine からデフォルトで提供されています。検索パスにエントリを追加した結果、エントリの合計数が 6 件を超える場合、6 件目より後の検索ルールは OS によって適用されません。これは、インスタンス名を使用したインスタンスへのアクセスなど、Compute Engine の機能が動作しなくなる原因となる場合があります。
  • resolv.conf を手動で編集しても、インスタンスの DHCP リースが 24 時間ごとに期限切れとなるため、そのたびにデフォルトの DHCP に戻ります。インスタンスの resolv.conf に加えた変更が元に戻らないようにするため、多くの Linux ディストリビューションでは DHCP ポリシーの先頭または末尾にアイテムを追加できるようになっています。たとえば Debian では、dhclient.conf がこの機能を提供しています。

ユーザーによるネットワークの作成

ネットワークは、プロジェクトごとに default ネットワークを含め 5 つまで作成できます。default ネットワークが不要な場合は削除し、その代わりに別のネットワークを作成することもできます。プロジェクトで必要なネットワークの数が 5 つを超える場合は、追加の割り当てを申請できます。

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

既存のネットワークは変更できない点に注意してください。ネットワークに関連付けられたファイアウォール ルールの追加・削除や、ルートの追加・削除は可能です。ただしネットワークの作成後は、そのネットワークのアドレス範囲やゲートウェイを変更することはできません。

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

  1. 自動的に割り当てられたサブネットワークを使用して、新しいネットワークをプロジェクトで作成します。--mode フラグで auto が指定されているため、あらかじめ用意された 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-east1192.168.7.0/24 を割り当てています。

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

    NAME                 REGION     NETWORK         RANGE
    subnet-asia-east-192 asia-east1 custom-network1 192.168.7.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 192.168.7.0/24

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

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

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

  1. プロジェクトで新しいレガシー ネットワークを作成します。

      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
europe-west-192   europe-west     custom-network1 192.168.5.0/24
auto-network1     us-central1     auto-network1   10.128.0.0/20
us-central-192    us-central1     custom-network1 192.168.1.0/24
asia-east-192     asia-east1      custom-network1 192.168.7.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 beta 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 beta 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].

ネットワーク スループットの測定

仮想マシンからの送信トラフィック、つまり出力トラフィックは、ネットワークの最大出力スループット容量の影響を受けます。この容量は仮想マシン インスタンスが持つコア数に依存します。各コアの容量は、ピーク パフォーマンス時で 2 G ビット / 秒(Gbps)です。 出力スループット容量の詳細をご覧ください

このような容量との相対でインスタンスのパフォーマンスを測定するには、PerfKitBenchMarker を使用してインスタンスの出力スループットのパフォーマンスを測定します。

たとえば、ローカル コンピュータで次の各コマンドを実行します。このコマンドを実行するとインスタンスが作成され、そのパフォーマンスが測定されます。各値の意味は次のとおりです。

  • [MACHINE_TYPE] はテストするマシンタイプです(例: n1-standard-32)。
  • [ZONE] はインスタンスの作成先となるゾーンです。
  • [NUMBER_OF_CORES] はインスタンスのコア数です(例: n1-standard-32 マシンタイプの場合は 32)。

シングルストリームのパフォーマンスを測定するには:

./pkb.py --cloud=GCP --machine_type=[MACHINE_TYPE] --benchmarks=iperf --ip_addresses=INTERNAL --zones=[ZONE]

マルチストリームのパフォーマンスを測定するには:

./pkb.py --cloud=GCP --machine_type=[MACHINE_TYPE] --benchmarks=iperf --ip_addresses=INTERNAL --zones=[ZONE] --iperf_sending_thread_count=[NUMBER_OF_CORES]

高度なネットワーキングの詳細

このセクションでは、ここまでのセクションでは取り上げていない下位レベルの情報を示します。一般的な用途の場合、このセクションを読む必要はありませんが、このセクションを読むと Compute Engine におけるネットワーキングの仕組みについて理解が深まります。次の図はこれらの下位レベル情報を表します。詳細については、対応する各セクションをご覧ください。

A more detailed diagram of the Compute Engine
    network

ネットワーク

  • すべてのアクティブな接続をトラックするルックアップ テーブルを保持します。アクティブな接続の一環としてパケットが到着すると、そのパケットはファイアウォール ルールを参照することなく宛先に送信されます。
  • 外部 IP アドレスとインスタンスを関連付けるルックアップ テーブルを保持します。外部 IP アドレスに向かうすべてのパケットはネットワークにルーティングされ、そのアドレスに対応する内部 IP が検索されて、インスタンスに転送されます。
  • 特定の IP アドレスについて MAC アドレス検索(プロキシ ARP)を実行します。
  • ネットワーク上のインスタンスとの間でパケットのルーティングを行います。
  • パケットを外部にルーティングします(課金を伴います)。

ファイアウォール

  • Compute Engine のファイアウォールは、インスタンスに向かうパケットはブロックできますが、インスタンスから離れるパケットはブロックできません。インスタンスから離れる送信パケットをブロックする場合は、iptables などの別の手法をインスタンスで設定する必要があります。
  • いったん接続が確立されると、同じ 2 つの IP アドレス、同じインスタンス ポート、同じプロトコルを含むすべての送受信パケットは、接続が期限切れになるまで許可されます。アクティブでない状態が 10 分間続くと、接続は期限切れになります。ただし、別のインスタンス ポートに応答が送信された場合(FTP リクエストが別のポートからのレスポンスを要求した場合など)、そのレスポンスは自動的に許可されません。この場合、その新しいポートでの接続を許可するファイアウォール ルールが必要になります。

インスタンス

  • 各インスタンスにはメタデータ サーバーがあり、そのインスタンスの DNS リゾルバとしても機能します。DNS ルックアップはインスタンス名に対して実行されます。メタデータ サーバー自体は、ローカル ネットワークのすべての DNS 情報を保持します。ローカル ネットワーク外のアドレスについては、Google のパブリック DNS サーバーに問い合わせます。
  • インスタンスは自身に割り当てられている外部 IP アドレスを一切認識しません。その代わりにネットワークが、外部 IP アドレスと該当するインスタンスの内部 IP アドレスを対応付けるルックアップ テーブルを保持しています。

各処理を実行する要素

内部的には、各ネットワーキング機能は Compute Engine システムのさまざまな要素によって処理されています。これには、各種ドキュメントで説明されている標準的なネットワーキング機能もあれば、Compute Engine に固有のものもあります。また、ユーザーが設定できるものもあれば、設定できないものもあります。Compute Engine では、Linux の VIRTIO ネットワーク モジュールを使用してイーサネット カードとルーターの機能をモデル化しています。ただし、ARP ルックアップなど、上位レベルのネットワーキング スタックは、標準的なネットワーキング ソフトウェアを使って処理されます。

ARP ルックアップ
インスタンスのカーネルが ARP リクエストを発行し、ネットワークが ARP 応答を発行します。MAC アドレスと IP アドレスのマッピングはインスタンスのカーネルによって処理されます。
MAC ルックアップ テーブル、IP ルックアップ テーブル、アクティブ接続テーブル
これらのテーブルは基盤となるネットワークでホストされているため、検査や設定はできません。
DNS サーバー
各インスタンスのメタデータ サーバーは DNS サーバーとして機能します。これはローカル ネットワーク内のすべてのネットワーク IP アドレスに対応する DNS エントリを保持し、ネットワーク外のエントリについては Google のパブリック DNS サーバーを呼び出します。この DNS サーバーを構成することはできません。ただし、/etc/resolv.conf ファイルを編集することで、インスタンスで独自の DNS サーバーを使用できます。
ネットワークと外部との間でのパケット処理
ネットワークに出入りするパケットはネットワーク コードによって処理されます。ネットワーク コードは、ファイアウォール ルール、外部 IP のルックアップ テーブル、アクティブ接続テーブルとの照合によりパケットを検査します。また、ネットワークに出入りするパケットに対して NAT も実行されます。
インスタンスによって受信されたパケット
このようなパケットは、標準的な方法でインスタンスのカーネルによって受信され、ストリームに変換されます。
インスタンスによって送信されたパケット
パケットは標準的な方法でインスタンスのカーネルによって送信されます。インターフェースとネットワークの機能は、VIRTIO ネットワーク モジュールを使用してモデル化されています。

接続の詳細な流れ

ここでは、インスタンスがネットワーク呼び出しを実行したときに発生する動作を詳しく説明します。

インスタンスが呼び出しを実行する:

  1. ターゲット アドレスがインスタンス名または www.google.com などの URL の場合、インスタンスはメタデータ サーバーで DNS サービスを呼び出し、一致する IP アドレスを取得します。インスタンスが別の DNS サービスを参照するように設定することもできます。ただし、この場合はインスタンス名を解決できなくなります。
  2. 宛先 IP アドレスが、すべてのインスタンスが認識しているサブネットワークの IP アドレス範囲と照合されます。

    1. IP アドレスがネットワーク外の場合:

      1. インスタンスが、宛先がパケットの最終的な宛先に設定されているサブネットワークのゲートウェイ MAC アドレスにパケットを送信します。インスタンスは、場合によっては ARP リクエストを実行し、ゲートウェイの MAC アドレスを解決する必要があります。

      2. ネットワークが IP ヘッダーを書き換え、送信元としてインスタンスの外部 IP アドレスを宣言します。インスタンスに外部 IP アドレスが割り当てられていない場合、この呼び出しは許可されず、ネットワークは送信者に通知することなく、そのパケットを破棄します。

      3. ネットワークが送信パケットを記録し、送信元と宛先をアクティブ接続テーブルに追加します。

      4. ネットワークが、パケットを宛先に送信します。

      5. 宛先がパケットを受け取り、選択に応じて応答します。

      6. ネットワークが応答を受信し、アクティブ接続テーブルを参照します。これはアクティブな接続であるため、許可される点に注意してください。ネットワークは、ネットワーク / 外部 IP のルックアップ テーブルを参照し、インスタンスの外部 IP アドレスを一致するネットワーク アドレスに置き換えて、パケットを送信元のインスタンスに送信します。

      7. インスタンスがパケットを受信します。

    2. 宛先 IP アドレスがネットワーク内の場合:

      1. インスタンスは 255.255.255.255 のマスクを持つ IP で構成されているため、サブネットワークのゲートウェイ MAC アドレスにパケットを送信します。インスタンスは、場合によっては最初に ARP リクエストを実行し、ゲートウェイの MAC アドレスを解決する必要があります。

      2. プロキシ ARP を使用するネットワークは、宛先インスタンスの MAC アドレスを使用して応答します。

      3. ゲートウェイがパケットを受信し、ネットワーク内の宛先 IP にパケットをルーティングします。

      4. ターゲット インスタンスがパケットを受信します。ターゲット インスタンスは入力ファイアウォールを確認し、そのパケットを許可するかどうか判断します。許可されない場合、パケットは通知なく破棄されます。それ以外の場合は、インスタンスがパケットを処理します。

外部インスタンスまたはコンピュータがインスタンスを呼び出す:

  1. 外部の呼び出し元が、インスタンスの外部 IP アドレス(ネットワークが所有するアドレス)にパケットを送信します。

  2. ネットワークがパケットとアクティブ接続テーブルを比較し、それが既存の接続かどうかを確認します。

    1. 既存の接続でない場合、ネットワークは、接続を許可するファイアウォール ルールを検索します。
    2. ファイアウォール ルールが存在しない場合、ネットワークは、送信者に通知することなくパケットを破棄します。
  3. 既存の接続または有効なファイアウォール ルールが存在する場合、ネットワークはルックアップ テーブルを調べ、パケット内の外部 IP を対応するネットワーク IP に置き換えます。そして、受信パケットをアクティブ接続テーブルに記録し、そのパケットをターゲット インスタンスに送信します。

  4. インスタンスは、ネットワーク範囲外にパケットを送信する場合、IP アドレスがネットワーク IP の範囲外の場合の説明に沿って、パケットを受信して応答します。

  5. ネットワークが応答を受信すると、一致する受信リクエストをアクティブ接続テーブルで確認してからパケットの通過を許可します。送信する前に、インスタンスのネットワーク IP をルックアップ テーブルから取得した対応する外部 IP に置き換えて、送信元 IP アドレスを変更します。

ファイアウォール

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

各ネットワークのファイアウォールは、インスタンスに向かうすべてのトラフィックをブロックしますが、インスタンスから外部に送信されるトラフィックはブロックしません。インスタンスに向かう受信トラフィックを許可するには、ファイアウォールの「allow」ルールを作成する必要があります。

default ネットワークではファイアウォール ルールが自動的に作成されますが、ユーザーが作成したネットワークでは作成されません。

各ファイアウォール ルールは、送信元、宛先、ポート、プロトコルによって許可する受信接続リクエストを指定します。リクエストがインスタンスに送信されると、送信元が内部、別のネットワーク、インターネットのいずれであるかにかかわらず、ファイアウォールのいずれかのルールで接続が許可されていれば、そのリクエストは許可されます。

インスタンスによるパケットの送信はファイアウォールによって制限されません。インスタンスは、自身と同じネットワーク内であれば、どのインスタンスにでもパケットを送信できます。ただし、そのパケットが受け入れられるかどうかは、ターゲット インスタンスに関連付けられているファイアウォール ルールによって決定されます。送信リクエストを制御するには、iptables など、別のシステムを使用します。

ネットワーク外にパケットを送信できるのは、外部 IP アドレスを持つインスタンスだけです。ただし、同じネットワーク内の別のサブネットワークにあるインスタンスであれば、外部 IP アドレスを使わずに相互に到達できます。

ネットワーク外から直接アドレス指定できるのは、外部 IP アドレスを持ち、トラフィックを許可するファイアウォール ルールが設定されたインスタンスだけです。また、外部からのアドレス指定が可能なプロキシ サーバーを経由して、外部 IP アドレスを持たないインスタンスにパケットをルーティングすることもできます。

ファイアウォール ルールをプロジェクト間、あるいは同じプロジェクト内のネットワーク間で共有することはできません。

Compute Engine は、接続トラッキング テーブルを使用してステートフル ファイアウォール フィルタリングをサポートします。テーブルで定義できる接続の最大数はインスタンス タイプによって異なります。現在の最大接続数を次に示します。

  • 共有コア マシンタイプの場合は、インスタンスあたり 130,000
  • CPU 数が 1~8 のインスタンスの場合は、CPU あたり 130,000
  • CPU 数が 8 を超えるインスタンスの場合は、インスタンスあたり 130,000*8(1,040,000)

ファイアウォール ルールでは次のプロパティが公開されます。これらは gcloud compute firewall-rules create コマンドを使用して設定することもできます。各ルールは複数の要素で構成されており、そのほとんどは接続が許可される前に定義しておく必要があります。

network
[必須] このファイアウォール ルールを割り当てるネットワーク。各ファイアウォール ルールは 1 つのネットワークにのみ関連付けることができます。API 呼び出しを実行してファイアウォール ルールを作成するときは、ネットワークを指定する必要があります。ただし、gcloud compute を使用したときにネットワークを指定しなかった場合、そのルールは自動的に default ネットワークに割り当てられます。
sourceRanges

CIDR 表記で記述された IP アドレス ブロックのリストに従って、許可される発信者を識別します。sourceRanges または sourceTags のどちらも指定されていない場合、デフォルトは 0.0.0.0/0 になり、ネットワークの内部または外部からのすべての受信接続に対してルールが適用されます。sourceRangessourceTags の両方が指定されている場合は、送信元の範囲が sourceRanges と一致する場合、または送信元のタグが sourceTags と一致する場合に受信接続が許可されます。ファイアウォール ルールは IPv6 をサポートしません。

"sourceRanges": [ "198.51.100.0/24", "203.0.113.0/25" ]
sourceTags

送信元がネットワークの内部で、指定されているタグのいずれかに関連付けられている場合、その接続は受け入れられます。sourceRanges または sourceTags のどちらも指定されていない場合、sourceRanges はデフォルトで 0.0.0.0/0 になり、ネットワークの内部または外部からのすべての受信接続に対してルールが適用されます。sourceRangessourceTags の両方が指定されている場合は、送信元の範囲が sourceRanges と一致する場合、または送信元のタグが sourceTags と一致する場合に受信接続が許可されます。

"sourceTags": [ "management" ]
targetTags

[省略可] ネットワーク上のどのインスタンスが、指定された送信元からのリクエストを受け入れるのかを指定したインスタンス タグのリスト。指定しない場合、そのファイアウォール ルールはネットワーク上のすべてのインスタンスに適用されます。次に例を示します。

"targetTags": [ "web", "database" ]
allowed

[必須] そのファイアウォール ルールで許可される接続の配列。配列の各要素は IP プロトコルとオプションのポート範囲(TCP トラフィックと UDP トラフィックの場合)で構成されており、ここで指定された接続が targetTags で指定されているインスタンスへの到達を許可されます。

IPProtocol
[必須] この接続で許可されるプロトコル。tcpudpicmpespahsctp の文字列値(大文字と小文字を区別)か、任意の IP プロトコル番号を指定します。
ports
[省略可] この接続で許可されるターゲット ポートの配列。TCP 接続と UDP 接続だけに適用されます。各値は単一のポートまたはポート範囲を表す文字列です。指定しない場合、すべてのポートが許可されます。: ["80", "160", "300-500"]

次に例を示します。

"allowed": [
  {
    "IPProtocol": "tcp",
    "ports": [ "22" ],
  },
  {
    "IPProtocol": "udp",
    "ports": [ "161" ],
  }
]
name

[必須] ファイアウォールの名前。名前はプロジェクト内で固有でなければならず、1~63 文字でなければなりません。また、[a-z]([-a-z0-9]*[a-z0-9])? という正規表現と一致する必要があります。 最初の文字は小文字でなければならず、それに続くすべての文字はダッシュ、小文字、数字のいずれかでなければなりません。最後の文字をダッシュにすることはできません。

どのプロジェクトでも、default ネットワークには次の標準ファイアウォール ルールが用意されています。これらのルールは変更または削除できます。また、別のルールを追加、変更、削除することもできます。

default-allow-internal
任意の 2 つのインスタンス間で任意のプロトコルとポートのネットワーク接続を許可します。
default-allow-ssh
任意の送信元からネットワーク上の任意のインスタンスへのポート 22 を経由した TCP 接続を許可します。ただし外部 IP アドレスを持たないインスタンスには、外部の送信元から直接到達することはできません。
default-allow-icmp
任意の送信元からネットワーク上の任意のインスタンスへの ICMP トラフィックを許可します。
default-allow-rdp
ポート 3389 へのリモート デスクトップ プロトコルのトラフィックを許可します。

上記のデフォルト ルールは、外部の送信元からの HTTP または HTTPS トラフィックを許可しません。このようなトラフィックを許可する手順については、外部 HTTP 接続の設定をご覧ください。

次の例は、default-allow-ssh ファイアウォール ルールを示したものです。送信元の 0.0.0.0/0 という CIDR は、ネットワークの内部か外部かを問わず、どこからでも接続できることを意味します。

gcloud compute firewall-rules describe default-allow-ssh
allowed:
- IPProtocol: tcp
  ports:
  - '22'
creationTimestamp: '2014-07-08T10:32:46.214-07:00'
description: Allow SSH from anywhere
id: '13715544083725015625'
kind: compute#firewall
name: default-allow-ssh
network: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/default
selfLink: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls/default-allow-ssh
sourceRanges:
- 0.0.0.0/0

便利な gcloud compute コマンド:

ファイアウォール ルールの追加

ファイアウォール ルールを追加するには、許可する IP 範囲、ターゲットタグ、ターゲット ポート、送信元タグ、プロトコル、ネットワークを記述したファイアウォール ルール リソースを作成します。このファイアウォールは、指定したネットワークに接続するすべてのインスタンスに適用されます。gcloud compute で、次の firewall-rules create コマンドを使用します。

gcloud compute firewall-rules create [FIREWALL_RULE] \
    --allow [PROTOCOL][:[PORT][-[PORT]]],[[PROTOCOL][:[PORT][-[PORT]]],…] \
    [--network [NETWORK]; default="default"] \
    [--source-ranges [CIDR_RANGE],[[CIDR_RANGE],…]]

次のコマンドを実行すると、任意の送信元から外部 IP アドレスを公開しているネットワーク内の任意のインスタンスにポート 80 経由で HTTP 接続を確立することを許可するファイアウォールが追加されます。

gcloud compute firewall-rules create allow-http --description "Incoming http allowed." \
         --allow tcp:80 --format json
{
  "allowed": [
    {
      "IPProtocol": "tcp",
      "ports": [
        "80"
      ]
    }
  ],
  "creationTimestamp": "1234-56-78T09:12:34.567",
  "description": "Incoming http allowed.",
  "id": "13AAA70BBBB5639CCCC9",
  "kind": "compute#firewall",
  "name": "allow-http",
  "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/default",
  "selfLink": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls/allowhttp",
  "sourceRanges": [
    "0.0.0.0/0"
  ]
}

ファイアウォール ルールの削除

ファイアウォール ルールを削除するには、次の firewall-rules delete コマンドを実行します。

gcloud compute firewall-rules delete [FIREWALL_RULE]

ルート

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

状況によっては、追加のルートを作成して、一部のパケットを代替の宛先に明示的に転送できます。たとえば、すべてのネットワークには、トラフィックをネットワーク外に送信するデフォルトのルートが用意されています。ただし、宛先が 0.0.0.0/0 のパケットについては別のルートを作成し、プロキシを実行する仮想マシン インスタンスにこれらのパケットをルーティングするよう指定できます。

ルートを使用して、多対 1 の NAT や透過プロキシなど、さらに高度なネットワーク機能を仮想マシンに実装できます。高度なルーティング ソリューションを必要としない場合は、デフォルトのルートでほとんどの送信トラフィックを十分に処理できます。

自動作成されたルート

ネットワークを作成すると、一定のルートが作成されます。

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

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

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

レガシー ネットワークの場合

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

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

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

インスタンスのルーティング テーブル

Routes コレクションの各ルートは 1 つまたは複数のインスタンスに適用できます。ルートはネットワークとインスタンスのタグが一致する場合にインスタンスに適用されます。ネットワークが一致し、インスタンス タグが指定されていない場合、ルートはそのネットワーク内のすべてのインスタンスに適用されます。Compute Engine は Routes コレクションを使用して、各インスタンスに対応した個別の読み取り専用ルーティング テーブルを作成します。

この処理は、各ネットワークの中心に大規模でスケーラブルな仮想ルーターがある図を描くとわかりやすくなります。ネットワーク内のすべての仮想マシン インスタンスはこのルーターに直接接続しているため、仮想マシン インスタンスから離れるすべてのパケットは、まずこのレイヤで処理されてからネクストホップに転送されます。仮想ネットワークのルーターは、そのインスタンスのルーティング テーブルを参照してパケットのネクストホップを選択します。以下の図はこの関係を示したものです。緑色のボックスが仮想マシン インスタンスで、中心にルーターがあります。茶色のボックスは個別のルーティング テーブルを表します。

図のレガシー ネットワークの Routes コレクションは次のようになります。

NAME                           NETWORK DEST_RANGE    NEXT_HOP                 PRIORITY
default-route-68079898SAMPLEe7 default 0.0.0.0/0     default-internet-gateway   1000
default-route-78SAMPLEd2bc5762 default 10.100.0.0/16                            1000
vpngateway                     default 172.12.0.0/16 us-central1-a/instances/vpngateway  1000

vpngateway ルートを詳しく見ると、ルートの vpn タグが次のように公開されています。

gcloud compute routes describe vpngateway
creationTimestamp: '2014-07-28T15:26:27.023-07:00'
destRange: 172.12.0.0/16
id: '12304245498973864442'
kind: compute#route
name: vpngateway
network: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/default
nextHopGateway: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-a/instances/vpngateway
priority: 1000
selfLink: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/routes/vpngateway
tags:
- vpn

この vpngateway ルートにより、vpn タグを持つすべてのインスタンスに、2 つのデフォルト ルートと vpngateway ルートを含むルーティング テーブルが自動的に設定されます。この図では、vm1vm2 のどちらも、それぞれのルーティング テーブルにこのようなルートが含まれているため、172.12.0.0/16 という外部 IP 範囲を宛先とするすべての送信トラフィックは vpngateway インスタンスによって処理されます。

インスタンスのルーティング テーブルは読み取り専用のエンティティです。このテーブルを直接編集することはできません。ルートの追加、削除、編集は Routes コレクション経由で実行する必要があります。

個別のルート

ルートは次の各要素で構成されています。

name
[必須] ユーザーにとってわかりやすいルートの名前。たとえば、インターネットへのアクセスを許可するルートには internetroute という名前を付けます。
network
[必須] このルートを適用するネットワークの名前。たとえば、default ネットワークなどです。
destRange
[必須] このルートを適用する宛先 IP の範囲。パケットの宛先 IP がこの範囲内にある場合は、このルートと一致しているものとみなされます。たとえば、0.0.0.0/0 と指定します。Compute Engine が、一致するすべてのルートの中からパケットのネクストホップを 1 つだけ選択する仕組みについては、ルートの選択セクションをご覧ください。ルートでは IPv6 はサポートされません。デフォルトは 0.0.0.0/0 になり、ネットワークの内部または外部からのすべての受信接続に対してルールが適用されます。
instanceTags
[必須] このルートを適用するインスタンス タグのリスト。空の場合、このルートは指定したネットワーク内のすべてのインスタンスに適用されます。このフィールドは、API では必須です。gcloud compute では、このフィールドは省略可能です。フィールドが指定されていない場合、gcloud compute はリストが空であるものとみなします。

ネクストホップの指定は、次のいずれか 1 つだけを選ぶ必要があります。

nextHopInstance

一致するパケットを処理するインスタンスの完全修飾 URL。インスタンスが存在していて、IP 転送が有効になっている必要があります。次に例を示します。

https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances/<instance>

ネクストホップ インスタンスがクラッシュしてシステムによって再起動された場合、またはインスタンスを削除して同じゾーンに同じ名前で再作成した場合、一致するパケットは引き続き新しいインスタンスにルーティングされます。

nextHopIp

一致するパケットを処理するインスタンスのネットワーク IP アドレス。この IP アドレスはネットワークのアドレス空間の範囲内にある必要があります。たとえば、ネットワークが 10.240.0.0/16 の場合、nextHopIp=1.1.1.1 を指定することはできません。インスタンスが存在していて、IP 転送が有効になっている必要があります。ネクストホップ インスタンスがクラッシュし、システムによって同じ IP アドレスで再起動された場合、またはインスタンスを削除して同じ IP アドレスで再作成した場合、一致するパケットは引き続き新しいインスタンスにルーティングされます。

nextHopNetwork

[読み取り専用] 一致するパケットを処理するローカル ネットワークの URL。デフォルトのローカルルートでのみ使用できます。このフィールドを手動で設定することはできません。

nextHopGateway

一致するパケットを処理するゲートウェイの URL。現在のところ、使用できるのはインターネット ゲートウェイだけです。

/projects/[PROJECT_ID]/global/gateways/default-internet-gateway
nextHopVpnTunnel

一致するパケットを処理する Compute Engine VPN トンネルの URL。

priority

[必須] このルートの優先度。優先度は、最大長の一致ルートが複数ある場合に優先順位を付けるために使用されます。値が小さいほど優先度は高いため、100 のほうが 200 よりも優先されます。たとえば、次の各ルートは接頭辞長が同じで同じネットワーク内にあるため、優先順位は同一になります。ただし優先度値が異なるため、vpnroute のほうが優先されます。

NAME                       NETWORK     DEST_RANGE         NEXT_HOP                            PRIORITY
vpnroute                   default     192.168.0.0/16     [ZONE]/instances/vpninstance          1000
vpnroute-backup            default     192.168.0.0/16     [ZONE]/instances/vpninstance-backup   2000

この構成では、通常は VPN トラフィックが vpninstance によって処理され、vpnroute が削除されている場合は vpninstance-backup にフォールバックします。

このフィールドは、API では必須です。gcloud compute では、このフィールドは省略可能です。フィールドが指定されていない場合、gcloud compute はデフォルトの優先度 1000 であるものとみなします。

ルートの選択

送信パケットが仮想マシン インスタンスから離れるとき、使用するルートとパケットの転送先は次のステップに従って決定されます。

  1. パケットの宛先アドレスに一致する最も限定的なルート以外のすべてのルートを破棄します。たとえば、destinationRange=10.1.1.1 で、10.1.1.0/24 のルートと 10.240.0.0/16 のルートが存在する場合は、10.1.1.0/24 が選択されます。これは前者のほうが限定的であるためです。

  2. 同じ接頭辞長を持つルートが複数存在する場合は、最も小さい優先度値を持つルート以外のすべてのルートを破棄します(優先度値が小さいほど優先度が高いことを示します)。この時点では、まだ複数のルートが残されている可能性があります。

  3. IP プロトコル フィールド、送信元と宛先の IP アドレス、送信元ポートと宛先ポートのハッシュ値を計算します。Compute Engine はこのハッシュ値を使用して、残りの同順位のルートからネクストホップを 1 つだけ選択します。

  4. ネクストホップが見つかった場合、パケットを転送します。ネクストホップが見つからない場合はパケットを破棄し、ICMP 宛先またはネットワーク到達不能エラーを返します。

ネクストホップの選択時にネットワークの距離は考慮されない点に注意してください。ネクストホップ インスタンスまたはゲートウェイはパケットを送信するインスタンスとは異なるゾーンにある可能性があるため、ルーティング テーブルは局所性を制御するように設計する必要があります。たとえば、インスタンス タグを使用することで、別のゾーンにあるインスタンスのパケットをローカルの透過プロキシまたは VPN ゲートウェイに向けることができます。ゾーン別にインスタンスにタグ付けすることで、あるゾーンのインスタンスから離れるパケットが、同じゾーン内のネクストホップだけに送信されるようにすることができます。

ルートの一覧表示

gcloud compute を使用してプロジェクトのルートを一覧表示するには、次のように routes list コマンドを実行します。

gcloud compute routes list

次に例を示します。

gcloud compute routes list
NAME                           NETWORK   DEST_RANGE    NEXT_HOP                 PRIORITY
default-route-02a98b9a14f7edc4 default   10.128.0.0/20                          1000
default-route-081fa300345dd52a default   0.0.0.0/0     default-internet-gateway 1000
default-route-0fcb41f96ba1b57d legacy1   0.0.0.0/0     default-internet-gateway 1000
default-route-907f4b8dbd772dc3 legacy1   10.240.0.0/16                          1000
default-route-93a38d78c77eac66 default   10.132.0.0/20                          1000
default-route-999664b72dd247e7 default   10.140.0.0/20                          1000
default-route-a1f15d0858cd51e1 default   10.142.0.0/20                          1000

ルートの追加

gcloud compute を使用してルーティング テーブルにルートを追加するには、次のように routes create コマンドを使用します。

gcloud compute routes create ROUTE --destination-range DEST_RANGE --network NETWORK NEXT_HOP

ルートの削除

ルートを削除するには、次のように routes delete コマンドを実行します。

gcloud compute routes delete [ROUTE]

API でルートを削除するには、リクエストの本文が空の HTTP DELETE リクエストを次の URI に対して実行します。

https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/routes/<route-name>

ルート オペレーションの一貫性

Routes コレクションに変更を加えると、その変更は(即時ではなく)最終的にすべてのインスタンスに適用されます。つまり、ルートを更新・追加・削除した後、該当するすべてのインスタンスについてその変更が有効であることが保証されるのは、DONE というオペレーション ステータスが返された後になります。PENDING または RUNNING のステータスのオペレーションは、その変更が一部のインスタンスについて有効であり、必ずしもすべてのインスタンスで有効にはなっていない可能性があります。

一連の順序で変更を加える場合、そのような変更は不定の順序でインスタンスに適用される可能性があります。リクエストが作成された順に処理されるとは限りません。また、ルーティングの変更は即座に有効になるわけではないため、タイミングによっては、インスタンスごとに異なる変更内容が参照される可能性があります。ただし、影響を受けるすべてのインスタンスに変更が実装されると、オペレーションのステータスは DONE に移行します。

インスタンスに対する IP 転送の有効化

デフォルトでは、Compute Engine のインスタンスから、送信元 IP アドレスがパケットを送信するインスタンスの IP アドレスと一致しないパケットを送信しようとすると、ブロックされます。同様に、宛先 IP アドレスがパケットを受信するインスタンスの IP アドレスと異なるパケットは伝送されません。ただし、どちらの機能も、インスタンスを使ってパケットのルーティングを支援する場合に必要になります。このような送信元と宛先の IP チェックを無効にするには、canIpForward フィールドを有効にします。これによりインスタンスは、一致しない宛先 IP または送信元 IP を持つパケットを送受信できるようになります。

gcloud computecanIpForward フィールドを設定するには、インスタンスの作成時に --can-ip-forward フラグを使用します。

gcloud compute instances create ... --can-ip-forward

API では、新しいインスタンスを作成するリクエスト本文を構築するときに、canIpForward フィールドを true に設定します。

{
  "name": "myinstance",
  "description": "",
  "image": "https://www.googleapis.com/compute/v1/projects/debian-cloud/global/images/debian-8-jessie-vYYYYMMDD",
  "machineType": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/machineTypes/n1-standard-2",
  "networkInterfaces": [
      ...
  ],
  "canIpForward": true
}

このフィールドを設定できるのはインスタンスの作成時のみです。 インスタンスの作成後は、フィールドは読み取り専用になります。

ファイアウォール ルールの操作

ルートを作成しただけでは、指定したネクストホップでパケットが受信されることは保証されません。受信トラフィックがネットワークまたはインスタンスへの進入を許可されるかどうかは、ファイアウォール ルールによって判断されます。たとえば、複数のインスタンスを通じてパケットを送信するルートを作成する場合、各インスタンスには、前のインスタンスから送信されたパケットを受け入れるファイアウォール ルールが関連付けられている必要があります。

IP アドレスの照合については、パケットの送信元 IP アドレスだけが使用されるため、必ずしもパケットを送信しているインスタンスの IP アドレスであるとは限りません。ファイアウォール ルールで、10.240.0.3 から送信されたパケットだけを受け入れるように指定されている場合、その送信元 IP アドレスを持つパケットは、パケットを送信したインスタンスの IP アドレスにかかわらず、すべて受け入れられます。

  • インスタンス 10.240.0.3canIpForward を有効にしていて、パケットが送信元 IP 10.240.0.4 を持つようになりすましている場合、そのパケットはファイアウォールによって拒否されます。
  • インスタンス 10.240.0.4canIpForward を有効にしていて、パケットが送信元 IP 10.240.0.3 を持つようになりすましている場合、そのパケットはファイアウォールによって受け入れられます。

送信元タグとはパケットの送信元 IP に対応するエイリアスであり、パケットを送信しているインスタンスの IP ではありません。たとえば、mytag という名前の送信元タグが、IP 10.240.0.3 を持つインスタンスに割り当てられている場合、mytag からのトラフィックを許可するルールでは、パケットを送信したインスタンスにかかわらず、10.240.0.3 の送信元 IP を持つすべてのパケットが許可されます。IP 転送が有効になっているインスタンスは、そのインスタンスの IP アドレスとは異なる送信元 IP アドレスを持つパケットを送信できるため、この点は重要です。一方、ターゲットタグは受信側インスタンスの IP だけに対応するエイリアスであるため、このような曖昧さはありません。

将来的に Compute Engine では、ファイアウォール ルールによる送信元タグの処理方法を変更する可能性があります。

詳細については、ファイアウォールをご覧ください。

インターネットへのパケットのルーティング

現在のところ、インターネットに送信されるすべてのパケットは、外部 IP アドレスを持つインスタンスから送信する必要があります。特定のインスタンスからインターネットへパケットを送信するルートを作成する場合、そのインスタンスは外部 IP アドレスも持つインスタンスでなければなりません。インターネット ゲートウェイにパケットを送信するルートを作成し、送信元インスタンスが外部 IP アドレスを持っていない場合、そのパケットは破棄されます。

特別な設定

静的な内部 IP アドレスの設定

Compute Engine では、インスタンスのライフサイクルを超えて存続する静的な内部 IP アドレスを設定することはできませんが、ルートとインスタンスの --can-ip-forward 機能を組み合わせることで、IP アドレスを静的な内部 IP アドレスとして追加できます。同じネットワーク内の他のインスタンスは、このアドレスを仮想マシン インスタンスのターゲットとして使用できます。また、その IP アドレスからトラフィックを送信するようにインスタンス自体を変更することもできます。

たとえば、内部 IP アドレスとして 10.1.1.1 というアドレスを仮想マシン インスタンスに特定的に割り当てる場合は、そのインスタンスの内部 IP アドレスが 10.1.1.1 でない場合であっても、10.1.1.1 からインスタンスにトラフィックを送信する静的なルートを作成できます。また、10.1.1.1 からトラフィックを送信するようにインスタンスを設定することもできます。

各操作については、次の手順を参照してください。

次の手順はプロジェクトで default ネットワークを使用していることを前提としています。

静的な内部 IP アドレスを設定するときは、次のことを念頭に置いてください。

  • インスタンスの作成時は、ルートを使用せずに特定の内部 IP アドレスをインスタンスに割り当てることができます。詳細については、インスタンス作成時の内部 IP アドレスの指定のドキュメントをご覧ください。
  • インスタンスとの通信にインスタンス名を使用することもできます。インスタンスの内部 IP が変わってもインスタンス名は変更されないため、パケットをインスタンス名に送信するようアプリケーションを設定できます。インスタンス名を使用したほうが、ルートを使用して静的な内部 IP アドレスを設定するよりも確実な動作を実現できます。

ルートを使用した静的なターゲット内部 IP アドレスの設定

このセクションでは、IP(ターゲット IP)に送信されたパケットを受信するようにインスタンスとネットワークを設定する作業だけを行います。この IP アドレス(送信元 IP)を持つパケットを送信するようにインスタンスを設定する方法は、静的な送信元 IP アドレスの設定をご覧ください。

Debian 8


  1. プロジェクト内のどのネットワークにも属していない内部 IP アドレスを選択します。

    10.x.x.x または 192.168.x.x のようなプライベート範囲のアドレスを使用します。ただし、プロジェクトで使用されている範囲のアドレスは使用しないでください。この例では、10.1.1.1 を使用します。

  2. 新しい仮想マシン インスタンスを作成し、IP 転送を有効にします。

    デフォルトでは、宛先 IP アドレスがパケットを受信するインスタンスの IP アドレスと異なるパケットは伝送されません。この宛先 IP チェックを無効にするには、インスタンスの IP 転送を有効にします。

    gcloud compute instances create my-configurable-instance --can-ip-forward
    
  3. 静的なネットワーク ルートを作成し、10.1.1.1 を宛先とするパケットをインスタンスに転送します。

    静的ルートのターゲットは、プロジェクト内のどのネットワークにも属していない IP アドレスでなければなりません。

    gcloud compute routes create ip-10-1-1-1 \
        --next-hop-instance my-configurable-instance \
        --next-hop-instance-zone us-central1-f \
        --destination-range 10.1.1.1/32
    
  4. この IP に対するトラフィックを許可するファイアウォール ルールを作成します。

    ここでは、10.0.0.0/8 の IP アドレス範囲を通過するすべてのトラフィックを許可するファイアウォール ルールを作成します。必要に応じて、各自の状況に合わせた IP 範囲の追加やアクセスの制限を行うことができます。

    gcloud compute firewall-rules create allow-internal \
      --allow icmp,udp,tcp --source-range 10.0.0.0/8
    
  5. 新しい仮想インターフェースをインスタンスに追加します。

    1. インスタンスに ssh でログインします。

      gcloud compute ssh my-configurable-instance
      
    2. /etc/network/interfaces ファイルに次の行を追加します。

      # Change to root first
      user@my-configurable-instance:~$ sudo su -
      

      # Append the following lines
      root@my-configurable-instance:~# cat <<EOF >>/etc/network/interfaces
      auto eth0:0
      iface eth0:0 inet static
      address 10.1.1.1
      netmask 255.255.255.255
      EOF
      

    3. インスタンスを再起動します。

      root@my-configurable-instance:~# sudo reboot
      

  6. インスタンスの内部から 10.1.1.1 に ping コマンドを実行して、仮想マシン インスタンスのインターフェースが動作中であることを確認します。

    user@my-configurable-instance:~$ ping 10.1.1.1
    

    プロジェクト内の別のインスタンスから、インターフェースに ping コマンドを実行することもできます。

Ubuntu 14.04


  1. プロジェクト内のどのネットワークにも属していない内部 IP アドレスを選択します。

    10.x.x.x または 192.168.x.x のようなプライベート範囲のアドレスを使用します。ただし、プロジェクトで使用されている範囲のアドレスは使用しないでください。この例では、10.1.1.1 を使用します。

  2. 新しい仮想マシン インスタンスを作成し、IP 転送を有効にします。

    デフォルトでは、宛先 IP アドレスがパケットを受信するインスタンスの IP アドレスと異なるパケットは伝送されません。この宛先 IP チェックを無効にするには、インスタンスの IP 転送を有効にします。

    gcloud compute instances create my-configurable-instance --can-ip-forward
    
  3. 静的なネットワーク ルートを作成し、10.1.1.1 を宛先とするパケットをインスタンスに転送します。

    静的ルートのターゲットは、プロジェクト内のどのネットワークにも属していない IP アドレスでなければなりません。

    gcloud compute routes create ip-10-1-1-1 \
        --next-hop-instance my-configurable-instance \
        --next-hop-instance-zone us-central1-f \
        --destination-range 10.1.1.1/32
    
  4. この IP に対するトラフィックを許可するファイアウォール ルールを作成します。

    ここでは、10.0.0.0/8 の IP アドレス範囲を通過するすべてのトラフィックを許可するファイアウォール ルールを作成します。必要に応じて、各自の状況に合わせた IP 範囲の追加やアクセスの制限を行うことができます。

    gcloud compute firewall-rules create allow-internal \
        --allow icmp,udp,tcp --source-range 10.0.0.0/8
    
  5. 新しい仮想インターフェースをインスタンスに追加します。

    1. インスタンスに ssh でログインします。

      gcloud compute ssh my-configurable-instance
      
    2. /etc/network/interfaces ファイルに次の行を追加します。

      # Change to root first
      user@my-configurable-instance:~$ sudo su -
      

      # Append the following lines
      root@my-configurable-instance:~# cat <<EOF >>/etc/network/interfaces
      auto eth0:0
      iface eth0:0 inet static
      address 10.1.1.1
      netmask 255.255.255.255
      EOF
      

    3. インスタンスを再起動します。

      root@my-configurable-instance:~# sudo reboot
      

  6. インスタンスの内部から 10.1.1.1 に ping コマンドを実行して、仮想マシン インスタンスのインターフェースが動作中であることを確認します。

    user@my-configurable-instance:~$ ping 10.1.1.1
    

    プロジェクト内の別のインスタンスから、インターフェースに ping コマンドを実行することもできます。

CentOS 6


  1. プロジェクト内のどのネットワークにも属していない内部 IP アドレスを選択します。

    10.x.x.x または 192.168.x.x のようなプライベート範囲のアドレスを使用します。ただし、プロジェクトで使用されている範囲のアドレスは使用しないでください。この例では、10.1.1.1 を使用します。

  2. 新しい仮想マシン インスタンスを作成し、IP 転送を有効にします。

    デフォルトでは、宛先 IP アドレスがパケットを受信するインスタンスの IP アドレスと異なるパケットは伝送されません。この宛先 IP チェックを無効にするには、インスタンスの IP 転送を有効にします。

    gcloud compute instances create my-configurable-instance --can-ip-forward
    
  3. 静的なネットワーク ルートを作成し、10.1.1.1 を宛先とするパケットをインスタンスに転送します。

    静的ルートのターゲットは、プロジェクト内のどのネットワークにも属していない IP アドレスでなければなりません。

    gcloud compute routes create ip-10-1-1-1 \
        --next-hop-instance my-configurable-instance \
        --next-hop-instance-zone us-central1-f \
        --destination-range 10.1.1.1/32
    
  4. この IP に対するトラフィックを許可するファイアウォール ルールを作成します。

    ここでは、10.0.0.0/8 の IP アドレス範囲を通過するすべてのトラフィックを許可するファイアウォール ルールを作成します。必要に応じて、各自の状況に合わせた IP 範囲の追加やアクセスの制限を行うことができます。

    gcloud compute firewall-rules create allow-internal \
      --allow icmp,udp,tcp --source-range 10.0.0.0/8
    
  5. 新しい仮想インターフェースをインスタンスに追加します。

    1. インスタンスに ssh でログインします。

      gcloud compute ssh my-configurable-instance
      
    2. /etc/sysconfig/network-scripts/ifcfg-eth0:0 という名前を付けた新しいファイルに次の行を追加します。

      # Change to root first
      user@my-configurable-instance:~$ sudo su -
      

      # Add the following lines
      root@my-configurable-instance:~# cat <<EOF >>/etc/sysconfig/network-scripts/ifcfg-eth0:0
      DEVICE="eth0:0"
      BOOTPROTO="static"
      IPADDR=10.1.1.1
      NETMASK=255.255.255.255
      ONBOOT="yes"
      EOF
      

    3. 新しいインターフェースを起動します。

      root@my-configurable-instance:~# ifup eth0:0
      

  6. インスタンスの内部から 10.1.1.1 に ping コマンドを実行して、仮想マシン インスタンスのインターフェースが動作中であることを確認します。

    user@my-configurable-instance:~$ ping 10.1.1.1
    

    プロジェクト内の別のインスタンスから、インターフェースに ping コマンドを実行することもできます。

静的な送信元 IP アドレスの設定

仮想マシンに対して静的なターゲット内部 IP を設定するだけでなく、他の仮想マシンと通信するときに送信元 IP として静的な内部 IP を使用するようにインスタンスを設定することもできます。

このセクションでは、送信元アドレス(送信元 IP)として IP を使用するようにインスタンスを設定する作業だけを行います。ネットワークが、この宛先 IP を持つパケットをインスタンスにルーティングするように設定するには、静的なターゲット IP アドレスの設定もご覧ください。

Linux インスタンス上で静的な内部 IP として送信元 IP を設定するには:

# Change to root first
user@my-configurable-instance:~$ sudo su -
# Get the next hop route of your packets
root@my-configurable-instance:~# route -n
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.240.0.1      0.0.0.0         255.255.255.255 UH    0      0        0 eth0
# Add a route, where 10.0.0.0/16 is the address range the route applies;
# replace this range with an address range of your choice.
# This means that all instance in this range will see the source IP of your
# instance as 10.1.1.1
root@my-configurable-instance:~# ip route add 10.0.0.0/16 dev eth0:0 via 10.240.0.1 src 10.1.1.1

これをテストするには、同じネットワーク上のアドレス範囲 10.0.0.0/16 の IP アドレスに対し、インスタンスを使用して ping コマンドを実行してみます。たとえば次の例は、静的な内部 IP 10.1.1.110.0.0.2 を持つインスタンスから実行されたリクエストの tcpdump を示したものです。

root@my-configurable-instance-2:~# tcpdump -npi eth0 -vv icmp or arp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:59:05.374093 IP (tos 0x0, ttl 64, id 59993, offset 0, flags [DF], proto ICMP (1), length 84)
    10.1.1.1 > 10.0.0.2: ICMP echo request, id 4319, seq 1, length 64
17:59:05.374126 IP (tos 0x0, ttl 64, id 55671, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.0.2 > 10.1.1.1: ICMP echo reply, id 4319, seq 1, length 64
17:59:06.375432 IP (tos 0x0, ttl 64, id 60166, offset 0, flags [DF], proto ICMP (1), length 84)
    10.1.1.1 > 10.0.0.2: ICMP echo request, id 4319, seq 2, length 64

ネットワーク プロキシの設定

ネットワークを設計する際、ネットワーク内の 1 つのインスタンスだけが外部にアクセスし、その他すべてのインスタンスはそのインスタンスをプロキシ サーバーとして外部にアクセスするように構成できます。このような設計は、ネットワークに出入りするアクセスの制御や、複数の外部 IP アドレスにかかるコストの低減に役立ちます。

この例は、特に Debian イメージを使用する Compute Engine インスタンスでネットワーク プロキシを設定する方法について説明したものです。ここでは、Squid プロキシ サーバーとしてゲートウェイ インスタンスを使用します。これはプロキシ サーバーを設定する唯一の方法です。

Squid プロキシ サーバーを設定するには:

  1. 外部(静的またはエフェメラル)IP アドレスを持つインスタンスを 1 つ設定します。この例では、インスタンスに gateway-instance という名前を付けます。
  2. gcloud compute instances create ... --no-address を指定して、外部 IP アドレスを持たない 1 つまたは複数のインスタンスを設定します。この例では、インスタンス hidden-instance を呼び出します。
  3. あるインスタンスから別のインスタンスに接続する方法を理解します。これは、読み取り専用のインスタンスには直接接続できないためです。
  4. 次のように、ポート 3128 での tcp トラフィックを許可するファイアウォールを追加します。

    gcloud compute firewall-rules create FIREWALL_RULE --network NETWORK --allow tcp:3128
    
  5. gateway-instanceSquid をインストールし、共有内部ネットワーク(RFC1918RFC4193、および RFC4291 の各 IP 空間)上の任意のマシンからのアクセスを許可するように設定します。これは、gateway-instancehidden-instance がどちらも同じネットワークに接続されていて、相互に接続できることを前提としています。

    user@gateway-instance:~$ sudo apt-get install squid3
    

    ローカル ネットワーク上の任意のマシンが Squid3 サーバーを使用できるようにします。次の sed コマンドによって、ローカルのネットワークとマシンの Squid 設定ファイルに記述されている acl localnet src エントリのコメントが解除されて有効化されます。

    user@gateway-instance:~$ sudo sed -i 's:#\(http_access allow localnet\):\1:' /etc/squid3/squid.conf
    

    user@gateway-instance:~$ sudo sed -i 's:#\(http_access deny to_localhost\):\1:' /etc/squid3/squid.conf
    

    user@gateway-instance:~$ sudo sed -i 's:#\(acl localnet src 10.0.0.0/8.*\):\1:' /etc/squid3/squid.conf
    

    user@gateway-instance:~$ sudo sed -i 's:#\(acl localnet src 172.16.0.0/12.*\):\1:' /etc/squid3/squid.conf
    

    user@gateway-instance:~$ sudo sed -i 's:#\(acl localnet src 192.168.0.0/16.*\):\1:' /etc/squid3/squid.conf
    

    user@gateway-instance:~$ sudo sed -i 's:#\(acl localnet src fc00\:\:/7.*\):\1:' /etc/squid3/squid.conf
    

    user@gateway-instance:~$ sudo sed -i 's:#\(acl localnet src fe80\:\:/10.*\):\1:' /etc/squid3/squid.conf
    

    # Prevent proxy access to metadata server
    user@gateway-instance:~$ sudo cat <<EOF >>/etc/squid3/squid.conf
    acl to_metadata dst 169.254.169.254
    http_access deny to_metadata
    EOF
    

    # Start Squid
    user@gateway:~$ sudo service squid3 start
    

  6. gateway-instance をプロキシとして使用するように hidden-instance を設定します。ssh を使用して hidden-instance に接続し、次に示すように、プロキシ URL アドレスがポート 3128(デフォルトの Squid 設定)上の gateway-instance を指すように定義します。

    user@gateway-instance:~$ ssh hidden-instance
    

    user@hidden-instance:~$ sudo -s
    

    root@hidden-instance:~# echo "export http_proxy=\"http://gateway-instance.$(dnsdomainname):3128\"" >> /etc/profile.d/proxy.sh
    

    root@hidden-instance:~# echo "export https_proxy=\"http://gateway-instance.$(dnsdomainname):3128\"" >> /etc/profile.d/proxy.sh
    

    root@hidden-instance:~# echo "export ftp_proxy=\"http://gateway-instance.$(dnsdomainname):3128\"" >> /etc/profile.d/proxy.sh
    

    root@hidden-instance:~# echo "export no_proxy=169.254.169.254,metadata,metadata.google.internal" >> /etc/profile.d/proxy.sh
    

    このような環境変数を通すように sudoer を更新します。

    root@hidden-instance:~# cp /etc/sudoers /tmp/sudoers.new
    

    root@hidden-instance:~# chmod 640 /tmp/sudoers.new
    

    root@hidden-instance:~# echo "Defaults env_keep += \"ftp_proxy http_proxy https_proxy no_proxy"\" >>/tmp/sudoers.new
    

    root@hidden-instance:~# chmod 440 /tmp/sudoers.new
    

    root@hidden-instance:~# visudo -c -f /tmp/sudoers.new && cp /tmp/sudoers.new /etc/sudoers
    

  7. sudo を終了し、変数をロードして、hidden-instanceapt-get を実行します。この操作はゲートウェイをプロキシとして使用することで正常に動作します。ゲートウェイがプロキシとして機能していない場合、hidden-instance はインターネットに直接接続していないため、apt-get は動作しません。

    root@hidden-instance:~# exit
    

    user@hidden-instance:~$ source ~/.profile
    

    user@hidden-instance:~$ sudo apt-get update
    

外部 HTTP 接続の設定

デフォルトのファイアウォール ルールでは、インスタンスへの HTTP または HTTPS 接続は許可されていません。ただし、そのような接続を許可するルールを追加するのは簡単です。インスタンスが外部 IP アドレスを持たない場合は、ネットワーク外部からのトラフィックを受信できない点に注意してください。

HTTP または HTTPS 接続を許可するファイアウォール ルールは、gcloud compute または Google Cloud Platform Console を使用して追加できます。また、API を使用してファイアウォール ルールを追加することもできます。

コンソール

Cloud Platform Console を使用すると、ネットワーク上の全インスタンスに適用される全体的なファイアウォール ルールを作成することも、HTTP 接続や HTTPS 接続に対する個別のインスタンスのアクセスを許可することもできます。どちらの場合もインスタンスの作成時に該当するオプションを選択します。後者のオプションのほうが個別のインスタンスに対して細かく制御できるため、そちらを先に説明します。

  1. Cloud Platform Console で、[VM インスタンス] ページに移動します。

    [VM インスタンス] ページに移動する

  2. [インスタンスを作成] ボタンをクリックします。
  3. [ファイアウォール] で、[HTTP トラフィックを許可する] と [HTTPS トラフィックを許可する] を選択します。
  4. [作成] ボタンをクリックし、インスタンスを作成します。

これらのチェックボックスを選択することで、http-server タグまたは https-server タグを持つすべてのインスタンスに適用される default-http ルールまたは default-https ルールが自動的に作成されます。新しいインスタンスには、チェックボックスの選択に応じて、適切なタグ付けが行われます。

default-http および default-https のファイアウォール ルールが既にある場合は、インスタンスの詳細ページで [HTTP トラフィックを許可する] または [HTTPS トラフィックを許可する] オプションを有効にすることで、そのファイアウォール ルールを既存のインスタンスに適用できます。

  1. [VM インスタンス] ページに移動します。
  2. 目的のインスタンスの名前をクリックします。
  3. ページの上部にある [編集] ボタンをクリックします。
  4. [ファイアウォール] セクションまでスクロールします。
  5. 目的のネットワークについて、[HTTP トラフィックを許可する] または [HTTPS トラフィックを許可する] オプションをオンにします。
  6. [保存] をクリックします。

同様に、いずれかまたは両方のチェックボックスをオフにすることで、インスタンスの外部 HTTP または HTTPS アクセスを無効にすることもできます。

すべてのインスタンスに適用される全体的なファイアウォール ルールを作成するのではなく、HTTP トラフィックと HTTPS トラフィックに対して特定のインスタンスがタグ付けされるようにすることで、プロジェクト内のすべての仮想マシンへの外部トラフィックが許可されるというセキュリティ上の問題が発生する可能性が低減されます。However, if you would like to create a firewall rule that allows HTTP or HTTPS traffic to all virtual machine instances, you can create your own firewall rule:

  1. [ネットワーク] ページに移動します。
  2. ファイアウォール ルールを適用するネットワークを選択します。
  3. [ファイアウォール ルール] の横にある [新規作成] をクリックします。
  4. ファイアウォール ルールに名前を付け、[プロトコルとポート] ボックスに tcp:80 を追加します。HTTPS トラフィックの場合には、tcp:443 を追加します。
  5. [作成] をクリックします。
gcloud

プロジェクト内のすべての仮想マシンに対する HTTP トラフィックと HTTPS トラフィックを許可する場合は、次のコマンドを実行して、任意の場所からそのネットワークに接続されている任意のインスタンスに対する受信 HTTP リクエストと HTTPS リクエストを許可するファイアウォールを作成します。

gcloud compute firewall-rules create FIREWALL_RULE --allow tcp:80,tcp:443

**例**

gcloud compute firewall-rules create sample-http \
 --description "Incoming http and https allowed." \
 --allow tcp:80,tcp:443
gcloud compute firewall-rules describe sample-http
allowed:
- IPProtocol: tcp
  ports:
  - '80'
  - '443'
creationTimestamp: '2014-06-13T13:27:12.206-07:00'
id: '5057780722612413546'
kind: compute#firewall
name: sample-http
network: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/default
selfLink: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls/samplehttp
sourceRanges:
- 0.0.0.0/0

NAT ゲートウェイの設定

この例では、レガシー ネットワークでゲートウェイを設定する方法を示します。サブネットワークを使用している場合は、示されているネットワーク範囲を調整してください。

Routes コレクションに変更を加えることで、さらに複雑なネットワーキング シナリオを作成できます。このセクションでは、内部専用の仮想マシン インスタンスからインターネットにトラフィックをルーティングできるネットワーク アドレス変換(NAT)ゲートウェイ インスタンスを設定する方法について説明します。これにより、1 つの外部 IP アドレスを使用して複数の仮想マシン インスタンスからトラフィックを送信できるようになります。ただし、インターネットには単一の仮想マシンしか公開されません。

  1. まず、このシナリオの仮想マシン インスタンスをホストする GCP ネットワークを作成します。この例では、使用するレガシー ネットワークの範囲は 10.240.0.0/16 で、ゲートウェイは 10.240.0.1 です。ただし、独自の IPv4 範囲とゲートウェイ アドレスを選択してもかまいません。また、サブネット ネットワークを作成することもできます。

    gcloud compute networks create gce-network \
        --mode legacy \
        --range 10.240.0.0/16
    
  2. 先ほど作成した新しいネットワークでの ssh 接続を許可するファイアウォール ルールを作成します。

    gcloud compute firewall-rules create gce-network-allow-ssh --allow tcp:22 --network gce-network
    gcloud compute firewall-rules create gce-network-allow-internal --allow tcp:1-65535,udp:1-65535,icmp \
        --source-ranges 10.240.0.0/16 --network gce-network
    
  3. gce-network または default ネットワークで NAT ゲートウェイとして機能する仮想マシンを作成します。

    gcloud compute instances create nat-gateway --network gce-network --can-ip-forward \
        --zone us-central1-a \
        --image-family debian-8 \
        --image-project debian-cloud \
        --tags nat
    
  4. 外部 IP アドレスを持たず、ゲートウェイ インスタンスを使用する任意の仮想マシン インスタンスに no-ipタグ付けするか、外部 IP アドレスを持たない新しい仮想マシンを作成して、そのインスタンスに no-ip タグを付けます。

    • 既存のインスタンスにタグを追加します。

      gcloud compute instances add-tags existing-instance --tags no-ip
      
    • または、外部 IP アドレスを持たない新しい仮想マシンを作成します。

      gcloud compute instances create example-instance --network gce-network --no-address \
          --zone us-central1-a \
          --image-family debian-8 \
          --image-project debian-cloud \
          --tags no-ip
      
  5. ゲートウェイ インスタンスを経由し、インターネットを宛先とするトラフィックを送信するルートを作成します。

    gcloud compute routes create no-ip-internet-route --network gce-network \
        --destination-range 0.0.0.0/0 \
        --next-hop-instance nat-gateway \
        --next-hop-instance-zone us-central1-a \
        --tags no-ip --priority 800
    

    他に競合するルートが存在する場合は、このルートが優先されるように優先度を設定します。デフォルトの優先度は 1000 なので、1000 よりも小さい値を指定します。

  6. 次に、ゲートウェイ インスタンスにログインし、内部トラフィックからインターネットへの NAT 処理を行う iptables を設定します。

    gcloud compute ssh nat-gateway --zone us-central1-a
    

    インスタンスで iptables を次のように設定します。

    $ sudo sysctl -w net.ipv4.ip_forward=1
    

    $ sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
    

    最初の sudo コマンドでは、IP 転送を許可するカーネルを指定します。2 番目の sudo コマンドでは、内部インスタンスから受信したパケットを、NAT ゲートウェイ インスタンスから送信されたパケットであるかのようにマスカレードします。

VPN ゲートウェイの設定

このセクションでは、いずれかのインスタンスに strongSwan VPN ソフトウェアをインストールする方法を説明します。この説明はレガシー ネットワークを前提としています。Compute Engine VPN については、Cloud VPN をご覧ください。

このセクションでは、Compute Engine の VPN ゲートウェイ インスタンスを非 Cloud ネットワークに配置された Debian ベースの VPN ゲートウェイに接続するというサンプルのシナリオを使用して説明します。このシナリオは単なる例であるため、実際のネットワークには適していない場合もあります。詳細については、ネットワーク管理者にお問い合わせください。

  1. まず、VPN 経由で接続する Compute Engine ネットワークを作成します。

    gcloud compute networks create gce-network --range 10.120.0.0/16
    
  2. gce-network で VPN ゲートウェイ仮想マシンを作成します。

    gcloud compute instances create vpn-gateway --can-ip-forward \
        --network gce-network \
        --zone us-central1-a \
        --image debian-7 \
        --tags vpn
    
  3. 次のコマンドを実行して、新しく作成した仮想マシンの内部 IP アドレスを書き留めておきます。

    gcloud compute instances describe --zone us-central1-a vpn-gateway
    

    networkIPnatIP ではありません)の横のアドレスを書き留めます。このアドレスは 10.120.x.x で始まります。

  4. ローカル ネットワークと通信する「普通の」非 VPN ゲートウェイ仮想マシンを作成します。

    gcloud compute instances create povm-1 --network gce-network --image debian-7 --tags vpn --zone us-central1-a
    
  5. ローカル ネットワークを宛先とする場合は、vpn-gateway を経由してトラフィックをルーティングするルートを gce-network に作成します。

    gcloud compute routes create gce-network-via-gateway --destination-range LOCAL_NETWORK_ADDRESS_SPACE \
        --next-hop-address VPN_GATEWAY_NETWORK_IP \
        --network gce-network \
        --tags vpn
    

    VPN_GATEWAY_NETWORK_IP の値は、ステップ 3 で書き留めた networkIp のアドレスでなければなりません。

  6. 次の Compute Engine ファイアウォール ルールを Compute Engine ネットワークに追加して、受信トラフィックを受け入れます。

    gcloud compute firewall-rules create ssh --source-ranges 0.0.0.0/0 --allow tcp:22 --network gce-network
    
    gcloud compute firewall-rules create  allow-internal --source-ranges 10.120.0.0/16 --allow tcp:1-65535,udp:1-65535,icmp \
        --network gce-network --target-tags vpn
    
    gcloud compute firewall-rules create allow-ipsec-nat --source-ranges IP_LOCAL_VPN_GATEWAY/32 \
        --allow udp:4500,udp:500 --network gce-network --target-tags vpn
    
    gcloud compute firewall-rules create allow-all-peer --source-ranges LOCAL_NETWORK_ADDRESS_SPACE \
        --allow tcp:1-65535,udp:1-65535,icmp --network gce-network --target-tags vpn
    

    場合によっては、Compute Engine ネットワークからの受信トラフィックを受け入れるために、ローカル ネットワークでファイアウォール設定を調整する必要があります。このプロセスはネットワークによって異なります。

  7. VPN ソフトウェアをインストールし、ゲートウェイのゲスト OS を設定します。VPN ゲートウェイ マシンの外部 IP アドレスが必要になります。以下のコマンドを実行します。

    gcloud compute instances describe vpn-gateway
    

    外部 IP アドレスをコピーし、仮想マシン ゲートウェイ インスタンスに ipsec.conf という名前のファイルを作成します。このファイルには次の内容を含めます。

    conn myconn
      authby=psk
      auto=start
      dpdaction=hold
      esp=aes128-sha1!
      forceencaps=yes
      ike=aes128-sha1-modp2048!
      keyexchange=ikev2
      mobike=no
      type=tunnel
      left=%any
      leftid=<vpn-vm-gateway-external-address>
      leftsubnet=<internal-ip-subnet>
      leftauth=psk
      leftikeport=4500
      right=<public-ip-of-your-local-vpn-gateway-machine>
      rightsubnet=<your-local-network-address-space>
      rightauth=psk
      rightikeport=4500
    

    <internal-ip-subnet> の値は、手順 3 でメモした internal-ip の値に応じて 10.120.0.0/16 または 10.240.0.0/16 のいずれかにする必要があります。

    次に、以下のコマンドを実行します。<secret-key> の部分は使用する秘密鍵に置き換えてください。

    $ sudo apt-get update
    

    $ sudo apt-get install strongswan -y
    

    $ echo "%any : PSK \"<secret-key>\"" | sudo tee /etc/ipsec.secrets > /dev/null
    

    $ sudo sysctl -w net.ipv4.ip_forward=1
    

    $ sudo cp ipsec.conf /etc
    

    $ sudo ipsec restart
    

    $ sudo ipsec up myconn
    

    ローカルのゲートウェイ マシンが Debian ベースのオペレーティング システムを実行していることを前提とすると、同じステップでローカルマシンに VPN をインストールできます。ローカルのゲートウェイ マシンで ipsec.conf ファイルのコピーを作成し、次のように変更を加えます。

    conn myconn
      authby=psk
      auto=start
      dpdaction=hold
      esp=aes128-sha1!
      forceencaps=yes
      ike=aes128-sha1-modp2048!
      keyexchange=ikev2
      mobike=no
      type=tunnel
      left=%any
      leftid=<public-ip-of-local-VPN-gateway-machine>
      leftsubnet=<your-local-network-address-space>
      leftauth=psk
      leftikeport=4500
      rightid=<vpn-vm-gateway-external-address>
      rightsubnet=10.120.0.0/16
      rightauth=psk
      rightikeport=4500
    

    ローカルの VPN ゲートウェイ マシンで上記の説明と同じコマンドを実行します。

  8. 次のコマンドを試してみます。

    gcloud compute ssh povm-1 --command 'ping -c 3 LOCAL_NETWORK_EXTERNAL_ADDRESS'
    

トラブルシューティング

上記の手順で VPN を設定しても問題が発生する場合は、次のヒントを参考に、設定のトラブルシューティングを行ってください。

  1. 2 か所の VPN エンドポイントが通信できているかどうかを確認します。

    netcat を使用して VPN と同様のトラフィック(UDP、ポート 4500)を送信します。ローカルの VPN エンドポイントで次のコマンドを実行します。

    $ echo | nc -u  4500
    

    受信側で tcpdump を実行し、Compute Engine インスタンスがポート 4500 でパケットを受信できていることを確認します。

    $ tcpdump -nn -n host  -i any
    

  2. ipsec.conf ファイルに次の行を追加し、取得されるログの冗長性を高めます。

    config setup
      charondebug="ike 3, mgr 3, chd 3, net 3"
    
    conn myconn
      authby=psk
      auto=start
      ...
    

    次に、接続を再試行します。接続は引き続き失敗しますが、ログでエラーを確認できます。ログファイルは Compute Engine インスタンスの /var/log/charon.log にあります。

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

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

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

Compute Engine ドキュメント