トラフィック フローについて
このページでは、一般的なトラフィック フローで VPC Flow Logs がログを報告する方法について説明します。例については、以下のセクションをご覧ください。
- VM フロー、GKE フロー、ハイブリッド接続フローでは、 Google Cloud 内のフローについて説明しています。また、 Google Cloud と Google Cloud外のリソース間のフローについても説明しています。異なるGoogle Cloud プロジェクト間のフローの例では、VPC Flow Logs がプロジェクト レベルで構成されていることを前提としています。
- 異なるプロジェクトの VPC ネットワーク間のフローでは、VPC Flow Logs が組織レベルで構成されている場合に、クロス プロジェクト フローにアノテーションが付けられる方法について説明しています。
VM フロー
以降のセクションでは、VPC Flow Logs が仮想マシン（VM）インスタンス間のトラフィック フローにアノテーションを付ける方法の例を示します。
同一 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.* src_vpc.* dest_instance.* dest_vpc.* |
| 応答 | 10.50.0.2 | 10.10.0.2 | 5,342 |
src_instance.* src_vpc.* dest_instance.* dest_vpc.* |
| 応答側 VM（10.50.0.2）による報告 | ||||
|---|---|---|---|---|
| リクエスト / 応答 | connection.src_ip | connection.dest_ip | bytes_sent | アノテーション |
| リクエスト | 10.10.0.2 | 10.50.0.2 | 1,224 |
src_instance.* src_vpc.* dest_instance.* dest_vpc.* |
| 応答 | 10.50.0.2 | 10.10.0.2 | 5,342 |
src_instance.* src_vpc.* dest_instance.* 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 |
src_location.* dest_instance.* dest_vpc.* |
共有 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.* |
Private Service Connect を介した VM から VM へのフロー
VPC Flow Logs は、Private Service Connect コンシューマーと公開サービスの間のフローにアノテーションを付けます。次の例では、VPC Flow Logs がコンシューマー VM とプロデューサー VM のログレコードにアノテーションを付ける方法について説明します。
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 のログレコードにアノテーションを付ける方法について説明します。
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.* dest_google_service.* psc.reporter psc.psc_endpoint.* |
| 応答 | 10.10.110.10 | 10.10.0.2 | 5,342 |
src_google_service.* dest_instance.* dest_vpc.* psc.reporter psc.psc_endpoint.* |
Cloud Load Balancing を介した VM フロー
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 | bytes_sent | アノテーション |
| リクエスト | 192.168.1.2 | 10.240.0.200 | 1,224 |
src_instance.* src_vpc.* dest_instance.* dest_vpc.* load_balancing.* （url_map_name を除くすべてのフィールド） |
| 応答 | 10.240.0.200 | 192.168.1.2 | 5,342 |
src_instance.* src_vpc.* dest_instance.* 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 が 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.* |
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.* |
ハイブリッド接続フロー
Cloud Interconnect と Cloud VPN トンネルの VLAN アタッチメントを介したハイブリッド接続の場合、VPC Flow Logs は次のフローにアノテーションを付けます。
- VM インスタンス（GKE ノードとして使用されるインスタンスを含む）とオンプレミス エンドポイント間のフロー
- Google サービスとオンプレミス エンドポイント間のフロー
- オンプレミス エンドポイント間のトランジット フロー
次の例は、VPC Flow Logs が VPC ネットワーク内の VM インスタンスとオンプレミス エンドポイント間のフローにアノテーションを付ける方法を示しています。ネットワークは、Cloud Interconnect の VLAN アタッチメントを介してエンドポイントに接続されます。
VPC ネットワークの VM と内部 IP アドレスを持つオンプレミス エンドポイント間のフローの場合、Google Cloud からのみフローログが報告されます。次のリソースはフローログを報告します。
- VM。VM が接続されているサブネットで VPC Flow Logs が有効になっている場合は、フローログを報告します。
- VPC ネットワークをオンプレミス エンドポイントに接続するゲートウェイ。ゲートウェイ（この例では VLAN アタッチメント）で VPC Flow Logs が有効になっている場合は、フローログを報告します。
上の図では、オンプレミス エンドポイント 10.30.0.2 が VPC ネットワークの VM 10.0.0.2 に 1,224 バイトのリクエストを送信します。次に、VM 10.0.0.2 は 5,243 バイトを含む応答でリクエストに応答します。リクエストと応答の両方が、VLAN アタッチメントと VM の両方から記録されます。
| VLAN アタッチメントで報告される値 | ||||
|---|---|---|---|---|
| リクエスト / 応答 | connection.src_ip | connection.dest_ip | bytes_sent | アノテーション |
| リクエスト | 10.30.0.2 | 10.0.0.2 | 1,224 |
src_gateway.* dest_instance.* dest_vpc.* |
| 応答 | 10.0.0.2 | 10.30.0.2 | 5,342 |
src_instance.* src_vpc.* dest_gateway.* |
| VM（10.0.0.2）による報告 | ||||
|---|---|---|---|---|
| リクエスト / 応答 | connection.src_ip | connection.dest_ip | bytes_sent | アノテーション |
| リクエスト | 10.30.0.2 | 10.0.0.2 | 1,224 |
src_gateway.* dest_instance.* dest_vpc.* |
| 応答 | 10.0.0.2 | 10.30.0.2 | 5,342 |
src_instance.* src_vpc.* dest_gateway.* |
異なるプロジェクトの VPC ネットワーク間のフロー
VPC Flow Logs が組織用に構成され、プロジェクト間のアノテーションが有効になっている場合（デフォルト）、異なるプロジェクトの VPC ネットワーク間のトラフィック フローは、同じプロジェクトの VPC ネットワーク間のトラフィック フローと同じ方法でアノテーションが付けられます。これらのフローのログレコードには、接続の両側に関する情報が提供されます。
プロジェクト間のアノテーションが無効になっている場合、ログレコードにはトラフィック フローのレポート作成者に関する情報のみが記録されます。
プロジェクト間のアノテーションが有効
次の例は、プロジェクト間のアノテーションが有効になっている場合に、VPC Flow Logs がプロジェクト間の VM から VM へのフローのログレコードにアノテーションを付ける方法を示しています。プロジェクト間のアノテーションは、共有 VPC、VPC ネットワーク ピアリング、Network Connectivity Center を介したトラフィック フローで使用できます。
VM 10.0.0.2 が 1,224 バイトのリクエストを VM 10.0.0.1.2 に送信します。次に、VM 10.0.0.1.2 は 5,342 バイトを含む応答でリクエストに応答します。リクエストと応答の両方が、要求側 VM と応答側 VM の両方から記録されます。
| 要求側 VM（10.0.0.2）による報告 | ||||
|---|---|---|---|---|
| リクエスト / 応答 | connection.src_ip | connection.dest_ip | bytes_sent | アノテーション |
| リクエスト | 10.0.0.2 | 10.0.1.2 | 1,224 |
src_instance.* src_vpc.* dest_instance.* dest_vpc.* |
| 応答 | 10.0.1.2 | 10.0.0.2 | 5,342 |
src_instance.* src_vpc.* dest_instance.* dest_vpc.* |
| 応答側 VM（10.0.1.2）による報告 | ||||
|---|---|---|---|---|
| リクエスト / 応答 | connection.src_ip | connection.dest_ip | bytes_sent | アノテーション |
| リクエスト | 10.0.0.2 | 10.0.1.2 | 1,224 |
src_instance.* src_vpc.* dest_instance.* dest_vpc.* |
| 応答 | 10.0.1.2 | 10.0.0.2 | 5,342 |
src_instance.* src_vpc.* dest_instance.* dest_vpc.* |
プロジェクト間のアノテーションが無効
次の例は、プロジェクト間のアノテーションが無効になっている場合に、VPC Flow Logs がプロジェクト間の VM から VM へのフローのログレコードにアノテーションを付ける方法を示しています。
VM 10.0.0.2 が 1,224 バイトのリクエストを VM 10.0.0.1.2 に送信します。次に、VM 10.0.0.1.2 は 5,342 バイトを含む応答でリクエストに応答します。リクエストと応答の両方が、要求側 VM と応答側 VM の両方から記録されます。ただし、他の VM に関する情報は提供されません。
| 要求側 VM（10.0.0.2）による報告 | ||||
|---|---|---|---|---|
| リクエスト / 応答 | connection.src_ip | connection.dest_ip | bytes_sent | アノテーション |
| リクエスト | 10.0.0.2 | 10.0.1.2 | 1,224 |
src_instance.* src_vpc.* |
| 応答 | 10.0.1.2 | 10.0.0.2 | 5,342 |
dest_instance.* dest_vpc.* |
| 応答側 VM（10.0.1.2）による報告 | ||||
|---|---|---|---|---|
| リクエスト / 応答 | connection.src_ip | connection.dest_ip | bytes_sent | アノテーション |
| リクエスト | 10.0.0.2 | 10.0.1.2 | 1,224 |
dest_instance.* dest_vpc.* |
| 応答 | 10.0.1.2 | 10.0.0.2 | 5,342 |
src_instance.* src_vpc.* |