トラフィック フローについて
このページでは、一般的なユースケースで VPC Flow Logs がフローログを報告する方法について説明します。VPC Flow Logs によってサンプリングされたトラフィック フローの例については、次のセクションをご覧ください。
VM フロー
次のセクションでは、VPC Flow Logs が仮想マシン（VM）インスタンスによって送受信されるトラフィックをサンプリングする方法の例を示します。VPC Flow Logs が Google Kubernetes Engine（GKE）Pod のフローログを報告する方法については、GKE フローをご覧ください。
同一 VPC ネットワーク内での VM から VM へのフロー
同じ VPC ネットワーク内の VM から VM へのフローでは、VPC Flow Logs が有効になっているサブネットに両方の VM がある場合、フローログはリクエストとレスポンスの両方の VM から報告されます。この例では、VM 10.10.0.2 が 1,224 バイトのリクエストを、同様にロギングが有効になっているサブネット内にある VM 10.50.0.2 に送信します。次に、10.50.0.2 は 5,342 バイトを含む応答でリクエストに応答します。リクエストと応答の両方が、要求側 VM と応答側 VM の両方から記録されます。
| 要求側 VM（10.10.0.2）による報告 | ||||
|---|---|---|---|---|
| リクエスト / 応答 | connection.src_ip | connection.dest_ip | bytes_sent | アノテーション |
| リクエスト | 10.10.0.2 | 10.50.0.2 | 1,224 |
src_instance.* dest_instance.* src_vpc.* dest_vpc.* |
| 応答 | 10.50.0.2 | 10.10.0.2 | 5,342 |
src_instance.* dest_instance.* src_vpc.* dest_vpc.* |
| 応答側 VM（10.50.0.2）による報告 | ||||
|---|---|---|---|---|
| リクエスト / 応答 | connection.src_ip | connection.dest_ip | バイト | アノテーション |
| リクエスト | 10.10.0.2 | 10.50.0.2 | 1,224 |
src_instance.* dest_instance.* src_vpc.* dest_vpc.* |
| 応答 | 10.50.0.2 | 10.10.0.2 | 5,342 |
src_instance.* dest_instance.* src_vpc.* dest_vpc.* |
VM から外部 IP アドレスへのフロー
VPC ネットワークの VM と外部 IP アドレスを持つエンドポイントの間でインターネットを通過するフローの場合、フローログは、VPC ネットワークの VM からのみ報告されます。
- 下り（外向き）フローの場合、ログはトラフィックの送信元である VPC ネットワーク VM から報告されます。
- 上り（内向き）フローの場合、ログはトラフィックの宛先である VPC ネットワーク VM から報告されます。
この例では、VM 10.10.0.2 は、インターネットを介して、外部 IP アドレス 203.0.113.5 を持つエンドポイントとパケットを交換します。10.10.0.2 から 203.0.113.5 に送信された 1,224 バイトのアウトバウンド トラフィックは、送信元 VM 10.10.0.2 から報告されます。203.0.113.5 から 10.10.0.2 に送信された 5,342 バイトのインバウンド トラフィックは、トラフィックの宛先である VM 10.10.0.2 から報告されます。
| リクエスト / 応答 | connection.src_ip | connection.dest_ip | bytes_sent | アノテーション |
|---|---|---|---|---|
| リクエスト | 10.10.0.2 | 203.0.113.5 | 1,224 |
src_instance.* src_vpc.* dest_location.* internet_routing_details.* |
| 応答 | 203.0.113.5 | 10.10.0.2 | 5,342 |
dest_instance.* dest_vpc.* src_location.* |
共有 VPC での VM から VM へのフロー
共有 VPC での VM から VM へのフローの場合は、ホスト プロジェクトでサブネットに対して VPC Flow Logs を有効にできます。たとえば、サブネット 10.10.0.0/20 が、ホスト プロジェクトで定義されている共有 VPC ネットワークに属しているとします。このサブネットに属する VM のフローログを確認できます（サービス プロジェクトによって作成されたものを含みます）。この例では、サービス プロジェクトは "web server"、"recommendation"、"database" と呼ばれます。
VM から VM へのフローの場合に、両方の VM が同じプロジェクト内にある場合、または共有ネットワーク内にある場合、同じホスト プロジェクトや、プロジェクト ID のアノテーションなどが接続のもう一方のエンドポイントで提供されます。他の VM が別のプロジェクトにある場合、その他の VM のアノテーションは提供されません。
次の表には、10.10.0.10 または 10.10.0.20 で報告されるフローが示されています。
src_vpc.project_idとdest_vpc.project_idは VPC サブネットがホスト プロジェクトに属しているため、ホスト プロジェクト用のものです。src_instance.project_idとdest_instance.project_idはインスタンスがサービス プロジェクトに属しているため、サービス プロジェクト用のものです。
| connection .src_ip |
src_instance .project_id |
src_vpc .project_id |
connection .dest_ip |
dest_instance .project_id |
dest_vpc .project_id |
|---|---|---|---|---|---|
| 10.10.0.10 | web server | host_project | 10.10.0.20 | recommendation | host_project |
サービス プロジェクトは独自の共有 VPC ネットワークを所有していないため、共有 VPC ネットワークのフローログにアクセスできません。
VPC ネットワーク ピアリングでの VM から VM へのフロー
両方の VM が同じ Google Cloud プロジェクトにない場合、ピアリングされた VPC の VM から VM へのフローは外部エンドポイントの場合と同じ方法で報告されます。他の VM に関するプロジェクトとその他のアノテーション情報は提供されません。両方の VM が同じプロジェクトにある場合、異なるネットワーク上にある場合でも、プロジェクトとその他のアノテーション情報は他の VM についても提供されます。
次の例では、プロジェクト analytics-prod の VM 10.10.0.2 およびプロジェクト webserver-test の VM 10.50.0.2 のサブネットが VPC ネットワーク ピアリングで接続されています。VPC フローログがプロジェクト analytics-prod で有効になると、10.10.0.2 から 10.50.0.2 に送信されるトラフィック（1,224 バイト）が、フローの送信元である VM 10.10.0.2 から報告されます。10.50.0.2 から 10.10.0.2 に送信されるトラフィック（5,342 バイト）も、フローの宛先である VM 10.10.0.2 から報告されます。
この例では、VPC Flow Logs はプロジェクト webserver-test で有効になっていないため、VM 10.50.0.2 でログは記録されません。
| reporter | connection.src_ip | connection.dest_ip | bytes_sent | アノテーション |
|---|---|---|---|---|
| ソース | 10.10.0.2 | 10.50.0.2 | 1,224 |
src_instance.* src_vpc.* |
| destination | 10.50.0.2 | 10.10.0.2 | 5,342 |
dest_instance.* dest_vpc.* |
Cloud Load Balancing を使用した VM フロー
Cloud Load Balancing を介したフローの場合、VPC Flow Logs は、パススルー ネットワーク ロードバランサ、プロキシ ネットワーク ロードバランサ、またはアプリケーション ロードバランサを介して送信されたトラフィックにアノテーションを付けます。次の例では、これらのロードバランサが内部ロードバランサとして構成されていることを前提としています。
内部パススルー ネットワーク ロードバランサを介した VM から VM へのフロー
内部パススルー ネットワーク ロードバランサのバックエンド サービスに VM を追加すると、Google Cloud で VM のローカル ルーティング テーブルにロードバランサの IP アドレスが追加されます。これにより、宛先がロードバランサの IP アドレスに設定されたリクエスト パケットを VM が受け入れられるようになります。VM が応答すると、そのレスポンスが直接送信されます。ただし、レスポンス パケットの送信元 IP アドレスは、負荷分散される VM ではなく、ロードバランサの IP アドレスに設定されます。
内部パススルー ネットワーク ロードバランサを介して送信された VM から VM へのフローは、送信元と宛先の両方から報告されます。
| クライアント VM（192.168.1.2）による報告 | ||||
|---|---|---|---|---|
| リクエスト / 応答 | connection.src_ip | connection.dest_ip | bytes_sent | アノテーション |
| リクエスト | 192.168.1.2 | 10.240.0.200 | 1,224 |
src_instance.* src_vpc.* load_balancing.forwarding_rule_project_id load_balancing.reporter load_balancing.type load_balancing.scheme load_balancing.forwarding_rule_name load_balancing.backend_service_name load_balancing.vpc.* |
| 応答 | 10.240.0.200 | 192.168.1.2 | 5,342 |
dest_instance.* dest_vpc.* load_balancing.forwarding_rule_project_id load_balancing.reporter load_balancing.type load_balancing.scheme load_balancing.forwarding_rule_name load_balancing.backend_service_name load_balancing.vpc.* |
| バックエンド VM（10.240.0.3）による報告 | ||||
|---|---|---|---|---|
| リクエスト / 応答 | connection.src_ip | connection.dest_ip | バイト | アノテーション |
| リクエスト | 192.168.1.2 | 10.240.0.200 | 1,224 |
src_instance.* dest_instance.* src_vpc.* dest_vpc.* load_balancing.* （url_map_name を除くすべてのフィールド） |
| 応答 | 10.240.0.200 | 192.168.1.2 | 5,342 |
src_instance.* dest_instance.* src_vpc.* dest_vpc.* load_balancing.* （url_map_name を除くすべてのフィールド） |
ロードバランサがバックエンド VM に分散するリクエストでは、送信元 IP アドレスがクライアント VM の IP アドレスに設定されます。つまり、バックエンド VM はクライアント VM に関する src_instance と dest_instance の情報を指定できます。ただし、バックエンド VM とは異なり、クライアント VM はバックエンド VM に関する src_instance 情報と dest_instance 情報をレポートに追加できません。これは、クライアント VM はバックエンド VM ではなくロードバランサの IP アドレスにリクエストを送信し、ロードバランサの IP アドレスから応答を受信するためです。
VM から内部プロキシ ネットワーク ロードバランサへのフロー、VM から内部アプリケーション ロードバランサへのフロー
内部プロキシ ネットワーク ロードバランサまたは内部アプリケーション ロードバランサを通過するトラフィック フローは、クライアント VM が VPC Flow Logs が有効になっているサブネット内にある限り、クライアント VM によって報告されます。たとえば、IP アドレスが 10.10.0.2 のクライアント VM が、1,224 バイトのリクエストをロードバランサ エンドポイント 10.10.0.3 に送信したとします。このリクエストはバックエンドに到達します。次に、バックエンドは 5,342 バイトを含む応答でリクエストに応答します。リクエストと応答の両方がクライアント VM に記録されます。クライアント VM のログは、VM が属する Google Cloud プロジェクトで使用できます。
| クライアント VM（10.10.0.2）による報告 | ||||
|---|---|---|---|---|
| リクエスト / 応答 | connection.src_ip | connection.dest_ip | bytes_sent | アノテーション |
| リクエスト | 10.10.0.2 | 10.10.0.3 | 1,224 |
src_instance.* src_vpc.* load_balancing.forwarding_rule_project_id load_balancing.reporter load_balancing.type load_balancing.scheme load_balancing.url_map_name（アプリケーション ロードバランサの場合） load_balancing.forwarding_rule_name load_balancing.vpc.* |
| 応答 | 10.10.0.3 | 10.10.0.2 | 5,342 |
dest_instance.* dest_vpc.* load_balancing.forwarding_rule_project_id load_balancing.reporter load_balancing.type load_balancing.scheme load_balancing.url_map_name（アプリケーション ロードバランサの場合） load_balancing.forwarding_rule_name load_balancing.vpc.* |
Private Service Connect を介した VM から VM へのフロー
Private Service Connect を介した VM 間のトラフィックの場合、VPC Flow Logs は Private Service Connect コンシューマーと公開サービスの間のフローをサンプリングします。
公開サービスへの Private Service Connect エンドポイント
Private Service Connect 公開サービスへのトラフィック フローは、コンシューマー VM とプロデューサー VM の両方が VPC Flow Logs が有効になっているサブネットにある限り、この両方から報告されます。この例では、コンシューマー VM 10.10.0.2 が 1,224 バイトのリクエストを Private Service Connect エンドポイント 10.10.0.3 に送信します。プロデューサー VPC では、リクエストの送信元 IP アドレスがサービス アタッチメント サブネットの IP アドレスに変換されます。この例では 10.40.0.2 です。リクエストの宛先 IP アドレスは、内部パススルー ネットワーク ロードバランサの IP アドレス 10.50.0.3 に変換されます。リクエストはバックエンド VM 10.50.0.2 に到達します。この VM は、ロギングが有効になっているサブネット内にもあります。次に、10.50.0.2 は 5,342 バイトを含む応答でリクエストに応答します。リクエストと応答の両方が、要求側 VM と応答側 VM の両方から記録されます。コンシューマー VM のログはコンシューマー プロジェクトで使用でき、プロデューサー VM のログはプロデューサー プロジェクトで使用できます。
| コンシューマー VM（10.10.0.2）による報告 | ||||
|---|---|---|---|---|
| リクエスト / 応答 | connection.src_ip | connection.dest_ip | bytes_sent | アノテーション |
| リクエスト | 10.10.0.2 | 10.10.0.3 | 1,224 |
src_instance.* src_vpc.* psc.reporter psc.psc_endpoint.* psc.psc_attachment.* |
| 応答 | 10.10.0.3 | 10.10.0.2 | 5,342 |
dest_instance.* dest_vpc.* psc.reporter psc.psc_endpoint.* psc.psc_attachment.* |
| プロデューサー VM（10.50.0.2）による報告 | ||||
|---|---|---|---|---|
| リクエスト / 応答 | connection.src_ip | connection.dest_ip | bytes_sent | アノテーション |
| リクエスト | 10.40.0.2 | 10.50.0.3 | 1,224 |
dest_instance.* dest_vpc.* psc.reporter psc.psc_attachment.* |
| 応答 | 10.50.0.3 | 10.40.0.2 | 5,342 |
src_instance.* src_vpc.* psc.reporter psc.psc_attachment.* |
VM から Google API へのフロー
VM の外部 IP アドレス、限定公開の Google アクセス、または Private Service Connect エンドポイントを経由して Google API に送信される VM トラフィックの場合、VPC Flow Logs はログレコードに Google API 情報のアノテーションを付けます。次のセクションでは、VPC Flow Logs が Private Service Connect エンドポイントを介してグローバル Google API にアクセスする VM のログレコードにアノテーションを付ける方法の例を示します。
Private Service Connect を介したグローバル Google API への VM フロー
Google API へのトラフィック フローは、VPC Flow Logs が有効になっているサブネット内に VM がある限り、コンシューマー VM によって報告されます。この例では、コンシューマー VM 10.10.0.2 が 1,224 バイトのリクエストを Private Service Connect エンドポイント 10.10.110.10 に送信します。このリクエストは、Cloud Storage などの適切な Google サービスに転送されます。次に、Cloud Storage は 5,342 バイトを含む応答でリクエストに応答します。リクエストと応答の両方が、要求側 VM から記録されます。
| コンシューマー VM（10.10.0.2）による報告 | ||||
|---|---|---|---|---|
| リクエスト / 応答 | connection.src_ip | connection.dest_ip | bytes_sent | アノテーション |
| リクエスト | 10.10.0.2 | 10.10.110.10 | 1,224 |
src_instance.* src_vpc.* psc.reporter psc.psc_endpoint.* dest_google_service.* |
| 応答 | 10.10.110.10 | 10.10.0.2 | 5,342 |
src_google_service.* dest_instance.* dest_vpc.* psc.reporter psc.psc_endpoint.* |
GKE フロー
以降のセクションでは、VPC Flow Logs が Pod との間の GKE トラフィックをサンプリングする方法の例を示します。
Pod から ClusterIP へのフロー
この例では、トラフィックはクライアント Pod（10.4.0.2）から cluster-service（10.0.32.2:80）に送信されます。宛先は、ターゲット ポート（8080）で選択したサーバー Pod IP アドレス（10.4.0.3）に解決されます。
ノードエッジでは、変換された IP アドレスとポートを使用してフローが 2 回サンプリングされます。どちらのサンプリング ポイントでも、宛先 Pod がポート 8080 でサービス cluster-service をバックアップしていることを特定し、Service の詳細と Pod の詳細を記録します。トラフィックが同じノード上の Pod にルーティングされた場合、トラフィックはノードから離れず、サンプリングは行われません。
この例では、次のレコードが確認できます。
| reporter | connection.src_ip | connection.dst_ip | bytes_sent | アノテーション |
|---|---|---|---|---|
| SRC | 10.4.0.2 | 10.4.0.3 | 1,224 | src_instance.* src_vpc.* src_gke_details.cluster.* src_gke_details.pod.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.* |
| DEST | 10.4.0.2 | 10.4.0.3 | 1,224 | src_instance.* src_vpc.* src_gke_details.cluster.* src_gke_details.pod.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.* |
GKE 外部 LoadBalancer のフロー
外部 IP アドレスから GKE サービス（35.35.35.35）へのトラフィックは、クラスタ内のノード（この例では 10.0.12.2）にルーティングされます。デフォルトでは、外部パススルー ネットワーク ロードバランサは、ノードが関連する Pod を実行していない場合でも、クラスタ内のすべてのノード間でトラフィックを分散します。トラフィックは、関連する Pod に到達するまでに追加のホップが必要になる場合があります。詳細については、クラスタ外のネットワーキングをご覧ください。
その後、トラフィックはノード（10.0.12.2）から選択したサーバー Pod（10.4.0.2）にルーティングされます。すべてのノードエッジがサンプリングされるため、両方のホップがログに記録されます。トラフィックが同じノード（この例では 10.4.0.3）上の Pod にルーティングされた場合、2 番目のホップはノードから離れないため、ログに記録されません。2 番目のホップは両方のノードのサンプリング ポイントによって記録されます。最初のホップでは、ロードバランサの IP とサービスポート（80）に基づいてサービスを識別します。2 番目のホップでは、宛先 Pod がターゲット ポート（8080）で Service をバックアップしています。
この例では、次のレコードが確認できます。
| reporter | connection.src_ip | connection.dst_ip | bytes_sent | アノテーション |
|---|---|---|---|---|
| DEST | 203.0.113.1 | 35.35.35.35 | 1,224 | src_location.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.service.* |
| SRC | 10.0.12.2 | 10.4.0.2 | 1,224 | src_instance.* src_vpc.* src_gke_details.cluster.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.* |
| DEST | 10.0.12.2 | 10.4.0.2 | 1,224 | src_instance.* src_vpc.* src_gke_details.cluster.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.* |
GKE Ingress フロー
外部 IP アドレスから Ingress 宛先への接続は、Cloud Load Balancing サービスで終了します。接続は URL に従って NodePort Service にマッピングされます。リクエストを処理するために、ロードバランサ（130.211.0.1）はクラスタノード（10.0.12.2）のいずれかに接続し、サービスの NodePort を使用してルーティングを行います。デフォルトでは、Ingress オブジェクトを作成すると、GKE Ingress コントローラにより HTTP(S) ロードバランサが構成されます。このロードバランサは、関連する Pod を実行していない場合でも、クラスタ内のすべてのノードにトラフィックを分散します。トラフィックは、関連する Pod に到達するまでに追加のホップが必要になる場合があります。詳細については、クラスタ外のネットワーキングをご覧ください。その後、トラフィックはノード（10.0.12.2）から選択したサーバー Pod（10.4.0.2）にルーティングされます。
すべてのノードエッジがサンプリングされるため、両方のホップがログに記録されます。最初のホップでは、Service の NodePort（60000）に基づいて Service を識別します。2 番目のホップでは、宛先 Pod がターゲット ポート（8080）で Service をサポートしていることを特定します。2 番目のホップは、両方のノードのサンプリング ポイントによって記録されます。ただし、トラフィックが同じノード（10.4.0.3）の Pod にルーティングされた場合、トラフィックがノードから離れていないため、2 番目のホップはログに記録されません。
この例では、次のレコードが確認できます。
| reporter | connection.src_ip | connection.dst_ip | bytes_sent | アノテーション |
|---|---|---|---|---|
| DEST | 130.211.0.1 | 10.0.12.2 | 1,224 | dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.service.* |
| SRC | 10.0.12.2 | 10.4.0.2 | 1,224 | src_instance.* src_vpc.* src_gke_details.cluster.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.* |
| DEST | 10.0.12.2 | 10.4.0.2 | 1,224 | src_instance.* src_vpc.* src_gke_details.cluster.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.* |
コンテナ ネイティブのロード バランシングを使用した GKE Ingress フロー
外部 IP アドレスからコンテナ ネイティブのロード バランシングを使用している Ingress 宛先へのリクエストは、ロードバランサで終了します。このタイプの Ingress では、Pod はロード バランシングのコア オブジェクトです。次に、ロードバランサ（130.211.0.1）から選択した Pod（10.4.0.2）に直接リクエストが送信されます。宛先 Pod がターゲット ポート（8080）でサービスをバックアップすることを識別します。
この例では、次のレコードが確認できます。
| reporter | connection.src_ip | connection.dst_ip | bytes_sent | アノテーション |
|---|---|---|---|---|
| DEST | 130.211.0.1 | 10.4.0.2 | 1,224 | dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.* |
Pod から外部へのフロー
Pod（10.4.0.3）から外部 IP（203.0.113.1）へのトラフィックは、Pod IP アドレスではなくノード IP（10.0.12.2）から送信されるように IP マスカレードによって変更されます。GKE クラスタは、デフォルトで外部の宛先にトラフィックをマスカレードするように構成されます。詳細については、IP マスカレード エージェントをご覧ください。
このトラフィックの Pod アノテーションを表示するには、Pod IP アドレスをマスカレードしないようにマスカレード エージェントを構成します。このような場合、インターネットへのトラフィックを許可するために、Pod IP アドレスを処理する Cloud NAT を構成できます。Cloud NAT と GKE の詳細については、GKE の操作をご覧ください。
この例では、次のレコードが確認できます。
| reporter | connection.src_ip | connection.dst_ip | bytes_sent | アノテーション |
|---|---|---|---|---|
| SRC | 10.0.12.2 | 203.0.113.1 | 1,224 |
src_instance.* src_vpc.* src_gke_details.cluster.* dest_location.* internet_routing_details.* |
ハイブリッド接続フロー
Google Cloud とオンプレミス ネットワーク間のトラフィックの場合、VPC Flow Logs は、VM インスタンス（GKE ノードとして使用されるインスタンスを含む）とオンプレミス エンドポイント間のフロー、Google API とオンプレミス エンドポイント間のフロー、オンプレミス エンドポイント間のトランジット トラフィックにアノテーションを付けます。次の例は、VPC Flow Logs が VPC ネットワーク内の VM インスタンスとオンプレミス エンドポイント間のフローにアノテーションを付ける方法を示しています。
VPC ネットワークの VM と内部 IP アドレスを持つオンプレミス エンドポイント間のフローの場合、Google Cloud からのみフローログが報告されます。次のリソースはフローログを報告します。
- VM。VM が接続されているサブネットで VPC Flow Logs が有効になっている場合は、フローログを報告します。
- VPC ネットワークをオンプレミス エンドポイントに接続するゲートウェイ。ゲートウェイで VPC Flow Logs が有効になっている場合は、フローログを報告します。
上の図では、オンプレミス エンドポイント 10.30.0.2 が Cloud Interconnect を介して VPC ネットワークの VM 10.0.0.2 に 1,224 バイトのリクエストを送信します。次に、VM 10.0.0.2 は 5,243 バイトを含む応答でリクエストに応答します。リクエストと応答の両方が、Cloud Interconnect の VLAN アタッチメントと VM の両方から記録されます。
| VLAN アタッチメントで報告される値 | ||||
|---|---|---|---|---|
| リクエスト / 応答 | connection.src_ip | connection.dest_ip | bytes_sent | アノテーション |
| リクエスト | 10.30.0.2 | 10.10.0.2 | 1,224 |
reporter src_gateway.* dest_instance.* dest_vpc.* |
| 応答 | 10.10.0.2 | 10.30.0.2 | 5,342 |
reporter src_instance.* src_vpc.* dest_gateway.* |
| VM（10.10.0.2）による報告 | ||||
|---|---|---|---|---|
| リクエスト / 応答 | connection.src_ip | connection.dest_ip | bytes_sent | アノテーション |
| リクエスト | 10.30.0.2 | 10.10.0.2 | 1,224 |
reporter src_gateway.* dest_instance.* dest_vpc.* |
| 応答 | 10.10.0.2 | 10.30.0.2 | 5,342 |
reporter src_instance.* src_vpc.* dest_gateway.* |