ip access-list extended とは？基本から理解する設定方法

By /

ip access-list extended とは？基本から理解する設定方法

はじめに

現代のネットワーク環境において、セキュリティは最も重要な要素の一つです。インターネットに接続されたネットワークは常に様々な脅威にさらされており、不正アクセス、マルウェアの侵入、情報漏洩といったリスクが存在します。これらの脅威からネットワーク資産を保護するために、様々なセキュリティ対策が講じられますが、その基本的な、しかし非常に強力なツールの一つが「アクセスリスト（Access Control List, ACL）」です。

アクセスリストは、ネットワーク機器（ルーターやスイッチなど）を通過するパケットに対して、許可（Permit）または拒否（Deny）のルールを定義し、トラフィックを制御するための機能です。特定の通信だけを許可したり、特定の通信をブロックしたりすることで、ネットワークへの不要なアクセスを防ぎ、セキュリティレベルを高めることができます。

アクセスリストにはいくつかの種類がありますが、この記事で焦点を当てるのは「拡張アクセスリスト（Extended Access List）」です。特にCiscoルーターなどで使用されるip access-list extendedコマンドに代表される、より柔軟で詳細なトラフィック制御を可能にするアクセスリストについて、その基本から応用、そして具体的な設定方法までを深く掘り下げて解説します。

標準アクセスリストが送信元IPアドレスのみに基づいてフィルタリングを行うのに対し、拡張アクセスリストは送信元IPアドレス、宛先IPアドレス、プロトコル（TCP, UDP, ICMPなど）、そしてポート番号といった、より多くの条件を指定してフィルタリングを行うことができます。このきめ細やかな制御能力が、拡張アクセスリストを今日の複雑なネットワーク環境において不可欠なツールにしています。

この記事では、拡張アクセスリストの基本的な考え方から始め、その構文、各種設定要素の意味、設定時の注意点、そして実際のネットワーク環境を想定した具体的な設定例を多数紹介します。読者が拡張アクセスリストを完全に理解し、自身のネットワーク環境で効果的に活用できるようになることを目指します。

アクセスリスト (ACL) の基本

拡張アクセスリストの詳細に入る前に、まずアクセスリスト全般の基本的な概念を理解しておきましょう。

ACLとは何か、なぜ使うのか

ACLは、ネットワークトラフィックをフィルタリング（選別）するためのルールの集合体です。ネットワーク機器（主にルーター）のインターフェイスにACLを適用することで、そのインターフェイスを通過しようとするパケットがACLのルールに合致するかどうかを検査し、許可するか拒否するかを決定します。

ACLを使用する主な目的は以下の通りです。

  1. セキュリティの向上:
    • 外部からの不正アクセスを防止する。
    • 特定のサーバーやサービスへのアクセスを制限する。
    • 内部ネットワーク間の不要な通信を制限し、被害の拡散を防ぐ。
    • 特定のプロトコルやアプリケーションの使用を制限する。
  2. トラフィック制御:
    • ネットワークリソース（帯域幅など）の利用を制御する。
    • 特定のトラフィック（例えばQoSやNATの対象トラフィック）を識別する。

ACLはネットワークエッジ（インターネットとの境界）だけでなく、内部ネットワークのセグメント間でも使用することで、より強固な多層防御を実現できます。

ACLの基本的な考え方

ACLは、複数のアクセス制御エントリ（Access Control Entry, ACE）、または単にルールと呼ばれる行から構成されます。これらのルールはリストとして定義され、パケットがACLを通過する際に、リストの先頭から順番に評価されます。

パケットが特定のルールにマッチすると、そのルールに定義されたアクション（許可または拒否）が実行され、それ以降のルールは評価されません。これを「First Match, First Action」と呼びます。つまり、ルールの順番は非常に重要です。より具体的なルール（特定のホスト、特定のポートなど）は、より一般的なルール（任意のホスト、任意のプロトコルなど）よりも先に記述する必要があります。

ACLの種類

ACLには主に以下の種類があります。

  1. 標準アクセスリスト (Standard ACL):
    • 送信元IPアドレスのみに基づいてフィルタリングを行います。
    • Ciscoでは通常、番号が1～99、または1300～1999の範囲で指定されます。
    • フィルタリング条件が限定的であるため、適用場所によってはネットワーク全体に影響を与える可能性があります。通常は宛先に近い場所（ルーターのインターフェイスの出方向）に適用することが推奨されます。
  2. 拡張アクセスリスト (Extended ACL):
    • 送信元IPアドレス、宛先IPアドレス、プロトコル、ポート番号など、複数の条件に基づいてフィルタリングを行います。
    • Ciscoでは通常、番号が100～199、または2000～2699の範囲で指定されます。
    • フィルタリング条件が詳細であるため、よりきめ細かい制御が可能です。通常は送信元に近い場所（ルーターのインターフェイスの入方向）に適用することが推奨されます。
  3. 名前付きアクセスリスト (Named ACL):
    • 標準または拡張ACLに名前を付けたものです。
    • 番号ではなく名前で指定するため、可読性が高く、ルールの編集や挿入が容易です。
    • Ciscoではip access-list standard <name>またはip access-list extended <name>という構文で定義します。現在では、番号付きACLよりも名前付きACLを使用することが推奨されています。

この記事で解説するip access-list extendedコマンドは、名前付き拡張ACLを定義するためのコマンドです。番号付き拡張ACLはaccess-list <番号>コマンドで定義しますが、機能的には名前付き拡張ACLとほぼ同じです。可読性や管理のしやすさから、名前付きACL（ip access-list extended <name>）を使うのが一般的です。本記事でも主に名前付き拡張ACLを中心に解説します。

ACLの適用方向と適用場所

ACLは、ルーターのインターフェイスに「入方向（in）」または「出方向（out）」として適用されます。

  • 入方向 (in): インターフェイスに入ってくるパケットに適用されます。パケットはルーティング処理の前にACLによって検査されます。パケットがルーターに入る直前にフィルタリングされるため、不要なパケットを早期に破棄し、ルーターのリソース消費を抑えることができます。
  • 出方向 (out): インターフェイスから出ていくパケットに適用されます。パケットはルーティング処理によって宛先インターフェイスが決定された後、そのインターフェイスから出ていく直前にACLによって検査されます。

標準ACLは送信元IPアドレスのみで判断するため、送信元に近い場所（入方向）に適用すると、そのルーターを経由する同じ送信元からのすべてのトラフィックがフィルタリングされてしまい、意図しない通信までブロックしてしまう可能性があります。そのため、標準ACLはフィルタリング対象の宛先に近い場所（出方向）に適用するのが一般的です。

一方、拡張ACLは送信元、宛先、プロトコル、ポート番号など、より詳細な条件で判断できるため、送信元に近い場所（通常はルーターのインターフェイスの入方向）に適用することが推奨されます。これにより、ネットワーク内部に入る前に不要なトラフィックをブロックでき、ネットワーク全体のセキュリティと効率を高めることができます。

