NACLの「ステートレス」という檻：パケットの帰還路を設計するアーキテクトの視点
クラウドインフラを設計する際、多くのエンジニアがセキュリティグループ（SG）のステートフルな挙動に甘えている。しかし、VPCネットワークの根幹であるネットワークACL（NACL）に触れるとき、我々は「ステートレス」という冷徹な現実と向き合わねばならない。
NACLは、パケットがサブネットの境界を通過するたびに、インバウンド・アウトバウンドのルールを個別に評価する。SGのように「往きの通信を許可したから戻りも通す」といった気の利いた記憶能力は持っていない。この「記憶がない」という仕様が、特にパブリックサブネットからの外部通信において、多くのエンジニアを苦しめることになる。
エフェメラルポートの罠と「双方向」の原則
パブリックサブネットにあるインスタンスから外部APIを叩く際、カーネルは送信元ポートとして動的に割り当てられるエフェメラルポート（通常 1024-65535）を使用する。
ここで発生する典型的なミスが、NACLの設定不足だ。アウトバウンドの許可ルールを設定しても、レスポンスパケットが戻ってきた際に、インバウンド側の許可ルールが存在しなければ、そのパケットは容赦なくNACLによって破棄される。
これを回避するためには、インバウンドルールにおいて「許可された送信元からのエフェメラルポートへの戻り通信」を明示的に許可しなければならない。
理想的なNACLインバウンドルール（例）
| ルール番号 | タイプ | プロトコル | ポート範囲 | 送信元 | 設定の意図 |
| :— | :— | :— | :— | :— | :— |
| 100 | カスタムTCP | TCP | 1024-65535 | 0.0.0.0/0 | 外部からの戻り通信を許可 |
パケットレベルで考えるRTT削減とTCPバッファチューニング
高負荷なWeb API通信やマイクロサービス間通信において、単に通信を許可するだけでは足りない。パケットがネットワークを駆け巡る際の「往復遅延時間（RTT）」を極限まで削り込む必要がある。
特に、TLSハンドシェイクが伴う通信では、TCPの3ウェイハンドシェイクに加え、TLSのネゴシエーションが追加される。ここでパケットロスや再送が発生すれば、そのオーバーヘッドは指数関数的に増大する。
Linuxカーネルパラメータによる最適化
sysctl を調整し、TCPスタックの振る舞いを最適化することで、パフォーマンスの底上げを図る。
# TCPウィンドウサイズを拡大し、高遅延環境でのスループットを向上させる
sysctl -w net.ipv4.tcp_window_scaling=1
# 初期CWND（Congestion Window）を大きくし、通信開始直後のパケット送出量を増やす
# クラウド上の広帯域環境では、デフォルトの10では小さすぎることが多い
ip route change default via 10.0.0.1 dev eth0 initcwnd 20
# TIME_WAIT状態のソケットを再利用し、ポート枯渇を防ぐ
sysctl -w net.ipv4.tcp_tw_reuse=1TLSハンドシェイクの「泥臭い」最適化
TLS 1.3が普及した現在、ハンドシェイクのRTTは削減されたが、依然として証明書のサイズや暗号スイートの選択がボトルネックになり得る。
1. TLS False Startの活用: サーバーが最初のハンドシェイク応答を返す前に、クライアントが暗号化されたアプリケーションデータを送信する技術。これにより、RTTを1回分削減できる。
2. ヘッダー圧縮（HPACK / QPACK）: HTTP/2以降では必須の機能だが、不要なカスタムヘッダーの削減や、頻出ヘッダーのインデックス化を意識するだけで、パケットのペイロードサイズは劇的に変わる。
セキュリティとパフォーマンスのトレードオフ：脆弱性への備え
NACLのポート範囲を 1024-65535 で広く開けることは、一見するとセキュリティリスクが高いように見える。しかし、これはあくまでサブネットレベルの防御線に過ぎない。
重要なのは、NACLを「最後の砦」と見なし、SGによる厳密なフィルタリングを併用することだ。
もしNACLでエフェメラルポートを一律開放することに抵抗があるならば、特定の外部IPアドレスに対してのみアウトバウンドトラフィックを制限し、そのIPからの戻りパケットのみを許可するという、ホワイトリストベースの厳密なルーティングを検討すべきだ。
アーキテクトとしての結論
ネットワークのトラブルシューティングにおいて、「なぜ繋がらないのか」を調べる際は、常にパケットの「往き」と「戻り」の両方をトレースすること。NACLのステートレスな仕様は、パケットがサブネットを通過する瞬間の「身分証明」を毎回求めてくる。
クラウドの抽象化されたネットワークを単なる「ブラックボックス」として扱うのではなく、カーネルのスタックからVPCの境界まで、パケットの旅路を可視化できているか。それが、インフラエンジニアとしての真の生存能力であると言えるだろう。
次回の運用では、ぜひ tcpdump を活用し、特定のセッションでACKが戻ってきているか、あるいはどのルールでDROPされているかをパケットヘッダーレベルで確認してほしい。画面上のメトリクスよりも、パケットの断片こそが真実を語っているのだから。
コメント