AWSの境界線を守る「無慈悲な門番」：NACLのステートレス性をエンジニアリングの視点で解剖する
クラウドアーキテクトとして数多の障害対応に当たってきたが、未だに「セキュリティグループ（SG）があるからNACLはデフォルト（全許可）でいい」という設計を散見する。確かにSGは便利だ。しかし、VPCのサブネット境界という「最前線」でパケットを遮断できるNACL（Network Access Control List）を理解せずして、堅牢なマルチレイヤー防御を語ることはできない。
今回は、NACLが持つ「ステートレス」という特性が、いかに現代の高速なネットワーク通信に影響を与えるか。そして、我々SREがどうこの「ステートレスな門番」を手懐けるべきか、その深い領域に踏み込んでいく。
—
1. 評価順序という名の「絶対的なルール」
NACLの評価は、ルール番号の昇順で実行される。番号の若い順にパケットを検証し、マッチした瞬間にその評価は終了する（即時適用）。
多くのエンジニアが躓くのは、この「マッチした瞬間に終了する」という挙動だ。特に、100番で「全拒否」を置いておきながら、200番で「特定の通信を許可」しても、パケットは100番の門前払いを食らうことになる。
# AWS CLIでのNACLルール作成例
# 評価順序100番で特定のWebトラフィックを許可し、それ以外を排除する設計
aws ec2 create-network-acl-entry \
--network-acl-id acl-xxxxxxxx \
--ingress \
--rule-number 100 \
--protocol tcp \
--port-range From=443,To=443 \
--rule-action allow \
--cidr-block 0.0.0.0/0 # 本来は特定の踏み台IPなどに絞るべきこの「評価順序の厳格さ」は、高トラフィック環境ではパフォーマンスに直結する。マッチ頻度の高いルールを若い番号に配置することで、カーネルレベルでのパケットフィルタリングのレイテンシを極小化できる。些細な差に見えるかもしれないが、マイクロサービス間通信が数万QPSを超える環境では、このCPUサイクルすら惜しい。
—
2. ステートレスの代償：エフェメラルポートの悪夢
NACLがSGと決定的に異なるのは「ステートレス」であるという点だ。SGは接続状態（コネクショントラッキング）を保持してくれるため、インバウンドの許可だけで戻りのアウトバウンドパケットも自動的に許可される。
だが、NACLは違う。「戻りのパケット」もルールとして明示的に許可しなければならない。
ここで問題になるのが、クライアント側が使用する「エフェメラルポート（一時的なポート番号）」だ。
エフェメラルポートの範囲（Linuxのデフォルト例）
多くのLinuxディストリビューションでは、net.ipv4.ip_local_port_range は 32768 から 60999 に設定されている。もし、パブリックサブネットにあるEC2がアウトバウンド通信を開始し、その戻りパケットをNACLで拾い上げるには、この範囲をインバウンドの許可ルールとして定義する必要がある。
# NACLのインバウンド設定例（戻りトラフィック用）
# ルール番号: 150
# 許可対象: TCP
# 範囲: 32768-60999
# これを忘れると、TCP 3-way handshakeのSYNは届いても、
# 戻りのSYN/ACKがNACLの出口で遮断され、通信がタイムアウトする。これを怠ると、ハンドシェイクが完了せず、TCPバッファが溢れ、バックログが詰まる。TLSハンドシェイクにおいては、RTT（往復遅延時間）の増加がそのままユーザー体験の悪化に直結するため、この「NACLの戻り許可設定」はネットワークのパフォーマンスチューニングにおいて最初に見直すべき項目の一つだ。
—
3. パフォーマンスとセキュリティの最適化戦略
NACLを運用する上で、以下のテクニックは現場の知見としてぜひ持っておいてほしい。
① TCPウィンドウサイズとバッファの整合性
パケットロスが発生した際、NACLで無駄な評価が重なっていると、再送処理（Retransmission）のオーバーヘッドが大きくなる。高スループットを求めるなら、sysctl でTCPバッファ（rmem, wmem）を調整しつつ、NACLの評価ルールを最小限に絞り、フィルタリングのオーバーヘッドを極限まで排除すべきだ。
② ヘッダーとハンドシェイクの最適化
TLS 1.3が主流の今、ハンドシェイクのRTTは削減されている。しかし、NACLの設定不備によりパケットが廃棄されると、クライアントはTCP再送を試みる。これが数回繰り返されるだけで、TLSの0-RTT接続のメリットは霧散する。
③ 脆弱性回避のための「最小権限」
セキュリティの観点から言えば、NACLは「多層防御の最後の砦」だ。
0.0.0.0/0を不用意に開けない。- セキュリティグループで解決できることはセキュリティグループに任せる。
- NACLは、サブネットレベルでの「明確な境界隔離（例：DMZとPrivateの完全隔離）」にのみ使用する。
—
SREとしての結論
NACLは、現代の柔軟なクラウドネットワークにおいて「原始的で無慈悲なツール」だ。しかし、だからこそ最も信頼できる。SGがコンテナやインスタンスのIDに基づいた動的な保護を行うのに対し、NACLはL4のパケットヘッダーを読み解く「静的かつ決定論的なルール」に基づいて動作する。
もしあなたがインフラのパフォーマンスを極め、かつ誰にも突破されない堅牢なVPCを構築したいのであれば、NACLを「面倒な設定」と捉えるのではなく、「ネットワークトラフィックを制御するカーネルに近いレイヤーの武器」として捉えてほしい。
パケットがNICを通過するその一瞬、あなたの書いたルールが光速で評価され、通信の可否が決まる。その責任の重さを、ぜひコードを通じて楽しんでいただきたい。
コメント