ip access-list extended とは

ip access-list extended <acl-name>コマンドは、Cisco IOSなどのネットワークOSで、名前付き拡張アクセスリストを定義するために使用されます。このコマンドを実行すると、指定した名前の拡張アクセスリストを作成または編集するためのコンフィグレーションモードに入ります。

拡張ACLの定義

拡張ACLは、以下の要素を組み合わせてルールを定義します。

  • アクション: パケットを「許可（permit）」するか「拒否（deny）」するかを指定します。
  • プロトコル: 検査対象となるプロトコルを指定します。例えば、IP、TCP、UDP、ICMPなどです。特定のプロトコルを指定しない場合は、ipキーワードを使用することで、IPプロトコル全体を対象とします。
  • 送信元アドレス: パケットの送信元IPアドレスまたはネットワークを指定します。
  • 送信元ワイルドカードマスク: 送信元IPアドレスまたはネットワークのどの部分を一致させるかを指定します。
  • 宛先アドレス: パケットの宛先IPアドレスまたはネットワークを指定します。
  • 宛先ワイルドカードマスク: 宛先IPアドレスまたはネットワークのどの部分を一致させるかを指定します。
  • ポート番号（TCP/UDPの場合）: プロトコルがTCPまたはUDPの場合、送信元または宛先のポート番号を指定します。
  • その他のオプション: establishedキーワード（TCPセッション確立済みパケットの判断）、ICMPタイプ/コード、DSCP値、TTL値など、追加の条件を指定できる場合があります。

標準ACLとの決定的な違い

標準ACLは送信元IPアドレスとワイルドカードマスクのみを条件としますが、拡張ACLは上記のように非常に多くの条件を組み合わせることができます。これが両者の最も重要な違いです。

例えば、「特定のホストからのSSHアクセスのみ許可し、他のホストからのSSHアクセスは拒否する」といった制御は、送信元IPアドレスと宛先ポート番号（SSHは22番）を両方指定できる拡張ACLでなければ実現できません。標準ACLで同じことをしようとすると、特定のホストからのすべての通信を許可または拒否することになり、きめ細やかな制御ができません。

なぜ拡張ACLが必要なのか

現代のネットワークでは、様々なアプリケーションが多岐にわたるプロトコルやポート番号を使用して通信を行います。サーバーへのアクセス制御、特定のサービス（Web、メール、ファイル共有など）へのアクセス制限、P2Pアプリケーションのブロック、VoIPトラフィックの優先制御（QoSとの連携）など、ネットワーク管理者が行うべき制御は非常に複雑になっています。

拡張ACLは、これらの要件に対して、送信元、宛先、サービス（プロトコルとポート）といった、パケットの主要な情報を基にきめ細やかなフィルタリングルールを定義することを可能にします。これにより、必要な通信は許可しつつ、不要な通信やセキュリティリスクのある通信を正確にブロックすることができます。これは、ネットワークのセキュリティを強化し、リソースを効率的に利用するために不可欠です。

拡張ACLの基本的な構文

名前付き拡張ACLを定義するには、グローバルコンフィグレーションモードで以下のコマンドを使用します。

bash
Router(config)# ip access-list extended <acl-name>

<acl-name>は、ACLに付ける任意のおおよそ1～90文字の英数字（機種によって制限は異なる）の名前です。この名前を使って、後でACLを参照したり、インターフェイスに適用したりします。

このコマンドを実行すると、以下のようなACLコンフィグレーションモードに移行します。

bash
Router(config-ext-nacl)#

このモードで、ACLのルール（ACE）を1行ずつ定義していきます。ルールの基本的な構文は以下の通りです。

bash
Router(config-ext-nacl)# [sequence-number] {permit | deny} <protocol> <source> <source-wildcard> <destination> <destination-wildcard> [operator <port>] [established] [...]

各要素の詳細を見ていきましょう。

  • [sequence-number]: ルールのシーケンス番号（行番号）です。名前付きACLの場合、通常はこの番号を省略しても構いません。省略した場合、IOSは自動的に番号を振ります（デフォルトは10から始まり、10刻み）。番号を指定すると、既存のルールの間に新しいルールを挿入したり、特定のルールを削除したりする際に便利です。
  • {permit | deny}: パケットがこのルールにマッチした場合に、そのパケットを「許可する（permit）」か「拒否する（deny）」かを指定します。
  • <protocol>: 検査対象のIPプロトコルを指定します。以下のいずれかを指定します。
    • ip: すべてのIPプロトコル（TCP, UDP, ICMPなどを含む）
    • tcp: TCPプロトコルのみ
    • udp: UDPプロトコルのみ
    • icmp: ICMPプロトコルのみ
    • gre: GREプロトコルのみ
    • その他、多数のIPプロトコル番号またはキーワードが指定可能です（例: ospf, eigrp）。
  • <source>: 送信元IPアドレスを指定します。以下の形式があります。
    • any: すべての送信元IPアドレス（0.0.0.0 255.255.255.255 と同義）
    • host <ip-address>: 特定のホストIPアドレス
    • <network-address>: ネットワークアドレス（ワイルドカードマスクと組み合わせて使用）
  • <source-wildcard>: 送信元IPアドレスのどのビットを検査するかを指定するワイルドカードマスクです。後で詳細に解説します。
  • <destination>: 宛先IPアドレスを指定します。指定方法は<source>と同様です。
  • <destination-wildcard>: 宛先IPアドレスのワイルドカードマスクです。指定方法は<source-wildcard>と同様です。
  • [operator <port>]: プロトコルがTCPまたはUDPの場合に指定できるオプションで、送信元または宛先のポート番号を指定します。<port>はポート番号（例: 80, 22, 53）または一般的なサービス名（例: www, ssh, domain）で指定します。<operator>は以下のいずれかです。
    • eq <port>: 指定したポート番号と等しい
    • neq <port>: 指定したポート番号と等しくない
    • gt <port>: 指定したポート番号より大きい
    • lt <port>: 指定したポート番号より小さい
    • range <port1> <port2>: 指定したポート番号の範囲内（port1からport2までを含む）
    • 送信元ポートを指定する場合は<source-wildcard>の直後に、宛先ポートを指定する場合は<destination-wildcard>の直後に記述します。通常は宛先ポートを指定することが多いです。
  • [established]: 主にTCPプロトコルで指定するオプションです。既存のTCPセッションの一部であるパケット（つまり、ACKまたはRSTビットがセットされているパケット）にのみこのルールを適用します。これにより、内部から外部への通信によって確立されたセッションに対する外部からの応答トラフィックを許可しつつ、外部から内部への新たなセッション開始要求（SYNパケット）をブロックすることができます。ファイアウォール的な機能を実現する上で非常に重要なキーワードです。
  • [...]: その他のオプションとして、ICMPタイプ/コード、DSCP値、TTL値、logキーワードなどがあります。

ルールの定義が完了したら、exitコマンドでACLコンフィグレーションモードを終了します。

