複数のネットワーク インターフェース
このページでは、Compute Engine VM インスタンスの複数のネットワーク インターフェースの概要について説明します。複数のネットワーク インターフェースを持つインスタンスは、マルチ NIC インスタンスと呼ばれます。
インスタンスには、常に少なくとも 1 つの仮想ネットワーク インターフェース（vNIC）があります。マシンタイプによっては、追加のネットワーク インターフェースを構成できます。
ユースケース
マルチ NIC インスタンスは、次のようなシナリオで役立ちます。
別々の VPC ネットワーク内のリソースに接続する: マルチ NIC インスタンスは、VPC ネットワーク ピアリングまたは Network Connectivity Center を介して相互に接続されていない、異なる VPC ネットワークにあるリソースに接続できます。
マルチ NIC インスタンスの各インターフェースは個別の VPC ネットワークにあるため、各インターフェースを固有の目的に使用できます。たとえば、一部のインターフェースを、本番環境トラフィックを伝送する VPC ネットワーク間でのパケット ルーティングに使用し、別のインターフェースを管理または構成に使用できます。
各マルチ NIC インスタンスのゲスト OS 内で、ルートポリシーとローカル ルートテーブルを構成する必要があります。
VPC ネットワーク間のパケット ルーティング: マルチ NIC インスタンスは、2 つ以上の VPC ネットワークを接続するルートのネクストホップとして使用できます。
マルチ NIC インスタンスのゲスト OS 内で実行されているソフトウェアは、パケット検査、ネットワーク アドレス変換（NAT）、その他のネットワーク セキュリティ機能を実行できます。
マルチ NIC インスタンスを使用して VPC ネットワークを接続する場合は、2 つ以上のマルチ NIC インスタンスを構成し、各 VPC ネットワークの内部パススルー ネットワーク ロードバランサのバックエンドとして使用することをおすすめします。詳細については、ネクストホップとしての内部パススルー ネットワーク ロードバランサのドキュメントでユースケースをご覧ください。
Private Service Connect インターフェースを備えたマルチ NIC インスタンスを使用して、異なるプロジェクトのサービス プロデューサー ネットワークとコンシューマー ネットワークを接続することもできます。
ネットワーク インターフェースのタイプ
Google Cloud は、次のタイプのネットワーク インターフェースをサポートしています。
vNIC: Compute Engine インスタンスの仮想ネットワーク インターフェース。各インスタンスには、少なくとも 1 つの vNIC が必要です。通常の VPC ネットワークの vNIC は、
GVNIC、VIRTIO_NET、IDPFのいずれかになります。vNIC を構成できるのは、インスタンスの作成時のみです。Dynamic NIC（プレビュー）: 親 vNIC の子インターフェース。Dynamic NIC は、インスタンスの作成時に構成することも、後で追加することもできます。詳細については、Dynamic NIC をご覧ください。
RDMA ネットワーク インターフェース（MRDMA）を含むマシンタイプを使用してマルチ NIC インスタンスを構成することもできます。この場合、RDMA ネットワーク プロファイルを持つ VPC ネットワークに接続する必要があります。RDMA ネットワーク プロファイルを持つ VPC ネットワークでは、Dynamic NIC などの他のネットワーク インターフェース タイプはサポートされていません。
仕様
複数のネットワーク インターフェースを持つインスタンスには、次の仕様が適用されます。
インスタンスとネットワーク インターフェース: すべてのインスタンスに
nic0インターフェースがあります。ネットワーク インターフェースの最大数は、インスタンスのマシンタイプによって異なります。- 各インターフェースにはスタックタイプが関連付けられています。このスタックタイプによって、サポートされるサブネット スタックタイプと IP アドレスのバージョンが決まります。詳細については、スタックタイプと IP アドレスをご覧ください。
各ネットワーク インターフェースに一意のネットワーク: RDMA ネットワーク プロファイルを使用して作成された VPC ネットワークを除き、各ネットワーク インターフェースは一意の VPC ネットワーク内のサブネットを使用する必要があります。
RDMA ネットワーク プロファイルを使用して作成された VPC ネットワークの場合、各 RDMA NIC が一意のサブネットを使用している限り、複数の RDMA NIC で同じ VPC ネットワークを使用できます。
ネットワーク インターフェースでネットワークとサブネットを使用するインスタンスを作成するには、VPC ネットワークとサブネットが存在している必要があります。ネットワークとサブネットの作成の詳細については、VPC ネットワークの作成と管理をご覧ください。
インスタンスとサブネットのプロジェクト: スタンドアロン プロジェクトのマルチ NIC インスタンスの場合、各ネットワーク インターフェースでは、インスタンスと同じプロジェクトにあるサブネットを使用する必要があります。
共有 VPC ホスト プロジェクトまたはサービス プロジェクト内のインスタンスについては、共有 VPC をご覧ください。
マルチ NIC インスタンスで Private Service Connect インターフェースを使用すると、ネットワーク インターフェースで別のプロジェクト内のサブネットを使用できます。詳細については、ネットワーク アタッチメントについてをご覧ください。
IP 転送、MTU、ルーティングに関する考慮事項: マルチ NIC インスタンスでは、次のインスタンスとインターフェース固有の構成オプションを慎重に計画する必要があります。
IP 転送オプションはインスタンスごとに構成可能で、すべてのネットワーク インターフェースに適用されます。詳細については、インスタンスの IP 転送を有効にするをご覧ください。
各ネットワーク インターフェースは、関連付けられた VPC ネットワークの MTU に一致する一意の最大伝送単位（MTU）を使用できます。詳細については、最大伝送単位をご覧ください。
各インスタンスは、RFC 3442 で定義されている DHCP オプション 121 を使用してデフォルト ルートを受け取ります。デフォルト ルートは
nic0に関連付けられています。インスタンスから送信されるトラフィックは、宛先が直接接続されているサブネット以外の場合、手動で別途構成しない限りnic0のデフォルト ルートを経由します。Linux システムでは、
/etc/iproute2/rt_tablesファイルとip ruleおよびip routeコマンドを使用して、ゲスト OS 内でカスタムルールとカスタムルートを構成できます。詳細については、ゲスト OS のドキュメントをご覧ください。例については、追加のインターフェースのルーティングを構成するチュートリアルをご覧ください。
Dynamic NIC
Dynamic NIC は、次のようなシナリオで役立ちます。
既存のインスタンスにネットワーク インターフェースを追加するか、既存のインスタンスからネットワーク インターフェースを削除する必要がある。Dynamic NIC の追加または削除に、インスタンスの再起動や再作成は必要ありません。
ネットワーク インターフェースがさらに必要。 Google Cloud のほとんどのマシンタイプで、vNIC の最大数は 10 です。ただし、Dynamic NIC を使用すると、最大 16 個のインターフェースを構成できます。詳細については、ネットワーク インターフェースの最大数をご覧ください。
vNIC が 1 つしかないマルチ NIC Compute Engine ベアメタル インスタンスを構成する必要がある。
Dynamic NIC のプロパティ
Dynamic NIC のプロパティについては、次の情報をご覧ください。
Dynamic NIC は、IEEE 802.1Q 標準パケット形式を使用する VLAN インターフェースです。次の考慮事項をご覧ください。
- Dynamic NIC の VLAN ID は、2～255 の整数にする必要があります。
- Dynamic NIC の VLAN ID は、親 vNIC 内で一意である必要があります。ただし、異なる親 vNIC に属する Dynamic NIC では同じ VLAN ID を使用できます。
Google Cloud では、Dynamic NIC の名前として
nicNUMBER.VLAN_IDという形式が使用されます。ここでnicNUMBERは、親 vNIC の名前です（例:nic0）。VLAN_IDは、設定した VLAN ID です（4など）。
たとえば、Dynamic NIC の名前は
nic0.4のようになります。Dynamic NIC を使用してインスタンスを作成するか、既存のインスタンスに Dynamic NIC を追加するには、ゲスト OS で対応する VLAN インターフェースをインストールして管理するための追加の手順が必要です。次のいずれかの方法を使用できます。
- Google ゲスト エージェントを使用して、Dynamic NIC の自動管理を構成します。
- ゲスト OS を手動で構成します。
詳細については、Dynamic NIC 用にゲスト OS を構成するをご覧ください。
Dynamic NIC は親 vNIC の帯域幅を共有します。親 vNIC 内でトラフィックの分離は行われません。ネットワーク インターフェースが帯域幅をすべて消費しないようにするには、ゲスト OS でアプリケーション固有のトラフィック ポリシーを作成して、Linux Traffic Control（TC）などの方法でトラフィックの優先順位付けや分散を行う必要があります。
Dynamic NIC は、親 vNIC と同じ受信キューと送信キューを共有します。
Dynamic NIC の制限事項
Dynamic NIC には次の制限があります。
Dynamic NIC の次のプロパティは、作成後に変更できません。
- Dynamic NIC が属する親 vNIC。
- Dynamic NIC の VLAN ID。
Dynamic NIC は、次の機能をサポートしていません。
- Google Cloud Armor の高度なネットワーク DDoS 対策とネットワーク エッジのセキュリティ ポリシー
- MIG のインスタンスごとの構成
- IPv6 のみのインターフェース（プレビュー）
- ファイアウォール エンドポイントなど、パケット インターセプトに依存する機能
- Windows オペレーティング システム（OS）
タイプが
GVNICの親 vNIC を使用する Dynamic NIC では、一部のカスタム MTU サイズでパケットロスが発生することがあります。パケットロスを回避するには、1,986 バイト、3,986 バイト、5,986 バイト、7,986 バイトの MTU サイズを使用しないでください。第 3 世代の VM の場合、VLAN ID が
255の Dynamic NIC は、メタデータ サーバーの IP アドレスにアクセスできません。メタデータ サーバーにアクセスする必要がある場合は、別の VLAN ID を使用してください。第 3 世代の VM の場合、同じ VLAN ID を持つ Dynamic NIC を削除して追加すると、異なる VPC ネットワーク間で未承認のアクセスが発生する可能性があります。詳細については、既知の問題をご覧ください。
スタックタイプと IP アドレス
vNIC を作成するときに、次のいずれかのインターフェース スタック タイプを指定します。
- IPv4 のみ
- デュアルスタック
IPv6 のみ（プレビュー）
次の表に、サポートされているサブネット スタックタイプと、各インターフェース スタックタイプの IP アドレスの詳細を示します。
| インターフェース | IPv4 のみのサブネット | デュアルスタック サブネット | IPv6 のみのサブネット（プレビュー） | IP アドレスの詳細 |
|---|---|---|---|---|
| IPv4 のみ（シングル スタック） | IPv4 アドレスのみ。IPv4 アドレスの詳細をご覧ください。 | |||
| IPv4 と IPv6（デュアル スタック） | IPv4 アドレスと IPv6 アドレスの両方。IPv4 アドレスの詳細と IPv6 アドレスの詳細をご覧ください。 | |||
| IPv6 のみ（シングル スタック）（プレビュー） | IPv6 アドレスのみ。IPv6 アドレスの詳細をご覧ください。 |
ネットワーク インターフェースのスタックタイプの変更
ネットワーク インターフェースのスタックタイプを変更するには、次の操作を行います。
インターフェースのサブネットがデュアルスタック サブネットの場合、またはインスタンスを停止してインターフェースをデュアルスタック サブネットに割り当てる場合は、IPv4 のみのインターフェースをデュアルスタックに変換できます。
デュアルスタック インターフェースは IPv4 のみに変換できます。
IPv6 のみのインターフェースのスタックタイプは変更できません。IPv6 のみのインターフェース（プレビュー）は、インスタンスの作成時にのみサポートされます。
IPv4 アドレスの詳細
IPv4 のみまたはデュアルスタックの各ネットワーク インターフェースには、プライマリ内部 IPv4 アドレスが割り当てられます。各インターフェースは、必要に応じてエイリアス IP 範囲と外部 IPv4 アドレスをサポートします。IPv4 の仕様と要件は次のとおりです。
プライマリ内部 IPv4 アドレス: Compute Engine は、インターフェースのサブネットのプライマリ IPv4 アドレス範囲から、ネットワーク インターフェースにプライマリ内部 IPv4 アドレスを割り当てます。プライマリ内部 IPv4 アドレスは DHCP によって割り振られます。
割り当てられるプライマリ内部 IPv4 アドレスを制御するには、静的内部 IPv4 アドレスを構成するか、カスタム エフェメラル内部 IPv4 アドレスを指定します。
VPC ネットワーク内では、各 VM ネットワーク インターフェースのプライマリ内部 IPv4 アドレスは一意です。
エイリアス IP 範囲: 必要に応じて、インターフェースに 1 つ以上のエイリアス IP 範囲を割り当てることができます。各エイリアス IP 範囲は、インターフェースのサブネットのプライマリ IPv4 アドレス範囲またはセカンダリ IPv4 アドレス範囲のいずれかから取得できます。
- VPC ネットワーク内では、各インターフェースのエイリアス IP 範囲は一意である必要があります。
外部 IPv4 アドレス: 必要に応じて、インターフェースにエフェメラルまたは予約済みの外部 IPv4 アドレスを割り当てることができます。 Google Cloud は、各外部 IPv4 アドレスの一意性を保証します。
IPv6 アドレスの詳細
Compute Engine は、デュアルスタックまたは IPv6 のみ（プレビュー版）の各ネットワーク インターフェースに、インターフェースのサブネットの /64 IPv6 アドレス範囲から /96 IPv6 アドレス範囲を割り当てます。
/96IPv6 アドレス範囲が内部か外部かは、インターフェースのサブネットの IPv6 アクセスタイプによって決まります。 Google Cloud は、内部と外部の各 IPv6 アドレス範囲の一意性を保証します。詳細については、IPv6 の仕様をご覧ください。- インスタンスに内部 IPv6 アドレス範囲と外部 IPv6 アドレス範囲の両方が必要な場合: 2 つのデュアルスタック インターフェース、2 つの IPv6 のみのインターフェース、または 1 つのデュアルスタック インターフェースと 1 つの IPv6 のみのインターフェースを構成する必要があります。1 つのインターフェースで使用されるサブネットには外部 IPv6 アドレス範囲が必要で、もう一方のインターフェースで使用されるサブネットには内部 IPv6 アドレス範囲が必要です。
最初の IPv6 アドレス（
/128）は、DHCP によってインターフェースに構成されます。詳細については、IPv6 アドレスの割り当てをご覧ください。静的な内部または外部 IPv6 アドレス範囲を構成することで、割り当てられる
/96IPv6 アドレス範囲を制御できます。内部 IPv6 アドレスの場合は、カスタム エフェメラル内部 IPv6 アドレスを指定できます。
IPv6 アドレスを使用してインスタンスを複数のネットワークに接続する場合は、google-guest-agent バージョン 20220603.00 以降をインストールします。詳細については、セカンダリ インターフェースの IPv6 アドレスに接続できないをご覧ください。
ネットワーク インターフェースの最大数
ほとんどのマシンタイプでは、インスタンスに接続可能なネットワーク インターフェースの最大数は、次の表に示すように、vCPU の数に応じてスケーリングされます。
マシン固有の例外は次のとおりです。
Compute Engine ベアメタル インスタンスは、単一の vNIC をサポートします。
A3、A4、A4X などの一部のアクセラレータ最適化マシンタイプでは、vNIC の最大数が異なります。詳細については、アクセラレータ最適化マシン ファミリーをご覧ください。
インターフェースの最大数
次の表を使用して、インスタンスに接続できるネットワーク インターフェース数を判断してください。
| vCPU 数 | vNIC の最大数 | Dynamic NIC の最大数 | ネットワーク インターフェースの最大数 （vNIC + Dynamic NIC） |
|---|---|---|---|
| 2 以下 | 2 | 1 | 2 |
| 4 | 4 | 3 | 4 |
| 6 | 6 | 5 | 6 |
| 8 | 8 | 7 | 8 |
| 10 | 10 | 9 | 10 |
| 12 | 10 | 10 | 11 |
| 14 | 10 | 11 | 12 |
| 16 | 10 | 12 | 13 |
| 18 | 10 | 13 | 14 |
| 20 | 10 | 14 | 15 |
| 22 以上 | 10 | 15 | 16 |
参照数式
次の表に、インスタンスのネットワーク インターフェースの最大数を計算するために使用される式を示します。この式は vCPU の数によって異なります。
| vCPU 数（X） | vNIC の最大数 | Dynamic NIC の最大数 | ネットワーク インターフェースの最大数 （vNIC + Dynamic NIC） |
|---|---|---|---|
X=1 |
2 |
1 |
2 |
2 ≤ X ≤ 10 |
X |
(X-1) |
X |
X ≥ 12 |
10 |
min(15, (X-10)/2 + 9) |
min(16, (X-10)/2 + 10) |
Dynamic NIC の分散例
Dynamic NIC を vNIC 間で均等に分散する必要はありません。ただし、Dynamic NIC は親 vNIC の帯域幅を共有するため、均等な分布が必要になる場合があります。
1 つのインスタンスに少なくとも 1 つの vNIC が必要です。たとえば、2 個の vCPU を持つインスタンスには、次のいずれかの構成を設定できます。
- 1 個の vNIC
- 2 個の vNIC
- 1 個の vNIC と 1 個の Dynamic NIC
次の表に、特定の数の vCPU で最大数のネットワーク インターフェースを使用しながら、Dynamic NIC を vNIC に均等に分散する構成の例を示します。
2 vCPU、2 NIC
次の表に、2 個の vCPU を持つインスタンスの例を示します。この例では、特定の数の vNIC に対して使用できる Dynamic NIC の数を示します。
| vCPU 数 | vNIC の数 | vNIC あたりの Dynamic NIC の数 | ネットワーク インターフェース（vNIC + Dynamic NIC）の合計数 |
|---|---|---|---|
| 2 | 1 | 1 | 2 |
| 2 | 0 |
4 vCPU、4 NIC
次の表に、4 個の vCPU を持つインスタンスの例を示します。この例では、特定の数の vNIC に対して使用できる Dynamic NIC の数を示します。
| vCPU 数 | vNIC の数 | vNIC あたりの Dynamic NIC の数 | ネットワーク インターフェース（vNIC + Dynamic NIC）の合計数 |
|---|---|---|---|
| 4 | 1 | 3 | 4 |
| 2 | 1 | ||
| 4 | 0 |
8 vCPU、8 NIC
次の表に、8 個の vCPU を持つインスタンスの例を示します。この例では、特定の数の vNIC に対して使用できる Dynamic NIC の数を示します。
| vCPU 数 | vNIC の数 | vNIC あたりの Dynamic NIC の数 | ネットワーク インターフェース（vNIC + Dynamic NIC）の合計数 |
|---|---|---|---|
| 8 | 1 | 7 | 8 |
| 2 | 3 | ||
| 4 | 1 | ||
| 8 | 0 |
14 vCPU、12 NIC
次の表に、12 個の vCPU を持つインスタンスの例を示します。この例では、特定の数の vNIC に対して使用できる Dynamic NIC の数を示します。
| vCPU 数 | vNIC の数 | vNIC あたりの Dynamic NIC の数 | ネットワーク インターフェース（vNIC + Dynamic NIC）の合計数 |
|---|---|---|---|
| 14 | 1 | 11 | 12 |
| 2 | 5 | ||
| 4 | 2 | ||
| 6 | 1 |
22 vCPU、16 NIC
次の表に、22 個の vCPU を持つインスタンスの例を示します。この例では、特定の数の vNIC に対して使用できる Dynamic NIC の数を示します。
| vCPU 数 | vNIC の数 | vNIC あたりの Dynamic NIC の数 | ネットワーク インターフェース（vNIC + Dynamic NIC）の合計数 |
|---|---|---|---|
| 22 | 1 | 15 | 16 |
| 2 | 7 | ||
| 4 | 3 | ||
| 8 | 1 |
プロダクトの相互作用
このセクションでは、マルチ NIC インスタンスと Google Cloudの他のプロダクトや機能との間の相互作用について説明します。
共有 VPC
Private Service Connect インターフェースを除き、共有 VPC ホスト プロジェクトまたはサービス プロジェクトのマルチ NIC インスタンスのサブネットとプロジェクトの関係は次のとおりです。
共有 VPC ホスト プロジェクトにあるマルチ NIC インスタンスの各ネットワーク インターフェースは、ホスト プロジェクトの共有 VPC ネットワークのサブネットを使用する必要があります。
共有 VPC サービス プロジェクトのマルチ NIC インスタンスの各ネットワーク インターフェースは、次のいずれかを使用できます。
- サービス プロジェクトの VPC ネットワークのサブネット。
- ホスト プロジェクトの共有 VPC ネットワークのサブネット。
共有 VPC の詳細については、以下をご覧ください。
Compute Engine の内部 DNS
Compute Engine は、インスタンスの nic0 ネットワーク インターフェースのプライマリ内部 IPv4 アドレスに対してのみ、内部 DNS 名 A レコードと PTR レコードを作成します。Compute Engine は、nic0 とは異なるネットワーク インターフェースに関連付けられた IPv4 アドレスまたは IPv6 アドレスの内部 DNS レコードを作成しません。
詳細については、Compute Engine の内部 DNS をご覧ください。
静的ルート
静的ルートは、ネットワーク タグを使用して、特定のインスタンスの範囲を制限できます。ネットワーク タグがインスタンスに関連付けられると、そのタグはインスタンスのすべてのネットワーク インターフェースに適用されます。そのため、インスタンスにネットワーク タグを追加したり、インスタンスからネットワーク タグを削除すると、インスタンスのネットワーク インターフェースのいずれかに適用されている静的ルートが変更される可能性があります。
ロードバランサ
インスタンス グループのバックエンドとゾーン NEG バックエンドには、それぞれ次のように関連付けられた VPC ネットワークがあります。
マネージド インスタンス グループ（MIG）の場合、インスタンス グループの VPC ネットワークは、インスタンス テンプレートの
nic0インターフェースに割り当てられた VPC ネットワークです。非マネージド インスタンス グループの場合、インスタンス グループの VPC ネットワークは、非マネージド インスタンス グループに追加する最初のインスタンスの
nic0ネットワーク インターフェースで使用される VPC ネットワークです。
次の表に、任意のネットワーク インターフェースへの接続またはリクエストの分散をサポートするバックエンドを示します。
| ロードバランサ | インスタンス グループ | GCE_VM_IP NEG |
GCE_VM_IP_PORT NEG |
|---|---|---|---|
| バックエンド サービスベースの外部パススルー ネットワーク ロードバランサ バックエンド サービスが VPC ネットワークに関連付けられていません。詳細については、バックエンド サービスと VPC ネットワークをご覧ください。 |
nic0 のみ |
任意の NIC | 該当なし |
| 内部パススルー ネットワーク ロードバランサ バックエンド サービスが VPC ネットワークに関連付けられています。詳細については、バックエンド サービスのネットワーク仕様とバックエンド サービスのネットワーク ルールをご覧ください。 |
任意の NIC | 任意の NIC | 該当なし |
| 外部プロキシ ネットワーク ロードバランサ バックエンド サービスとネットワークの要件の詳細については、バックエンドと VPC ネットワークをご覧ください。 |
nic0 のみ |
該当なし | 任意の NIC |
| 内部プロキシ ネットワーク ロードバランサ バックエンド サービスとネットワークの要件について詳しくは、バックエンドと VPC ネットワークをご覧ください。 |
nic0 のみ |
該当なし | 任意の NIC |
| 外部アプリケーション ロードバランサ バックエンド サービスとネットワークの要件の詳細については、バックエンドと VPC ネットワークをご覧ください。 |
nic0 のみ |
該当なし | 任意の NIC |
| 内部アプリケーション ロードバランサ バックエンド サービスとネットワークの要件について詳しくは、バックエンドと VPC ネットワークをご覧ください。 |
nic0 のみ |
該当なし | 任意の NIC |
ターゲット プールベースの外部パススルー ネットワーク ロードバランサは、インスタンス グループまたは NEG を使用せず、nic0 ネットワーク インターフェースへのロード バランシングのみをサポートします。
ファイアウォール ルール
階層型ファイアウォール ポリシー、グローバル ネットワーク ファイアウォール ポリシー、リージョン ネットワーク ファイアウォール ポリシー、VPC ファイアウォール ルールのファイアウォール ルールのセットは、ネットワーク インターフェースごとに固有です。各ネットワークで、マルチ NIC インスタンスとの間のトラフィックを許可する適切なファイアウォール ルールが設定されていることを確認します。ネットワーク インターフェースに適用されるファイアウォール ルールと各ルールのソースを確認するには、VM インターフェースで有効なファイアウォール ルールを取得するをご覧ください。
ファイアウォール ルールにより、ネットワーク タグまたはセキュアタグを使用して特定の VM インスタンスに範囲を限定できます。どちらも、インスタンスのすべてのネットワーク インターフェースに適用されます。詳細については、セキュアタグとネットワーク タグの比較をご覧ください。
既知の問題
このセクションでは、 Google Cloudで複数のネットワーク インターフェースを使用することに関連する既知の問題について説明します。
Dynamic NIC で VLAN ID を再利用する際のファイアウォールの相互作用
第 3 世代の VM の場合、同じ VLAN ID を持つ Dynamic NIC を削除して追加すると、異なる VPC ネットワーク間で未承認のアクセスが発生する可能性があります。
2 つのネットワーク（network-1 と network-2）と VLAN ID A を含む次のシナリオを考えてみましょう。
network-1から VLAN IDAの Dynamic NIC を削除します。- 10 分間の Cloud NGFW 接続トラッキング期間内に、
network-2で同じ VLAN IDAを持つ新しい Dynamic NIC を作成します。 network-2の新しい Dynamic NIC から発信されたトラフィックが、network-1で削除された Dynamic NIC によって以前に作成された既存の接続トラッキング エントリと一致する可能性があります。
この場合、network-2 の新しい Dynamic NIC から送信または受信されたトラフィックは、Cloud NGFW 接続トラッキング テーブルのエントリと一致すると許可されている可能性があります。このエントリは、network-1 で削除された Dynamic NIC によって使用される接続用に作成されたものです。この問題を回避するには、次の回避策をご覧ください。
回避策:
この問題を回避するには、以下のいずれかを行います。
- Dynamic NIC を削除したら、新しい Dynamic NIC を作成するときにその VLAN ID を再利用しないでください。
- Dynamic NIC を削除した後、同じ VLAN ID を使用する新しい Dynamic NIC を作成するまで、少なくとも 10 分待ちます。
接続トラッキングとファイアウォール ルールの詳細については、Cloud Next Generation Firewall のドキュメントの仕様をご覧ください。