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

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

概要

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

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

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

使用例

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

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

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

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

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

構成例

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

例 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 がない

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

共有 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
    

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

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

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

例:

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

手順の番号は次の図のコールアウトの番号に対応しています。

カスタム静的ルートと複数のネットワーク インターフェース(クリックして拡大)
カスタム静的ルートと複数のネットワーク インターフェース(クリックして拡大)

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

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

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

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

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

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

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

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

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

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

詳しくは、ファイアウォール ルールの概要をご覧ください。

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

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

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

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

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

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

  • nic0network-1 内)
  • nic1network-2 内)

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

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

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

  1. vm1vm1-network1vm1-network22 つのネットワーク タグを割り当てます

  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

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

ファイアウォール ルール(クリックで拡大)
ファイアウォール ルール(クリックで拡大)

次のステップ