設定要素の詳細

各設定要素について、さらに詳しく見ていきましょう。

permit vs deny

  • permit: ルールにマッチしたパケットの通過を許可します。
  • deny: ルールにマッチしたパケットの通過を拒否します。拒否されたパケットは破棄されます。

ACLはルールのリストであり、リストの最後には必ず「暗黙の deny」ルールが存在します。これは、ACLのどのルールにもマッチしなかったパケットはすべて拒否される、という見えないルールです。したがって、必要な通信を許可するルールを明示的に定義しない限り、その通信は暗黙のdenyによってブロックされてしまいます。ACLを設計する際は、この暗黙のdenyを常に意識する必要があります。

<protocol>

最も一般的なプロトコル指定です。

  • ip: TCP、UDP、ICMPなど、あらゆるIPプロトコルを対象とします。最も一般的な指定です。
  • tcp: TCPプロトコルのみ。Web（HTTP/HTTPS）、SSH、FTP、Telnetなどのアプリケーション層プロトコルでよく使用されます。ポート番号によるフィルタリングと組み合わせるのが一般的です。
  • udp: UDPプロトコルのみ。DNS、DHCP、SNMP、VoIPなど、リアルタイム性が要求されるアプリケーション層プロトコルでよく使用されます。ポート番号によるフィルタリングと組み合わせるのが一般的です。
  • icmp: ICMPプロトコルのみ。ping（echo request/reply）やtraceroute、到達不能メッセージなどの制御に使用されます。特定のICMPタイプ/コードを指定することも可能です。

<source>, <destination> と <wildcard>

送信元/宛先IPアドレスの指定と、それに対応するワイルドカードマスクの組み合わせは、ACLの柔軟性を決定する重要な要素です。

  • any: 0.0.0.0 255.255.255.255 と同義です。すべてのIPアドレスにマッチします。
  • host <ip-address>: 特定の単一ホストを指定します。例えば、host 192.168.1.10はIPアドレス192.168.1.10のみにマッチします。これは<ip-address> 0.0.0.0と同義です。
  • <network-address> <wildcard-mask>: ネットワークアドレスとワイルドカードマスクを指定します。これにより、特定のネットワーク全体や、IPアドレスの特定の範囲を指定できます。

<wildcard-mask> の詳細

ワイルドカードマスクは、IPアドレスのどのビットを「一致させるべきか（固定）」、どのビットを「任意とするか（無視）」を指定するための32ビットの値です。ワイルドカードマスクはサブネットマスクとは逆の考え方をします。

  • ワイルドカードマスクのビットが 0: 対応するIPアドレスのビットは、指定されたアドレスのビットと一致しなければならない。
  • ワイルドカードマスクのビットが 1: 対応するIPアドレスのビットは、指定されたアドレスのビットが何であっても任意（無視）。

例えば、IPアドレスとワイルドカードマスクのペアが192.168.1.0 0.0.0.255だった場合を考えてみましょう。
バイナリで表現すると：
* IPアドレス 192.168.1.0: 11000000.10101000.00000001.00000000
* ワイルドカードマスク0.0.0.255: 00000000.00000000.00000000.11111111

ワイルドカードマスクのビットが0の箇所（最初の3オクテット）では、対応するIPアドレスのビットは指定されたアドレス（192.168.1.0）のビットと一致する必要があります。
つまり、11000000.10101000.00000001. の部分は固定されます。

ワイルドカードマスクのビットが1の箇所（最後の1オクテット）では、対応するIPアドレスのビットは任意です。
つまり、. の部分は 00000000 から 11111111 のどの値でもマッチします。

結果として、192.168.1.0 0.0.0.255は、192.168.1.0 から 192.168.1.255 までの範囲のIPアドレスにマッチします。これは、/24のサブネットマスク255.255.255.0に対応するネットワークアドレス192.168.1.0の範囲全体です。

ワイルドカードマスクは、サブネットマスクの各オクテットを255から引くことで簡単に計算できる場合がありますが、これは特定のサブネットマスク形式の場合に限られます。正確にはビット単位で考える必要があります。

ワイルドカードマスクの計算例:

  • 特定のホスト: 192.168.1.10 にマッチさせたい。
    • IPアドレス: 192.168.1.10
    • ワイルドカードマスク: 0.0.0.0 (すべてのビットを一致させる)
    • 構文: host 192.168.1.10 または 192.168.1.10 0.0.0.0
  • /24 ネットワーク: 192.168.1.0/24 (192.168.1.0 – 192.168.1.255) にマッチさせたい。
    • ネットワークアドレス: 192.168.1.0
    • サブネットマスク /24 は 255.255.255.0
    • ワイルドカードマスク: 255.255.255.255 – 255.255.255.0 = 0.0.0.255
    • 構文: 192.168.1.0 0.0.0.255
  • /25 ネットワーク: 192.168.1.0/25 (192.168.1.0 – 192.168.1.127) にマッチさせたい。
    • ネットワークアドレス: 192.168.1.0
    • サブネットマスク /25 は 255.255.255.128
    • ワイルドカードマスク: 255.255.255.255 – 255.255.255.128 = 0.0.0.127
    • 構文: 192.168.1.0 0.0.0.127
  • 特定の範囲: 192.168.1.64 から 192.168.1.127 までの範囲にマッチさせたい。（これは /26の192.168.1.64ネットワークです）
    • ネットワークアドレス: 192.168.1.64
    • サブネットマスク /26 は 255.255.255.192
    • ワイルドカードマスク: 255.255.255.255 – 255.255.255.192 = 0.0.0.63
    • 構文: 192.168.1.64 0.0.0.63
  • 任意のIPアドレス:
    • 構文: any または 0.0.0.0 255.255.255.255

ワイルドカードマスクは、サブネットマスクのように連続した0とそれに続く連続した1である必要はありません。任意の位置に0と1を配置できますが、通常はネットワークアドレスと組み合わせてネットワーク範囲を指定するために使用されるため、連続した0と1の形式になることが多いです。

[operator <port>]

プロトコルがTCPまたはUDPの場合に、特定のポート番号を指定してさらにフィルタリングを絞り込むことができます。これは拡張ACLの最も強力な機能の一つです。

ポート番号は数値（例: 80）で指定することも、一般的なサービス名（例: www）で指定することもできます。サービス名を使用する場合は、ルーターの/etc/servicesに相当する情報が参照されます。

  • eq <port>: Equal to (等しい)
    • 例: eq 80 (HTTP), eq www (HTTP), eq 443 (HTTPS), eq ssh (SSH), eq 23 (Telnet), eq 21 (FTP Control), eq 20 (FTP Data), eq 53 (DNS), eq 25 (SMTP), eq 110 (POP3), eq 143 (IMAP)
  • neq <port>: Not equal to (等しくない)
  • gt <port>: Greater than (より大きい)
  • lt <port>: Less than (より小さい)
  • range <port1> <port2>: Range (port1 から port2 までを含む)

