GCPのVPCファイアウォール：その「評価順序」を理解しないと、夜中に泣きを見ることになる
インフラエンジニアの皆さん、こんにちは。大規模なトラフィックを捌いていると、ふと「なぜこのパケットが通るのか（あるいは通らないのか）」という迷宮に入り込む瞬間がありますよね。
GCPのVPCファイアウォールは、一見シンプルに見えて、実はその裏で「パケットの生命線」を握る非常に重要なルールが渦巻いています。特に、Web APIを設計・運用する際、ファイアウォールの優先順位（Priority）を正しく理解していないと、いざという時のデバッグで地獄を見ることになります。
今回は、現場のSREが必ず押さえておくべき「ファイアウォール評価の真実」を紐解いていきましょう。
—
1. 評価順序の鉄則：数値が「小さい」ほど偉い
GCPのファイアウォールには 0 から 65535 までの数値で priority が設定されます。ここで勘違いしやすいのが、「数値が小さいほど優先度が高い（先に評価される）」という点です。
例えば、priority: 1000 で全拒否するルールを書いても、priority: 900 で許可するルールがあれば、パケットは後者に従います。これは、プログラミング言語の if-else 文とは異なり、評価順序が数値によって厳格に制御される「非順次的評価」であることを意味します。
実務でのTips
現場では、以下のように優先度をブロック分けして設計するのが定石です。
- 0-999: 拒否ルール（Deny）の最優先確保
- 1000-5000: インフラ管理用（SSH, IAP, 監視ツールなど）
- 5001-60000: アプリケーション用（Web API, DB接続など）
- 65535: 暗黙の拒否（デフォルト）
—
2. 「ステートフル」という魔法
GCPのファイアウォールは「ステートフル（Stateful）」です。これは、「行き」のパケットが許可されれば、「帰り」のパケットは自動的に許可されるという、ネットワークエンジニアにとって非常にありがたい特性を指します。
「APIサーバーから外部の決済ゲートウェイへ接続し、その戻り値を待つ」というケースを考えてみましょう。往路のトラフィックさえ許可しておけば、戻りのパケットに対して個別にファイアウォールルールを書く必要はありません。
Pythonによる疎通確認コード
APIサーバーの挙動を確認する際、私はよく以下のようなスクリプトで、特定のエンドポイントへの疎通をテストします。
import requests
# APIサーバーから外部リソースへリクエストを送るテスト
def test_connectivity(target_url):
try:
# ステートフルな通信が許可されているか確認
response = requests.get(target_url, timeout=5)
print(f"Status Code: {response.status_code}")
except Exception as e:
# ここでタイムアウトが発生する場合、往路が遮断されている可能性が高い
print(f"Connection Failed: {e}")
# 実行
test_connectivity("https://api.example.com/v1/ping")—
3. 現場で役立つ gcloud コマンドによるデバッグ術
設定を確認するために、いちいちコンソールをポチポチするのは効率が悪すぎます。CLIを使って、現在のルールを「Priority順」にリストアップする習慣をつけましょう。
# 優先度順にルールを一覧表示し、内容を精査する
gcloud compute firewall-rules list \
--sort-by=priority \
--format="table(name, priority, direction, action, targetTags)"もし、特定のインスタンスに適用されているルールを絞り込みたい場合は、以下のように対象のタグを指定してフィルタリングするのが定石です。
# 特定のサービス用インスタンスに適用されているルールを特定
gcloud compute firewall-rules list \
--filter="targetTags:web-api-server" \
--sort-by=priority—
4. 最後に：設計の「罠」を避けるために
多くの現場で障害になるのが、「後から追加した特定のIPを許可するルール」が、既存の「全域拒否ルール」の優先度に負けているケースです。
もし、意図した通信が通らない場合は、以下の手順でトラブルシューティングを行ってください。
1. gcloud compute firewall-rules list でルールの優先度を確認する。
2. Network Intelligence Center の「ファイアウォール分析」を活用し、パケットがどのルールで拒否されたかを可視化する。
3. priority を調整し、既存ルールとの競合を避ける（必要に応じて 65535 に近い数値を 1000 以下に繰り上げる等の調整を行う）。
ファイアウォールは、ただの「壁」ではありません。それは、あなたのサービスを守るための「精緻な門番」です。この門番のルールを正しく理解し、適切に数値を割り振ることは、スケーラブルなインフラを構築する上での教養と言えるでしょう。
何かトラブルが起きたとき、パケットの気持ちになって「このパケットはどの門をくぐろうとしているのか？」を想像してみてください。そうすれば、きっと解決の糸口は見えてきます。
それでは、また次回の深掘りでお会いしましょう。健闘を祈ります！
コメント