複数のネットワーク インターフェース

このページでは、仮想マシン（VM）インスタンス内の複数のネットワーク インターフェースの概要について、動作方法やサンプル構成を含めて説明します。複数のインターフェースを使用する構成の作成については、複数のネットワーク インターフェースを持つ VM を作成するをご覧ください。

Google Cloud Virtual Private Cloud（VPC）ネットワークは、デフォルトでは分離されたプライベート ネットワーク ドメインです。ネットワークはグローバル スコープを持ち、リージョン サブネットがあります。VPC ネットワーク内の VM インスタンスは、ファイアウォール ルールで許可される限り、内部 IP アドレスを使って相互に通信できます。ただし、内部 IP アドレスによるネットワーク間通信は、VPC ネットワーク ピアリングや Cloud VPN などのメカニズムを設定しない限り許可されません。

VPC ネットワーク内のすべてのインスタンスには、デフォルトのネットワーク インターフェースがあります。ネットワーク インターフェースを構成する際には、インターフェースを接続する VPC ネットワークと、その VPC ネットワーク内のサブネットを選択します。VM に接続するネットワーク インターフェースを追加できますが、各インターフェースはそれぞれ異なる VPC ネットワークに接続する必要があります。複数のネットワーク インターフェースを使用すると、1 つのインスタンスが複数の VPC ネットワークに直接接続する構成を作成できます。

インスタンスのタイプに応じて、各インスタンスに最大 8 個のインターフェースを割り当てることができます。詳細については、ネットワーク インターフェースの最大数をご覧ください。

各インターフェースには、次の IP アドレスを構成できます。

  • 内部 IPv4 アドレス（必須）
  • 外部 IPv4 アドレス

  • IPv6 アドレス（内部または外部のどちらか一方）

    IPv6 アドレスを構成するには、IPv6 範囲が構成されているサブネットにインターフェースを接続する必要があります。

ロード バランシング、侵入検知 / 防止（IDS / IPS）、ウェブ アプリケーション ファイアウォール（WAF）、ネットワーク間の WAN 最適化を行うネットワーク アプライアンスとしてインスタンスを構成する場合、複数のインターフェースが必要になることがあります。複数のネットワーク インターフェースは、1 つのインスタンスで実行されているアプリケーションのトラフィックを分離する必要がある場合（データプレーン トラフィックと管理プレーン トラフィックを分離する場合など）にも役立ちます。

VM 上の各インターフェースは、接続されたネットワークの MTU の影響を受けます。インターフェース MTU の詳細については、最大伝送単位をご覧ください。

ユースケース

複数のネットワーク インターフェースは、1 つのインスタンスから複数の VPC ネットワークへのアクセスが必要で、ネットワーク同士を直接接続したくない場合に使用します。

  • ネットワークとセキュリティの機能: 複数のネットワーク インターフェースによって、ロードバランサ、ネットワーク アドレス変換（NAT）サーバー、複数のネットワーク インターフェースで構成されているプロキシ サーバーなど、仮想化されたネットワーク アプライアンス機能が有効になります。詳細については、例 1: ネットワーキングとセキュリティの仮想アプライアンスをご覧ください。

  • 境界分離（DMZ の分離ともいいます）: 階層化されたネットワーキング アーキテクチャにおける重要なベスト プラクティスは、一般公開されるサービスを内部ネットワークとそのサービスから分離することです。複数のネットワーク インターフェースを使用して、インスタンスに別個のネットワーク インターフェース（パブリック トラフィックを受け入れるインターフェースと、アクセスがより厳しく制御されるバックエンドのプライベート トラフィックを処理するインターフェース）がある構成を作成します。

    インターネットから到達できるリソースは、内部ネットワークとそのサービスから分離する必要があります。これにより、セキュリティ侵害の範囲と損害が大幅に限定されます。たとえば、アプリケーション サーバーが存在する中間層ネットワークに接続する個々のウェブサーバーに 2 つ目のネットワーク インターフェースを配置できます。データベース サーバーが存在するバックエンド ネットワークにアプリケーション サーバーをデュアルホーム接続することもできます。個々のデュアルホーム接続インスタンスは、フロントエンドのリクエストを受信して処理し、バックエンドへの接続を開始した後、バックエンド ネットワーク上のサーバーにリクエストを送信します。

    パブリック インターフェースとプライベート インターフェースを別々に構成することで、各インターフェースに異なるファイアウォール ルールとアクセス制御を適用し、パブリック ドメインからプライベート ドメインへの通信にセキュリティ機能を適用できます。詳細については、例 2: 共有 VPC ネットワークのシナリオにおけるサードパーティ アプライアンスの使用をご覧ください。

