VPC フローログ
VPC フローログの概要には、VM インスタンスによって送受信されたネットワーク フローのサンプルが記録されます。これには Google Kubernetes Engine ノードとして使用されるインスタンスも含まれます。これらのログは、ネットワーク モニタリング、フォレンジック、リアルタイム セキュリティ分析、および費用の最適化に使用できます。
フローログは Cloud Logging で表示でき、Cloud Logging のエクスポート先としてサポートされている任意の宛先にエクスポートできます。
フローログは、Compute Engine VM からの接続ごとに集計され、リアルタイムでエクスポートされます。Pub/Sub に登録すると、リアルタイム ストリーミングの API を使用してフローログを分析できます。
基本特性
- VPC フローログは、VPC ネットワークを強化するソフトウェアである Andromeda の一部です。VPC フローログが有効になると、遅延やパフォーマンスの低下は発生しません。
- VPC フローログは、レガシー ネットワークではなく、VPC ネットワークで機能します。サブネットごとに VPC フローログを有効または無効にできます。サブネットに対して有効になっている場合、VPC フローログはそのサブネット内のすべての VM インスタンスからデータを収集します。
- VPC フローログは、各 VM の TCP、UDP、ICMP、ESP、GRE フローをサンプリングします。受信フローと送信フローの両方がサンプリングされます。これらのフローは、VM と別の VM、オンプレミス データセンターのホスト、Google サービス、またはインターネット上のホストの間で行うことができます。フローがサンプリングによってキャプチャされると、VPC フローログがフロー用のログを生成します。各フローレコードには、レコードの形式セクションで説明されている情報が含まれます。
- VPC フローログは、次の方法でファイアウォール ルールとやり取りします。
- 下り（外向き）のパケットは、下り（外向き） ファイアウォール ルールの前にサンプリングされます。下り（外向き）ファイアウォール ルールによって送信パケットが拒否されていても、これらのパケットは VPC フローログでサンプリングできます。
- 上り（内向き）パケットは、上り（内向き）ファイアウォールルールの後にサンプリングされます。上り（内向き）ファイアウォール ルールによって受信パケットが拒否された場合、それらのパケットは VPC フローログでサンプリングされません。
- VPC フローログのフィルタを使用して、特定のログのみを生成できます。
- VPC フローログは、複数のネットワーク インターフェースを持つ VM をサポートします。ネットワーク インターフェースを含む各 VPC のサブネットごとに VPC フローログを有効にする必要があります。
- 同じ Google Kubernetes Engine（GKE）ノード上の Pod 間のフローをログに記録するには、クラスタのノード内の可視化を有効にする必要があります。
ユースケース
ネットワーク モニタリング
VPC フローログを使用すると、ネットワークのスループットとパフォーマンスをリアルタイムで把握できます。以下を実現できます。
- VPC ネットワークをモニタリングする
- ネットワーク診断を実行する
- VM とアプリケーションによりフローログをフィルタ処理して、トラフィックの変化を理解する
- トラフィックの増加を把握し、キャパシティの予測に役立てる
ネットワーク使用方法の理解とネットワーク トラフィック費用の最適化
VPC フローログを使用すると、ネットワーク使用量を分析できます。ネットワーク フローを分析して次のことを把握できます。
- リージョンとゾーンの間のトラフィック
- インターネットでの特定の国へのトラフィック
- トラフィック使用量が特に多いプロセス
分析を基にして、ネットワーク トラフィックの費用を最適化できます。
ネットワーク フォレンジック
VPC フローログをネットワーク フォレンジックに利用できます。たとえば、インシデントが発生した場合、以下を調べることができます。
- どの IP が、いつ、どの相手と情報をやり取りしたか
- 不正使用された IP（すべての受信と送信のネットワーク フローを分析して調査）
リアルタイムのセキュリティ分析
リアルタイム ストリーミングの API を（Pub/Sub 経由で）利用し、SIEM（Security Information and Event Management）システムと統合できます。これにより、リアルタイムのモニタリング、イベントの相関、分析、およびセキュリティ アラートを提供できます。
ログの収集
フローログは、各 VM 接続ごとに特定の間隔で収集されます。特定の接続について特定の間隔で収集されたすべてのパケットは、一定期間（一定集計間隔で）単一のフローログ エントリに集計されます。このデータは Logging に送信されます。
ログはデフォルトで 30 日間 Logging に保存されます。それより長く保持するには、カスタム保持期間を設定するか、サポートされている保存先にログをエクスポートします。
ログのサンプリングと処理
Google Cloud は、VM で送受信されたパケットをサンプリングして、フローログを生成します。すべてのパケットが独自のログレコードに収集されるとは限りません。30 パケットごとに約 1 パケットがキャプチャされますが、このサンプリング レートは VM の負荷に応じて低くなることもあります。このレートは調整できません。
Google Cloud で生成されたフローログは、次の手順で処理されます。
- フィルタリング: 指定した条件に一致するログのみを生成するように指定できます。たとえば、特定の VM のログのみ、または特定のメタデータ値を持つログのみが生成され、残りは破棄されるようにフィルタリングできます。詳細については、ログのフィルタリングをご覧ください。
- 集計: サンプリングされたパケットの情報が、ユーザーが構成可能な集計間隔で集計され、フローログ エントリが生成されます。
- フローログのサンプリング: これは 2 番目のサンプリング処理です。ユーザーが構成可能なサンプルレートのパラメータに従って、フローログのエントリがさらにサンプリングされます。
- メタデータ: 無効にすると、すべてのメタデータ アノテーションが破棄されます。メタデータを保持する場合は、すべてのフィールドまたは指定したフィールド セットが保持されるように指定できます。詳細については、メタデータのアノテーションをご覧ください。
- Logging への書き込み: 最終的なログエントリが Cloud Logging に書き込まれます。
VPC フローログはすべてのパケットをキャプチャするわけではないため、キャプチャされたパケットから補完することで、欠落したパケットを補います。これは、初期構成とユーザーが構成可能なサンプリング設定が原因でパケットが欠落している場合に起こります。
Google Cloud ではすべてのパケットをキャプチャしませんが、ログレコードのキャプチャは非常に大きくなる可能性があります。ログ収集の以下の設定を調整すると、トラフィックの可視性と必要なストレージ費用のバランスをとることができます。
- 集計間隔: 一定の時間間隔でサンプリングされたパケットは、単一のログエントリに集計されます。この時間間隔は、5 秒（デフォルト）、30 秒、1 分、5 分、10 分、15 分から選択できます。
- サンプルレート: Logging に書き込まれる前に、ログの数をサンプリングして数を減らすことができます。デフォルトでは、ログエントリのボリュームが 0.5（50%）に縮小されます。つまり、エントリの半分が保持されます。このサンプルレートは
1.0（100%、すべてのログエントリを保持）から0.0（0%、ログを保持しない）の範囲で設定できます。 - メタデータ アノテーション: デフォルトでは、フローログ エントリには、送信元と宛先の VM の名前や、外部の送信元と宛先の地理的リージョンなどのメタデータ情報でアノテーションが付きます。メタデータ アノテーションをオフにすることも、特定のアノテーションのみを指定して保存容量を節約することもできます。
- フィルタリング: デフォルトでは、ログはサブネット内のすべてのフローに対して生成されます。特定の条件に一致するログのみを生成するように、フィルタを設定できます。
メタデータ アノテーション
ログレコードには、基本フィールドとメタデータ フィールドが含まれます。レコード形式セクションには、フィールドの種類（メタデータか基本か）が記載されています。すべての基本フィールドが常に含まれます。保持するメタデータ フィールドはカスタマイズできます。
すべてのメタデータを選択すると、VPC フローログ レコード内のすべてのメタデータ フィールドがフローログに含まれます。新しいメタデータ フィールドがレコード形式に追加されると、フローログに新しいフィールドが自動的に含まれます。
メタデータを選択しない場合は、すべてのメタデータ フィールドが省略されます。
カスタム メタデータを選択した場合、親フィールド（
src_vpcなど）または完全名（src_vpc.project_idなど）を使用して、含めるメタデータ フィールドを指定できます。新しいメタデータ フィールドがレコード形式に追加された場合、これらのフィールドが指定した親フィールド内の新しいフィールドである場合を除き、これらのフィールドはフローログに含まれません。
親フィールドを使用してカスタム メタデータを指定した場合、その親フィールド内のレコード形式に新しいメタデータ フィールドが追加されると、フローログには新しいフィールドが自動的に含まれます。
フィールドの完全名を使用してカスタム メタデータを指定した場合、新しいメタデータ フィールドが親フィールドに追加されたときに、新しいフィールドはフローログに含まれません。
メタデータ フィールドのカスタマイズについては、サブネットの作成時に VPC フローロギングを有効にするで gcloud CLI または API の手順をご覧ください。
GKE アノテーション
GKE クラスタにエンドポイントがあるフローには、そのエンドポイントのクラスタ、Pod、Service の詳細を含む GKE アノテーションを付けることができます。
GKE Service アノテーション
ClusterIP、NodePort、LoadBalancer に送信されたトラフィックは、Service アノテーションを取得できます。NodePort または LoadBalancer に送信された場合、フローは接続の両方のホップで Service アノテーションを受け取ります。
Pod の Service ポートに直接送信されたトラフィックには、宛先エンドポイントの Service アノテーションでアノテーションが付けられます。
Pod が同じ Service ポートで複数の Service をサポートしている場合、Pod のサービスポートに送信されるトラフィックには、宛先エンドポイントで複数の Service がアノテーションされます。これは 2 つの Service に限定されます。それ以上ある場合は、エンドポイントに特別な MANY_SERVICES マーカーが付けられます。
インターネット トラフィックでの Pod アノテーション
Pod とインターネット間のトラフィックは、デフォルトでは Pod アノテーションを受信しません。インターネットへのパケットの場合、マスカレード エージェントが Pod の IP アドレスをノード IP アドレスに変換してから VPC フローログがパケットを認識します。このため、VPC フローログは Pod に関する情報がないため Pod アノテーションを追加できません。
マスカレードのため、リンク先がデフォルトの非マスカレードの宛先またはカスタム nonMasqueradeCIDRs リスト内にある場合にのみ、Pod アノテーションが表示されます。インターネットの宛先をカスタム nonMasqueradeCIDRs リストに含める場合は、インターネットに到達する前に内部 Pod IP アドレスが変換されるようにする必要があります。Cloud NAT は限定公開クラスタと非プライベート クラスタの両方で使用できます。詳細については、GKE の操作をご覧ください。
レコードの形式
ログレコードには、各ログレコードのコアフィールドであるベース フィールドと、詳細情報を追加するメタデータ フィールドが含まれています。メタデータ フィールドは、ストレージ費用を節約するために省略できます。
一部のログフィールドはマルチ フィールド形式であり、所定のフィールドに複数のデータが含まれます。たとえば、connection フィールドは IpConnection 形式で、送信元と宛先の IP アドレスとポート、およびプロトコルが 1 つのフィールドに格納されます。これらのマルチフィールドのフィールドについては、レコードの形式に関する表を示した後で説明します。
| フィールド | フィールドの形式 | フィールド タイプ: 基本またはオプションのメタデータ |
|---|---|---|
| connection |
IpConnection
この接続に関する説明を含む 5 つのタプル。 |
ベース |
| reporter |
string
フローを報告した側。 SRC か DEST のいずれかになります。 |
ベース |
| rtt_msec |
int64
時間間隔中に測定されたレイテンシ。TCP フローに対してのみ測定されます。測定されたレイテンシは、SEQ を送信してから対応する ACK を受信するまでの経過時間です。レイテンシの結果は、ネットワーク RTT とアプリケーションが消費した時間の合計です。 |
ベース |
| bytes_sent |
int64
送信元から宛先に送信されるバイト数 |
ベース |
| packets_sent |
int64
送信元から宛先に送信されるパケット数 |
ベース |
| start_time |
string
集計対象である時間間隔で最初に観測されるパケットのタイムスタンプ（RFC 3339 の日付文字列形式）。 |
ベース |
| end_time |
string
集計対象である時間間隔で最後に観測されるパケットのタイムスタンプ（RFC 3339 の日付文字列形式）。 |
ベース |
| src_gke_details |
GkeDetails
送信元のエンドポイントの GKE メタデータ。エンドポイントが GKE の場合にのみ使用できます。 |
メタデータ |
| dest_gke_details |
GkeDetails
宛先エンドポイントの GKE メタデータ。エンドポイントが GKE の場合にのみ使用できます。 |
メタデータ |
| src_instance |
InstanceDetails
接続の送信元が同じ VPC 上の VM である場合、このフィールドには VM インスタンスの詳細が入力されます。共有 VPC 構成の場合、 project_id はインスタンスを所有するプロジェクト（通常はサービス プロジェクト）に対応します。 |
メタデータ |
| dest_instance |
InstanceDetails
接続の宛先が同じ VPC 上の VM である場合、このフィールドには VM インスタンスの詳細が入力されます。共有 VPC 構成の場合、 project_id はインスタンスを所有するプロジェクト（通常はサービス プロジェクト）に対応します。 |
メタデータ |
| src_location |
GeographicDetails
接続の参照元が VPC の外部にある場合、このフィールドには使用可能な場所のメタデータが入力されます。 |
メタデータ |
| dest_location |
GeographicDetails
接続の宛先が VPC の外部にある場合、このフィールドには使用可能な場所のメタデータが入力されます。 |
メタデータ |
| src_vpc |
VpcDetails
接続の参照元が同じ VPC 上の VM である場合、このフィールドには VPC ネットワークの詳細が入力されます。共有 VPC 構成の場合、 project_id はホスト プロジェクトの詳細に対応します。 |
メタデータ |
| dest_vpc |
VpcDetails
接続の宛先が同じ VPC 上の VM である場合、このフィールドには VPC ネットワークの詳細が入力されます。共有 VPC 構成の場合、 project_id はホスト プロジェクトの詳細に対応します。 |
メタデータ |
IpConnection フィールドの形式
| フィールド | タイプ | 説明 |
|---|---|---|
| protocol | int32 | IANA プロトコル番号 |
| src_ip | 文字列 | 送信元 IP アドレス |
| dest_ip | 文字列 | 宛先 IP アドレス |
| src_port | int32 | 送信元ポート |
| dest_port | int32 | 宛先ポート |
GkeDetails フィールドの形式
| フィールド | タイプ | 説明 |
|---|---|---|
| クラスタ | ClusterDetails | GKE クラスタ メタデータ |
| Pod | PodDetails | トラフィックの送信元または宛先が Pod である場合に入力される GKE Pod のメタデータ。 |
| サービス | ServiceDetails |
Service エンドポイントにのみ入力される GKE Service メタデータ。レコードには最大 2 つの Service が含まれます。関連する Service が 3 つ以上ある場合、このフィールドには特別な MANY_SERVICES マーカーを持つ 1 つの Service が含まれます。 |
ClusterDetails フィールドの形式
| フィールド | タイプ | 説明 |
|---|---|---|
| cluster_location | 文字列 | クラスタのロケーション。ゾーンクラスタかリージョン クラスタかに応じて、ゾーンまたはリージョンになります。 |
| cluster_name | 文字列 | GKE クラスタ名。 |
PodDetails フィールドの形式
| フィールド | タイプ | 説明 |
|---|---|---|
| pod_name | 文字列 | Pod の名前 |
| pod_namespace | 文字列 | Pod の Namespace |
ServiceDetails フィールドの形式
| フィールド | タイプ | 説明 |
|---|---|---|
| service_name | 文字列 |
Service の名前。関連する Service が 3 つ以上ある場合、フィールドは特別な MANY_SERVICES マーカーに設定されます。 |
| service_namespace | 文字列 | Service の名前空間。 |
例:
2 つのサービスがある場合、[Service] フィールドは次のようになります。
service: [
0: {
service_name: "my-lb-service"
service_namespace: "default"
}
1: {
service_name: "my-lb-service2"
service_namespace: "default"
}
]
3 つ以上のサービスがある場合、[Service] フィールドは次のようになります。
service: [
0: {
service_name: "MANY_SERVICES"
}
]
InstanceDetails フィールドの形式
| フィールド | タイプ | 説明 |
|---|---|---|
| project_id | 文字列 | VM を含むプロジェクトの ID |
| region | 文字列 | VM のリージョン |
| vm_name | 文字列 | VM のインスタンス名 |
| zone | 文字列 | VM のゾーン |
GeographicDetails フィールドの形式
| フィールド | タイプ | 説明 |
|---|---|---|
| asn | int32 | このエンドポイントが属する外部ネットワークの自律システム番号（ASN） |
| city | 文字列 | 外部エンドポイントの都市 |
| continent | 文字列 | 外部エンドポイントの大陸 |
| country | 文字列 | 外部エンドポイントの国で、ISO 3166-1 Alpha-3 の国コードにより表されます。 |
| region | 文字列 | 外部エンドポイントのリージョン |
VpcDetails フィールドの形式
| フィールド | タイプ | 説明 |
|---|---|---|
| project_id | 文字列 | VPC を含むプロジェクトの ID |
| subnetwork_name | 文字列 | VM が動作しているサブネットワーク |
| vpc_name | 文字列 | VM が動作している VPC |
ログのフィルタリング
VPC フローログを有効にすると、フィルタに一致するログのみを保持する基本フィールドとメタデータ フィールドの両方に基づいてフィルタを設定できます。他のすべてのログは Logging に書き込まれる前に破棄されるため、コストが節約され、必要な情報の検索にかかる時間が短縮されます。
[レコード形式] のフィールドのサブセットでフィルタリングできます。
VPC フローログ フィルタリングでは、属性ベースの論理式に埋め込み式の表現言語である CEL が使用されます。VPC フローログのフィルタ式は 2,048 文字以内に制限されています。詳しくは、サポートされている CEL 論理演算子をご覧ください。
CEL の詳細については、CEL の概要と言語の定義をご覧ください。生成フィルタ機能では、CEL 構文の特定のサブセットのみがサポートされます。
ログ フィルタリングを使用するサブネットの作成については、サブネット作成時の VPC フローログの有効化で gcloud CLI または API の手順をご覧ください。
ログ フィルタリングの構成については、VPC フローログ パラメータの更新で gcloud CLI または API の手順をご覧ください。
例 1: ログの収集を my-vm という名前の特定の VM に制限する。この場合、トラフィックの送信元から報告された src_instance フィールドが my-vm であるか、トラフィックの宛先から報告された dst_instance フィールドが my-vm であるログのみが記録されます。
gcloud compute networks subnets update my-subnet \
--logging-filter-expr="(src_instance.vm_name == 'my-vm' && reporter=='SRC') || (dest_instance.vm_name == 'my-vm' && reporter=='DEST')"
例 2: ログの収集を送信元 IP アドレスが 10.0.0.0/8 サブネットのパケットに限定する。
gcloud compute networks subnets update my-subnet \
--logging-filter-expr="inIpRange(connection.src_ip, '10.0.0.0/8')"
例 3: ログの収集を VPC の外部のトラフィックに制限する。
gcloud compute networks subnets update my-subnet \
--logging-filter-expr '!(has(src_vpc.vpc_name) && has(dest_vpc.vpc_name))'
サポートされている CEL 論理演算子
| 式 | サポートされる形式 | 説明 |
|---|---|---|
| true、false | ブール値 | ブール定数 |
x == y x != y |
ブール値、整数、文字列 | 比較演算子 例: connection.protocol == 6 |
x && y x || y |
ブール値 | ブール論理演算子 例: connection.protocol == 6 && src_instance.vm_name == "vm_1" |
| !x | ブール値 | 否定 |
| 1、2.0、0、... | Int | 定数の数値リテラル |
| x + y | 文字列 | 文字列の連結 |
| "foo"、'foo'、... | 文字列 | 定数の文字列リテラル |
| x.lower() | 文字列 | 文字列の小文字の値を返します。 |
| x.upper() | 文字列 | 文字列の大文字の値を返します。 |
| x.contains(y) | 文字列 | 文字列に指定された部分文字列が含まれている場合は true を返します。 |
| x.startsWith(y) | 文字列 | 文字列が、指定された部分文字列で始まる場合に true を返します。 |
| x.endsWith(y) | 文字列 | 文字列が、指定された部分文字列で終わる場合に true を返します。 |
| inIpRange(X, Y) | 文字列 | X が IP で Y が X を含む IP 範囲である場合、true を返します 例: inIpRange("1.2.3.1", "1.2.3.0/24") |
| x.containsFieldValue(y) |
x: list y: map(string, string) |
指定された Key-Value ペアと一致するフィールドを含むオブジェクトがリストに含まれている場合、true が返されます。 例: dest_gke_details.service.containsFieldValue({'service_name': 'service1', 'service_namespace': 'namespace1'}) |
| has(x) | 文字列 | フィールドが存在する場合は true を返します。 |
トラフィック パターンの例
このセクションでは、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.* |
| 応答 | 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 のフローログを確認できます（サービス プロジェクトによって作成されたものを含みます）。この例では、サービス プロジェクトは "webserver"、"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 | webserver | 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 番目のホップは両方のノードのサンプリング ポイントによって記録されます。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.* |
料金
Logging、BigQuery、または Pub/Sub の標準料金が適用されます。VPC フローログの料金については、ネットワーク テレメトリーの料金をご覧ください。
よくある質問
VPC フローログには、ファイアウォール ルールに基づいて許可されるトラフィックと拒否されるトラフィックの両方が含まれていますか？
- VPC フローログでは、VM の観点からトラフィックがカバーされます。VM からのすべての下り（発信）トラフィックは、ファイアウォールの下り拒否ルールによってブロックされていても記録されます。上り（着信）トラフィックは、ファイアウォールの上り許可ルールによって許可されている場合に記録されます。ファイアウォールの上り（内向き）拒否ルールによってブロックされた上りトラフィックは記録されません。
VPC フローログは、インターフェースが複数ある VM インスタンスで動作しますか？
- はい。複数インターフェース VM 上のすべてのインターフェースに対して VPC フローログを有効にできます。
VPC フローログはレガシー ネットワークで動作しますか？
- いいえ。レガシー ネットワークでは、VPC フローログはサポートされていません。