複数のネットワーク インターフェースの概要と例

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

概要

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

VPC ネットワーク内のすべてのインスタンスには、デフォルトのネットワーク インターフェースがあります。追加のネットワーク インターフェースを作成して、VM に接続できます。複数のネットワーク インターフェースを使用することで、1 つのインスタンスが複数の VPC ネットワークに直接接続する構成を作成できます。各インターフェースには内部 IP アドレスが必要で、外部 IP アドレスも設定できます。インスタンスのタイプに応じて、各インスタンスに最大 8 個のインターフェースを割り当てることができます。詳細については、インターフェースの最大数をご覧ください。

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

使用例

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

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

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

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

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

  • 個別のインターフェースへの帯域幅分離: これには、コントロール プレーンとデータプレーンの間で発生するヘッドオブライン問題の回避が含まれます。ネットワーク インターフェースを使って、管理プレーン、コントロール プレーン、ストレージ プレーン、データプレーンの各ネットワークを分離できます。たとえば、コントロール(ハートビート信号など)に非常に敏感なアプリケーションがあります。このようなアプリケーションでは、トラフィックの急増や輻輳が発生した場合でも利用可能な最低限の帯域幅を保証するため、データパスのインターフェースからコントロールを分離するほうがよいでしょう。このシナリオでは、専用の仮想インターフェースを使ってコントロールのトラフィックを他のトラフィックから分離します。インターフェースごとに仮想キューを設定します。仮想キューは、1 つの VPC ネットワーク上で発生した帯域幅の急激な増大や DDoS 攻撃が他の VPC ネットワークに影響することを防ぎます。このようなインターフェース単位の仮想キューによって、ヘッドオブライン ブロッキングも回避され、インスタンスの CPU は各 I/O インターフェースで公平に共有されます。詳細については、例 3: SaaS アーキテクチャにおける管理インターフェースとデータプレーン インターフェースの分離をご覧ください。

構成例

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

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

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

以下の図は、一般的な設定を示したものです。このケースでは、パブリックからプライベートへの接続パスに仮想ネットワーク アプライアンスを構成します。このように、パブリック側の外部クライアントからのトラフィックは常にアプリケーションレベルの仮想化されたファイアウォール適用ポイントを介してプライベート VPC ネットワークに到達します。このアプリケーションレベルのファイアウォールは、仮想マシンに適用されます。

使用例 1: 複数のインターフェースを持つインスタンスのプロビジョニングと構成(クリックで拡大)
使用例 1: 複数のインターフェースを使ったインスタンスのプロビジョニングと構成(クリックで拡大)

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

以下では、subnet0subnet1subnet2 がすでに存在し、範囲の重複がないと仮定します。この例の 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 ネットワークのシナリオにおけるサードパーティ製アプライアンスの使用

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

使用例 2: サードパーティ製アプライアンスを使った共有 VPC の例(クリックで拡大)
使用例 2: サードパーティ製アプライアンスを使った共有 VPC の例(クリックで拡大)

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

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

VM アプライアンスを作成するには:

gcloud compute instances create VM-appliance \
    --network-interface subnet=subnet-dmz,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-dmz の一部である subnet-dmz に接続され、静的アドレス 'reserved-address' がある
  • nic1 は network-1 の一部である subnet-1 に接続され、パブリック IP がない
  • nic2 は network-2 の一部である subnet-2 に接続され、パブリック IP がない
  • nic3 は network-3 の一部である subnet-3 に接続され、パブリック IP がない
  • nic4 は network-4 の一部である subnet-4 に接続され、パブリック IP がない

例 3: SaaS アーキテクチャにおける管理インターフェースとデータプレーン インターフェースの分離

複数の異なるユーザー(テナント)に提供する 1 つのサービスを GCP で運用する場合は、別個の管理インターフェースを使ってサービスを管理できます。管理インターフェースを使って、テナントが使用するインターフェースに関係なく、ソフトウェア アップグレード、メンテナンス処理、トラブルシューティングを実行できます。

