「なぜ弾かれた？」を即断する：GCP VPCファイアウォールログの極意
ネットワークエンジニアにとって、一番の悪夢は「何が起きているか分からない」状態です。特にGCP（Google Cloud）のVPCファイアウォールで通信が遮断されたとき、ログを正しく読み解けるかどうかで、障害復旧までの時間は雲泥の差が出ます。
今回は、公式ドキュメントの奥底に眠っている「VPCファイアウォールログ」の真の活用法と、現場で必ず使うべき解析の勘所を伝授します。
—
1. VPCファイアウォールログは「究極のブラックボックス」を解明する鍵
VPCファイアウォールルールは、いわばクラウド環境の「検問所」です。デフォルトではログが無効化されていますが、本番環境でこれをオフにしているのは、目隠しをして高速道路を走るようなものです。
まずは、ログを有効化する際の鉄則から。すべてのルールでログを出すとコストが跳ね上がります。「許可(Allow)」のログは監査用にサンプリングしつつ、「拒否(Deny)」のログは全量取得するのが、SREとしての定石です。
ログを有効化する設定（gcloudコマンド）
# 特定の拒否ルールに対してログ出力を有効化する例
gcloud compute firewall-rules update [ルール名] \
--enable-logging \
--project [プロジェクトID]—
2. ログの中身を解剖する：パケットの「身元」を特定する
ファイアウォールログがCloud Logging（旧Stackdriver）に吐き出されるとき、そこにはパケットの指紋とも言えるメタデータが詰め込まれています。
特に注目すべきは以下のフィールドです。
connection.src_ip/connection.dest_ip: 通信の起点と終点。これがNATゲートウェイを通っている場合は、期待したIPか確認が必要です。connection.src_port/connection.dest_port: 特にEphemeralポートの枯渇や、期待しないポートへのアクセスを検知します。disposition:DENYかALLOWか。これがすべてを物語ります。matched_rule: どのルールにヒットしたか。「意図しないルール」に先制攻撃されていないかを確認するのがトラブルシューティングの第一歩です。
—
3. 実践：ログを用いたデバッグのフロー
Web APIで「なぜか特定のクライアントから接続できない」という事象が発生したとしましょう。
手順1: ログを絞り込むクエリ（Log Explorer）
まずは以下のクエリで、拒否されたパケットを炙り出します。
# 拒否された通信だけを抽出し、時間軸でソート
resource.type="gce_subnetwork"
jsonPayload.disposition="DENY"手順2: Pythonで自動解析（Cloud Logging API）
手動で検索するのも良いですが、頻発する拒否ログを自動検知してアラートを飛ばすPythonスクリプトの断片を紹介します。
from google.cloud import logging_v2
def check_firewall_denials(project_id):
client = logging_v2.LoggingServiceV2Client()
# フィルタリング条件（拒否されたパケットのみ）
filter_str = 'resource.type="gce_subnetwork" AND jsonPayload.disposition="DENY"'
# ログエントリを取得
entries = client.list_log_entries(
resource_names=[f"projects/{project_id}"],
filter_=filter_str
)
for entry in entries:
payload = entry.json_payload
print(f"拒否発生: {payload['connection']['src_ip']} -> {payload['connection']['dest_ip']}")
print(f"ヒットしたルール: {payload['matched_rule']['rule_id']}")—
4. 現場で役立つ「罠」とTips
優先順位（Priority）を疑え
GCPのファイアウォールは、数値が小さい方が優先度が高いという仕様です。意外と多いのが、「あとから追加した許可ルールが、既存の拒否ルールよりも優先度が低く、永遠に適用されない」というケースです。ログを確認する際は、matched_rule.priority を必ずチェックしてください。
コンテナネットワーク（GKE）の盲点
GKEを利用している場合、firewall-rulesだけでなく、NetworkPolicyも関わってきます。ファイアウォールのログに何も出ていないのに通信が通らない場合は、Kubernetesレイヤーでの制御（Calicoなどによるポリシー）を疑う必要があります。
監査ログとファイアウォールログを混同するな
- ファイアウォールログ: パケットごとの許可/拒否の結果。
- 監査ログ (Admin Activity): 「誰がルールを書き換えたか」という操作ログ。
セキュリティ事故の調査では、この2つを組み合わせて「誰が、いつ、どのルールを弄り、その結果どの通信が遮断されたか」という相関関係を突き止めるのが、プロの仕事です。
—
まとめ：ネットワークは「観測」から始まる
クラウドインフラにおいて、ネットワークは目に見えない空気のようなものです。しかし、ログという「観測機器」を正しく設定すれば、そこには極めて論理的で美しい通信フローが浮かび上がります。
「接続できない」と相談されたら、まずは焦って再起動する前に、Cloud Loggingを開いてください。パケットは必ず何らかの証拠を残しています。その証拠を読み解く力こそが、SREとしてのあなたの武器になるはずです。
次回は、これらを応用した「VPCフローログによるコスト最適化と不正アクセス検知」について深掘りしていきましょう。それでは、良いインフラライフを！
コメント