構成例

このセクションでは、複数のネットワーク インターフェースの使用方法を示す一般的な例をいくつか紹介します。

例 1: ネットワーキングとセキュリティの仮想アプライアンス

ネットワーキングとセキュリティの仮想アプライアンス（ウェブ アプリケーション ファイアウォール（WAF）、セキュリティ アプリケーション レベル ファイアウォール、WAN アクセラレータなど）は、通常、複数の仮想インターフェースを使って構成されます。複数のインターフェースは、それぞれ固有の内部 IP アドレスと必要に応じて固有の外部 IP アドレスを使って構成されます。

図 1 は、インターネットから VPC ネットワークへのトラフィックを制御するアプリケーション レベルのファイアウォールの構成例を示しています。アプリケーション レベルのファイアウォールは Compute Engine VM に実装されます。

この例では、アプライアンス VM のデフォルトのルートが nic1 を使用するように構成されています。

図 1.VM アプライアンスを使用するインスタンスに 3 つのネットワーク インターフェースがあります。各インターフェースは、異なる VPC ネットワーク内のサブネットに接続されています（クリックして拡大）。

例 1 のインスタンスのプロビジョニングと構成

以下では、subnet0、subnet1、subnet2 がすでに存在し、範囲の重複がないと仮定します。

この例の VM とネットワーク インターフェースを作成するには、次のコマンドを使用します。

gcloud compute instances create vm-appliance \
    --network-interface subnet=subnet0,no-address \
    --network-interface subnet=subnet1 \
    --network-interface subnet=subnet2,no-address \
    --machine-type n1-standard-4

このコマンドを実行すると、3 つのネットワーク インターフェースを持つインスタンスが作成されます。

  • nic0 は subnet0 に接続され、外部 IP アドレスを持ちません。
  • nic1 は subnet1 に接続され、エフェメラル外部 IP アドレスを持っています。
  • nic2 は subnet2 に接続され、外部 IP アドレスを持ちません。

例 2: 共有 VPC ネットワークのシナリオにおけるサードパーティ アプライアンスの使用

この設定は、異なるプロジェクトでホストされるワークロードやアプリケーションのために一元化された単一系列のサードパーティ製アプライアンスを共有する際に役立ちます。図 2 では、異なるサービス プロジェクトにホストされている 4 つの異なるアプリケーション（App1、App2、App3、App4）があります。すべてのインターネット上り（内向き）でこれらを保護し、共有 VPC ホスト プロジェクトで一元管理されているサードパーティ製アプライアンスを使って下り（外向き）トラフィックを検査およびフィルタリングする必要があります。

図 2.共有 VPC ホスト プロジェクトのインスタンスが VM アプライアンスをホストします。インスタンスには、4 つのサービス プロジェクト対するネットワーク インターフェースと、ネットワーク境界 VPC ネットワーク用のインターフェースがあります（クリックして拡大）。

例 2 の VM およびネットワーク インターフェースのプロビジョニングと構成

この例の VM とネットワーク インターフェースを作成するには、次のコマンドを使用します。

gcloud compute instances create VM-appliance \
    --network-interface subnet=subnet-perimeter,address='reserved-address' \
    --network-interface subnet=subnet-1,no-address \
    --network-interface subnet=subnet-2,no-address \
    --network-interface subnet=subnet-3,no-address \
    --network-interface subnet=subnet-4,no-address \
    --machine-type=n1-standard-4

これを実行すると、5 つのネットワーク インターフェースを持つインスタンスが作成されます。

  • nic0 は、network-perimeter の一部で、静的アドレス reserved-address を持つ subnet-perimeter に接続されます。
  • nic1 は、network-1 の一部で、外部 IP アドレスのない subnet-1 に接続されます。
  • nic2 は、network-2 の一部で、外部 IP アドレスのない subnet-2 に接続されます。
  • nic3 は、network-3 の一部で、外部 IP アドレスのない subnet-3 に接続されます。
  • nic4 は、network-4 の一部で、外部 IP アドレスのない subnet-4 に接続されます。