これらのオペレーターは、送信元ポートを指定する場合は送信元IPアドレスとワイルドカードマスクの後に、宛先ポートを指定する場合は宛先IPアドレスとワイルドカードマスクの後に記述します。通常、サーバーへのアクセス制御などでは宛先ポートを指定します。

例:
* 特定のサーバーへのHTTPアクセスのみ許可: permit tcp any any host <server-ip> eq 80
* 任意の宛先へのSSHアクセスを許可: permit tcp any any any eq 22
* ポート番号1024以上の全てのTCP通信を許可: permit tcp any any any gt 1023
* ポート番号6000から6009までのUDP通信を拒否: deny udp any any any range 6000 6009

[established]

このキーワードはTCPプロトコルにのみ適用できます。TCPセッションの確立を示すACKまたはRSTビットがセットされているパケットにのみマッチします。SYNビットのみがセットされている（新規接続を試みる）パケットにはマッチしません。

このキーワードは、主に外部から内部ネットワークへのインバウンドトラフィックを制御するACLで使用されます。例えば、内部ネットワークのクライアントが外部のWebサーバーに接続する場合、クライアントはSYNパケットを外部に送信します。外部のWebサーバーからの応答（SYN-ACK）やその後のデータパケットは、establishedキーワード付きのルールにマッチします。

例:
* 外部から内部へのACLで、establishedキーワードを使用する: permit tcp any any established
* このルールは、内部から外部への通信によって既に確立されたTCPセッションに対する外部からの応答パケットを許可します。
* 外部から内部への新たな接続要求（SYNパケット）は、このルールにはマッチしません。
* このルールの後にdeny ip any any（暗黙のdenyまたは明示的な拒否）を配置することで、外部から内部への新規接続要求はブロックされ、内部から外部への通信のみを許可する（その応答も許可する）という、基本的なステートフルフィルタリングのような振る舞いを実現できます。

ACLの処理順序と評価

ACLのルールはリストの先頭から順番に評価されます。パケットがいずれかのルールにマッチすると、そのルールで指定されたアクション（許可または拒否）が実行され、それ以降のルールは評価されません。

重要なポイント:

  1. First Match, First Action: 最初のマッチが決定的なアクションとなります。
  2. ルールの並び順の重要性: より限定的（具体的）なルールは、より一般的（広範）なルールよりも先に配置する必要があります。一般的なルールを先に配置してしまうと、限定的なルールが評価される前にパケットがマッチしてしまい、意図したフィルタリングが行われない可能性があります。
  3. ルールの追加: 名前付きACLの場合、デフォルトではリストの最後に追加されます。しかし、シーケンス番号を指定することで、既存のルールの間に新しいルールを挿入できます。
  4. ルールの削除: 名前付きACLの場合、ACLコンフィグレーションモードでno [sequence-number] {permit | deny} ...のように、削除したいルールのシーケンス番号または内容を指定して削除できます。
  5. ルールの編集: 一度追加されたルールは直接編集できません。変更したい場合は、そのルールを削除し、新しいルールを再追加する必要があります。シーケンス番号を指定して挿入/削除すると、他のルールの番号が自動的に調整されるため、名前付きACLでの編集は比較的容易です。

例:
ネットワーク192.168.1.0/24からのSSHアクセスを拒否したいが、その中の特定のホスト192.168.1.10からのSSHアクセスは許可したい、という場合。

誤った順序:
bash
ip access-list extended SSH_CONTROL
deny tcp 192.168.1.0 0.0.0.255 any eq 22 <-- ネットワーク全体からのSSHを拒否
permit tcp host 192.168.1.10 any eq 22 <-- 特定ホストからのSSHを許可
この順序では、192.168.1.10からのSSHパケットは最初のルール（deny tcp 192.168.1.0 0.0.0.255 any eq 22）にマッチして拒否されてしまい、2番目のルールは評価されません。

正しい順序:
bash
ip access-list extended SSH_CONTROL
permit tcp host 192.168.1.10 any eq 22 <-- 特定ホストからのSSHを許可（より具体的）
deny tcp 192.168.1.0 0.0.0.255 any eq 22 <-- ネットワーク全体からのSSHを拒否（より一般的）
この順序であれば、192.168.1.10からのSSHパケットは最初のルールにマッチして許可されます。192.168.1.0/24ネットワーク内の他のホストからのSSHパケットは最初のルールにはマッチしませんが、2番目のルールにマッチして拒否されます。

暗黙の deny (Implicit Deny)

前述の通り、すべてのACLの最後に、見えないルールとして「暗黙の deny any any」が存在します。これは、リスト内のどの明示的なルールにもマッチしなかったパケットはすべて拒否される、というルールです。

この暗黙のdenyがあるため、ACLを定義する際には、許可したい通信はすべて明示的にpermitルールとして記述する必要があります。許可したい通信のルールを一つも記述しないACLは、すべての通信をブロックすることになります。

逆に、特定の通信だけを拒否し、それ以外のすべての通信を許可したい場合は、拒否ルールを記述した後に、明示的にpermit ip any anyというルールをリストの最後に追加する必要があります。このルールは、暗黙のdenyの前に評価されるため、拒否ルールにマッチしなかったすべてのパケットを許可することになります。

例: 特定のホストからのWebアクセスだけを拒否し、他のホストからのWebアクセスを含むそれ以外のすべての通信は許可したい。

bash
ip access-list extended WEB_DENY
deny tcp host 192.168.1.20 any eq 80 <-- 特定ホストからのHTTPアクセスを拒否
permit ip any any <-- それ以外のすべての通信を許可
このACLでは、192.168.1.20からのHTTPパケットは最初のルールで拒否されます。その他のホストからのHTTPパケットや、あらゆる送信元・宛先・プロトコルのパケットは最初のルールにはマッチしませんが、2番目のpermit ip any anyルールにマッチして許可されます。暗黙のdenyは、このpermit ip any anyルールの後に存在しますが、そこに到達するパケットはないため影響しません。

もしpermit ip any anyルールがなかった場合、暗黙のdenyによって、192.168.1.20からのHTTP以外の通信も、他のすべてのホストからのあらゆる通信も、すべてブロックされてしまいます。

設定例

具体的なシナリオを想定した設定例を見ていきましょう。以下の例では、ネットワーク構成を簡略化し、ルーターのインターフェイスにACLを適用することを前提とします。

例1: 特定ホストからのSSHアクセスのみ許可

シナリオ:
内部ネットワーク (192.168.1.0/24) からサーバーゾーンにあるサーバー (192.168.10.10) へのSSHアクセスを制御したい。管理用PC (192.168.1.100) からのSSHアクセスのみを許可し、他の内部PCからのSSHアクセスは拒否する。他のサーバーへのSSHアクセスは許可してもよい。他のプロトコル（HTTP, Pingなど）は通常通り許可する。

