パケット ミラーリングの概要

パケット ミラーリングでは、Virtual Private Cloud(VPC)ネットワーク内で特定のインスタンスのトラフィックのクローンを作成し、検査用として転送します。パケット ミラーリングでは、すべての上り(内向き)トラフィックと下り(外向き)トラフィック、ペイロードやヘッダーなどのパケットデータをキャプチャします。ミラーリングは、ネットワークではなく、仮想マシン(VM)インスタンスで行われます。このため、パケット ミラーリングではホスト上で追加の帯域幅が消費されます。

パケット ミラーリングは、セキュリティ ステータスのモニタリングと分析で役立ちます。この機能では、サンプリング期間内のトラフィックだけでなく、すべてのトラフィックをエクスポートします。たとえば、ミラーリングされたトラフィックをセキュリティ ソフトウェアで分析して、脅威や異常を検出できます。また、すべてのトラフィック フローを検査し、アプリケーションのパフォーマンス上の問題を検出することもできます。詳細については、使用例をご覧ください。

仕組み

パケット ミラーリングは、ミラーリング対象のソースからトラフィックをコピーし、コレクタ宛先に送信します。パケット ミラーリングを構成するには、パケット ミラーリング ポリシーを作成し、送信元と宛先を指定します。

  • ミラーリング対象のソースは、サブネット、ネットワーク タグ、インスタンス名を指定することで選択可能な Compute Engine インスタンスです。サブネットを指定すると、そのサブネット内に現在存在するインスタンスだけでなく、今後そのサブネット内に作成されるインスタンスもミラーリングされます。ソースタイプは 1 つ以上指定できます。インスタンスが指定されたタイプの少なくともいずれか 1 つに一致すると、インスタンスがミラーリングされます。

    パケット ミラーリングは、パケット ミラーリング ポリシーが適用されるネットワークに存在するインスタンスのネットワーク インターフェースからトラフィックを収集します。別のポリシーが構成されていない限り、インスタンスに複数のネットワーク インターフェースがあっても他のインターフェースはミラーリングされません。

  • コレクタ宛先は、内部ロードバランサの背後にあるインスタンス グループです。インスタンス グループ内のインスタンスは、コレクタ インスタンスと呼ばれます。インスタンス グループには、自動スケーリング機能と自動修復機能があるマネージド インスタンス グループを使用することをおすすめします。

    コレクタ宛先を指定する場合、内部ロードバランサに関連付けられている転送ルールの名前を入力します。Google Cloud は、ミラーリングされたトラフィックをコレクタ インスタンスに転送します。パケット ミラーリングの転送ルールを構成しなければならない点を除くと、パケット ミラーリングの内部ロードバランサは他の内部ロードバランサと似ています。ミラーリング対象でないトラフィックがロードバランサに送信されると、そのトラフィックは破棄されます。

フィルタリング

デフォルトでは、パケット ミラーリングはミラーリング対象インスタンスで発生したすべての送受信トラフィックを収集します。フィルタを使用すると、すべてのトラフィックではなく、一部のミラーリングされたトラフィックのみを収集できます。フィルタを使用すると、ミラーリング対象のインスタンスによる帯域幅の使用量を抑えることができます。

プロトコル、IP アドレス範囲、またはその両方に基づいてトラフィックを収集するようにフィルタを構成できます。フィルタでは、収集するミラーリング対象トラフィックを指定できますが、除外するトラフィックは指定できません。

ポリシーの順序

1 つのインスタンスに複数のパケット ミラーリング ポリシーを適用できます。Google Cloud は、各ポリシーのフィルタに応じてフローごとに 1 つのポリシーを選択します。別のポリシーがある場合、Google Cloud はミラーリングされたトラフィックに対応するポリシーを使用します。たとえば、1 つのポリシーに 198.51.100.3/24:TCP フィルタが設定され、別のポリシーに 203.0.113.2/24: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 は最も狭い IP アドレス範囲を使用するポリシーを選択します。ミラーリング対象のインスタンスから送信される TCP パケットの宛先が 10.240.1.4 で、10.240.1.0/24:ALL10.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:TCP10.240.1.0/24:ALL)。一致する TCP トラフィックの場合、Google Cloud は 10.240.1.0/24:TCP ポリシーを使用します。 10.240.1.0/24:ALL ポリシーは、他のすべてのプロトコルの一致するトラフィックに適用されます。

  • ポリシーの CIDR 範囲が完全に一致していてもプロトコルが異なる場合、ポリシーは重複しません。Google Cloud は、ミラーリング対象トラフィックのプロトコルに対応するポリシーを使用します。たとえば、10.240.1.0/24:TCP10.240.1.0/24:UDP に別のポリシーがあるとします。Google Cloud は、ミラーリング対象トラフィックのプロトコルに応じて TCP または UDP のいずれかのポリシーを使用します。

  • 重複するポリシーのフィルタがまったく同じ場合、Google Cloud は非決定的な方法を使用してフィルタを選択します。一致するトラフィックがこれらのポリシーで再評価されるたびに、Google Cloud は同じポリシーまたは別のポリシーを選択します。

