「止まるはずが通っている」を解決する——ACLのトラブルシューティング

私のロードマップを使って勉強している方から、「ACLを設定したのに、止めたいパケットが普通に通ってしまいます」という相談をもらいました。

OSPFのトラブルと違い、ACLのトラブルは「動いていない」ではなく「意図と違う動きをしている」ことがほとんどです。

ACLは作った通りに動きます。
ただ、人間が書いた設定が「意図通りとは限らない」のです。
今回はその典型的なミスのパターンと診断の手順を整理します。

ACLトラブルの3大パターン

・ パターン1：ACLは設定されているのに何も効いていない
・パターン2：止めたいパケットが通ってしまう
・ パターン3：通したいパケットが止まってしまう


それぞれの原因は異なります。どのパターンかを最初に見極めてから診断に入ります。

まず確認すること——ACLの現状把握

どのパターンでも最初にやることは同じです。現在の設定と適用状況を確認します。
Router# show access-lists

ACLの全エントリとマッチカウントが表示されます。
マッチカウントがゼロのままであれば、そのエントリには一度もパケットが当たっていません。
止めたいパケットに対応するエントリのカウントが増えていなければ、条件の書き方が間違っているか、そもそもそのパケットがこのACLを通っていない可能性があります。
Router# show ip interface GigabitEthernet0/0

インターフェースにACLが正しく適用されているかを確認します。
Inbound access listとOutbound access listの欄に期待するACL名/番号が表示されているかを見ます。

パターン1：何も効いていない

最もシンプルな原因です。以下の2点を確認します。
インターフェースに適用されているか
show ip interfaceでACLがインターフェースに紐付いていない場合、作成しただけで適用を忘れています。
Router(config)# interface GigabitEthernet0/0
Router(config-if)# ip access-group 100 in

適用方向が合っているか
inとoutを間違えているケースです。制御したいパケットがどちらの方向に流れているかを再確認します。

パターン2：止めたいパケットが通ってしまう

エントリの順番を確認する
ACLは上から順に評価し、最初に一致したエントリで処理が決まります。

denyの前に広いpermitが書かれていると、目的のパケットがpermitに先に一致してしまいdenyに到達しません。

例：意図と逆になっている設定
Router(config)# access-list 1 permit 192.168.1.0 0.0.0.255
Router(config)# access-list 1 deny host 192.168.1.10   ← ここには届かない

denyは必ずpermitより前に書きます。
Router(config)# access-list 1 deny host 192.168.1.10   ← denyを先に
Router(config)# access-list 1 permit 192.168.1.0 0.0.0.255

ワイルドカードマスクを確認する
ワイルドカードマスクの書き間違いにより、意図した範囲が一致していないケースです。
0.0.0.255は「下位8ビットは何でもよい（/24のネットワーク全体）」を意味します。
0.0.0.0は「全ビット一致（ホスト単体）」を意味します。hostキーワードは0.0.0.0の省略形です。
確認はshow access-listsのマッチカウントで行います。カウントが増えないなら条件が一致していません。

拡張ACLの送信元/宛先の取り違えを確認する
拡張ACLは送信元と宛先の両方を指定します。この順番を逆に書いてしまうと意図通りに動きません。
access-list 100 deny tcp [送信元] [ワイルドカード] [宛先] [ワイルドカード] eq [ポート]

送信元と宛先の順番を必ず確認してください。

パターン3：通したいパケットが止まってしまう

暗黙のdenyを確認する
ACLの末尾には常にdeny anyが存在します。
明示的なpermitがなければ全てのパケットが破棄されます。
許可したいパケットが漏れなくpermitエントリに含まれているかを確認します。
特に注意が必要なのはOSPFや他のルーティングプロトコルのパケットです。
ACLをinboundに適用すると、ルーティングプロトコルのパケットも対象になります。
Router(config)# access-list 100 permit ospf any any
Router(config)# access-list 100 deny tcp any any eq 23
Router(config)# access-list 100 permit ip any any
適用場所が正しいか確認する
標準ACLと拡張ACLで適用場所の原則が逆です。
・ 標準ACL → 宛先に近い場所（outbound）
・ 拡張ACL → 送信元に近い場所（inbound）

拡張ACLを誤って宛先側のoutboundに適用すると、正しい条件を書いていても意図した制御にならない場合があります。

established——戻りパケットの制御

TCPセッションの戻りパケットだけを許可したい場面があります。
内側からの通信は自由にしつつ、外側からの新規接続は拒否するという構成です。
Router(config)# access-list 102 permit tcp any any established
Router(config)# access-list 102 deny tcp any any
Router(config)# access-list 102 permit ip any any

establishedキーワードはTCPヘッダーのACKビットまたはRSTビットが立っているパケットに一致します。
ACKが立っているということはすでに確立済みのセッションの戻りパケットであることを意味します。
新規接続（SYNのみのパケット）にはACKが立っていないため一致しません。

マッチカウントのリセット

テスト中にマッチカウントをリセットして動作を確認し直したいときは次のコマンドを使います。

Router# clear ip access-list counters
Router# clear ip access-list counters 100

番号を指定するとそのACLだけリセットできます。

トラブルシューティングの全体フロー

show ip interface [IF名]
└─ ACLが適用されていない → ip access-groupコマンドを確認

show access-lists
└─ マッチカウントがゼロ → ワイルドカード・プロトコル・ポートを確認
└─ permitのカウントが増えている → denyがpermitより前にあるか確認

通したいパケットが止まる
└─ 暗黙のdenyに落ちていないか → 明示的なpermitが抜けていないか確認
└─ 適用場所・方向を確認（標準はoutbound宛先側、拡張はinbound送信元側）

まとめ

ACLのトラブルは「設定が意図通りに書かれているか」の問題です。
確認の出発点はshow access-listsのマッチカウントです。
カウントが増えていないなら条件が当たっていない。
増えているのに意図と違う動きをしているなら順番か方向の問題です。
ACL3本柱——標準・拡張・トラブルシューティング——これで揃いました。

明日もお会いしましょう。
フォローしてお待ちください。

#CCNA #資格勉強 #相互フォロー