変更要約: 初版
5.2ACL によるインフラ保護
標準ACL（送信元IPのみで判定）と拡張ACL（送信元/宛先IP・プロトコル・ポートで判定）の違い、順次評価（上から順に最初に一致したエントリで確定）と末尾の暗黙のdeny、そしてどのインタフェースのどちら向きに適用するかという配置判断を扱います。名前付きACLでのシーケンス番号編集や、log による検証も含め、「意図した通信だけを通す」構成を組み立てられるようにします。
ACL はフィルタであると同時に「一致条件を書く言語」で、QoS の分類、PBR の対象指定、NAT の対象指定、access-class による管理アクセス制限、そして次節の CoPP のクラス定義まで、ENCOR のあらゆる場面で再利用されます。だからこそ評価の仕組み（順次・最初に一致で確定・末尾は暗黙のdeny）を体に入れておく必要があります。ENCOR で問われるのは「標準と拡張の定義」ではなく、「このACLをこの向きに当てると何が落ちるか」「なぜ意図した通信まで止まったのか」という診断です。
5.2.1標準ACLと拡張ACL
- 標準ACL（番号 1-99・1300-1999、または名前付き
ip access-list standard）は送信元IPアドレスだけで一致を判定する。宛先やポートを見られないため、特定サーバへのアクセスだけを止めるといった用途には使えない。粒度が粗い分、送信元に近い場所で当てると必要な通信まで巻き添えで落ちるため、伝統的に宛先に近い側へ配置する。 - 拡張ACL（番号 100-199・2000-2699、または
ip access-list extended）はプロトコル・送信元IP・宛先IP・送信元/宛先ポートなどで判定できる。permit tcp 10.1.1.0 0.0.0.255 host 10.9.9.10 eq 443のように意図を正確に表現できるため、送信元に近い側に置いて不要なトラフィックを早期に破棄するのがセオリー（無駄な帯域消費を避けられる）。 - マスクはワイルドカードマスク（0＝一致必須、1＝任意）で書く。サブネットマスクの反転であり、
10.1.1.0 0.0.0.255は /24 に相当する。単一ホストはhost 10.1.1.5、全体はanyと書ける。この反転を取り違えると、意図より広い/狭い範囲に一致してしまう。
5.2.2評価の仕組みと編集
- ACL は順次評価される＝上のエントリから順に照合し、最初に一致したエントリの permit/deny で処理が確定し、以降のエントリは評価されない。したがって広い条件を上に書くと下の細かい条件が永久に到達不能になる（例：
permit ip any anyを先頭に置くと以降の deny は無意味）。順序そのものがポリシーである。 - 全てのACLの末尾には暗黙のdeny（deny any）が存在し、どのエントリにも一致しなかったトラフィックは破棄される。つまり「1行 permit を書いただけ」のACLは、その1行以外の全通信を落とす。運用では意図を明示するため末尾に
deny ip any any logを書き、show access-listsのヒットカウントで想定外の遮断を検出する。 - 名前付きACLはシーケンス番号で個別編集ができ、
ip access-list extended WEB-IN配下で15 permit tcp ...と番号を指定して途中に挿入したり、no 30で1行だけ削除したりできる。番号付きACLでno access-list 101を打つとACL全体が消えるため、適用中のインタフェースが「暗黙のdenyだけのACL」を参照して全遮断、という事故が起きやすい。
5.2.3配置場所と方向の判断
- 適用は
interface配下のip access-group <name> in|outで行い、方向はルータ（そのインタフェース）視点で決める。inはそのインタフェースへ入ってくるトラフィック、outはそのインタフェースから出ていくトラフィックを指す。方向を逆にすると、意図した通信は通らず、止めたい通信は素通りする。 - 拡張ACLは送信元近く、標準ACLは宛先近くが原則。ただし ENCOR では原則の暗唱ではなく、戻りトラフィックまで考慮できるかが問われる。TCP セッションの戻りパケットは送信元/宛先ポートが逆転するため、片方向だけを許可した ACL を戻り側に当てると通信が成立しない。
establishedキーワードやリフレクシブ/ゾーンベースの状態管理で戻りを許可する。 - インフラ保護の定石として、境界での送信元アドレス検証（自組織のアドレスを送信元に詐称した外部からのパケットを入口で落とす）、
no ip directed-broadcast、そして管理平面へのアクセスはaccess-class、コントロールプレーンは CoPP（次節）と、面ごとに守りを分ける。データプレーンのACLだけでは装置自身のCPUは守れない。
順次評価＝上から順・最初の一致で確定、末尾は暗黙のdeny、標準は送信元IPのみ・拡張は送信元/宛先/プロトコル/ポート、方向はインタフェース視点の in/out が最頻出です。「通信が止まった」系の設問では、ACLの行順序（広い permit が上にある）、方向の取り違え、戻りトラフィックの考慮漏れ、暗黙のdenyで巻き添えの4つを順に疑ってください。
あなたは支店ルータで「支店LAN 10.20.0.0/16 からデータセンタの Web サーバ 10.9.9.10 の HTTPS だけを許可し、他は落とす」という要件を受け、拡張ACL permit tcp 10.20.0.0 0.0.255.255 host 10.9.9.10 eq 443 を1行書いて WAN インタフェースに out で適用しました。直後、Web は通るものの支店の DNS 解決と NTP 同期が全滅し、さらに運用端末からルータへの SSH も切れました。ここで「ACLが壊れている」と考えるのは的外れで、実際には書いた通りに動いているのが問題です。第一の原因は暗黙のdeny——1行の permit 以外はすべて末尾の deny any に落ちるため、DNS(53)・NTP(123)・その他の業務通信が巻き添えで破棄されました。正しくは必要なサービスを明示的に permit udp 10.20.0.0 0.0.255.255 host 10.9.9.53 eq 53 のように追加し、末尾に deny ip any any log を置いてヒットカウントで漏れを検出します。第二に、SSH が切れた理由は別の面の問題です。トランジットするトラフィックを制御するインタフェースACLは、装置自身宛て（管理平面）の通信の制御には向きません——管理アクセスの制限は line vty 配下の access-class で行うのが正しく、インタフェースACLで管理経路を塞いだのは副作用です。第三に、順序と方向の確認も欠かせません。out の向きは「このインタフェースから出ていく＝支店からDCへ向かう」方向なので要件には合致しますが、戻りの HTTPS 応答は反対方向であり、もし戻り側にも同種のACLを in で当てるなら established などで戻りを許可しなければセッションは成立しません。この一連の判断——暗黙のdenyの影響範囲を先に見積もる／面（データ・管理・コントロール）ごとに適切な道具を選ぶ／片方向だけでなく往復で考える——が ENCOR の ACL 問題の核心です。
| 観点 | 標準ACL | 拡張ACL |
|---|---|---|
| 番号範囲 | 1-99・1300-1999 | 100-199・2000-2699 |
| 一致条件 | 送信元IPのみ | プロトコル・送信元/宛先IP・ポート |
| 推奨配置 | 宛先に近い側（巻き添え回避） | 送信元に近い側（早期破棄） |
| 主な用途 | 簡易な送信元制限・`access-class` | サービス単位の制御・QoS/PBR/CoPP の分類 |
| 共通の落とし穴 | 末尾の暗黙のdenyで想定外遮断 | 広い permit を上に書き以降が到達不能 |
ひっかけ： 「ACLは全エントリを評価して最も一致度の高いものを選ぶ」は誤りです——最初に一致したエントリで確定し、以降は評価されません（ルーティングのロンゲストマッチとは別の原理）。また「permit を1行書けばその通信だけ制御され、他は影響を受けない」も誤り＝末尾の暗黙のdenyにより他は全て破棄されます。「装置自身へのSSHはインタフェースACLで制御するのが正しい」も誤りで、管理アクセスの制限は line vty 配下の access-class が適切です。
5.2.4この節のまとめ
- 標準ACLは送信元IPのみ（宛先近くへ）、拡張ACLはプロトコル/送信元/宛先/ポートで判定（送信元近くへ早期破棄）。マスクはワイルドカードで書く
- 評価は順次で最初の一致で確定し、末尾には暗黙のdenyがある。広い permit を上に置くと以降が到達不能になり、permit 1行だけのACLは他の全通信を落とす
- 方向はインタフェース視点の
in/out。戻りトラフィックを考慮し、管理平面はaccess-class、コントロールプレーンは CoPP と面ごとに道具を分ける
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 支店ルータのWANインタフェースに、拡張ACLの `permit tcp 10.20.0.0 0.0.255.255 host 10.9.9.10 eq 443` を1行だけ書いて `out` で適用した。直後から支店のDNS解決とNTP同期が失敗している。原因として最も適切なものはどれか。
Q2. 「10.1.1.0/24 からサーバ 10.9.9.10 への Telnet(23) を禁止し、それ以外の通信は許可する」要件でACLを作ったが、Telnet が依然として通ってしまう。設定は上から `permit ip any any` / `deny tcp 10.1.1.0 0.0.0.255 host 10.9.9.10 eq 23` の順である。最も適切な是正はどれか。
Q3. 本社ルータの内側インタフェースに拡張ACLを `in` で適用し、社内からインターネット上の任意のHTTPSサーバへの通信のみを許可した。社内からの接続開始は成功するが、外向きインタフェースにも同種のACLを `in` で当てたところ、既存セッションの応答が届かなくなった。最も適切な対処はどれか。