トラフィック フローについて
このページでは、一般的なユースケースで VPC フローログがフローログを報告する方法について説明します。VPC フローログによってサンプリングされたトラフィック フローの例については、次のセクションをご覧ください。
同一 VPC ネットワーク内での VM から VM へのフロー
同じ VPC 内の VM から VM へのフローでは、VPC フローログが有効になっているサブネットに両方の 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.* |
| reply | 203.0.113.5 | 10.10.0.2 | 5,342 |
dest_instance.* dest_vpc.* src_location.* |
VM からオンプレミスへのフロー
VPC ネットワークの VM と内部 IP アドレスを持つオンプレミス エンドポイント間のフローの場合、VPC ネットワークの VM からのみフローログが報告されます。
- 下り（外向き）フローの場合、ログはトラフィックの送信元である VPC ネットワーク VM から報告されます。
- 上り（内向き）フローの場合、ログはトラフィックの宛先である VPC ネットワーク VM から報告されます。
次の例では、VM 10.10.0.2 とオンプレミス エンドポイント 10.30.0.2 は、VPN ゲートウェイまたは Cloud Interconnect を介して接続されています。10.10.0.2 から 10.30.0.2 に送信された 1,224 バイトのアウトバウンド トラフィックは、送信元 VM 10.10.0.2 から報告されます。10.30.0.2 から 10.10.0.2 に送信された 5,342 バイトのインバウンド トラフィックは、トラフィックの宛先である VM 10.10.0.2 から報告されます。
| リクエスト / 応答 | connection.src_ip | connection.dest_ip | bytes_sent | アノテーション |
|---|---|---|---|---|
| リクエスト | 10.10.0.2 | 10.30.0.2 | 1,224 |
src_instance.* src_vpc.* |
| 応答 | 10.30.0.2 | 10.10.0.2 | 5,342 |
dest_instance.* dest_vpc.* |
共有 VPC での VM から VM へのフロー
共有 VPC での VM から VM へのフローの場合は、ホスト プロジェクトでサブネットに対して VPC フローログを有効にできます。たとえば、サブネット 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 フローログはプロジェクト 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.* |
内部パススルー ネットワーク ロードバランサでの VM から VM へのフロー
内部パススルー ネットワーク ロードバランサのバックエンド サービスに VM を追加すると、Linux または Windows のゲスト環境で VM のローカル ルーティング テーブルにロードバランサの IP アドレスが追加されます。これにより、宛先がロードバランサの IP アドレスに設定されたリクエスト パケットを VM が受け入れられるようになります。VM が応答すると、そのレスポンスが直接送信されます。ただし、レスポンス パケットの送信元 IP アドレスは、ロードバランスされる VM ではなく、ロードバランサの IP アドレスに設定されます。
内部パススルー ネットワーク ロードバランサを介して送信された VM から VM へのフローは、送信元と宛先の両方から報告されます。HTTP リクエスト / レスポンスのペアの例について、監視されたフローログのエントリに使用されるフィールドを以下の表で説明します。これを示すために、以下のネットワーク構成を想定します。
- ブラウザ インスタンス（192.168.1.2）
- 内部パススルー ネットワーク ロードバランサ（10.240.0.200）
- ウェブサーバー インスタンス（10.240.0.3）
| トラフィックの方向 | reporter | connection.src_ip | connection.dest_ip | connection.src_instance | connection.dest_instance |
|---|---|---|---|---|---|
| リクエスト | SRC | 192.168.1.2 | 10.240.0.200 | ブラウザ インスタンス | |
| リクエスト | DEST | 192.168.1.2 | 10.240.0.200 | ブラウザ インスタンス | ウェブサーバー インスタンス |
| レスポンス | SRC | 10.240.0.3 | 192.168.1.2 | ウェブサーバー インスタンス | ブラウザ インスタンス |
| レスポンス | DEST | 10.240.0.200 | 192.168.1.2 | ブラウザ インスタンス |
要求側 VM は、どの VM がリクエストに応答するのかを認識しません。また、相手側 VM は送信元アドレスとして内部ロードバランサの IP を使用してレスポンスを送信するため、どの VM が応答したかも認識しません。このため、要求側 VM は dest_instance 情報をレポートに追加できず、src_instance 情報のみを追加できます。レスポンス側 VM はリクエスト側 VM の IP アドレスを認識しているため、src_instance と dest_instance の両方の情報を提供できます。
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 宛先への接続は、ロードバランサ サービスで終了します。接続は URL に従って NodePort Service にマッピングされます。リクエストを処理するために、ロードバランサ（130.211.0.1）はクラスタノード（10.0.12.2）のいずれかに接続し、Service の 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.* |