次の図に、クラウドでホストされているサービスを示します。サービス プロデューサーは、各テナントに提供するサービスを別々の VPC ネットワークに分離します。つまり、各テナント用の VPC ネットワークを作成し、各ユーザーにサービスを提供するインスタンスを作成します。たとえば、テナント A に提供するインスタンスを作成し、それらのインスタンスをネットワーク A に分離します。これにより、テナント A のオンプレミス マシンはこのサービスにアクセスできますが、残りのテナントはこのサービスにアクセスできなくなります。さらに、同じ構成をテナント B とテナント C にも作成します。

しかし、ソフトウェア アップデート、サポート、トラブルシューティングを行うには、各テナントの GCP でホストされているサービスにアクセスできる必要があります。そのためには、各インスタンスに管理インターフェースを追加し、それをオンプレミスの設備にプライベート接続された管理ネットワークに関連付けます。

使用例 3: SaaS の例(クリックで拡大)
使用例 3: SaaS の例(クリックで拡大)

テナント A のインスタンスには 2 つのインターフェースがあります。1 つはテナント A のネットワークに属するインターフェース、もう 1 つはプロデューサー(SaaS プロバイダ)の管理ネットワークに属するインターフェースです。同様に、テナント B のインスタンスにも 2 つのインターフェースがあります。1 つはテナント B のネットワークに属するインターフェース、もう 1 つはプロデューサー(SaaS プロバイダ)の管理ネットワークに属するインターフェースです。

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

この例のテナント インスタンスを構成するには、次のコマンドを使用します。

VM-A を作成するには:

gcloud compute instances create vm-a \
    --network-interface subnet=subnet-a,no-address \
    --network-interface subnet=subnet-mgmt,private-network-ip=198.168.0.2, \
    no-address

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

  • nic0 は network-a の一部である subnet-a に接続される
  • nic1 は network-mgmt の一部である subnet-mgmt に接続される

VM-B を作成するには:

gcloud compute instances create vm-b\
    --network-interface subnet=subnet-b,no-address \
    --network-interface subnet=subnet-mgmt,private-network-ip=198.168.0.3, \
    no-address

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

  • nic0 は network-b の一部である subnet-b に接続される
  • nic1 は network-mgmt の一部である subnet-mgmt に接続される

VM-C を作成するには:

gcloud compute instances create vm-c\
    --network-interface subnet=subnet-c,no-address \
    --network-interface subnet=subnet-mgmt,private-network-ip=198.168.0.4, \
    no-address

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

  • nic0 は network-c の一部である subnet-c に接続される
  • nic1 は network-mgmt の一部である subnet-mgmt に接続される

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

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

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

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

複数のネットワーク インターフェースを持つインスタンスを作成すると、インスタンスまたはインスタンス テンプレートの特定のインターフェースをプロジェクトのローカル サブネットに接続し、同時に他のインターフェースを共有 VPC ネットワークに接続できます。

共有 VPC ネットワークに関連付けられたインターフェースを持つインスタンスを作成するには、共有 VPC ホスト プロジェクトで compute.networkUser 役割を持っている必要があります。

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

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

Compute Engine のプライベート DNS レコードは、インターフェースごとに生成されません。

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

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

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

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

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

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

複数のネットワーク インターフェースがある場合の静的ルート

静的ルートは、VPC ネットワーク単位で適用されるか、または構成されたネットワーク タグと一致する VPC ネットワーク内の特定のインスタンスに適用されます。

個々の VPC ネットワークは、一連の異なるルートを持つことができます。複数のインターフェースを持つインスタンスを構成すると、各インターフェースは異なる VPC ネットワークに属します。そのため、各インターフェースに関連付けられたトラフィックには、そのインターフェースが属する VPC ネットワークのルートが適用されます。

複数のネットワーク インターフェースを持つインスタンスのルートにおけるタグの使用

ルートにタグを使用する場合は、インスタンス レベルでタグが適用されるため、仮想マシン インスタンスのすべてのインターフェースにタグが適用されることに注意してください。これを避けるには、特定の VPC ネットワークのルートに特定のタグのみが使用されるように構成を設定して、実質的にこれらのタグが特定の VPC ネットワークに関連付けられたインターフェースにのみ適用されるようにします。

複数のネットワーク インターフェースがある場合のロードバランサ

負荷分散されたバックエンド(インスタンス グループやターゲット プールなど)に複数のネットワーク インターフェースがある場合、ロードバランサはバックエンド インスタンスのデフォルト インターフェースにのみトラフィックを送信します。

