ACLの暗黙のdenyとは？必要な通信を止めない設計と確認方法

ACLにはpermitの行しかないのに、ほかの通信が通らなくなった。これは、最後までどの行にも一致しなかった通信を拒否する「暗黙のdeny」があるためです。

暗黙とは、設定に一行として書いていなくても働く、という意味です。まず上からの評価を一つの通信で追い、そのあと必要な通信の漏れをどう確認するかを見ていきます。ここではCisco IOS／IOS XEのIPv4インターフェースACLを例にします。

最初に一致した行で、許可か拒否が決まる

ACLの一行をACEと呼びます。受信したパケットは上のACEから評価され、最初に一致した行のpermitかdenyが適用されます。一致しなければ次へ進み、最後まで一致しなかったものは暗黙に拒否されます。

例のTCP443を許可する行に合えば通りますが、同じIP間のTCP22やUDP443は別条件です。ほかの許可がなければ末尾まで進み、拒否されます。

ip access-list extended WEB-IN
 10 permit tcp 172.28.31.0 0.0.0.255 host 172.28.53.10 eq 443
 20 deny ip any any log

deny ip any any logを明示する方法はありますが、大量のログが出ることもあります。暗黙の拒否を調べるためのログ設定は、対象機種の負荷と通信量に合わせて検討します。

必要な通信を、IP・プロトコル・ポートへ分ける

「Webを許可する」だけでは、どの端末からどのサーバーへ、TCPなのかUDPなのかを決められません。送信元、宛先、プロトコル、必要なポート、方向を要件から書き出します。

DNSや監視、時刻同期など、業務通信を支える通信も確認します。HTTPSだけ通しても、名前解決ができなければ利用者には「開かない」と見える場合があります。

1. 変更前のACL全文と適用インターフェースを保存する。
2. 必要通信をACEへ変換し、既存の上位ACEに先に一致しないか確認する。
3. 許可・拒否・既存通信の3種類を試験し、対象行のヒットカウンターと実通信を照合する。
4. 暗黙denyで落ちる通信が業務上不要であることを、通信要件と突き合わせる。

単純なインターフェースACLは、FWのように接続状態をすべて自動追跡する仕組みではありません。戻り側にもACLがあるなら、返信がその方向で許可されるかを考えます。

必要な条件が決まれば、一つの要件をどのACEが受け持つか対応させられます。目的が分からない広いpermitを増やすより、確認しやすい設定になります。

ACL本文と、適用する場所・方向を合わせる

正しいACLを書いても、インターフェースへ適用していなければその場所で評価されません。逆向きや別のSVIへ適用した場合も、意図した通信を制御できません。

show ip interfaceで適用名とin/outを確認し、show ip access-listsで行順と内容を読みます。カウンターは試験前後を比較して、どの行に一致したかを調べます。

ip access-list extended WEB-IN
 10 permit tcp 172.28.31.0 0.0.0.255 host 172.28.53.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-IN

Extended IP access list WEB-IN
    10 permit tcp 172.28.31.0 0.0.0.255 host 172.28.53.10 eq 443 (24 matches)
    90 deny ip any any log (3 matches)

NATがあるなら、評価点で見えるIPが変換前か後かも必要です。端末のIPをそのままどのACLにも書けるとは限りません。

表示例の数値は説明用です。実際には機種のカウンター表示やハードウェア転送の仕様も確認し、一度の表示だけで通信を断定しないようにします。

通らない通信が、どの条件に合ったかを調べる

試験の送信元・宛先・プロトコル・ポートを確認し、上からどの行に一致するかを追います。想定したpermitの前にdenyがある場合も、permitの範囲が違う場合もあります。

該当行が見つからなければ、暗黙のdenyへ進む可能性があります。ただし、通信がそのACLの場所まで届いたかは、ログやキャプチャなどでも確認します。

試験失敗だけでは、ACLに拒否されたのか、経路がないのか、サービスが停止しているのかは決まりません。拒否した装置とルールを示せる証拠を合わせます。

原因確認のためにpermit ip any anyを足すと、関係のない通信まで許可してしまいます。まずパケットの条件と評価点を絞り、必要な許可へ直します。

通す試験と、止める試験を一組にする

変更後は、許可すべき通信、拒否すべき通信、既存の業務通信、戻り通信を確認します。許可一本だけの成功では、不要な通信まで通る状態を見逃します。

試験の期待値は実行前に書きます。実結果には端末の表示と、装置側のカウンターやログを残し、どこで判定したかを対応させます。

暗黙のdenyは、要件に書かなかった通信も止める仕組みです。末尾の存在を覚えるだけでなく、必要通信の洗い出し、行順、適用点、試験をつなげて考えてください。

短いACLを一つ選び、TCP443とTCP22がどの行まで進むかを紙で追うと、評価の順番をつかみやすくなります。

動画・筆者の投稿で補足する

文章と図で流れをつかんだら、関連する動画も参考にしてください。画面の表示や操作は、機種・ソフトウェアの版によって異なる場合があります。

関連する動画・筆者の投稿：2026年5月8日 ／ けんと＠設計構築チャンネルのポスト（X）

この記事の執筆・監修者

けんと＠設計構築チャンネル

ネットワーク設計構築エンジニア／インフラ転職コンパス編集者

30歳・IT未経験からSIerへ転職。ネットワークエンジニアとして、金融系・オフィス系ネットワークの設計・構築に携わり、PL・PMも経験。自身の未経験転職と現場経験をもとに、仕事内容・技術・キャリア・求人選びをわかりやすく解説しています。

YouTube登録者5,000人 Xフォロワー5,000人

執筆者プロフィール・編集方針