その他のオペレーションの詳細

共有 VPC 環境における複数のネットワーク インターフェース

共有 VPC を使用すると、Google Cloud 組織のプロジェクト間で VPC ネットワークを共有できます。

共有 VPC でインスタンスを作成し、一元化された共有 VPC ホスト プロジェクトでホストされている共有 VPC ネットワークに関連付けることができます。共有 VPC ネットワークの構成については、共有 VPC のプロビジョニングをご覧ください。

共有 VPC ネットワークに関連付けられたインターフェースを持つインスタンスを作成するには、共有 VPC ホスト プロジェクトに Compute ネットワーク ユーザーのロール（roles/compute.networkUser）が割り当てられている必要があります。

複数のネットワーク インターフェースがある場合の DNS の解決

インスタンスのホスト名を使った内部 DNS クエリが行われると、インスタンスのプライマリ インターフェース（nic0）に解決されます。インスタンスの nic0 インターフェースが、内部 DNS クエリを発行するインスタンスの VPC ネットワークとは異なる VPC ネットワーク内のサブネットに接続されている場合、クエリは失敗します。

Compute Engine の非公開 DNS レコードは、インターフェース単位では生成されません。

複数のネットワーク インターフェースがある場合の DHCP の動作

複数インターフェースのデフォルトの構成では、DHCP を使用するように OS が構成されます。複数インターフェースのそれぞれのインターフェースにおける DHCP と ARP の動作は、単一インターフェースを持つインスタンスでの DHCP と ARP の動作と同じです。

DHCP を使用する複数インターフェースのインスタンスでは、すべてのインターフェースが、そのインターフェースが属するサブネットのルートを取得します。さらに、インスタンスは、プライマリ インターフェース eth0 に関連付けられているデフォルト ルートを 1 つ取得します。インスタンスから送信されるトラフィックの宛先が直接接続されているサブネット以外の場合、手動で別途構成しない限り、トラフィックは eth0 のデフォルト ルートを経由します。

この動作は、IPv6 アドレスのインターフェースでも同じです。インターフェースは、それが配置されている IPv6 サブネット範囲のルートと、単一の IPv6 デフォルト ルートを取得します。

このサンプルでは、プライマリ インターフェース eth0 はデフォルト ルート（default via 10.138.0.1 dev eth0）を取得し、インターフェース eth0 と eth1 はそれぞれのサブネットのルートを取得します。

instance-1:~$ ip route
default via 10.138.0.1 dev eth0
10.137.0.0/20 via 10.137.0.1 dev eth1
10.137.0.1 dev eth1 scope link
10.138.0.0/20 via 10.138.0.1 dev eth0
10.138.0.1 dev eth0 scope link

詳細については、ポリシー ルーティングの構成をご覧ください。

カスタム静的ルートと複数のネットワーク インターフェース

VM インスタンスに複数のインターフェースとネットワーク タグがある場合、ネットワーク タグがすべての VM のインターフェースに影響するとは限りません。VM のネットワーク タグはインターフェースに影響するのは、タグが一致するカスタム静的ルートを含む VPC ネットワーク内にインターフェースがある場合です。

例:

  1. VM には nic0 と nic1 の 2 つのインターフェースがあります。nic0 インターフェースは vpc-net-a 内にあります。nic1 インターフェースは vpc-net-b 内にあります。VM には、vpn-ok というネットワーク タグがあります。タグは、特定のインターフェースではなくインスタンス上の属性です。
  2. vpc-net-a ネットワークには vpn-ok というタグを持つカスタム静的ルートがあります。
  3. vpc-net-b ネットワークには vpn-123 というタグを持つカスタム静的ルートがあります。

手順の番号は図 3 に対応しています。

図 3.vpc-net-a のカスタム静的ルートは nic0 に影響します（タグがあるため）が、vpc-net-b のカスタム静的ルートは nic1 に影響しません（クリックして拡大）。

