今日は、ACLの設定そのものというより、確認コマンドの見方とトラブルシュートの流れを中心に整理しました。
ACLは設定して終わりではなくて、実際にpingが通らなかったときに「どこを見ればいいのか」が分からないと、かなり混乱しやすいと感じました。自分も最初は、ACLのルールだけ見てしまって、インターフェースの向きや適用場所まできちんと確認できていませんでした。
今回あらためて大事だと思ったのは、ACLは上から順に評価されることと、最後には implicit deny（暗黙の拒否） があることです。つまり、どのルールにも当てはまらなかった通信は最後に自動で拒否されるので、permitを書き忘れるだけで通信が止まることがあります。ここは毎回意識しておきたいポイントです。
今回、自分の中で特に整理したかったこと
今日は次の4つを意識して確認しました。
show access-listsの見方を理解することshow ip interfaceで ACL の向きを確認できるようになること- ping 不通のときに順番に切り分けること
- Standard ACL と Extended ACL で起こりやすいミスを整理すること
💬 学習メモ
ACLでつまずくときは、難しい設定というより、向きの見間違いやpermitの入れ忘れのような基本的な部分で引っかかることが多い。
まずは確認コマンドを3つ覚える
今回の学習では、ACL確認のときにまず見るコマンドはこの3つだと整理しました。
show access-listsshow ip interfaceshow running-config
この3つを見れば、ACLの中身、どこに入っているか、全体設定をひと通り確認できます。自分の中では、ACLトラブル時の基本セットとして覚えておきたいです。
show access-lists でルールの当たり方を見る
show access-lists は、ACLの中身を確認するときに一番よく見るコマンドだと感じました。特に大事なのは、どのルールに何回当たったかが見えるところです。
見るときは、次のあたりを意識すると分かりやすかったです。
- ACL番号、またはACL名
permitとdenyの順番hostやanyの指定matchesの回数
たとえば、次のような表示です。
Standard IP access list 1
10 deny host 192.168.10.10 (5 matches)
20 permit any (12 matches)この表示なら、192.168.10.10 を拒否するルールに5回当たった、それ以外を許可するルールに12回当たった、という見方になります。こういうふうに見ると、「どのルールが実際に働いているのか」がかなり分かりやすくなります。
💬 学習メモmatches が増えていれば、そのルールは実際に使われていると考えやすいです。逆に増えていなければ、そもそもそこを通っていないか、向きや条件がずれている可能性がある。
show ip interface で ACL の向きを確認する
今回特に大事だと感じたのが、show ip interface です。ACLはルールの内容だけ見ても不十分で、どのインターフェースに、どちら向きで入っているかを見ないと正しく判断できないと実感しました。
たとえば次のような表示なら、
GigabitEthernet0/0 is up, line protocol is up
Inbound access list is 100
Outgoing access list is not setG0/0 に ACL 100 が in 側で適用されているという意味になります。自分は最初、この in / out を感覚で考えてしまって混乱したので、今後はここを必ず確認しようと思います。
💬 学習メモin は「入ってくるときに確認」、out は「出ていくときに確認」です。ここを逆に考えると、ACLの内容が合っていても期待通りに動かないので要注意。
show running-config で最後に全体を見直す
show running-config は、個別コマンドだけでは分からないときに、最後に全体を見るためのコマンドとして便利です。ACLそのものの定義だけでなく、ip access-group がどこに入っているかもまとめて確認できます。
たとえば、次のような点を見直すとよさそうです。
- 古いACLが残っていないか
- 同じ番号ACLを意図せず使っていないか
- 別のインターフェースに
ip access-groupが入っていないか
「設定したつもり」と「実際に入っている設定」が違っていることは普通にありそうなので、困ったときほど最後に全体を見直すのが大事です。
ACLを見るときにまず意識したいこと
今回あらためて整理できたのは、ACLは上から順に見て、最初に一致したルールだけが使われるということです。後ろに書いたルールは、前で一致した時点でもう見られません。
そのため、上の方に広い permit を書いてしまうと、下の deny が効かないことがあります。逆に、必要な permit を入れ忘れると、最後の implicit deny（暗黙の拒否） で止まってしまいます。ここは、頭では分かっていても実際の確認時に忘れやすいと感じました。
💬 学習メモ
implicit deny（暗黙の拒否）は、設定に書いていなくても最後にある前提で考える必要があるので、「permit any を入れていないから全部止まった」という見方がすぐできるようにしておきたい。
また、配置場所の基本として、Extended ACL は送信元側に近く、Standard ACL は宛先側に近く置くのが基本だと再確認しました。Standard ACL は送信元IPだけで判断するため、送信元の近くに置くと止めすぎやすいからです。
ping が通らないときの確認手順
ping が失敗すると、ついACLのルールそのものばかり見てしまいますが、実際にはもっと基本的なところから順に見たほうがよいです。
1. まずはIP設定を確認する
最初に見るのは、ACLより前の基本設定です。
- IPアドレス
- サブネットマスク
- デフォルトゲートウェイ
- インターフェースの
no shutdown
ここが間違っていると、ACL以前の問題なので、まずは土台を確認するのが大事です。
2. ACL の場所と向きを確認する
次に、show ip interface でACLの適用場所と向きを確認します。インターフェースが合っているか、in / out が合っているかを見る流れです。
3. matches を確認する
その次に、show access-lists で matches を確認します。deny の回数が増えていれば、そのルールで止まっている可能性が高いです。逆に増えていなければ、方向が違うか、条件がずれているか、そもそもそこを通っていないかもしれません。
4. 全体設定を見直す
最後に show running-config で設定全体を確認します。余計なACLが残っていないか、別の場所に ip access-group が入っていないかを見ると、見落としに気づきやすです。
5. ping は往復通信だと考える
ここも今回あらためて意識したいと思った点です。ping は、行きだけ通ればよいわけではなく、echo request と echo reply の両方が通ってはじめて成功します。
そのため、「片道だけ許可したつもり」でも、戻りが止まれば結果として ping は失敗します。実際の確認では、片道だけを見て安心しないようにしたいです。
💬 学習メモ
ping は往復で考える、というのはシンプルですが大事でした。request と reply のどちらが止まっているのかを意識すると、原因が見えやすくなる。
Standard ACL で起こりやすいこと
Standard ACL は、送信元IPアドレスだけで判断するので、思ったより広く止まってしまうことがあると感じました。
たとえば、「PC-A から PC-B だけ止めたい」と考えても、Standard ACL では細かい制御がしにくいので、PC-A から出る他の通信まで影響を受けることがあります。
また、permit any を忘れると、最後は implicit deny（暗黙の拒否） なので、残りの通信も止まります。Standard ACL はシンプルな分、止まり方も大ざっぱになりやすいです。
Extended ACL で起こりやすいこと
Extended ACL は細かく指定できる反面、条件を書き間違えるとそのまま通信不良につながりやすいです。
特に気をつけたいのは次のような点です。
- 送信元と宛先を逆に書く
- ICMP の種類を意識していない
inとoutの向きを逆にする
ping の場合は、echo と echo-reply を分けて考えないと、「片道だけ止めたつもりが結果として両方失敗した」ということも起こるので、ここは丁寧に見たいところです。
Extended ACL を設定するときは、誰が、誰に、どんな通信をするのかを一度紙などに書いて整理してから設定したほうが良さそうです。
Packet Tracer で確認するときの自分用チェックリスト
今後の実習で迷わないように、自分用の確認順としては次の流れで見たいです。
- IPアドレス、サブネット、GW を確認する
- インターフェースに
no shutdownが入っているか見る show ip interfaceで ACL の場所と向きを見るshow access-listsでmatchesを見るshow running-configで全体設定を見直す- ping は往復通信だと考える
- implicit deny（暗黙の拒否） を忘れない
- Standard ACL と Extended ACL の違いを意識する
最後に、自分の中で覚えておきたいこと
show access-listsでは、どのルールに当たったかを見るshow ip interfaceでは、どこにどの向きでACLが入っているかを見る- ACLは上から順に見て、最後は implicit deny（暗黙の拒否）
- ping は往復通信なので、行きと戻りの両方を見る
まとめ
今回は、ACLの設定を増やすというより、確認コマンドを使ってどう切り分けるかを整理できたのがよかったです。
特に、ACLの中身だけでなく、適用場所・向き・matches・全体設定まで見ることが大事だと実感しました。最初はややこしく感じますが、確認の順番を決めておけば、少しずつ落ち着いて見られるようになりそうです。
今後Packet TracerでACLを触るときも、まずはこの流れで確認していこうと思います。
コメント