パブリックサブネットとIGWの「本当の姿」：パケットが世界へ飛び出す瞬間
クラウドのインフラを設計する際、VPC（Virtual Private Cloud）の作成から始めるのはSREやインフラエンジニアにとって儀式のようなものだ。だが、「パブリックサブネットとは何か？」という問いに、単に「インターネットゲートウェイ（IGW）へのルートを持つサブネットです」と教科書通りの回答で満足していないだろうか。
実務の現場では、その無邪気なルーティング設定の裏側で、Linuxカーネルのネットワークスタック、仮想化レイヤーのパケット書き換え、そしてBGP（Border Gateway Protocol）による広大な経路制御が複雑に絡み合っている。今回は、パブリックサブネットがインターネットに直結されるメカニズムを、パケットレベルの挙動から極限のパフォーマンスチューニング、そしてセキュリティの急所まで、徹底的に解剖していこう。
—
1. パケットレベルで見るIGW連携の内部挙動
パブリックサブネットに配置されたEC2インスタンスなどのリソースから、インターネット上の外部サーバー（例えば 1.1.1.1）へ向けたパケットが送出される瞬間、何が起きているのか。
ルーティングテーブルとプレフィックスマッチの現実
インスタンスのカーネルルーティングテーブルには、デフォルトゲートウェイとしてVPCルーターのIPアドレス（通常はサブネットのベースIP + 2）が指定されている。アプリケーション層からソケットを通じて送出されたTCPセグメントは、IPヘッダーに宛先IP 1.1.1.1 を刻み、カーネルのL3レイヤーによってVPCルーターへ向けたイーサネットフレームとしてカプセル化される。
ここでAWSなどのメガクラウドの裏側を覗いてみよう。サブネットのルートテーブルに以下のような設定を書いたとき、何が起きているか。
{
"DestinationCidrBlock": "0.0.0.0/0",
"GatewayId": "igw-xxxxxxxxxxxxxxxxx"
}このルーティングエントリは、VPCの分散ルーター群に対して「0.0.0.0/0 に一致するすべてのパケットを、物理的なインターネットエッジに存在するIGWへ転送せよ」という命令を意味する。
IGWにおけるSNAT（Source NAT）の不在とルーティングの妙
よくある誤解として、「パブリックサブネット内のリソースも、NATゲートウェイを通るようにプライベートIPからパブリックIPへ変換（SNAT）されている」というものがある。しかし、パブリックサブネット上のリソースが持つENI（Elastic Network Interface）にグローバルIP（パブリックIPまたはEIP）が割り当てられている場合、IGWでSNATは行われない。
パケットはプライベートIPアドレス（例: 10.0.1.100）を送信元IPとしたままIGWに到達し、IGWは単にL2/L3のバウンダリーとして、それをワールドワイドなインターネット網へとルーティングする。つまり、パブリックサブネットのリソースは、インターネットに対して「裸のプライベートIP」のまま直結されている（もちろん、セキュリティグループとネットワークACLがファイアウォールとして機能している前提だが）。
この挙動を理解していないと、セキュリティ監査の際に「なぜこのサーバーのログに直接グローバルIPからの通信が記録されるのか」という根本的な見落としを生む原因になる。
—
2. エッジケースの罠：非対称ルーティングとホップバイホップの制約
クラウドネットワークの設計で最もエンジニアを悩ませるのが、エッジケースにおけるパケットロスや接続断だ。特に、マルチホーム環境や複雑な仮想アプライアンス（次世代ファイアウォールなど）をパブリックサブネットに配置する際に、非対称ルーティング（Asymmetric Routing）の罠に落ちることが多い。
非対称ルーティングが発生するメカニズム
通常、TCPコネクションは往復で同一の経路を通ることが期待される。しかし、パブリックサブネット内に複数のネットワークインターフェース（ENI）を持つインスタンスを配置し、それぞれ異なるルートテーブルを適用した場合、以下のような現象が起きる。
1. 往路: インスタンスの eth0 からパケットが出て、IGW経由でインターネットへ向かう。
2. 復路: インターネットからの応答パケットがIGWを通り、インスタンスの eth1 に着弾する。
Linuxカーネルのデフォルト設定（rp_filter = 1：Strict Reverse Path Filtering）では、パケットが受信されたインターフェースと、ルーティングテーブル上の送信元への経路が一致しない場合、そのパケットをセキュリティ上の脅威（IPスプーフィングなど）とみなして容赦なく破棄（ドロップ）する。
このトラブルを回避するためのカーネルパラメータチューニングの例を見ておこう。
# /etc/sysctl.d/99-network-performance.conf
# リバースパスフィルタリングを緩めのモード（Loose Mode: 2）に変更する
# これにより、マルチホーミング環境や非対称ルーティング時の意図しないパケットドロップを防ぐ
net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.default.rp_filter = 2
# 特定のインターフェースごとに個別設定する場合
net.ipv4.conf.eth0.rp_filter = 2
net.ipv4.conf.eth1.rp_filter = 2インフラエンジニアとして、ルーティングテーブルの静的な美しさだけでなく、OS内部のパケット検証ロジックまで見通す目が求められる所以だ。
—
3. 極限のパフォーマンスチューニング：RTT削減とTCPスタックの最適化
パブリックサブネットはインターネットとの最前線である。ミリ秒単位のレイテンシー削減がビジネスの勝敗を分ける現代において、デフォルトのOS設定のまま運用するのは怠慢と言わざるを得ない。ここでは、LinuxカーネルレベルでのTCP/IPスタックのチューニング手法を紐解く。
1. 初期輻輳ウィンドウ（Initial Congestion Window: initcwnd）の拡大
Linuxのデフォルトでは、TCPの3ウェイハンドシェイク直後に送信できるセグメント数（initcwnd）が少なめに設定されていることが多い。これを拡張することで、最初のラウンドトリップタイム（RTT）内で転送できるデータ量を増やし、体感速度を劇的に改善できる。
# 現在のルートキャッシュにおけるinitcwndを確認する
ip route show
# ipコマンドを使用して、特定のルートに対するinitcwndを強制的に10セグメント（約15KB）に拡張する例
ip route replace default via 10.0.1.1 dev eth0 initcwnd 102. BBR（Bottleneck Bandwidth and RTT）輻輳制御アルゴリズムの採用
長距離のインターネット通信や、パケットロス率がわずかにある環境では、従来のCUBICアルゴリズムよりもGoogleが開発したBBRの導入が圧倒的な効果を発揮する。BBRは、パケットロスを輻輳のシグナルとして捉えるのではなく、利用可能な帯域幅と伝搬遅延をリアルタイムで測定して送信レートを動的に決定する。
# カーネルがBBRをサポートしているか確認し、有効化する
# /etc/sysctl.d/99-bbr.conf
# 利用可能な輻輳制御アルゴリズムに bbr が含まれていることを確認後、設定を追記
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr設定を反映するには、以下のコマンドを実行する。
sudo sysctl --systemこれにより、パブリックサブネットからインターネットを跨いだAPI通信やデータ転送のスループットが限界まで引き上げられる。
—
4. セキュリティの要：パブリックサブネットにおける脆弱性回避策
「パブリック」という言葉の響きは、セキュリティ担当者の背筋を凍らせる。インターネットに直結されている以上、常にゼロデイ攻撃や不正アクセスの脅威に晒されているからだ。
セキュリティグループとネットワークACLの多層防御（Defense in Depth）
パブリックサブネットを安全に保つための鉄則は、「信頼するな、常に検証せよ（Zero Trust）」の精神に基づいたステートフルなフィルタリングの徹底だ。
- セキュリティグループ（SG）: インスタンスレベルのファイアウォール。ステートフル（往信を許可すれば復信は自動許可）であり、最小権限の原則に基づき、必要なポート（例: HTTPS
443）のみを外部から許可する。SSH（22）やRDP（3389）のフルオープン（0.0.0.0/0）などは論外であり、AWS Systems Manager Session Managerなどを活用して踏み台サーバーすら排除するのがモダンなアプローチだ。 - ネットワークACL（NACL）: サブネットレベルのファイアウォール。こちらはステートレスであるため、インバウンドだけでなくアウトバウンドのルール（特に一時ポートの範囲
1024-65535）を明示的に記述しなければならない。NACLは、特定の悪意あるIPレンジからのDDoS攻撃やスキャンをサブネットの境界で即座にドロップするための「最初の防壁」として機能する。
—
結びにかえて
パブリックサブネットとインターネットゲートウェイの連携は、一見するとクラウドのマネージドサービスが自動でやってくれるシンプルな機能に見える。しかし、その背後にはL3/L4のプロトコル仕様、OSカーネルのパケット処理哲学、そしてパフォーマンスとセキュリティの果てしないトレードオフが存在している。
「なぜこの設定が必要なのか」「パケットはこの瞬間、どこを通っているのか」。その泥臭い問いかけを忘れないことこそが、真に信頼性の高いインフラを支えるSRE・アーキテクトの矜持なのである。さあ、今すぐ自身のVPCのルートテーブルとカーネルパラメータを見直し、ネットワークの底力を限界まで引き出してみよう。
コメント