非決定的な方法でポリシーが選択された場合、Google Cloud は複数のロードバランサでミラーリング対象トラフィックを取得する可能性があります。ミラーリング対象のトラフィックを常に 1 つのロードバランサに送信するには、アドレス範囲が重複しないフィルタを持つポリシーを作成します。範囲が重複する場合、一意のフィルタ プロトコルを設定します。

VPC フローログ

ミラーリング対象のインスタンスが VPC フローログが有効なサブネット内に存在する場合、VPC フローログはミラーリングされたパケットを記録しません。VPC フローログには、ミラーリングされていないトラフィックのみが記録されます。

ただし、VPC フローログが有効なサブネット内にコレクタ インスタンスが存在する場合、VPC フローログは、ミラーリング対象のインスタンスとコレクタ インスタンス間のフローを取得します。ログには、ミラーリング対象のインスタンスとコレクタ インスタンスとして送信元と宛先の IP アドレスが記録されます。ミラーリングされたトラフィックのログの収集を停止するには、コレクタ インスタンス サブネットで VPC フローログを無効にします。

詳細については、VPC フローログの使用をご覧ください。

基本特性

パケット ミラーリングを使用する前に、次の制約と動作について理解しておく必要があります。

  • ミラーリングできるのは、TCP、UDP、ICMP トラフィックのみです。

  • ミラーリング対象のソースとコレクタ宛先は同じリージョンになければなりません。VPC ネットワーク ピアリングで接続されている場合、これらが別々の VPC ネットワークに存在している可能性があります。

  • VM インスタンスの同じネットワーク インターフェース上でトラフィックのミラーリングと収集を行うことはできません。このような処理が行われると、ミラーリング ループが発生します。

  • 同じ Google Kubernetes Engine(GKE)ノード上の Pod 間で送受信されるトラフィックをミラーリングするには、クラスタのノード内の可視化を有効にする必要があります。

  • ミラーリング トラフィックは、ミラーリングされたインスタンスで帯域幅を消費します。たとえば、ミラーリング対象のインスタンスで 1 Gbps の上り(内向き)トラフィックと 1 Gbps の下り(外向き)トラフィックが発生した場合、このインスタンスの合計トラフィックは上り(内向き)トラフィックが 1 Gbps、下り(外向き)トラフィックが 3 Gbps になります。下り(外向き)のトラフィックでは、通常の下り(外向き)トラフィックとして 1 Gbps が、ミラーリングされた下り(外向き)トラフィックとして 2 Gbps が発生しています。収集するトラフィックを制限するには、フィルタを使用します。

  • パケット ミラーリングの費用は、ミラーリング対象インスタンスからインスタンス グループに送信される下り(外向き)トラフィックの量と、トラフィックがゾーン間で転送されるかどうかによって異なります。

  • パケット ミラーリングは、上り(内向き)と下り(外向き)の両方の方向に適用されます。ミラーリング対象の 2 つの VM インスタンス間でトラフィックが送受信される場合、Google Cloud は同じパケットの 2 つのバージョンを収集します。

  • プロジェクトに作成できるパケット ミラーリング ポリシーの数には上限があります。詳細については、割り当てページでプロジェクトごとの割り当てをご覧ください。

  • パケット ミラーリング ポリシーごとに指定可能なミラーリング ソースの最大数はソースタイプによって異なります。

    • 5 個のサブネット
    • 5 個のタグ
    • 50 個のインスタンス
  • パケット ミラーリング フィルタの最大数は 30 で、これは IP アドレス範囲の数にプロトコル数をかけた値になります。たとえば、30 個の範囲と 1 個のプロトコルを指定すると、フィルタは 30 個になります。ただし、30 個の範囲と 2 個のプロトコルを指定することはできません。この場合、フィルタの数は 60 個になり、最大数を超えてしまいます。

  • パケット ミラーリングによって処理されたデータの量に対して課金されます。詳細については、パケット ミラーリングの料金をご覧ください。

    また、前提条件となるすべてのコンポーネントと、パケット ミラーリングに関連する下り(外向き)トラフィックに対しても課金されます。たとえば、トラフィックを収集するインスタンスは通常レートで課金されます。また、パケット ミラーリング トラフィックがゾーン間を移動した場合、下り(外向き)トラフィックに対して課金されます。料金の詳細については、関連する設定ページをご覧ください。