要件:
* 送信元: 192.168.1.100 から
* 宛先: 192.168.10.10 へ
* プロトコル/ポート: TCP 22 (SSH)
* アクション: 許可
* その他の送信元/宛先/プロトコルに対するアクション: 特定サーバーへのSSH拒否、それ以外の通信は許可

ACL設計:
1. 管理用PCから特定サーバーへのSSHを許可するルール。
2. 内部ネットワーク全体から特定サーバーへのSSHを拒否するルール（上記ルールよりも後に配置）。
3. それ以外のすべての通信を許可するルール（最後に配置）。

設定コマンド:
ルーターのグローバルコンフィグレーションモードで実行します。ここでは、内部ネットワーク側のインターフェイス（例: GigabitEthernet0/1）にアウトバウンドACLとして適用することを想定します。

bash
Router(config)# ip access-list extended SSH_TO_SERVER
Router(config-ext-nacl)# 10 permit tcp host 192.168.1.100 host 192.168.10.10 eq 22
Router(config-ext-nacl)# 20 deny tcp 192.168.1.0 0.0.0.255 host 192.168.10.10 eq 22
Router(config-ext-nacl)# 30 permit ip any any
Router(config-ext-nacl)# exit
(注: シーケンス番号は省略しても自動で振られますが、ここでは明確に指定しています。)

インターフェイスへの適用:
内部ネットワークに面したインターフェイス（例: GigabitEthernet0/1）に、サーバーゾーンに向かう方向（アウトバウンド）で適用します。

bash
Router(config)# interface GigabitEthernet0/1
Router(config-if)# ip access-group SSH_TO_SERVER out
Router(config-if)# end
(注: この例では、内部ネットワーク側のインターフェイスからのout方向でサーバーへの通信を制御しています。あるいは、サーバーゾーンに面したインターフェイス（例: GigabitEthernet0/2）にインバウンドACLとして適用することも可能です。その場合、ソースとデスティネーションは上記ACLの記述と同じになりますが、ACLを適用するインターフェイスと方向が変わります。)

解説:
* ルール10: 送信元192.168.1.100から宛先192.168.10.10へのTCPポート22の通信（SSH）を許可します。最も具体的なルールなので最初に配置します。
* ルール20: 送信元192.168.1.0/24ネットワーク全体から宛先192.168.10.10へのTCPポート22の通信（SSH）を拒否します。ルール10にマッチしなかった内部PCからのSSH通信がここで拒否されます。
* ルール30: それ以外のすべてのIP通信（送信元、宛先、プロトコル問わず）を許可します。これにより、特定サーバーへのSSH以外の通信や、他のサーバーへの通信、他のプロトコルの通信が許可されます。このルールがないと、暗黙のdenyによってすべての通信がブロックされてしまいます。

例2: 特定ネットワークからWebサーバーへのアクセスを許可

シナリオ:
DMZにあるWebサーバー (172.16.1.10) へのHTTP (TCP 80) および HTTPS (TCP 443) アクセスを、内部ネットワーク (192.168.1.0/24) からのみ許可し、インターネット側からのアクセスは拒否したい。

要件:
* 送信元: 192.168.1.0/24 から
* 宛先: 172.16.1.10 へ
* プロトコル/ポート: TCP 80 または TCP 443
* アクション: 許可
* その他の送信元に対するアクション: 拒否

ACL設計:
1. 内部ネットワークから特定WebサーバーへのHTTP/HTTPSを許可するルール。
2. それ以外のすべての通信を拒否するルール（暗黙のdenyを利用するか、明示的なdeny any anyを記述）。

設定コマンド:
インターネットに面したインターフェイス（例: GigabitEthernet0/0）にインバウンドACLとして適用することを想定します。

bash
Router(config)# ip access-list extended WEB_ACCESS
Router(config-ext-nacl)# permit tcp 192.168.1.0 0.0.0.255 host 172.16.1.10 eq 80
Router(config-ext-nacl)# permit tcp 192.168.1.0 0.0.0.255 host 172.16.1.10 eq 443
Router(config-ext-nacl)# exit
(注: シーケンス番号は省略しています)

インターフェイスへの適用:
インターネットに面したインターフェイス（例: GigabitEthernet0/0）に、ルーターに入ってくる方向（インバウンド）で適用します。

bash
Router(config)# interface GigabitEthernet0/0
Router(config-if)# ip access-group WEB_ACCESS in
Router(config-if)# end

解説:
* 最初の2つのルール: 送信元192.168.1.0/24から宛先172.16.1.10へのTCPポート80または443の通信を許可します。
* 暗黙のdeny: 上記ルールにマッチしないパケット（例: インターネットからのパケット、WebサーバーへのSSH/FTPアクセスなど）は、ACLの最後にある暗黙のdenyによって拒否されます。これにより、内部ネットワークからの指定されたWebアクセスのみが許可されます。

例3: 内部ネットワークから外部へのあらゆる通信を許可、ただし特定のポートをブロック

シナリオ:
内部ネットワーク (192.168.1.0/24) からインターネットへのあらゆる通信を基本的に許可するが、セキュリティ上の理由から、ファイル共有に使用される特定のポート（例: UDP 137, 138, TCP 139, 445）をブロックしたい。

要件:
* 送信元: 192.168.1.0/24 から
* 宛先: Internet (any) へ
* プロトコル/ポート: UDP 137/138, TCP 139/445
* アクション: 拒否
* その他の通信に対するアクション: 許可

ACL設計:
1. 特定のポートへの通信を拒否するルール（より限定的）。
2. それ以外のすべての通信を許可するルール（より一般的、最後に配置）。

設定コマンド:
内部ネットワークに面したインターフェイス（例: GigabitEthernet0/1）にアウトバウンドACLとして適用することを想定します。

bash
Router(config)# ip access-list extended BLOCK_FILE_SHARING
Router(config-ext-nacl)# deny udp 192.168.1.0 0.0.0.255 any eq 137
Router(config-ext-nacl)# deny udp 192.168.1.0 0.0.0.255 any eq 138
Router(config-ext-nacl)# deny tcp 192.168.1.0 0.0.0.255 any eq 139
Router(config-ext-nacl)# deny tcp 192.168.1.0 0.0.0.255 any eq 445
Router(config-ext-nacl)# permit ip 192.168.1.0 0.0.0.255 any
Router(config-ext-nacl)# exit

インターフェイスへの適用:
内部ネットワークに面したインターフェイス（例: GigabitEthernet0/1）に、インターネットに向かう方向（アウトバウンド）で適用します。

bash
Router(config)# interface GigabitEthernet0/1
Router(config-if)# ip access-group BLOCK_FILE_SHARING out
Router(config-if)# end

解説:
* 最初の4つのルール: 内部ネットワークからの指定されたUDP/TCPポートへの通信を拒否します。これらのポートは、インターネットへの通信としては不要な場合が多く、セキュリティリスクとなる可能性があるためブロックします。
* 最後のルール: 内部ネットワークからのそれ以外のすべてのIP通信を許可します。このルールがないと、暗黙のdenyによって内部ネットワークからのインターネットへの通信がすべてブロックされてしまいます。
* ルールの順序: 拒否したい具体的な通信ルールを先に置き、その後にすべての通信を許可する一般的なルールを配置します。

