クラウドの世界へ足を踏み入れたばかりの皆さん、こんにちは！インフラの裏側を覗き見するのが大好きなSREの筆者です。
AWSやGCPといったパブリッククラウドを触り始めると、必ずと言っていいほど直面するのが「ネットワークの壁」ですよね。「パブリックサブネット」や「プライベートサブネット」、そして外の世界と繋ぐための「NATゲートウェイ」……。なんとなく言葉は聞いたことがあっても、いざ自分で構築しようとすると、「あれ？ なぜ通信できないんだ！？」と頭を抱えてしまうことはありませんか？
特に、セキュリティの要である「ネットワークACL（NACL）」の設定でハマる初心者は後を絶ちません。「ルールを入れたはずなのに、なぜか戻りの通信がブロックされる！」というトラブルは、現場でも本当によくあるお話です。
今回は、このNACLの最大の特徴である「ステートレス（状態を保持しない）なパケット処理」の仕組みを、身近な例えを交えながら、一歩ずつ優しく紐解いていきましょう！
—
1. 郵便配達で例える「ステートレス」と「ステートフル」
ネットワークの世界には、大きく分けて「ステートフル」と「ステートレス」という2つの性格（処理方式）が存在します。難しく聞こえますが、身の回りの仕組みに置き換えると一発で理解できますよ。
ステートフル（セキュリティグループの性格）＝「常連さんを覚えている名バーテンダー」
クラウドのセキュリティグループ（SG）はステートフルです。これは、「行き（外への通信）を許可したなら、その返事（戻りの通信）は、自動的に許可してあげるね」という親切設計です。バーテンダーが「さっきカクテルを注文したお兄さんだから、お代わりを持ってきても怪しくないな」と顔を覚えている状態ですね。
ステートレス（ネットワークACLの性格）＝「毎回、身分証の提示を求める厳格な入国審査官」
一方、今回主役にするネットワークACLはステートレスです。ステートレスとは、文字通り「状態（過去のやり取り）を一切記憶しない」という意味です。
入国審査官を想像してください。あなたが外国から国に入るとき（行き）、厳重なチェックを受けて入国しますよね。では、用事を済ませて出国し、再び同じゲートから戻ってきたとき、さっき通った審査官はどう言うでしょうか？
「さっき通った顔だからどうぞ」とは言ってくれません。「行きと同じように、戻るときももう一度、最初からパスポートとビザを出しなさい！」と、容赦なく呼び止められます。
ネットワークACLは、まさにこの厳格な入国審査官です。パケットがサブネットの境界線（門番）を通るたびに、「行き」のルールだけでなく、「戻り」のルールさえも個別にチェックします。この「過去の記憶を一切持たない」という特性が、設定ミスを誘発しやすい最大の罠なのです。
—
2. NATゲートウェイと「一時ポート（エフェメラルポート）」の切ない関係
では、プライベートサブネットにあるサーバーが、NATゲートウェイを経由してインターネットへお出かけし、無事に帰ってくるまでの流れを見てみましょう。ここからが本番ですよ！
通信が外に出ていくときの一連の流れ
1. プライベートサブネットのアプリサーバーが、「インターネットの天気予報を見たいな」と思いました。
2. サーバーは、宛先をインターネット上の公開サーバー（例: 8.8.8.8 のポート 443）にしてリクエストを送ります。
3. このとき、サーバー自身の送信元ポート番号として、OSが空いている適当な番号（例: 50000番など）を勝手に割り当てます。この使い捨てのポート番号を一時ポート（エフェメラルポート、通常 1024〜65535 の範囲）と呼びます。
4. パケットはNATゲートウェイを通過し、IPアドレスをNATゲートウェイのものに書き換えてもらい、インターネットへ飛び出します。
さあ、問題の「戻りパケット」です！
インターネット側のサーバーからお返事（レスポンス）がやってきました。
パケットはNATゲートウェイを通り、あなたのサブネットの境界線（ネットワークACL）に到達します。このときのパケットの宛先は、先ほどサーバーが割り当てた「一時ポート（50000番）」です。
ここで、ネットワークACLの「インバウンド（入ってくる通信）ルール」が火を吹きます。
ネットワークACLは過去の記憶がないため、「お、外から50000番宛てのパケットが来たぞ。でも、俺のインバウンドルールに『50000番を受け入れて良い』って書いてあるか？」と確認します。
もし、ここでインバウンドルールに一時ポートの許可が漏れていると、「怪しい通信だ！」と判定され、容赦なくパケットは捨てられてしまいます（ドロップ）。 行きがいくら許可されていても、戻りが通れなければ通信は永遠に成立しません。これが「NACL地獄」の正体です。
—
3. 実務で必須！ネットワークACLの正しい設定例と注意点
「じゃあ、戻りの通信を通すために、インバウンドルールにどのポートを書けばいいの？」という疑問がわきますよね。
エフェメラルポートの範囲はOSによって異なりますが、現代のLinux（Amazon Linuxなど）の多くは 32768 から 65535（古いシステムやWindows等では 1024 から）を使用します。
ここでは、AWSのVPC環境を想定した、安全かつ確実なネットワークACL（インバウンド）の設定例をコード（Terraform風のイメージ）で見てみましょう。実務の現場でもそのまま考え方を流用できます。
# =====================================================================
# ネットワークACL (インバウンドルール) の設定サンプル
# =====================================================================
# ルール番号 100: 外部からの通常のWebアクセス（HTTPS）を受け入れる
# （※パブリックサブネットでWebサーバー等を動かす場合に必要）
rule_number = 100
protocol = "tcp"
rule_action = "allow"
cidr_block = "0.0.0.0/0"
from_port = 443
to_port = 443
# ルール番号 200: プライベートサブネットがインターネットから「戻りパケット」を受け取るための設定
# ★ここが今回の最重要ポイントです！OSが使う一時ポートの範囲を全て許可します。
rule_number = 200
protocol = "tcp"
rule_action = "allow"
cidr_block = "0.0.0.0/0"
from_port = 32768
to_port = 65535
# ルール番号 300: すべての拒否ルール（NACLは上から順番に評価されるため、最後にこれを置くのが鉄則）
rule_number = 300
protocol = "-1" # すべてのプロトコル
rule_action = "deny"
cidr_block = "0.0.0.0/0"💡 現場のSREからのアドバイス
「一時ポートの範囲を広く開けるのって、セキュリティ上危なくないの？」と心配になるかもしれません。
ですが、ご安心ください！前段でお話しした通り、ネットワークACLは「サブネット全体」の境界線です。さらに、その内側には個別のサーバーを守る「セキュリティグループ」という強力なステートフルの盾がもう一枚構えています。
NACLで一時ポートの受入を許可しておきつつ、実際の細かいアクセス制御はセキュリティグループに任せるというのが、クラウドインフラ設計の黄金律（ベストプラクティス）です。
—
4. まとめ：一歩ずつ、パケットの流れを想像できるようになろう！
今回は、NATゲートウェイにおけるネットワークACLのステートレス処理と、一時ポートの切ない関係について解説しました。最後に、今日のポイントを振り返ってみましょう。
- ネットワークACLは「ステートレス（状態を保持しない）」：行きだけでなく、戻りのパケットも毎回ルールで明示的に許可してあげる必要がある。
- NATゲートウェイを通る通信の帰り道：サーバーが勝手に決めた「一時ポート（エフェメラルポート）」宛てに戻ってくるため、その範囲（例:
32768-65535）をインバウンドルールで許可しなければならない。 - 迷ったら「パケットの旅」を想像する：パケットが今どこを走っていて、門番（NACL）に何を見せる必要があるのかを思い浮かべると、トラブルシューティングが一気に得意になります！
インフラの世界は、最初は呪文のような用語が多くて圧倒されてしまうかもしれませんが、一つひとつの仕組みを身近な例えに落とし込んでいけば、必ずスッと腑に落ちる瞬間がやってきます。
「あれ、通信できないな？」と思ったときは、焦らずに「おっと、この厳格な入国審査官（NACL）は、戻りのパスポートを見てくれたかな？」と心の中でつぶやいてみてくださいね。
それでは、また次回のテック解説でお会いしましょう！快適なクラウドライフを！
コメント