【テクニカル・上級編】ネットワークアクセスコントロールリスト(NACL)のステートレスな評価 – クラウドインフラと仮想化ネットワーク実践ガイド

AWS NACLの「ステートレス」という孤独な戦い：パケットが刻む運命の境界線

クラウドアーキテクチャの設計図を広げるとき、多くのエンジニアが「セキュリティグループ（SG）があればNACLは不要ではないか？」という問いにぶつかります。確かに、ステートフルなSGは接続状態を追跡し、戻りのパケットを自動的に許可してくれる。しかし、ネットワークの最前線でパケットを捌くSREとして言わせてもらえば、「NACLのステートレス性」を理解しない設計は、深い谷底に橋を架けずに渡ろうとするようなものです。

今日は、AWS VPCにおけるNACL（ネットワークアクセスコントロールリスト）の冷徹な挙動と、それがトラフィックのパフォーマンスやセキュリティに与える影響を、パケットレベルの視点から紐解いていきましょう。

1. ステートレスという名の「記憶喪失」

NACLは、サブネットの入り口に立つ厳格な門番です。SGと決定的に異なるのは、彼らが「パケットの文脈」を一切保持しないという点です。

例えば、クライアントからWebサーバーへのリクエスト（SYNパケット）がサブネットに入ってきたとします。NACLはインバウンドルールを上から順に評価し、許可すれば通過させます。ここまでは良い。問題はその次です。サーバーが応答を返そうとする際、NACLは「これは先ほど入ってきたパケットの返信だ」などとは微塵も考えません。アウトバウンドルールを改めてゼロから評価するのです。

この「文脈の欠如」が、一時ポート（Ephemeral Ports）の開放という悪夢を生みます。

エフェメラルポートのジレンマ

多くの現場で、NACLの設定ミスにより通信が遮断される最大の原因は、戻りトラフィックのためのポート開放忘れです。TCPの標準的なエフェメラルポート範囲（通常は 1024-65535）をアウトバウンドで許可しておかなければ、どれだけインバウンドで丁寧に 80 や 443 を開けても、パケットはサブネットの出口で奈落の底へ消え去ります。

2. パフォーマンスへの静かなる侵食：RTTとTCPバッファ

NACLの評価は、ルールの数が増えれば増えるほど、微細なレイテンシの積み重ねとなります。各サブネット境界で発生するパケットの照合処理は、高頻度なマイクロサービス間通信において、無視できないRTT（往復遅延時間）の増大を招く可能性があります。

TCPバッファとMTUの最適化

NACLでフィルタリングを行う際、パケットサイズがMTU（最大転送単位）を超え、断片化（Fragment）が発生すると、NACLの評価はさらに複雑化します。特に UDP を用いたロードバランシングや、QUIC（HTTP/3）のようなプロトコルでは、パケットの断片化がパフォーマンスを直撃します。

以下は、Linuxカーネルレベルでネットワーク性能を最適化し、NACL配下でもスループットを維持するためのsysctl設定例です。

# TCPウィンドウサイズの最適化（高帯域幅/高遅延ネットワーク向け）
# 大容量通信時のスループットを最大化する
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"

# TCP接続のタイムアウトを短縮し、NACLの影響を最小限に抑える
# 接続の再試行回数を減らす
sysctl -w net.ipv4.tcp_syn_retries=3

3. 実践：セキュアかつ効率的なNACL設計

NACLを「守りの要」として機能させるためには、ルール番号（Rule Number）の設計に魂を込める必要があります。ルールは番号の若い順から評価されるため、頻繁にアクセスされるルールは極力小さな番号に配置し、評価の計算コストを削減します。

推奨されるNACLルール構成例

| ルール番号 | タイプ | プロトコル | ポート範囲 | 送信元/宛先 | アクション | 備考 |
| :— | :— | :— | :— | :— | :— | :— |
| 100 | カスタムTCP | 6 | 443 | 0.0.0.0/0 | ALLOW | HTTPS通信を許可 |
| 110 | エフェメラル | 6 | 1024-65535 | 0.0.0.0/0 | ALLOW | 戻りトラフィック用 |
| 32767 | ALL | ALL | ALL | 0.0.0.0/0 | DENY | 明示的な拒否 |

4. 脆弱性回避とアーキテクチャの深淵

NACLは、SGをバイパスしようとする攻撃や、誤って公開されたサブネット内での横移動（Lateral Movement）を阻止する「最後の防衛線」です。例えば、特定の攻撃者が特定のIP範囲から執拗にスキャンを仕掛けてくる場合、SGで個別にブロックするよりも、NACLでそのIP範囲をサブネット境界で完全にドロップさせる方が、インフラ全体のCPU負荷を抑えられます。

TLSハンドシェイクの最適化とネットワーク

TLS 1.3が普及した現在、ハンドシェイクのRTTは最小化されていますが、NACLの評価処理が遅延を生むと、ハンドシェイクの「往復」回数がそのまま体感速度に跳ね返ります。

もしあなたが大規模なアーキテクチャを担当しているなら、以下の点を確認してください。

ログの可視化: VPCフローログを有効にし、REJECT されたパケットの srcaddr と dstaddr を分析する。
ルールの断捨離: 使用されていない古いルールは、評価コストだけでなく、設定ミスによる脆弱性の温床となります。

結びに：パケットを愛するということ

ネットワークエンジニアにとって、NACLは単なる設定ファイルではありません。それはパケットという名の旅人が、目的地にたどり着くために通過すべき「門」であり、その門をどう設計するかで、アプリケーションの呼吸が変わります。

ステートレスな評価という「面倒な仕組み」を味方につけ、パケットが最短距離で駆け抜けるルートを設計すること。それこそが、メガクラウドを極めるSREの矜持なのです。

さあ、次はあなたのVPCのNACLを見直す番です。不要なルールを削ぎ落とし、パケットの旅を最適化させてみませんか？