例4: ステートフルフィルタリングのシミュレーション (establishedキーワード)

シナリオ:
内部ネットワーク (192.168.1.0/24) はインターネットへの通信（Web閲覧、メール送受信、DNSクエリなど）を自由に行えるようにしたいが、インターネット側から内部ネットワークへの新規接続要求（例えば、外部からの内部サーバーへのTelnet/SSH接続試行など）はすべて拒否したい。ただし、内部からの要求に対する外部からの応答（Webサイトのコンテンツ、メール、DNS応答など）は許可する必要がある。

要件:
* 内部から外部への通信は許可。
* 外部から内部への新規接続は拒否。
* 内部からの通信に対する外部からの応答は許可。
* 特定のサービス（例: 外部DNSサーバーへのクエリ、外部からのWebサーバーへのアクセスなど、要件に応じて例外を設ける場合）は個別に検討。

ACL設計:
このシナリオでは、インターネットに面したインターフェイスにインバウンドACLを適用するのが適切です。

  1. 内部から確立されたセッションに対する外部からの応答を許可するルール (establishedキーワードを使用)。
  2. （必要に応じて）特定のサービス（例: 外部DNSへのUDP 53）を許可するルール。
  3. それ以外のすべての通信を拒否するルール（暗黙のdenyを利用）。

設定コマンド:
インターネットに面したインターフェイス（例: GigabitEthernet0/0）にインバウンドACLとして適用することを想定します。

bash
Router(config)# ip access-list extended INBOUND_FILTER
Router(config-ext-nacl)# permit tcp any any established <-- 内部から確立されたTCPセッションの応答を許可
Router(config-ext-nacl)# permit udp any any eq 53 <-- 外部DNSへのクエリ応答（UDP 53）を許可 (内部からのクエリに対する応答として)
Router(config-ext-nacl)# permit icmp any any echo-reply <-- 内部からのpingに対する応答（ICMP echo-reply）を許可
Router(config-ext-nacl)# exit
(注: ICMPのecho-replyを許可するのは、内部からのpingに対する応答を見たい場合など。セキュリティ上、外部からのping応答は拒否したい場合（ICMP echoを拒否）も多いです。また、UDP 53は双方向の通信ですが、establishedキーワードはTCPのみに適用されます。DNSクエリは内部から外部（UDP 53宛て）に送信され、応答が外部から内部（送信元ポートはランダム、宛先ポートは内部クライアントのポート）に戻ってきます。上記のpermit udp any any eq 53は宛先ポート53へのUDP通信を許可するルールですが、このACLがインバウンドに適用されているため、外部から内部のUDP 53ポート（通常はサーバーやルーター自身）への通信が許可されてしまいます。内部クライアントからのDNS応答を許可するには、より複雑なフィルタリングやReflexive ACL、またはファイアウォール機能が必要です。シンプルなACLで応答のみを許可するのは困難です。上記例はあくまでUDP 53宛て通信を許可する場合の記述として示しています。)

インターフェイスへの適用:
インターネットに面したインターフェイス（例: GigabitEthernet0/0）に、ルーターに入ってくる方向（インバウンド）で適用します。

bash
Router(config)# interface GigabitEthernet0/0
Router(config-if)# ip access-group INBOUND_FILTER in
Router(config-if)# end

解説:
* ルール10 (permit tcp any any established): 外部から内部へのTCPパケットのうち、既存のTCPセッションに対する応答（ACKまたはRSTビットがセット）であるものを許可します。内部クライアントが外部Webサイトを閲覧したり、外部メールサーバーからメールを受信したりする際の応答パケットがこれに該当します。外部から内部への新規接続要求（SYNパケット）はこのルールにはマッチしません。
* ルール20 (permit udp any any eq 53): これは外部から内部のUDP 53ポートへの通信を許可します。ルーター自体が外部DNSサーバーからの応答を受け取る場合などに使用できます。しかし、内部クライアントへのDNS応答は通常ランダムな高位ポートに戻るため、このルールだけでは内部クライアントへのDNS応答を許可できません。UDPトラフィックの応答をACLで制御するのはTCPより複雑です。
* ルール30 (permit icmp any any echo-reply): 外部から内部へのICMP echo-replyパケットを許可します。これは内部から外部へのpingに対する応答です。
* 暗黙のdeny: 上記のルールにマッチしないパケット（外部から内部への新規TCP接続要求、ICMP echoなど）はすべて拒否されます。

この設定は、完全なステートフルファイアウォールほど高度ではありませんが、establishedキーワードを使用することで、基本的な「内部からの通信に対する応答を許可する」という振る舞いを実現できます。

例5: ping (ICMP) の制御

シナリオ:
インターネットからルーターや内部ホストへのping (ICMP echo request) を拒否したいが、内部ホストからインターネットへのpingとその応答は許可したい。

要件:
* インターネットからのICMP echo request は拒否。
* 内部からのICMP echo request は許可。
* 内部からのICMP echo request に対する外部からの応答 (ICMP echo reply) は許可。

ACL設計:
インターネットに面したインターフェイスにインバウンドACLを適用します。

  1. 外部からのICMP echo request を拒否するルール。
  2. 内部からのICMP echo request に対する外部からの応答 (ICMP echo reply) を許可するルール。
  3. それ以外の通信を許可するルール (ping以外の通信)。

設定コマンド:
インターネットに面したインターフェイス（例: GigabitEthernet0/0）にインバウンドACLとして適用することを想定します。

bash
Router(config)# ip access-list extended PING_CONTROL
Router(config-ext-nacl)# deny icmp any any echo <-- 外部からのICMP echo request (ping) を拒否
Router(config-ext-nacl)# permit icmp any any echo-reply <-- 外部からのICMP echo reply を許可 (内部からのping応答)
Router(config-ext-nacl)# permit ip any any <-- ping以外のすべてのIP通信を許可
Router(config-ext-nacl)# exit

インターフェイスへの適用:
インターネットに面したインターフェイス（例: GigabitEthernet0/0）に、ルーターに入ってくる方向（インバウンド）で適用します。

bash
Router(config)# interface GigabitEthernet0/0
Router(config-if)# ip access-group PING_CONTROL in
Router(config-if)# end

解説:
* ルール10: 外部 (any) からあらゆる宛先 (any) へのICMP echo (ping) を拒否します。これにより、外部からルーターや内部ホストへのpingがブロックされます。
* ルール20: 外部 (any) からあらゆる宛先 (any) へのICMP echo-reply を許可します。これは内部から外部へのpingに対する応答パケットです。内部ホストが外部へpingする際には、そのpingパケットはルーターをアウトバウンド方向で通過します（このACLはインバウンドに適用されているので影響しません）。その応答パケットが外部から戻ってくる際に、このルールにマッチして許可されます。
* ルール30: ICMP以外のすべてのIP通信を許可します。このルールがないと、暗黙のdenyによってWeb閲覧やメールなどの通信もすべてブロックされてしまいます。

