ACLとは何か

ACLは、ルーターやレイヤー3スイッチのインターフェースなどへ適用し、 通過するIPパケットを制御します。 条件として利用できる情報はACLの種類によって異なります。

ACLの主な利用目的

• 利用者ネットワークからサーバーネットワークへの通信を必要最小限にする
• 管理端末だけにSSHやSNMPを許可する
• 特定の送信元やプロトコルを遮断する
• NAT、QoS、ルート制御などで対象通信を識別する

ACLは基本的にステートレス

基本的なIP ACLは、通信セッションの状態を記憶せず、 パケットごとに条件を確認します。 そのため、行きの通信を許可しただけで、戻りの通信が自動的に許可されるとは限りません。

ACLがパケットを判定する流れ

ACLを理解するうえで最も重要なのは、 上から順に評価し、最初に一致したルールで処理を終了することです。

1. ACLの先頭行から条件を確認する 送信元、宛先、プロトコル、ポート番号などを順番に照合します。
2. 一致しなければ次の行へ進む 条件が合わない行は処理せず、次のACEを確認します。
3. 最初に一致したpermitまたはdenyを実行する 一致後は、それより下のルールを確認しません。
4. 最後まで一致しなければ暗黙のdeny ACL末尾には、設定画面に見えない拒否ルールがあるものとして動作します。

ACLは上から順に評価される

ルールの順序が変わると結果も変わる

10 permit tcp 192.168.10.0 0.0.0.255 host 192.168.20.10 eq 443
20 deny ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255
30 permit ip any any

10 deny ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255
20 permit tcp 192.168.10.0 0.0.0.255 host 192.168.20.10 eq 443
30 permit ip any any

暗黙のdenyとは

ACLの末尾には、明示していなくてもすべての未一致通信を拒否する条件があります。 IPv4拡張ACLでは、概念的には次の行が末尾に存在すると考えます。

deny ip any any

たとえば、ACLへ1行だけdeny tcp any any eq 23を設定した場合、 「Telnetだけ拒否して、その他は許可」とはなりません。 その他の通信はどのpermitにも一致せず、最後の暗黙のdenyで拒否されます。

標準ACLと拡張ACLの違い

IPv4 ACLの基本分類は、標準ACLと拡張ACLです。 最大の違いは、どの情報を条件にできるかです。

標準ACL

標準ACLは、基本的に送信元IPv4アドレスだけで判定します。 宛先やTCP/UDPポート番号を区別できないため、広い範囲の通信へ影響しやすい点に注意します。

ip access-list standard MGMT-SOURCE
 10 permit 192.168.100.0 0.0.0.255
 20 deny any

このACLは、送信元が192.168.100.0/24かどうかを判定できます。 「どの宛先への通信か」「SSHかHTTPSか」は区別できません。

拡張ACL

拡張ACLは、送信元と宛先に加えて、IPプロトコルやTCP/UDPポート番号などを指定できます。 実務でユーザーVLANとサーバーVLANの通信を制御するときは、拡張ACLを使う場面が多くあります。

ip access-list extended USER-TO-SERVER
 10 permit tcp 192.168.10.0 0.0.0.255 host 192.168.20.10 eq 443
 20 deny ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255
 30 permit ip any any

なぜ配置場所の基本が異なるのか

ワイルドカードマスクの読み方

Cisco IOSのIPv4 ACLでは、アドレス範囲を指定するときに ワイルドカードマスクを使用することがあります。

サブネットマスクから求める方法

連続したサブネットを指定する場合は、各オクテットを255から引くとワイルドカードマスクを求められます。

サブネットマスク       255.255.255.0
各オクテットを255から引く
ワイルドカードマスク     0.0.0.255

in・outの方向を理解する

ACLをインターフェースへ適用するときは、 inまたはoutを指定します。 この方向は、利用者やサーバーから見た方向ではなく、 ACLを設定する機器・インターフェースから見た方向です。

同じ通信でも、見るインターフェースで方向が変わる

Cisco IOSの設定例

構成と通信要件

名前付き拡張ACLを作成する

L3SW(config)# ip access-list extended VLAN10-IN
L3SW(config-ext-nacl)# 10 remark Permit HTTPS to Server-A
L3SW(config-ext-nacl)# 20 permit tcp 192.168.10.0 0.0.0.255 host 192.168.20.10 eq 443
L3SW(config-ext-nacl)# 30 remark Deny other traffic to server VLAN
L3SW(config-ext-nacl)# 40 deny ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255
L3SW(config-ext-nacl)# 50 remark Permit traffic to other destinations
L3SW(config-ext-nacl)# 60 permit ip any any
L3SW(config-ext-nacl)# exit

設定を1行ずつ読む

20行目を40行目より前へ置くことで、HTTPSだけを例外として許可しています。 40行目でサーバーVLANへのその他通信を止め、60行目で別宛先への通信を許可します。

ACLをインターフェースへ適用する

L3SW(config)# interface Vlan10
L3SW(config-if)# ip access-group VLAN10-IN in
L3SW(config-if)# end

VLAN 10の端末からL3スイッチへ入る通信を確認したいため、 VLAN 10のSVIへin方向で適用します。

シーケンス番号とremarkを使う理由

名前付きACLでは、シーケンス番号を使ってルールの順序を管理できます。 途中へ新しい条件を追加しやすくなるため、10、20、30のように間隔を空けて設定するのが一般的です。

L3SW(config)# ip access-list extended VLAN10-IN
L3SW(config-ext-nacl)# 15 permit icmp host 192.168.10.50 host 192.168.20.10 echo
L3SW(config-ext-nacl)# end

remarkはACLの目的を説明するコメントです。 「誰が、どこへ、何のために通信するのか」を残すと、変更作業や障害調査で判断しやすくなります。

ACLの確認コマンドとカウンター

ACLの内容を確認する

L3SW# show ip access-lists VLAN10-IN
Extended IP access list VLAN10-IN
    10 remark Permit HTTPS to Server-A
    20 permit tcp 192.168.10.0 0.0.0.255 host 192.168.20.10 eq 443 (25 matches)
    30 remark Deny other traffic to server VLAN
    40 deny ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 (7 matches)
    50 remark Permit traffic to other destinations
    60 permit ip any any (310 matches)

インターフェースへの適用状況を確認する

L3SW# show ip interface Vlan10
Vlan10 is up, line protocol is up
  Internet address is 192.168.10.1/24
  Inbound  access list is VLAN10-IN
  Outgoing access list is not set

ACLの内容が正しくても、別インターフェースへ適用されていたり、 in・outが逆だったりすると意図した通信を制御できません。

running-configを確認する

L3SW# show running-config | section ip access-list
L3SW# show running-config interface Vlan10

カウンターを使った切り分け

ACL障害の切り分け

ACLが原因と疑われる場合は、設定全体を眺めるだけでなく、 1つの試験パケットを具体化して追跡します。

1. 通信要件を確認する
   誰から誰へ、どのプロトコル・ポートを許可したいのかを明確にします。
2. 実際の経路を確認する
   ルーティングテーブルや構成図から、パケットがACL適用インターフェースを通るか確認します。
3. ACLの適用場所と方向を確認する
   対象インターフェースへin・outのどちらで設定されているか確認します。
4. ACLを上から順に手作業で照合する
   試験パケットが最初に一致する行を特定します。
5. matchカウンターを確認する
   試験通信によってpermitまたはdenyの値が増えるか確認します。
6. 戻り通信の経路とACLを確認する
   反対方向のACL、サーバー側ファイアウォール、非対称経路を確認します。
7. ACL以外の原因を確認する
   ルーティング、NAT、TCP待ち受け、サーバー設定などを切り分けます。

よくある原因1：ACLを作成したが適用していない

ip access-listでACLを定義しても、 ip access-groupでインターフェースへ適用しなければ通信へ影響しません。

よくある原因2：in・outを逆にしている

VLAN 10から機器へ入る通信を制御したいのに、VLAN 10のSVIへoutで適用すると、 VLAN 10へ戻る方向の通信を確認するACLになります。

よくある原因3：広い条件が先にある

10 permit ip any any
20 deny tcp 192.168.10.0 0.0.0.255 host 192.168.20.10 eq 23

すべてのIP通信が10行目へ一致するため、20行目は使用されません。 Telnetを拒否したい場合はdenyを先に配置します。

よくある原因4：暗黙のdenyで必要通信が止まる

新しいdeny行だけを追加し、「それ以外は今までどおり通る」と考えると、 permitされていない通信が暗黙のdenyで止まる場合があります。

よくある原因5：送信元ポートと宛先ポートを混同する

WebサーバーへのHTTPS通信では、クライアントの送信元ポートは通常動的な番号で、 サーバーの宛先ポートが443です。 基本的な許可条件では、宛先側へeq 443を指定します。

よくある原因6：戻り通信が別ACLで拒否される

行きのHTTPSが許可されても、反対方向のインターフェースに厳しいACLがあると、 Server-AからPC-Aへ返るTCPパケットが拒否されることがあります。

切り分けチェックリスト

• 送信元・宛先IPアドレスは実際の試験端末と一致しているか
• プロトコルはTCP・UDP・ICMPのどれか
• ポート番号は送信元側か宛先側か
• ワイルドカードマスクの範囲は正しいか
• より広いpermit・denyが上にないか
• ACL末尾の暗黙のdenyを考慮したか
• 正しいインターフェースへ適用されているか
• in・outは機器視点で正しいか
• 戻り通信にも別のACLがないか
• matchカウンターは試験通信で増加したか

調査結果の報告例

実務での設計・変更ポイント

1．通信要件を先に表へする

コマンドから考え始めるのではなく、送信元、宛先、プロトコル、ポート番号、許可・拒否を整理します。

2．最小権限を基本にする

必要な送信元、宛先、プロトコル、ポート番号だけを許可します。 ただし、要件が未整理のまま厳しくすると業務通信を止めるため、ログや現行通信を確認して段階的に設計します。

3．名前付きACL・remark・シーケンス番号を使う

VLAN10-INやMGMT-ACCESSなど、用途が分かる名前を付けます。 remarkにはチケット番号、対象システム、通信目的など、運用に必要な情報を残します。

4．変更前に影響範囲を確認する

• 現在のACL全体と適用インターフェース
• 追加行を挿入する位置
• 対象通信以外に一致する可能性
• 冗長機器や別経路にも同じ設定が必要か
• IPv4 ACLとIPv6 ACLの両方が必要か
• 作業後の正常性確認と切り戻し条件

5．変更前後のカウンターを記録する

ACL行が意図した通信へ一致しているかを証明するため、 作業前後のshow ip access-listsを取得します。 疎通結果だけでなく、どのpermit行へ一致したかまで確認すると、試験の根拠が強くなります。

ACLに関するよくある勘違い

自分の言葉で説明する課題

後輩から「ACLの設定は、permitとdenyを書くだけですか」と質問されました。 60秒程度で説明してください。