使用例

以下では、パケット ミラーリングが必要になる事例について説明します。

エンタープライズ セキュリティ

セキュリティ チームとネットワーク エンジニアリング チームは、セキュリティ侵害や侵入の兆候を示す異常値や脅威をすべて把握する必要があります。このような場合は、不審なフローに対して包括的な検査を行えるように、すべてのトラフィックをミラーリングします。また、攻撃は複数のパケットにまたがることがあるため、セキュリティ チームはフローごとにすべてのパケットを取得する必要があります。

たとえば、次のセキュリティ ツールでは複数のパケットをキャプチャする必要があります。

  • 侵入検知システム(IDS)ツールでは、持続型の脅威を検出するため、単一フローの複数のパケットをシグネチャと照合する必要があります。

  • 詳細なパケット検査エンジンは、パケットのペイロードを検査してプロトコルの異常を検出します。

  • PCI コンプライアンスなどの法規制対応で使用されるネットワーク フォレンジックでは、ほとんどのパケットを検査する必要があります。パケット ミラーリングは、珍しい通信や試行に失敗した通信など、さまざまな攻撃ベクトルをキャプチャできます。

アプリケーション パフォーマンスのモニタリング

ネットワーク エンジニアは、アプリケーション チームやデータベース チームから報告されたパフォーマンスの問題を解決する際に、ミラーリングされたトラフィックを利用できます。ネットワークの問題を確認するため、ネットワーク エンジニアはアプリケーションのログを調べるだけでなく、ネットワーク上で何が起きているかも調査します。

たとえば、ネットワーク エンジニアはパケット ミラーリングのデータを使用して次の作業を行うことができます。

  • プロトコルや動作を分析して、パケット損失や TCP リセットなどの問題を検出し、解決します。

  • リモート デスクトップ、VoIP、その他のインタラクティブ アプリケーションからのトラフィック パターンをリアルタイムで分析します。ネットワーク エンジニアは、複数のパケットの再送や予想以上の再接続など、アプリケーションのユーザー エクスペリエンスに影響する問題を特定できます。

コレクタ宛先のトポロジ例

パケット ミラーリングはさまざまな環境で使用できます。次の例では、VPC ネットワーク ピアリングや共有 VPC など、異なるパケット ミラーリング構成でのコレクタ宛先とポリシーについて説明します。

同じネットワーク内のコレクタ宛先

以下のパケット ミラーリング構成の例では、ミラーリング対象のソースとコレクタ宛先が同じ VPC ネットワーク内に存在しています。

上の図では、mirrored-subnet をミラーリングし、ミラーリング対象のトラフィックを内部ロードバランサに送信するように、パケット ミラーリング ポリシーが構成されています。Google Cloud は、サブネット内に存在するインスタンス(これから作成されるインスタンスも含む)のトラフィックをミラーリングします。インターネット、オンプレミス ホスト、Google サービスとの間で送受信されるトラフィックがすべてミラーリングされます。

ピア ネットワーク内のコレクタ宛先

集中型コレクタモデルを構築し、異なる複数の VPC ネットワークにあるインスタンスが中央の VPC ネットワークにミラーリング対象トラフィックを送信するように構成することもできます。この場合、それぞれのネットワークに宛先コレクタを構築する必要はありません。中央の VPC ネットワークが 1 つ以上のコレクタ宛先をホストし、ここにすべてのミラーリング対象トラフィックが送信されます。

このシナリオを実現するには、VPC ネットワーク ピアリングを使用します。ミラーリング対象のソースを含むすべての VPC ネットワークを中央のネットワークとピアリングする必要があります。

VPC ネットワークは同じプロジェクトにある場合も、別のプロジェクトにある場合もあります。ピア VPC ネットワークごとに、パケット ミラーリング ポリシーを作成する必要があります。この場合、中央のネットワークを含むプロジェクトにポリシーを作成します。また、中央のネットワークとピアリングされたネットワークを含むプロジェクトにポリシーを作成することもできます。

上の図では、コレクタ宛先が 2 つの異なるネットワークのサブネットからミラーリングされたトラフィックを収集しています。すべてのリソース(ソースと宛先)が同じリージョン内に存在する必要があります。network-a の設定は、ミラーリング対象のソースとコレクタ宛先が同じ VPC ネットワークに存在する場合の例と似ています。policy-1 は、subnet-a からトラフィックを収集し、collector-ilb に送信するように構成されています。

