Packet Mirroring
このページでは、Packet Mirroring の概要について説明します。
Packet Mirroring では、Virtual Private Cloud（VPC）ネットワーク内で特定のインスタンスのトラフィックのクローンを作成し、検査用として転送します。Packet Mirroring では、ペイロードとヘッダーを含むすべてのトラフィックとパケットデータをキャプチャします。キャプチャは、下り（外向き）トラフィックと上り（内向き）トラフィックの両方、上り（内向き）トラフィックのみ、または下り（外向き）トラフィックのみに対して構成できます。
ミラーリングは、ネットワークではなく、仮想マシン（VM）インスタンスで行われます。このため、Packet Mirroring では VM 上で追加の帯域幅が消費されます。
Packet Mirroring は、セキュリティ ステータスのモニタリングと分析で役立ちます。この機能では、サンプリング期間内のトラフィックだけでなく、すべてのトラフィックをエクスポートします。たとえば、ミラーリングされたトラフィックをセキュリティ ソフトウェアで分析して、脅威や異常を検出できます。また、すべてのトラフィック フローを検査し、アプリケーションのパフォーマンス上の問題を検出することもできます。詳細については、使用例をご覧ください。
仕組み
Packet Mirroring は、ミラーリング対象のソースからトラフィックをコピーし、コレクタ宛先に送信します。Packet Mirroring を構成するには、パケット ミラーリング ポリシーを作成し、送信元と宛先を指定します。
ミラーリング対象のソースは、サブネット、ネットワーク タグ、インスタンス名を指定して選択できる Compute Engine VM インスタンスです。サブネットを指定すると、そのサブネット内に現在存在するインスタンスだけでなく、今後そのサブネット内に作成されるインスタンスもミラーリングされます。ソースタイプは 1 つ以上指定できます。インスタンスが指定されたタイプの少なくともいずれか 1 つに一致すると、インスタンスがミラーリングされます。
パケット ミラーリングは、パケット ミラーリング ポリシーが適用されるネットワークに存在するインスタンスのネットワーク インターフェースからトラフィックを収集します。別のポリシーが構成されていない限り、インスタンスに複数のネットワーク インターフェースがあっても他のインターフェースはミラーリングされません。
コレクタ宛先は、内部ロードバランサの背後にあるインスタンス グループです。インスタンス グループ内のインスタンスは、コレクタ インスタンスと呼ばれます。
コレクタの宛先を指定する場合は、内部パススルー ネットワーク ロードバランサに関連付けられている転送ルールの名前を入力します。Google Cloud は、ミラーリングされたトラフィックをコレクタ インスタンスに転送します。Packet Mirroring の転送ルールを構成しなければならない点を除くと、Packet Mirroring の内部ロードバランサは他の内部ロードバランサと似ています。ミラーリング対象でないトラフィックがロードバランサに送信されると、そのトラフィックは破棄されます。
フィルタリング
デフォルトでは、Packet Mirroring はミラーリング対象のインスタンスのすべての IPv4 トラフィックを収集します。フィルタを使用すると、IPv4 トラフィックだけではなく、IPv6 トラフィックの一部またはすべてを収集するように、トラフィックの収集範囲を広げることができます。また、ミラーリングされるトラフィックを絞り込むこともできます。これは、ミラーリングされるインスタンスで使用される帯域幅を制限する場合に役立ちます。
プロトコル、CIDR 範囲（IPv4、IPv6、またはその両方）、トラフィックの方向（上り（内向き）のみ、下り（外向き）のみ、またはその両方）、またはこれらの組み合わせに基づいてトラフィックを収集するようにフィルタを構成できます。
ポリシーの順序
1 つのインスタンスに複数のパケット ミラーリング ポリシーを適用できます。パケット ミラーリング ポリシーの優先度は常に 1000 であり、変更できません。まったく同じポリシーを使用することはできません。Google Cloud は、同じパケット ミラーリング ポリシーで構成された任意のロードバランサにトラフィックを送信できます。ミラーリング対象のトラフィックを常に 1 つのロードバランサに送信するには、アドレス範囲が重複しないフィルタを持つポリシーを作成します。範囲が重複する場合、一意のフィルタ プロトコルを設定します。
Google Cloud では、各ポリシーのフィルタに応じて、フローごとにポリシーが選択されます。別のポリシーがある場合、Google Cloud はミラーリングされたトラフィックに対応するポリシーを使用します。たとえば、1 つのポリシーに 198.51.100.3/24:TCP フィルタが設定され、別のポリシーに 2001:db8::/64:TCP:UDP フィルタが設定されているとします。これらのポリシーは完全に異なるため、Google Cloud がどちらのポリシーを使用するかは明らかです。
ただし、ポリシーが重複している場合は、Google Cloud がフィルタを評価して、使用するポリシーを選択します。たとえば、2 つのポリシーがあり、1 つには 10.0.0.0/24:TCP フィルタが設定され、もう 1 つには 10.0.0.0/16:TCP フィルタが設定されているとします。CIDR 範囲が重複しているため、これらのポリシーは重複しています。
ポリシーを選択するときに、Google Cloud はフィルタの CIDR 範囲サイズを比較し、ポリシーの優先度を判断します。
Google Cloud はフィルタに基づいてポリシーを選択します。
ポリシーの CIDR 範囲が重複し、プロトコルが完全に一致している場合、Google Cloud は最も狭い CIDR 範囲を使用するポリシーを選択します。ミラーリング対象のインスタンスから送信される TCP パケットの宛先が
10.240.1.4で、10.240.1.0/24:ALLと10.240.0.0/16:TCPというフィルタを使用する 2 つのポリシーが定義されているとします。10.240.1.4の最も狭い範囲の一致は10.240.1.0/24:ALLになるため、Google Cloud は10.240.1.0/24:ALLフィルタが設定されたポリシーを使用します。ポリシーの CIDR 範囲が完全に一致し、プロトコルも重複している場合、Google Cloud は最も狭い範囲のプロトコルを持つポリシーを選択します。たとえば、次のフィルタの範囲は同じですが、プロトコルは重複しています（
10.240.1.0/24:TCPと10.240.1.0/24:ALL）。一致する TCP トラフィックの場合、Google Cloud は10.240.1.0/24:TCPポリシーを使用します。10.240.1.0/24:ALLポリシーは、他のすべてのプロトコルの一致するトラフィックに適用されます。ポリシーの CIDR 範囲が完全に一致していてもプロトコルが異なる場合、ポリシーは重複しません。Google Cloud は、ミラーリング対象トラフィックのプロトコルに対応するポリシーを使用します。たとえば、
2001:db8::/64:TCPと2001:db8::/64:UDPに別のポリシーがあるとします。Google Cloud は、ミラーリング対象トラフィックのプロトコルに応じて TCP または UDP のいずれかのポリシーを使用します。重複するポリシーのフィルタがまったく同じ場合、これは完全に同じものになります。この場合、一致するトラフィックがこれらのポリシーで再評価されるたびに、Google Cloud で同じポリシーが選択されることも、別のポリシーが選択されることもあります。完全に一致するパケット ミラーリング ポリシーを作成しないことをおすすめします。
VPC Flow Logs
VPC Flow Logs では、ミラーリングされたパケットはログに記録されません。VPC Flow Logs が有効になっているサブネットにコレクタ インスタンスがある場合、コレクタ インスタンスに直接送信されたトラフィック（ミラーリングされたインスタンスからのトラフィックを含む）はログに記録されます。つまり、元の宛先 IPv4 または IPv6 アドレスがコレクタ インスタンスの IPv4 または IPv6 アドレスと一致すると、フローがログに記録されます。
VPC Flow Logs の詳細については、VPC Flow Logs の使用をご覧ください。
基本特性
Packet Mirroring を使用する前に、次の制約と動作について理解しておく必要があります。
各パケット ミラーリング ポリシーでは、ミラーリング対象のソースとコレクタの宛先を定義します。次のルールを遵守する必要があります。
- ミラーリング対象のソースはすべて同じプロジェクト、VPC ネットワーク、Google Cloud リージョンに配置されている必要があります。
- コレクタの宛先は、ミラーリング対象のソースと同じリージョンに存在する必要があります。コレクタの宛先は、ミラーリング ソースと同じ VPC ネットワークに配置できます。また、VPC ネットワーク ピアリングを使用してミラーリング ソースのネットワークに接続された VPC ネットワークにも配置できます。
- 各ミラーリング ポリシーで参照できるコレクタの宛先は 1 つだけです。ただし、1 つのコレクタの宛先は複数のミラーリング ポリシーから参照できます。
Packet Mirroring では、すべてのレイヤ 4 プロトコルがサポートされています。
VM インスタンスの同じネットワーク インターフェース上でトラフィックのミラーリングと収集を行うことはできません。このような処理が行われると、ミラーリング ループが発生します。
同じ Google Kubernetes Engine（GKE）ノード上の Pod 間で送受信されるトラフィックをミラーリングするには、クラスタのノード内の可視化を有効にする必要があります。
IPv6 トラフィックをミラーリングするには、ミラーリングする IPv6 トラフィックの IPv6 CIDR 範囲を限定するフィルタを使用します。
::/0という CIDR 範囲フィルタを使用すると、すべての IPv6 トラフィックをミラーリングできます。0.0.0.0/0,::/0というカンマ区切りの CIDR 範囲フィルタを使用すると、すべての IPv4 トラフィックと IPv6 トラフィックをミラーリングできます。ミラーリング トラフィックは、ミラーリングされたインスタンスで帯域幅を消費します。たとえば、ミラーリング対象のインスタンスで 1 Gbps の上り（内向き）トラフィックと 1 Gbps の下り（外向き）トラフィックが発生した場合、このインスタンスの合計トラフィックは上り（内向き）トラフィックが 1 Gbps、下り（外向き）トラフィックが 3 Gbps になります。下り（外向き）のトラフィックでは、通常の下り（外向き）トラフィックとして 1 Gbps が、ミラーリングされた下り（外向き）トラフィックとして 2 Gbps が発生しています。収集するトラフィックを制限するには、フィルタを使用します。
Packet Mirroring の費用は、ミラーリング対象インスタンスからインスタンス グループに送信される下り（外向き）トラフィックの量と、トラフィックがゾーン間で転送されるかどうかによって異なります。
Packet Mirroring は、上り（内向き）と下り（外向き）の両方の方向に適用されます。ミラーリング対象の 2 つの VM インスタンス間でトラフィックが送受信される場合、Google Cloud は同じパケットの 2 つのバージョンを収集します。この動作を変更するには、上り（内向き）パケットのみ、または下り（外向き）パケットのみがミラーリングされるように指定します。
プロジェクトに作成できるパケット ミラーリング ポリシーの数には上限があります。詳細については、割り当てページでプロジェクトごとの割り当てをご覧ください。
パケット ミラーリング ポリシーごとに指定可能なミラーリング ソースの最大数はソースタイプによって異なります。
- 5 個のサブネット
- 5 個のタグ
- 50 個のインスタンス
パケット ミラーリング フィルタの最大数は 30 で、これは IPv4 および IPv6 のアドレス範囲の数にプロトコル数をかけた値になります。たとえば、30 個の範囲と 1 個のプロトコルを指定すると、フィルタは 30 個になります。ただし、30 個の範囲と 2 個のプロトコルを指定することはできません。この場合、フィルタの数は 60 個になり、最大数を超えてしまいます。
Packet Mirroring によって処理されたデータの量に対して課金されます。詳しくは、Packet Mirroring の料金をご覧ください。
また、前提条件となるすべてのコンポーネントと、Packet Mirroring に関連する下り（外向き）トラフィックに対しても課金されます。たとえば、トラフィックを収集するインスタンスは通常レートで課金されます。また、パケット ミラーリング トラフィックがゾーン間を移動した場合、下り（外向き）トラフィックに対して課金されます。料金の詳細については、関連する料金ページをご覧ください。
ミラーリング対象のトラフィックは、VM がそのトラフィックをアプリケーション レイヤで暗号化している場合にのみ暗号化されます。VPC ネットワークとピアリングされた VPC ネットワーク内の VM 間の接続は暗号化されますが、暗号化と復号はハイパーバイザ内で行われます。VM では、このトラフィックは暗号化されません。
ユースケース
以下では、Packet Mirroring が必要になる事例について説明します。
エンタープライズ セキュリティ
セキュリティ チームとネットワーク エンジニアリング チームは、セキュリティ侵害や侵入の兆候を示す異常値や脅威をすべて把握する必要があります。このような場合は、不審なフローに対して包括的な検査を行えるように、すべてのトラフィックをミラーリングします。また、攻撃は複数のパケットにまたがることがあるため、セキュリティ チームはフローごとにすべてのパケットを取得する必要があります。
たとえば、次のセキュリティ ツールを使って複数のパケットをキャプチャする必要があります。
侵入検知システム（IDS）ツールでは、持続型の脅威を検出するため、単一フローの複数のパケットをシグネチャと照合する必要があります。
詳細なパケット検査エンジンは、パケットのペイロードを検査してプロトコルの異常を検出します。
PCI コンプライアンスなどの法規制対応で使用されるネットワーク フォレンジックでは、ほとんどのパケットを検査する必要があります。Packet Mirroring は、珍しい通信や試行に失敗した通信など、さまざまな攻撃ベクトルをキャプチャできます。
アプリケーション パフォーマンスのモニタリング
ネットワーク エンジニアは、アプリケーション チームやデータベース チームから報告されたパフォーマンスの問題を解決する際に、ミラーリングされたトラフィックを利用できます。ネットワークの問題を確認するため、ネットワーク エンジニアはアプリケーションのログを調べるだけでなく、ネットワーク上で何が起きているかも調査します。
たとえば、ネットワーク エンジニアは Packet Mirroring のデータを使用して次の作業を行うことができます。
プロトコルや動作を分析して、パケット損失や TCP リセットなどの問題を検出し、解決します。
リモート デスクトップ、VoIP、その他のインタラクティブ アプリケーションからのトラフィック パターンをリアルタイムで分析します。ネットワーク エンジニアは、複数のパケットの再送や予想以上の再接続など、アプリケーションのユーザー エクスペリエンスに影響する問題を特定できます。
コレクタ宛先のトポロジ例
Packet Mirroring はさまざまな環境で使用できます。次の例では、VPC ネットワーク ピアリングや共有 VPC など、異なるパケット ミラーリング構成でのコレクタ宛先とポリシーについて説明します。
同じネットワーク内のコレクタ宛先
以下のパケット ミラーリング構成の例では、ミラーリング対象のソースとコレクタ宛先が同じ VPC ネットワーク内に存在しています。
上の図では、mirrored-subnet をミラーリングし、ミラーリング対象のトラフィックを内部パススルー ネットワーク ロードバランサに送信するように、パケット ミラーリング ポリシーが構成されています。Google Cloud は、サブネット内に存在するインスタンス（これから作成されるインスタンスも含む）のトラフィックをミラーリングします。インターネット、オンプレミス ホスト、Google サービスとの間で送受信されるトラフィックがすべてミラーリングされます。
ピア ネットワーク内のコレクタ宛先
集中型コレクタモデルを構築し、異なる複数の VPC ネットワークにあるインスタンスが中央の VPC ネットワークのコレクタ宛先にミラーリング対象トラフィックを送信できます。これにより、単一の宛先コレクタを使用できます。
次の例では、collector-load-balancer 内部パススルー ネットワーク ロードバランサが、project-a の network-a VPC ネットワークの us-central1 リージョンにあります。この宛先コレクタは、次の 2 つのパケット ミラーリング ポリシーで使用できます。
policy-1は、project-aのnetwork-aVPC ネットワークのus-central1リージョン内にあるミラーリング対象のソースからパケットを収集し、collector-load-balancer宛先に送信します。policy-2は、project-bのnetwork-bVPC ネットワークのus-central1リージョン内にあるミラーリング対象のソースからパケットを収集し、同じcollector-load-balancer宛先に送信します。
ミラーリング ソースは異なる VPC ネットワークに存在するため、2 つのミラーリング ポリシーが必要です。
上の図では、コレクタ宛先が 2 つの異なるネットワークのサブネットからミラーリングされたトラフィックを収集しています。すべてのリソース（ソースと宛先）が同じリージョン内に存在する必要があります。network-a の設定は、ミラーリング対象のソースとコレクタ宛先が同じ VPC ネットワークに存在する場合の例と似ています。policy-1 は、subnet-a からトラフィックを収集し、collector-ilb に送信するように構成されています。
policy-2 は project-a に構成されていますが、ミラーリング対象のソースとして subnet-b が指定されています。network-a と network-b はピアリングされているため、宛先コレクタは subnet-b からのトラフィックを取得できます。
ネットワークは異なるプロジェクトにあるため、オーナーが異なる可能性があります。どちらのオーナーも、適切な権限があればパケット ミラーリング ポリシーを作成できます。
project-aのオーナーがパケット ミラーリング ポリシーを作成する場合、project-bでミラーリングするネットワーク、サブネット、インスタンスに対するcompute.packetMirroringAdminロールが必要です。project-bのオーナーがパケット ミラーリング ポリシーを作成する場合は、project-aにcompute.packetMirroringUserのロールが必要です。
2 つの VPC ネットワーク間のプライベート接続を有効にする方法については、VPC ネットワーク ピアリングをご覧ください。
共有 VPC
以下の共有 VPC シナリオでは、コレクタ宛先のミラーリング対象インスタンスはすべて同じ共有 VPC ネットワーク内に存在します。リソースがすべて同じネットワーク内に存在していても、これらのリソースがホスト プロジェクトや複数のサービス プロジェクトなど、異なるプロジェクトに分散していることもあります。次の例は、パケット ミラーリング ポリシーの作成場所と作成者を示しています。
ミラーリング対象のソースとコレクタの両方が同じプロジェクト（ホスト プロジェクトまたはサービス プロジェクト）にある場合、同じ VPC ネットワークにすべて配置する場合の設定と似ています。プロジェクト オーナーは、すべてのリソースを作成し、そのプロジェクトに必要な権限を設定できます。
詳しくは、共有 VPC の概要をご覧ください。
サービス プロジェクトのコレクタ宛先
以下の例では、コレクタ宛先がホスト プロジェクトのサブネットを使用するサービス プロジェクトにあります。この場合、ポリシーもサービス プロジェクトに含まれます。ポリシーはホスト プロジェクトに存在することもあります。
上の図では、共有 VPC ネットワークのコレクタ サブネットを使用するコレクタ インスタンスがサービス プロジェクトに含まれています。パケット ミラーリング ポリシーはサービス プロジェクトで作成され、subnet-mirrored にネットワーク インターフェースを持つインスタンスをミラーリングするように構成されています。
サービス プロジェクトまたはホスト プロジェクトのユーザーはパケット ミラーリング ポリシーを作成できます。作成するには、コレクタ宛先があるサービス プロジェクトの compute.packetMirroringUser ロールが必要です。また、ミラーリング ソースに compute.packetMirroringAdmin ロールが必要です。
ホスト プロジェクトのコレクタ宛先
以下の例では、コレクタ宛先はホスト プロジェクトにあり、ミラーリング対象のインスタンスはサービス プロジェクトにあります。
この例は、デベロッパーがサービス プロジェクトにアプリケーションをデプロイし、共有 VPC ネットワークを使用するシナリオに該当します。ネットワーク インフラストラクチャや Packet Mirroring を管理する必要はありません。代わりに、中央のネットワーク チームやセキュリティ チームがホスト プロジェクトと共有 VPC ネットワークを管理し、パケット ミラーリング ポリシーのプロビジョニングを行います。
上の図では、パケット ミラーリング ポリシーがホスト プロジェクトに作成されており、このプロジェクトにコレクタ宛先が配置されています。ミラーリング対象のサブネットのインスタンスをミラーリングするようにポリシーが構成されています。サービス プロジェクトの VM インスタンスはミラーリング対象のサブネットを使用でき、トラフィックがミラーリングされます。
サービス プロジェクトまたはホスト プロジェクトのユーザーはパケット ミラーリング ポリシーを作成できます。この作業を行うには、サービス プロジェクトのユーザーがホスト プロジェクトで compute.packetMirroringUser のロールが必要です。ホスト プロジェクトのユーザーには、サービス プロジェクトのミラーリング対象ソースに対する compute.packetMirroringAdmin ロールが必要です。
マルチインターフェース VM インスタンス
パケット ミラーリング ポリシーに複数のネットワーク インターフェースを持つ VM インスタンスを定義できます。1 つのポリシーで 1 つのネットワークのリソースをミラーリングするため、インスタンスのすべてのネットワーク インターフェースのトラフィックを 1 つのポリシーでミラーリングすることはできません。複数のネットワーク インターフェース インスタンスの複数のネットワーク インターフェースをミラーリングする必要がある場合は、各インターフェースを固有の VPC ネットワークに接続するため、インターフェースごとに 1 つの Packet Mirroring ポリシーを作成する必要があります。
次のステップ
- Packet Mirroring を使用するでパケット ミラーリング ポリシーを作成し、管理する。
- 指標を表示して既存のパケット ミラーリング ポリシーを確認する。Packet Mirroring のモニタリングをご覧ください。
- 内部パススルー ネットワーク ロードバランサの詳細を確認する。内部パススルー ネットワーク ロードバランサの概要をご覧ください。
- パートナー プロバイダのリストを確認する。Packet Mirroring パートナー プロバイダをご覧ください。