【SRE現場の知恵】AWSのNACLでなぜ「エフェメラルポート」を開放しなきゃいけないの？郵便配達で例えてみた
こんにちは！クラウドインフラの深淵を覗き続けているSRE兼アーキテクトです。
AWSでネットワークを構築していると、避けて通れないのが「NACL（ネットワークACL）」という関門ですよね。特に「セキュリティグループはステートフル（通信の状態を覚えていてくれる）なのに、なぜNACLはステートレス（覚えてくれない）なのか？」という壁にぶつかり、頭を抱えた経験はありませんか？
今回は、その中でも特に初心者泣かせの「エフェメラルポート（一時的なポート）」の開放要件について、郵便配達の流れを例えに、泥臭く、でも優しく解説していこうと思います。
—
ステートレスなNACLは「超厳格な門番」
まず、セキュリティグループとNACLの違いを整理しましょう。
- セキュリティグループ（ステートフル）： 「一度通した通信の『帰り道』は自動的に許可するよ！」という、気の利く門番です。
- NACL（ステートレス）： 「行くとき（往路）」と「帰ってくるとき（復路）」は別々の通信として扱う、融通の利かない厳格な門番です。
NACLの世界では、「行き」の許可設定があっても、「帰り」の許可設定がなければ、戻ってきたパケットは門前払い（ドロップ）されてしまいます。
ここで登場するのが「エフェメラルポート」という考え方です。
—
エフェメラルポートを「差出人の控え室」に例える
あなたが誰かに手紙を送るシーンを想像してください。
あなたが手紙を出すとき、相手の住所（宛先IP）と相手の郵便受け（宛先ポート：例えば 80 や 443）を指定しますよね。
でも、返事をもらうためには、相手に「返信はここ（私の自宅）に送ってね！」と伝える必要があります。この「返信を受け取るための窓口」が、あなたのPCでランダムに割り当てられるエフェメラルポート（一時ポート）なのです。
1. 送信： あなた（送信元）の「49152番の窓口」から、サーバーの「443番の窓口」へ手紙を出す。
2. 処理： サーバーが返事を書く。
3. 返信： サーバーがあなたの「49152番の窓口」へ向けて返信を投げる。
ここでNACLという門番はこう言います。
「おい、サーバーから返事が戻ってきたぞ！でも、この 49152 番という窓口への通信は許可リストに書いてないな。ルール違反だ、捨ててしまえ！」
これが、通信が繋がらない原因です。サーバーからの返信を受け取るためには、この「一時的に使われる広大なポート範囲」をあらかじめ許可しておく必要があるのです。
—
設定すべきエフェメラルポートの範囲
AWSの環境によって、この「エフェメラルポート」が使用する範囲は異なります。今の主流なOSやサービスでは、以下の範囲を使います。
- Amazon Linux 2 / 2023:
1024～65535 - Windows Server 2008以降:
49152～65535 - ALB（Application Load Balancer）:
1024～65535
これらを考慮すると、「とりあえず 1024 ～ 65535 を許可しておけば、大抵のトラブルは回避できる」というのが、現場のSREたちが辿り着く現実的な解です。
—
Terraformによる実践的な設定例
実際にTerraformを使って、プライベートサブネットの戻り通信を許可するNACL設定のサンプルを見てみましょう。
# プライベートサブネット用のインバウンドルール（戻り通信の許可）
resource "aws_network_acl_rule" "inbound_ephemeral" {
network_acl_id = aws_network_acl.private.id
rule_number = 100
egress = false # インバウンド（戻り）の通信
protocol = "tcp"
rule_action = "allow"
cidr_block = "0.0.0.0/0" # どこから戻ってきてもいいように
from_port = 1024 # エフェメラルポートの開始
to_port = 65535 # エフェメラルポートの終了
# コメント：インターネットからの応答パケットを受け入れるために必須
}—
最後に：初心者が陥りがちな罠
最後に一つだけアドバイスを。NACLの設定は「ルール番号」が小さい順に適用されます。
もし、うっかり 1024-65535 を許可する前に、別の拒否ルール（deny）を番号の若い位置に書いてしまうと、その下の許可設定は一生無視されます。
1. ルール番号は慎重に： 許可系は 100 番台、拒否系は 200 番台など、あらかじめルールを決めておきましょう。
2. 「戻り」を忘れない： 自分が何か通信を許可するルールを作ったら、必ず「その通信の帰り道」も許可されているか、指差し確認してください。
ネットワークのトラブルシューティングは、パケットになったつもりで「私はどこから来て、どこへ帰るのか？」を追いかけるパズルです。最初は難しく感じるかもしれませんが、この仕組みを理解すれば、もうNACLは怖くありません。
明日からのクラウド構築が、少しでも快適なものになりますように！
コメント