ACLの暗黙のdenyは、ACL末尾に明示されていなくても、どのpermit条件にも一致しないpacketを拒否する動作です。必要通信を止めないためには、通信要件からpermitを作り、rule順序、方向、hit counter、negative testまで確認します。
⭕️ネットワークエンジニアが
ACLで必ず理解した方がいいこと暗黙のdeny
ACLって、
permitを書くと
その通信を許可する。denyを書くと
その通信を拒否する。ここまでは分かりやすい。
でも地味に大事なのが、
ACLの最後には見えないdeny
があること。なので、… pic.twitter.com/FIoOje7IKl
— けんと＠設計構築チャンネル (@yeiquer12) 2026年5月8日
明示的に許可されていない通信はACL最後の暗黙のdenyで拒否されると示したポスト。
(出典：https://x.com/yeiquer12/status/2052692468509093999（X：明示的に許可されていない通信はACL最後の暗黙のdenyで拒否されると示したポスト。）)
ACLの暗黙のdenyとは？
先に答えると、ACLの暗黙のdenyは、ACL末尾に明示されていなくても、どのpermit条件にも一致しないpacketを拒否する動作です。必要通信を止めないためには、通信要件からpermitを作り、rule順序、方向、hit counter、negative testまで確認します。
必要通信を止めないACLはどう設計する？
仕組みを構成上の位置と観測点に分けると、用語だけでなく実際のpacket・stateを説明できます。
| 項目 | 仕組み・役割 | 実務での判断 |
|---|---|---|
| explicit permit | 要件に一致する通信を許可 | source/destination/protocol/port |
| explicit deny | 拒否を可視化・log化 | log量とCPU影響に注意 |
| implicit deny | どのentryにも不一致 | ACL末尾で拒否 |
| first match | 上から最初に一致したruleを適用 | 広いruleの位置に注意 |
packet → ACE 10 match? → ACE 20 match? → ... → implicit deny
YES permit YES deny NO MATCH = droprule順序と適用方向をどう確認する？
rule順序と適用方向をどう確認する？では、対象と期待値を固定し、状態取得、実通信、変更後確認の順に進めます。commandは例であり、本番投入前に対象OSの公式資料と現行設定を確認してください。
| STEP | 実施内容 | 確認する結果 |
|---|---|---|
| 1 | 通信要件を5-tupleと方向へ分解 | 曖昧な『Web通信』を避ける |
| 2 | 既存ruleとshadow/overlapをreview | 上位ruleの影響 |
| 3 | 変更前counterとlogを保存 | 現在利用中の通信を把握 |
| 4 | allow・deny・既存通信を試験 | hit entryと実通信を一致 |
ip access-list extended WEB-IN
10 permit tcp 192.0.2.0 0.0.0.255 host 203.0.113.10 eq 443
90 deny ip any any log
! 90を省略しても末尾は暗黙にdeny
interface GigabitEthernet0/1
ip access-group WEB-IN in
show ip access-lists WEB-INExtended IP access list WEB-IN
10 permit tcp 192.0.2.0 0.0.0.255 host 203.0.113.10 eq 443 (24 matches)
90 deny ip any any log (3 matches)暗黙のdenyで止まった通信をどう切り分ける？
一つの表示だけで原因を決めず、症状ごとに次の観測点を選びます。正常時の同条件出力が比較基準です。
| 症状・誤り | 主な原因候補 | 次に確認すること |
|---|---|---|
| 必要通信がdeny | permit漏れ・address/port誤り | deny logとpacket tuple |
| 追加permitが効かない | 上位denyに先に一致 | sequence順とcounter |
| counterが増えない | interface/方向/経路違い | show run interfaceとroute |
| log過多 | deny any logの大量traffic | rateと必要なlog範囲 |
変更後にどの試験を行う？
本番でpermit anyを一時追加して原因確認する方法は、不要通信まで開放します。まず拒否log、counter、captureでpacket条件を特定し、必要最小限のpermitと明確な削除条件をreviewします。
- 対象機器・interface・VRF/VLAN
- 取得日時・timezone・software version
- 変更前後の同一command出力
- 期待値・実測値・判定者
- 異常時の停止条件とrollback結果
関連する仕組みを次に確認する
定義だけで終わらせず、隣接する仕組みと障害切り分けへ進みます。
まとめ：通信要件を具体的なACEへ変換し、暗黙denyまで試験する
通信要件を具体的なACEへ変換し、暗黙denyまで試験することが結論です。構成図、設定・command、正常時と異常時の結果を同じ条件で保存し、第三者が判断を再現できる状態にしてください。
