AWSネットワークの「門番」、NACLのルール評価順序を完全攻略しよう！
クラウドの世界に飛び込んだばかりの皆さん、こんにちは！
AWSのVPC（仮想プライベートクラウド）を触り始めると、必ずと言っていいほど直面するのが「セキュリティ」の壁ですよね。「セキュリティグループ」については聞いたことがあっても、その影に隠れた「NACL（ネットワークACL）」という存在に少し戸惑っている方も多いのではないでしょうか？
今日は、パケットたちがVPCという街を駆け巡る際、必ず通らなければならない「NACL」という名の厳格な検問所について、そのルール評価の仕組みを紐解いていきましょう。
NACLは「厳格な門番」である
NACLを理解するために、まずは身近な例えを使いましょう。
皆さんが住んでいるマンションの入り口に、一人の「とても几帳面な門番さん」が立っていると想像してください。その門番さんは、手元に「ルールが書かれたリスト」を持っています。
マンションに誰かがやってくると、門番さんはリストの1行目から順番にチェックを始めます。そして、「あ、この人の条件に合致した！」と分かった瞬間、その場で「入れ！」「ダメ！」を即決します。
重要なのは、「リストの途中までしか確認しない」という点です。たとえリストのずっと下のほうに、その人にとって都合の良いルールが書いてあったとしても、門番さんは最初に見つけたルールで判断を下してしまうのです。これが、NACLの「ルール番号順・最初の一致で確定」という仕組みの正体です。
—
ルール番号の「若さ」こそが正義
NACLでは、すべてのルールに「ルール番号（1〜32766の数値）」を割り振ります。この数字が小さいほど、リストの上位（つまり門番さんが最初に見る場所）に配置されます。
なぜ「番号」が必要なの？
もし、複数のルールが重複していたらどうなるのでしょうか？ 例えば、こんな状況を考えてみてください。
- ルール番号 100: 「192.168.1.50」からの通信を「拒否（DENY）」する
- ルール番号 200: 「192.168.1.0/24」からの通信を「許可（ALLOW）」する
もし、番号が逆だったら？
200番の「許可」ルールを先に読んでしまったら、その後で100番の「拒否」ルールがあっても、門番さんは既に「許可！」と判断を下した後なので、拒否ルールは無視されてしまいますよね。
だからこそ、「特に厳しいルール（拒否など）ほど、番号を若くしてリストのトップに置く」というのが、クラウド設計の鉄則なんです。
—
デフォルトルールの「最後の砦」
NACLには、自分で設定したルールの他に、どうしてもリストの最後には勝手に決まっている「最後のルール」が存在します。これには少し注意が必要です。
- 番号 32767（または「*」）: このルールは、「上記すべてに該当しなかった通信は、すべて拒否（DENY）する」という、門番さんの最終判断です。
つまり、ルール番号 100とか 200で「許可」や「拒否」を丁寧に書いていない通信が来ると、この最後のルールに引っかかって、問答無用で「通信拒否！」となってしまうわけです。
—
実践！AWS CLIでNACLを確認してみよう
言葉だけだと少し抽象的なので、実際にAWS CLIを使って「どうなっているのか」を覗いてみましょう。
# 特定のNACLのルールリストを表示するコマンド
aws ec2 describe-network-acls \
--network-acl-ids acl-0123456789abcdef0 \
--query 'NetworkAcls[].Entries'このコマンドを叩くと、以下のような情報が返ってきます（一部抜粋・簡略化しています）。
[
{
"RuleNumber": 100,
"Protocol": "6", # TCPプロトコル
"RuleAction": "allow", # 許可
"CidrBlock": "0.0.0.0/0",
"PortRange": {"From": 80, "To": 80} # 80番ポート（HTTP）を許可
},
{
"RuleNumber": 32767,
"RuleAction": "deny", # 最後は必ず拒否（何も書かないとここになる）
"CidrBlock": "0.0.0.0/0"
}
]この例では、100番のルールでHTTP通信を許可し、それ以外は 32767番のルールで弾く、という構成になっています。非常にシンプルですが、これこそがNACLの基本形です。
—
最後に：トラブルシューティングの極意
現場で「なぜか通信が繋がらない！」というトラブルに出くわしたとき、NACLが原因であることは意外と多いです。そんな時は、以下の手順で思考を整理してみてください。
1. 「門番」は誰か？: 通信経路上のNACLはどれか特定する。
2. ルールリストを上からなぞる: 該当するパケットは、何番のルールで「最初の判定」を受けているか？
3. 最後を確認する: 意図しないルールに引っかかって、そのままDENYされていないか？
NACLは、セキュリティグループのような「インスタンス単位のガードマン」ではなく、サブネット全体を守る「街の入り口の検問所」です。この広域を守る門番さんの性格（ルール番号の若い順に即決！）さえ理解していれば、ネットワークトラブルを解決する力は飛躍的にアップします。
一歩ずつで大丈夫です。まずはご自身の環境のNACLリストを眺めて、「このルールは、どの番号で決着がついているのかな？」と想像することから始めてみてくださいね！
それでは、良いクラウドライフを！
コメント