GCPネットワークの深淵：VPCファイアウォールの評価ロジックと「ステートフル」の真実
クラウドアーキテクトやSREとして現場に立っていると、VPCファイアウォールを単なる「ポート開閉のスイッチ」と捉えているエンジニアに出くわすことがあります。しかし、GCPのファイアウォールは単なるパケットフィルタリングの道具ではありません。それは、Googleの巨大なSDN（Software Defined Network）である Andromeda の最前線で動く、極めて洗練されたステートフル・インスペクション・エンジンなのです。
本稿では、優先度の数学的評価から、パケットがカーネルレベルでどのように追跡されるのか、その「現場のリアル」を掘り下げます。
1. 優先度（Priority）の数学的評価と絶対的なルール
GCPのファイアウォールルールにおいて、Priority は 0 から 65535 の整数で定義されます。数値が小さいほど評価順位が高く、最初にマッチしたルールが適用されます。
ここで重要なのは、「マッチした時点で評価は終了する」という原則です。多くのトラブルシューティングで「許可したはずの通信が通らない」と叫ぶとき、その原因の9割は、より優先度の高い deny ルールが、下位の allow ルールを遮断していることにあります。
暗黙のルールの正体
明示的なルールが存在しない場合、以下の「暗黙のルール」が最後尾に控えています。
- 暗黙の拒否（Ingress）: 全てのトラフィックを
deny。 - 暗黙の許可（Egress）: 全てのトラフィックを
allow。
この非対称性は、セキュリティ設計上の強力な武器になります。特に Ingress をデフォルトで「全て拒否」にしておくことは、ゼロトラストアーキテクチャの基本線です。
2. ステートフル処理：コネクション追跡のメカニズム
GCPのファイアウォールは「ステートフル」です。これは、TCP や UDP のパケットが戻り先を明示的に許可しなくても、往路で許可されたコネクションであれば、復路のパケットは自動的に透過することを意味します。
この背後では、Googleの分散システムが Connection Tracking Table を保持しています。
- TCP:
SYNパケットを契機にステートが生成され、FINやRSTでクローズされるまで追跡されます。 - UDP: セッションの継続性を判断するため、タイムアウト値に基づいた擬似的なステートが維持されます。
なぜこれが「パフォーマンス」に直結するのか
ステートフルであることの恩恵は、ルールの可読性向上だけではありません。インバウンドとアウトバウンドを個別に制御する必要がないため、iptables のようなローカル側の複雑なフィルタリング負荷をクラウド基盤側にオフロードできる点にあります。これにより、インスタンスのCPU負荷を純粋なアプリケーション処理へ集中させることが可能です。
3. 極限のパフォーマンスチューニング：TCPスタックの最適化
ファイアウォールが適切に設定されている前提で、さらにネットワークのレイテンシを削り出すには、LinuxカーネルのTCPパラメータ調整が欠かせません。特に高トラフィックなAPIサーバでは、以下のチューニングが推奨されます。
# TCPウィンドウサイズの拡大（高帯域幅遅延積に対応）
# ネットワークのスループットを最大化するためにバッファを拡張
sysctl -w net.ipv4.tcp_rmem='4096 87380 16777216'
sysctl -w net.ipv4.tcp_wmem='4096 65536 16777216'
# TCP Fast Openの有効化
# 3ウェイハンドシェイクの初回RTTを省略し、TLSハンドシェイクを加速させる
sysctl -w net.ipv4.tcp_fastopen=3TCP Fast Open を有効にすると、クライアントが過去に接続したことがある場合、SYN パケットにデータを埋め込んで送信できるようになります。これにより、TLSハンドシェイクのオーバーヘッドを劇的に削減可能です。
4. セキュリティとパフォーマンスのトレードオフ：実務的知見
アーキテクトとして最も注意すべきは、Cloud CDN や Global Load Balancer を併用する際の「ヘッダー圧縮」と「TLSオフロード」の挙動です。
- HTTP/2 ヘッダー圧縮（HPACK）: CDN側で適切に設定されていれば、ヘッダーの重複は排除され、RTTあたりのデータ転送効率が劇的に向上します。
- TLS 1.3の採用: 0-RTTハンドシェイクを最大限活用するため、GCPのロードバランサー側で
TLS 1.3を強制すべきです。
脆弱性回避のための設定サンプル
不必要な公開を避けつつ、かつパフォーマンスを維持するファイアウォール設定のベストプラクティスを gcloud コマンドで示します。
# 特定のサービス間通信のみを最小権限で許可
gcloud compute firewall-rules create allow-internal-api \
--direction=INGRESS \
--priority=1000 \
--network=production-vpc \
--action=ALLOW \
--rules=tcp:8080 \
--source-ranges=10.128.0.0/20 \
--target-tags=backend-server # ターゲットタグでスコープを限定するのが鉄則結びに代えて
ネットワークは「ブラックボックス」ではありません。パケットが VPC のエッジを通り、Andromeda のステート追跡を抜け、カーネルのバッファに到達するまでのプロセスを想像できるかどうかが、SREとしての腕の見せ所です。
「とりあえず全許可」という設定は、セキュリティの死を意味するだけでなく、ネットワークのパフォーマンスという観点からも不透明な挙動を生むリスクがあります。一つひとつの優先度を制御し、ステートのライフサイクルを理解することで、初めて真に堅牢で高速なクラウドインフラが構築できるのです。
次にトラフィックが遅いと感じたときは、tcpdump でパケットの再送率を確認する前に、まずは Priority の序列を、そしてカーネルの TCP ウィンドウを確認してみてください。そこに、最適化の答えが隠れているはずです。
コメント