設定時の注意点

ACLはネットワークトラフィックの根幹に関わる制御を行うため、設定には細心の注意が必要です。誤った設定は、必要な通信をブロックしたり、逆に意図しない通信を許可してセキュリティリスクを高めたりする可能性があります。

  1. ACLの適用方向と場所: ACLを定義するだけでなく、どのインターフェイスの、入方向か出方向か、正しく適用することが非常に重要です。拡張ACLは送信元に近い場所（通常は入方向）に適用するのが一般的ですが、ネットワーク構成や制御したい内容によっては、宛先に近い場所や出方向に適用することもあります。十分に検討してから適用しましょう。
  2. 既存トラフィックへの影響: 稼働中のネットワークでACLを設定・変更・削除する場合、現在流れているトラフィックに予期しない影響を与える可能性があります。特にno access-listやno ip access-list extended <acl-name>コマンドでACL全体を削除すると、そのインターフェイスでは一時的にすべてのトラフィックが許可される状態になり、セキュリティホールが生まれる可能性があります。既存のACLを変更する際は、ルールの追加や削除を慎重に行い、サービスへの影響を最小限に抑える計画が必要です。可能であれば、メンテナンス時間に行うか、テスト環境で十分に検証してから実施しましょう。
  3. ルールの順序: 前述の通り、ACLは上から順に評価されます。具体的なルールは一般的なルールよりも先に記述してください。名前付きACLのシーケンス番号を活用すると、ルールの挿入や管理が容易になります。
  4. 暗黙のdeny: ACLの最後に暗黙のdenyが存在することを忘れないでください。必要な通信はすべて明示的にpermitする必要があります。特定の通信を拒否する目的でACLを使用する場合でも、最後にpermit ip any anyのようなルールを追加しないと、他のすべての通信がブロックされてしまいます。
  5. テストと検証: ACLを設定した後、意図した通りに動作しているか必ずテストしてください。許可すべき通信が許可されているか、拒否すべき通信が拒否されているか、様々なケースで確認します。show access-listsコマンドでヒット数を確認したり、pingやtelnetなどのツールを使って疎通確認を行ったりします。
  6. ログオプション: 重要な拒否ルールなどにlogキーワードを追加すると、そのルールにマッチしたパケットに関する情報がコンソールやログサーバーに出力されます。これは、ACLがどのように動作しているか、どのような通信が拒否されているかを確認する際に非常に役立ちます。ただし、トラフィック量が多い環境ではログメッセージが大量に出力され、ルーターのパフォーマンスに影響を与える可能性があるため、注意して使用する必要があります。
  7. コマンドミス: IPアドレス、ワイルドカードマスク、ポート番号、プロトコル名などの入力ミスは、ACLが正しく機能しない原因となります。設定時には注意深く入力し、設定後にshow running-configなどで設定内容を確認しましょう。
  8. 他の機能との連携: ACLは、NAT、QoS、VPNなど、ルーターの他の機能と連携して使用されることが多いです。ACLの設定がこれらの機能の動作に影響を与えないか、あるいは逆にこれらの機能がACLの適用順序やフィルタリング結果に影響を与えないか、全体を考慮して設計する必要があります。例えば、NATより前に入ってくるパケットにACLを適用する場合と、NAT変換後のアドレスでACLを適用する場合では、ACLの送信元/宛先アドレスの記述が変わってきます。

ACLの確認方法

ACLが正しく設定され、期待通りに機能しているかを確認するためのコマンドです。

  • show access-lists: 設定されているすべてのアクセスリスト（標準、拡張、名前付きすべて）とそのルールを表示します。各ルールの最後に、そのルールにマッチしたパケットの数（ヒット数）が表示されます。
    bash
    Router# show access-lists
    Extended IP access list SSH_TO_SERVER
    10 permit tcp host 192.168.1.100 host 192.168.10.10 eq 22 (30 matches)
    20 deny tcp 192.168.1.0 0.0.0.255 host 192.168.10.10 eq 22 (10 matches)
    30 permit ip any any (1500 matches)
    Extended IP access list WEB_ACCESS
    10 permit tcp 192.168.1.0 0.0.0.255 host 172.16.1.10 eq 80 (50 matches)
    20 permit tcp 192.168.1.0 0.0.0.255 host 172.16.1.10 eq 443 (120 matches)
  • show access-lists <acl-name>: 指定した名前のACLのみを表示します。
    bash
    Router# show access-lists SSH_TO_SERVER
    Extended IP access list SSH_TO_SERVER
    10 permit tcp host 192.168.1.100 host 192.168.10.10 eq 22 (30 matches)
    20 deny tcp 192.168.1.0 0.0.0.255 host 192.168.10.10 eq 22 (10 matches)
    30 permit ip any any (1500 matches)
  • show ip interface <interface>: 指定したインターフェイスに適用されているIP関連の設定（IPアドレス、ACLなど）を表示します。適用されているACLの名前と方向を確認できます。
    bash
    Router# show ip interface GigabitEthernet0/0
    GigabitEthernet0/0 is up, line protocol is up
    Internet address is 203.0.113.1/24
    ...
    Outgoing access list is not set
    Inbound access list is WEB_ACCESS
    ...
  • show running-config: ルーターの現在の設定全体を表示します。ACLの定義やインターフェイスへの適用状況をまとめて確認できます。
  • clear access-list counters [<acl-name> [<sequence-number>]]: ACLのヒット数をクリアします。特定の期間や特定のテストを行った際のヒット数を確認したい場合に、事前にカウンターをクリアして使用します。

これらのコマンドを組み合わせて使用することで、ACLの設定内容、適用状況、そして実際のパケットがどのルールにマッチしているか（ヒット数）を確認し、トラブルシューティングを行うことができます。

実践的な利用シナリオ

拡張ACLは、単にパケットを許可・拒否するだけでなく、様々なネットワーク機能と連携して使用されます。

  • ファイアウォール機能: 拡張ACLは、ルーターを簡易的なステートフルファイアウォールとして機能させるための基本的な要素です。インターネットとの境界ルーターに適用することで、外部からの不正アクセスを防ぎます。
  • サーバーへのアクセス制御: 内部ネットワークからDMZやサーバーゾーンへのアクセスを制御し、必要なユーザーやサービスだけがサーバーにアクセスできるようにします。
  • ネットワークセグメンテーション: 内部ネットワークを複数のセグメントに分割し、ACLを使用してセグメント間の通信を制御することで、セキュリティゾーンを構築し、脅威の拡散を防ぎます。
  • QoS (Quality of Service): ACLは、QoSにおいて特定のトラフィックを分類（classify）するために使用されます。分類されたトラフィックに対して、帯域幅の保証や優先制御といったQoSポリシーを適用します。match access-groupコマンドと組み合わせて使用します。
  • NAT (Network Address Translation): ACLは、NATの対象となるトラフィック（どの送信元IPアドレスのパケットを変換するか）を識別するために使用されます。ip nat inside source list <acl-name> ...のようなコマンドで使用されます。
  • VPN: VPNによって暗号化・復号化する対象となるトラフィックを定義するために、ACLが使用されます。
  • ルーティングポリシー: route-mapと組み合わせて、特定の送信元/宛先からのトラフィックに基づいてルーティングの挙動を変更する際に使用されることがあります。

