ACL（アクセスリスト）は書けるようになったのに、思った通りに効かない——原因はたいてい「順番」でした。
標準ACLと拡張ACL
- 標準ACL … 送信元IPだけで許可/拒否。番号 1〜99。宛先に近い所に置くのが定石。
- 拡張ACL … 送信元/宛先IP・プロトコル・ポートまで指定できる。番号 100〜199。送信元に近い所に置く。
やりたいことに応じて使い分けます。細かい制御は拡張ACLです。
一番の罠：上から順に評価され、最初にマッチした行で確定
ACLは上から順に評価し、最初に合致した行で許可/拒否を決めて、それ以降は見ません。だから順番を間違えると、意図しない行で先にマッチしてしまいます。
! 悪い例: 先に全部許可してしまっている
access-list 100 permit ip any any
access-list 100 deny tcp any host 10.0.0.10 eq 23 ← 到達しない
上の permit ip any any で全部通ってしまい、下のtelnet拒否は評価されません。具体的なルールを上、広いルールを下に置くのが鉄則です。
暗黙のdeny
ACLの最後には、書いていなくても deny any が隠れています。1行でも許可を書くと、それ以外は全部拒否になります。「許可を並べたら、最後に必要な通信の許可漏れがないか」を必ず確認します。
適用の向き（in / out）
ACLはインターフェースに in（入ってくる方向）か out（出ていく方向）で適用します。向きを間違えると全く効きません。
interface Gig0/1
ip access-group 100 in
確認とデバッグ
show access-lists
で各行のマッチ回数（カウンタ）が見えます。「効いていないはずの行にヒットしている」「効くはずの行が0」などから、順番ミスや向き違いを切り分けられます。ACLは書く力より並べる順番を設計する力だと痛感しました。