vpc-net-a ネットワークの場合、VM と共通のタグを持つルートがあるため、VM の vpn-ok タグが vpc-net-a の VM の nic0 インターフェースに適用されます。一方、vpc-net-b には vpn-ok タグを持つ静的ルートがないため、VM の vpn-ok ネットワーク タグは VM の nic1 インターフェースでは無視されます。

複数のネットワーク インターフェースを持つインスタンスのルートのタグ

ルートにタグを使用する場合は、インスタンス レベルでタグが適用されるため、仮想マシン インスタンスのすべてのインターフェースにタグが適用されることに注意してください。これが望ましくない場合、ルートに適用されるタグが各 VPC ネットワークに固有であることを確認してください。

ロードバランサと複数のネットワーク インターフェース

内部 TCP / UDP 負荷分散以外の Google Cloud ロードバランサはすべて、バックエンド インスタンスの最初のインターフェース（nic0）にのみトラフィックを分散します。

ファイアウォール ルールと複数のネットワーク インターフェース

各 VPC ネットワークには、独自の一連のファイアウォール ルールがあります。インスタンスのインターフェースが特定の VPC ネットワーク内にある場合、そのネットワークのファイアウォール ルールがそのインターフェースに適用されます。

たとえば、VM インスタンスに次の 2 つのインターフェースがあると仮定します。

  • VPC ネットワーク network-1 内の nic0
  • VPC ネットワーク network-2 内の nic1

network-1 ネットワーク用に作成したファイアウォール ルールが nic0 に適用されます。network-2 ネットワーク用に作成したファイアウォール ルールが nic1 に適用されます。

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

複数のネットワーク インターフェースを持つインスタンスのファイアウォール

  • 上り（内向き）ファイアウォール ルールでは、ネットワーク タグまたはサービス アカウントのいずれかを使用して、ソース、ターゲット（宛先）、またはその両方を識別できます。

  • 下り（外向き）ファイアウォール ルールでは、ネットワーク タグまたはサービス アカウントのいずれかを使用して、ターゲット（ソース）を識別できます。

詳細については、サービス アカウントによる送信元とターゲットのフィルタリングをご覧ください。

ネットワーク タグとサービス アカウントは、特定のインターフェースではなくインスタンスを識別します。ファイアウォール ルールは単一の VPC ネットワークに関連付けられ、マルチ NIC インスタンスの各インターフェースは一意の VPC ネットワーク内にあるサブネット内に存在する必要があります。

次の例は、ソースタグを上り（内向き）allow ファイアウォール ルールに効果的に使用する方法を示しています。vm1 インスタンスには次の 2 つのネットワーク インターフェースがあります。

  • nic0（network-1 内）
  • nic1（network-2 内）

vm1 からの次のトラフィックを許可する必要があると仮定します。

  • vm1 から network-1 の任意のインスタンスへの SSH トラフィック
  • vm1 から network-2 の任意のインスタンスへの HTTP および HTTPS トラフィック

これを行う手順は、次のとおりです。

  1. vm1 に vm1-network1 と vm1-network2 の 2 つのネットワーク タグを割り当てます。

  2. 次のコンポーネントを持つ上り（内向き）allow ファイアウォール ルールを network-1 に作成して、vm1 から network-1 内のすべての VM への SSH トラフィックを許可します。

    • 操作: allow
    • 方向: ingress
    • ソース: タグ vm1-network1 付き VM
    • ターゲット: VPC ネットワーク内のすべてのインスタンス
    • プロトコルとポート: tcp:22

  3. 次のコンポーネントを持つ network-2 の上り（内向き）許可ファイアウォール ルールを作成して、vm1 から network-2 内のすべての VM への HTTP および HTTPS トラフィックを許可します。

    • 操作: allow
    • 方向: ingress
    • ソース: タグ vm1-network2 付き VM
    • ターゲット: VPC ネットワーク内のすべてのインスタンス
    • プロトコルとポート: tcp:80,443

図 4 は、このファイアウォール構成の例を示しています。

図 4.ファイアウォール ルール 1 とファイアウォール ルール 2 には、それぞれ VM1 に関連付けられたソースタグがあります。network-1 にあるファイアウォール ルール 1 は VM1 の nic0 にのみ影響します。これらは両方とも network-1 にあるためです。ファイアウォール ルール 2 は、ネットワークを共有するため、VM1 の nic1 にのみ影響します（クリックして拡大）。

次のステップ