これらのシナリオからもわかるように、拡張ACLはネットワークのセキュリティと管理において非常に汎用性が高く、重要な役割を担っています。

トラブルシューティング

ACLに関するトラブルシューティングは、ネットワークエンジニアにとって一般的な作業です。通信がブロックされてしまう、あるいはブロックされるべき通信が通過してしまうといった問題が発生した場合、以下の手順で原因を特定できます。

  1. 問題の特定: どの送信元からどの宛先への、どのようなプロトコル/ポートの通信が問題となっているのか、具体的に特定します。
  2. ACLの確認:
    • show ip interface <interface>コマンドで、問題のトラフィックが通過する可能性のあるインターフェイスにACLが適用されているか、適用方向は正しいかを確認します。
    • show access-lists <acl-name>コマンドで、適用されているACLの内容を確認します。特に、問題のトラフィックに関するpermit/denyルールが正しく記述されているか、ワイルドカードマスクやポート番号は正しいかを確認します。
    • ルールの順序が正しいか、再度確認します。より具体的なルールが先に、より一般的なルールが後に来ているか。
    • 暗黙のdenyによって意図しない通信がブロックされていないか確認します。必要な通信に対するpermitルールが存在するか。
  3. ヒット数の確認: show access-lists <acl-name>の出力で、問題のトラフィックにマッチすると想定されるルールのヒット数を確認します。ヒット数が増えていれば、そのルールにパケットがマッチしていることを意味します。ヒット数が増えていない場合は、パケットがそのルールに到達する前に他のルールで処理されているか、そもそもパケットがルーターに到達していないか、あるいはACL以外の問題（ルーティング、ファイアウォール、NATなど）が原因である可能性があります。
  4. カウンターのクリア: トラフィックが少ない環境であれば、clear access-list counters <acl-name>でヒット数をクリアし、再度問題の通信を試行して、どのルールのヒット数が増えるかを確認すると、パケットがどのルールにマッチしているかをピンポイントで特定できます。
  5. ログオプション: 重要なdenyルールに一時的にlogキーワードを追加し、問題の通信を試行した際にログメッセージが出力されるか確認します。ログメッセージには、拒否されたパケットの送信元/宛先IPアドレス、プロトコル、ポート番号などが含まれるため、デバッグに非常に役立ちます。ただし、多用するとルーターの負荷が増えるので注意が必要です。
  6. Packet Tracer/GNS3などのシミュレーター: 複雑なACLや複数のACLが絡み合う設定の場合は、事前にシミュレーターで構成を再現し、ACLを設定して意図した動作をするか検証すると、実機でのトラブルを減らせます。
  7. 他の機能との連携: ACLがNAT、QoS、VPNなど他の機能と連携している場合は、それらの機能の設定も合わせて確認し、ACLとの相互作用が問題の原因になっていないか調査します。

ACLのトラブルシューティングは、ACLの評価順序、ワイルドカードマスクの仕組み、そして暗黙のdenyといった基本的な概念をしっかりと理解していることが成功の鍵となります。

高度な設定オプション (簡潔に)

拡張ACLには、さらに高度なフィルタリングを可能にするオプションが存在します。

  • Time-based ACL: ACLルールに時間帯の条件を追加できます。特定の時間帯だけ特定の通信を許可したり、特定の曜日だけ特定のサービスをブロックしたりといった制御が可能です。time-rangeコマンドで時間帯を定義し、ACLルールにtime-range <name>キーワードを追加して使用します。
  • Reflexive ACL: 一対のACLルール（インバウンドとアウトバウンド）を自動的に関連付け、アウトバウンド方向で開始されたセッションに対応するインバウンド方向のトラフィックのみを動的に許可する機能です。establishedキーワードよりも高度なステートフルフィルタリングを実現できます。
  • Context-Aware ACL: Cisco ASAなどのファイアウォール製品で利用されるACLの拡張で、ユーザーやアプリケーションなどのコンテキストに基づいてよりインテリジェントなフィルタリングを行います。ルーターのACLとは異なりますが、ACLの概念が基盤となっています。

これらの高度なオプションを使いこなすことで、さらに柔軟でセキュアなネットワーク制御が可能になります。

まとめ

ip access-list extendedコマンドで設定する拡張アクセスリストは、Ciscoルーターをはじめとするネットワーク機器におけるトラフィック制御とセキュリティ対策の非常に強力なツールです。送信元IPアドレス、宛先IPアドレス、プロトコル、ポート番号といった詳細な条件に基づいて、パケットの許可・拒否をきめ細かく設定できます。

この記事では、拡張ACLの基本的な概念、標準ACLとの違い、基本的な構文と各要素の詳細（特にワイルドカードマスクとポート指定）、ACLの処理順序、暗黙のdenyの重要性、そして具体的な設定例や確認・トラブルシューティング方法について解説しました。

拡張ACLを効果的に活用するためには、以下の点を深く理解し、実践することが重要です。

  • First Match, First Action: ルールの評価順序が結果を決定します。具体的なルールを先に、一般的なルールを後に配置する鉄則を守る必要があります。
  • ワイルドカードマスク: ネットワークアドレスや特定の範囲を指定するためのワイルドカードマスクの仕組みを正確に理解し、計算できるようになる必要があります。
  • 暗黙のdeny: ACLの最後にはすべての通信を拒否する見えないルールがあることを常に意識し、必要な通信は必ず明示的に許可するルールを記述する必要があります。
  • 適用方向と場所: ACLをどのインターフェイスのどの方向（in/out）に適用するかを慎重に検討する必要があります。拡張ACLは通常、送信元に近い場所の入方向に適用するのが効果的です。
  • テストと検証: 設定後は必ずテストを行い、意図した通りに動作しているか確認します。show access-listsのヒット数やログオプションがデバッグに役立ちます。

拡張ACLは、ネットワークのセキュリティを強化し、不要なトラフィックを削減し、ネットワークリソースを効率的に利用するための基盤となる機能です。この記事で解説した内容を参考に、自身のネットワーク環境で拡張ACLを適切に設計・設定・管理できるようになることで、より安全で信頼性の高いネットワーク運用を実現できるでしょう。

ACLはネットワーク設計における基本的なスキルであり、その習得はネットワークエンジニアとして必須です。この詳細な解説が、拡張ACLの理解を深め、実践的な設定能力を身につける一助となれば幸いです。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール