ACLの暗黙の拒否は、ACL末尾に明示されていなくても、どのpermit条件にも一致しないパケットを拒否する動作です。必要通信を止めないためには、通信要件からpermitを作り、ルール順序、方向、hit カウンター、negative 試験まで確認します。
この記事はネットワークエンジニア転職完全ガイドの関連テーマです。工程の全体像から確認したい場合はそちらへ。
⭕️ネットワークエンジニアが
ACLで必ず理解した方がいいこと暗黙のdeny
ACLって、
permitを書くと
その通信を許可する。denyを書くと
その通信を拒否する。ここまでは分かりやすい。
でも地味に大事なのが、
ACLの最後には見えないdeny
があること。なので、… pic.twitter.com/FIoOje7IKl
— けんと＠設計構築チャンネル (@yeiquer12) 2026年5月8日
明示的に許可されていない通信はACL最後の暗黙のdenyで拒否されると示したポスト。
(出典：けんと＠設計構築チャンネルのポスト（X）（X：明示的に許可されていない通信はACL最後の暗黙の拒否で拒否されると示したポスト。）)
ACLの暗黙の拒否とは？
Cisco IOS／IOS XEのIPv4インターフェースACLは、上から最初に一致したACEのpermit／denyを適用し、最後まで一致しなかった通信を暗黙に拒否します。暗黙のdenyは設定一覧に行として書かれていなくても有効です。最初の広いpermitに一致すれば、それより下のdenyは評価されません。
ip access-list extended WEB-IN
10 permit tcp 192.0.2.0 0.0.0.255 host 203.0.113.10 eq 443
20 deny ip any any log| 通信 | 一致する行 | 結果 |
|---|---|---|
| 192.0.2.10 → 203.0.113.10 TCP/443 | 10 | 許可 |
| 同じ宛先へのTCP/22 | 20 | 拒否・ログ対象 |
| 20行を削除した場合のTCP/22 | 末尾の暗黙deny | 拒否。明示denyのログと同じ扱いにはならない |
deny ip any any logは暗黙拒否を可視化するための明示行ですが、大量のログを発生させることがあります。本番投入前にログ量とプラットフォームの処理負荷を検討してください。
根拠：Cisco IOS XE：Creating an IP Access List
必要通信を止めないACLはどう設計する？
「Web通信を許可」では、ACLの条件を確定できません。要件表を送信元IP・宛先IP・IPプロトコル・宛先ポート・適用方向まで分解します。戻り通信も、同じACLがどの方向で評価するかを確認します。
- 変更前のACL全文と適用インターフェースを保存する。
- 必要通信をACEへ変換し、既存の上位ACEに先に一致しないか確認する。
- 許可・拒否・既存通信の3種類を試験し、対象行のヒットカウンターと実通信を照合する。
- 暗黙denyで落ちる通信が業務上不要であることを、通信要件と突き合わせる。
単にpermit ip any anyを末尾へ足すと原因の特定前に不要通信まで許可します。切り分けはログ・カウンター・キャプチャを先に使います。
ルール順序と適用方向をどう確認する？
実施順は「通信要件を5-タプルと方向へ分解」から「許可・拒否・既存通信を試験」です。
| STEP | 実施内容 | 確認する結果 |
|---|---|---|
| 1 | 通信要件を5-タプルと方向へ分解 | 曖昧な『Web通信』を避ける |
| 2 | 既存ルールとshadow/overlapをレビュー | 上位ルールの影響 |
| 3 | 変更前カウンターとログを保存 | 現在利用中の通信を把握 |
| 4 | 許可・拒否・既存通信を試験 | hit ルールと実通信を一致 |
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)暗黙の拒否で止まった通信をどう切り分ける？
症状ごとの原因候補と、次に確認することを次の表にまとめます。正常時の出力と並べて差を見ます。
| 症状・誤り | 主な原因候補 | 次に確認すること |
|---|---|---|
| 必要通信が拒否 | permit漏れ・アドレス/ポート誤り | 拒否ログとパケットタプル |
| 追加permitが効かない | 上位拒否に先に一致 | sequence順とカウンター |
| カウンターが増えない | インターフェース/方向/経路違い | show run interfaceと経路 |
| ログ過多 | 拒否 any ログの大量トラフィック | rateと必要なログ範囲 |
変更後にどの試験を行う？
本番でpermit anyを一時追加して原因確認する方法は、不要通信まで開放します。まず拒否ログ、カウンター、キャプチャでパケット条件を特定し、必要最小限のpermitと明確な削除条件をレビューします。
- 対象機器・インターフェース・VRF/VLAN
- 取得日時・タイムゾーン・ソフトウェアバージョン
- 変更前後の同一コマンド出力
- 期待値・実測値・判定者
- 異常時の停止条件と切り戻し結果
関連する記事
まとめ：通信要件を具体的なACEへ変換し、暗黙拒否まで試験する
要点は、通信要件を具体的なACEへ変換し、暗黙拒否まで試験することです。拒否されたのが明示のdenyか暗黙のdenyかを、ログとsequence番号で区別します。