これは、GCP でサポートされるロードバランサのタイプすべてに当てはまります。

複数のネットワーク インターフェースがある場合のファイアウォール ルール

次の組み合わせによって定義された特定のトラフィックのみを許可するようにファイアウォール ルールを構成できます。

  • ソース IP 範囲(許可される IP アドレス ブロックのリスト)またはソースタグ(許可される一連のインスタンス)
  • 宛先プロトコル、宛先ポート、またはその両方

ファイアウォール ルールは、VPC ネットワーク単位で適用されるか、または構成されたターゲットタグと一致する VPC ネットワーク内の特定のインスタンスに適用されます。

個々の VPC ネットワークは、一連の異なるファイアウォール ルールを持つことができます。複数のネットワーク インターフェースを持つインスタンスを構成すると、各インターフェースは異なる VPC ネットワークに属します。各インターフェースは、そのインターフェースが属する VPC ネットワークに適用されるファイアウォール ルールによって制限されます。

複数のネットワーク インターフェースを持つインスタンスのファイアウォールにおけるタグの使用

タグを使ってファイアウォール ルールを実装する場合は、インスタンス レベルでタグが適用されるため、インスタンスのすべてのインターフェースにタグが適用されることに注意してください。これを避けるには、特定の VPC ネットワークのルートとファイアウォール ルールに特定のタグのみが使用されるように構成を設定して、これらのタグが特定の VPC ネットワークに関連付けられたインターフェースにのみ適用されるようにします。

たとえば、タグに VPC ネットワークの名前を指定すると、ユーザーはこれらのタグが適用される VPC ネットワークを(続いてインターフェースも)明確に識別できます。

タグ名を選択して特定の VPC ネットワークを識別したら、その VPC ネットワークに適用されるファイアウォール ルールではそれらのタグのみを使用します。

たとえば、次のシナリオを考えてみましょう。network1network2 の 2 つの VPC ネットワークがあります。インスタンス vm-1 は、2 つの異なるインターフェースを介して両方の VPC ネットワークに接続されます。nic0network1 に関連付けられ、nic1network2 に関連付けられています。

次の図にこの設定を示します。

ファイアウォールでのタグの使用(クリックで拡大)
ファイアウォールでのタグの使用(クリックで拡大)

このシナリオでは、次のファイアウォール ルールを適用します。

  1. network1 のすべてのインスタンスが VM1 からの SSH 接続のみを受け入れます。
  2. network2 のすべてのインスタンスが VM1 からの HTTP/HTTPS 接続のみを受け入れます。

これらのルールを設定するには:

  1. network1 のすべてのインスタンスが VM1 からの SSH 接続のみを受け入れます。

    1. Network1 でのみ使用するタグを VM1 に適用します。この例では、このタグは vm1-network1-foo です。

      gcloud compute instances add-tags vm1 \
          --tags vm1-network1-foo
      
    2. タグ vm1-network1-foo をソースタグとして使用し、SSH(TCP、ポート 22)を許可するように network1 のファイアウォール ルールを構成します。

      gcloud compute firewall-rules create allow-ssh-from-vm1 \
          --allow tcp:22 \
          --network network1 \
          --source-tags vm1-network1-foo
      
  2. network2 のすべてのインスタンスが VM1 からの HTTP/HTTPS 接続のみを受け入れます。

    1. Network2 でのみ使用するタグを VM1 に適用します。この例では、vm1-network2-foo です。

      gcloud compute instances add-tags vm1 \
          --tags vm1-network2-foo
      
    2. タグ vm1-network2-foo をソースタグとして使用し、HTTP と HTTPS(TCP、ポート 80、443)を許可するように Network2 のファイアウォール ルールを構成します。

      gcloud compute firewall-rules create allow-http-https-from-vm1 \
          --allow tcp:80,443 \
          --network network2\
          --source-tags vm1-network2-foo
      
ファイアウォール ルール(クリックで拡大)
ファイアウォール ルール(クリックで拡大)

次のステップ

複数のネットワーク インターフェースを持つインスタンスの作成方法を確認する。

このページは役立ちましたか?評価をお願いいたします。