policy-2project-a に構成されていますが、ミラーリング対象のソースとして subnet-b が指定されています。network-anetwork-b はピアリングされているため、宛先コレクタは subnet-b からのトラフィックを取得できます。

ネットワークは異なるプロジェクトにあるため、オーナーが異なる可能性があります。どちらのオーナーも、適切な権限があればパケット ミラーリング ポリシーを作成できます。

  • project-a のオーナーがパケット ミラーリング ポリシーを作成する場合、project-b でミラーリングするネットワーク、サブネット、インスタンスに対する compute.packetMirroringAdmin ロールが必要です。

  • project-b のオーナーがパケット ミラーリング ポリシーを作成する場合は、project-acompute.packetMirroringUser のロールが必要です。

2 つの VPC ネットワーク間のプライベート接続を有効にする方法については、VPC ネットワーク ピアリングをご覧ください。

共有 VPC

以下の共有 VPC シナリオでは、コレクタ宛先のミラーリング対象インスタンスはすべて同じ共有 VPC ネットワーク内に存在します。リソースがすべて同じネットワーク内に存在していても、これらのリソースがホスト プロジェクトや複数のサービス プロジェクトなど、異なるプロジェクトに分散していることもあります。次の例は、パケット ミラーリング ポリシーの作成場所と作成者を示しています。

ミラーリング対象のソースとコレクタの両方が同じプロジェクト(ホスト プロジェクトまたはサービス プロジェクト)にある場合、同じ VPC ネットワークにすべて配置する場合の設定と似ています。プロジェクト オーナーは、すべてのリソースを作成し、そのプロジェクトに必要な権限を設定できます。

詳しくは、共有 VPC の概要をご覧ください。

サービス プロジェクトのコレクタ宛先

以下の例では、コレクタ宛先がホスト プロジェクトのサブネットを使用するサービス プロジェクトにあります。この場合、ポリシーもサービス プロジェクトに含まれます。ポリシーはホスト プロジェクトに存在することもあります。

上の図では、共有 VPC ネットワークのコレクタ サブネットを使用するコレクタ インスタンスがサービス プロジェクトに含まれています。パケット ミラーリング ポリシーはサービス プロジェクトで作成され、subnet-mirrored にネットワーク インターフェースを持つインスタンスをミラーリングするように構成されています。

サービス プロジェクトまたはホスト プロジェクトのユーザーはパケット ミラーリング ポリシーを作成できます。作成するには、コレクタ宛先があるサービス プロジェクトの compute.packetMirroringUser ロールが必要です。また、ミラーリング ソースに compute.packetMirroringAdmin ロールが必要です。

ホスト プロジェクトのコレクタ宛先

以下の例では、コレクタ宛先はホスト プロジェクトにあり、ミラーリング対象のインスタンスはサービス プロジェクトにあります。

この例は、デベロッパーがサービス プロジェクトにアプリケーションをデプロイし、共有 VPC ネットワークを使用するシナリオに該当します。ネットワーク インフラストラクチャやパケット ミラーリングを管理する必要はありません。代わりに、中央のネットワーク チームやセキュリティ チームがホスト プロジェクトと共有 VPC ネットワークを管理し、パケット ミラーリング ポリシーのプロビジョニングを行います。

上の図では、パケット ミラーリング ポリシーがホスト プロジェクトに作成されており、このプロジェクトにコレクタ宛先が配置されています。ミラーリング対象のサブネットのインスタンスをミラーリングするようにポリシーが構成されています。サービス プロジェクトの VM インスタンスはミラーリング対象のサブネットを使用でき、トラフィックがミラーリングされます。

サービス プロジェクトまたはホスト プロジェクトのユーザーはパケット ミラーリング ポリシーを作成できます。この作業を行うには、サービス プロジェクトのユーザーがホスト プロジェクトで compute.packetMirroringUser のロールが必要です。ホスト プロジェクトのユーザーには、サービス プロジェクトのミラーリング対象ソースに対する compute.packetMirroringAdmin ロールが必要です。

マルチインターフェース VM インスタンス

パケット ミラーリング ポリシーに複数のネットワーク インターフェースを持つ VM インスタンスを定義できます。1 つのポリシーで 1 つのネットワークのリソースをミラーリングするため、インスタンスのすべてのネットワーク インターフェースのトラフィックを 1 つのポリシーでミラーリングすることはできません。別のネットワーク インターフェースをミラーリングする場合、各インターフェースが異なるネットワークに存在するため、インターフェースごとにポリシーを作成する必要があります。

次のステップ