プライベートサブネットの「壁」を再定義する：パケットレベルで紐解くゼロトラストの境界線
「プライベートサブネットにインスタンスを配置すれば安全」。もしあなたが今なおこの言葉を信じているのであれば、少し立ち止まってネットワークの深層を覗き込む必要がある。
クラウドのネットワーク設計において、プライベートサブネットは単なる「インターネットから見えない場所」ではない。それは、OSI参照モデルの各レイヤーで発生するトラフィックを精緻に制御し、万が一の侵害（コンプロマイズ）が発生した際にも、攻撃者のラテラルムーブメントを物理的・論理的に封じ込めるための「戦術的な防波堤」でなければならない。
今日は、AWSのVPC設計におけるプライベートサブネットの真髄を、パケットの挙動とカーネルパラメータのチューニングという、泥臭くも美しい領域から解き明かしていこう。
—
1. パケットの経路と「見えない境界」の正体
プライベートサブネットの定義は、単に「Internet Gateway (IGW) へのルートを持たない」ことだけではない。真の境界は、サブネットの境界にアタッチされる Network ACL と、インスタンスごとの Security Group が形成する二重のフィルタリング層にある。
パケットがIGWへ到達できないとき、何が起きているのか。ルーターの実体である仮想デバイスは、パケットの宛先IPがローカルVPC外であり、かつ Main Route Table に igw-xxxxxxxx へのネクストホップが存在しないことを確認した瞬間に、ICMP Destination Unreachable（Type 3, Code 1）を返すか、あるいは黙殺（ドロップ）する。
ここで重要なのは、「経路がない」ことによる隔離と、「通信がステートフルに監視されている」ことによる隔離の違いだ。
現場で陥る「NATゲートウェイ」の罠
プライベートサブネットから外部APIを叩くために NAT Gateway を配置する際、多くのエンジニアは疎通確認だけで満足してしまう。しかし、NAT Gateway はソースIPを変換（SNAT）するだけでなく、TCPセッションのステート追跡を行っている。高トラフィック環境では、ここがボトルネックになる。
# NAT Gatewayのコネクション追跡限界に備えるためのカーネルチューニング
# /etc/sysctl.d/99-network-performance.conf
# TCPのタイムウェイトを短縮し、ポート枯渇を防ぐ
net.ipv4.tcp_fin_timeout = 15
# ローカルポートの範囲を拡張する（ephemeral port）
net.ipv4.ip_local_port_range = 1024 65535
# TCPコネクションの再利用を許可
net.ipv4.tcp_tw_reuse = 1—
2. トランスポート層の最適化：レイテンシを削ぎ落とす
プライベートサブネット内のデータベースやバックエンドサービスは、外部からのアクセスがない分、内部通信の効率化に全力を注ぐべきだ。特にマイクロサービス間通信では、RTT (Round Trip Time) をいかに減らすかがユーザー体験に直結する。
TCPハンドシェイクの最適化とTLS 1.3
現代のインフラでは、TLS 1.3 の採用は必須だ。TLS 1.2 が2往復のハンドシェイクを必要とするのに対し、TLS 1.3 は 1-RTT で鍵交換まで完了する。プライベートサブネット内の通信であっても、この「1往復」の差が積み重なれば、レイテンシの大きな障壁となる。
さらに、TCP Fast Open (TFO) を有効にすれば、SYNパケットにデータを含めて送信することで、実質的な0-RTTに近いハンドシェイクを実現できる。
# NginxでのTLS 1.3およびTCP Fast Openの設定例
listen 443 ssl http2 fastopen=256;
ssl_protocols TLSv1.3;
# ヘッダー圧縮の更なる最適化（HPACKの効率化）
http2_max_field_size 16k;—
3. セキュリティの深淵：パケットインスペクションと脆弱性回避
プライベートサブネットにあるからといって、無防備な通信を行ってはならない。真のアーキテクトは、ネットワークの境界でパケットを「観察」する。
MTUとフラグメンテーションの呪縛
AWS VPC の MTU は通常 1500 バイトだが、VPN を経由したり IPv6 を併用する場合、Path MTU Discovery (PMTUD) が失敗するとパケットがドロップされる。これは、セキュリティ機器が不正なフラグメンテーションを検知して遮断する挙動と酷似しているため、原因特定が極めて困難になる。
回避策： MSS Clamping を適切に設定すること。
# iptablesでTCP MSS値を制限し、フラグメンテーションを防ぐ
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360—
4. 総括：守るべきは「信頼」である
プライベートサブネットにおける設計思想とは、結局のところ「信頼の最小化」に他ならない。
1. デフォルト拒否（Deny All）を貫く： Security Group は、必要なポート以外は一切開けない。
2. 可観測性（Observability）の担保： VPC Flow Logs を単に保存するのではなく、CloudWatch Logs Insights 等で「異常な送信元IP」や「拒否されたパケットの急増」を検知するクエリを常駐させる。
3. トランスポートの最適化： カーネルパラメータのチューニングは「おまじない」ではない。パケットの生存時間を定義し、バッファを最適化することで、システムの堅牢性は数段跳ね上がる。
クラウドのインフラは、物理的な制約から解放されたかのように見える。しかし、パケットを流すネットワークの深層では、依然として物理法則とプロトコルの厳格なルールが支配している。そのルールを理解し、手懐けることこそが、SREとしての矜持であり、真にセキュアなインフラを構築する唯一の道なのだ。
次回の記事では、この「プライベートサブネット」から Transit Gateway を経由したマルチVPC環境におけるルーティングの複雑怪奇さと、そのデバッグ手法について深掘りしようと思う。ネットワークエンジニア諸君、さらなる深淵へ潜る準備はできているか？
コメント