概述
在【网络协议】ACL（访问控制列表）第一部分中，我们介绍了 ACL 的基本概念，讨论了它的工作原理，并以标准 ACL 的配置为结束。第二部分将重点讨论扩展 ACL 以及其他相关的 ACL 概念，接着介绍如何配置扩展 ACL，最后进行 ACL 故障排除。
ACL_9">扩展 ACL
标准 ACL 存在一个局限性，即它仅能根据源地址来过滤流量，这在精细控制上显得不够灵活。如果需要更强大和更灵活的流量控制能力，扩展访问控制列表（扩展 ACL）是更好的选择。正如我们之前提到的，扩展 ACL 不仅能够检查源 IP 地址，还可以基于以下条件进行配置：
在第一部分中，我们提到标准访问控制列表 (ACL) 的编号范围是 1 到 99，而扩展 ACL 的编号范围是 100 到 199。
以下是配置扩展 ACL 的命令语法：
操作符是一个关键字，用于比较源地址和目标地址。操作符包括：
注意：操作符关键字只能用于某些协议，例如 UDP 或 TCP。
下面的语句展示了一个扩展 ACL 的示例：
正如我们在本章第一部分中提到的，扩展 ACL 的最大效果在于尽可能靠近源网络的位置使用。
在接下来的部分中，我们将使用第一部分中的拓扑结构来配置扩展 ACL，但会使用不同的指令。
ACL_40">配置扩展 ACL
网络中所有设备的 IP 地址方案如下表所示：
场景说明
与第一部分中仅限制源 IP 地址的配置不同，本次配置将包括其他参数，但基础配置仍然与之前相同。
在本场景中，我们需要根据以下安全策略配置 ACL：
1、192.168.1.0/26 网络上的用户不应能够访问 PC E。
2、172.16.2.128/25 网络上的用户仅能访问 HTTP 服务器。
3、PC A 不应能够访问安全的 Web 服务。
4、PC A 可以使用 Telnet，而 PC B 不能使用 Telnet。
5、192.168.30.0/24 网络上的用户不应能够 ping HTTP 和 HTTPS 服务器，但应能够访问网站。
任务1
此访问控制列表 (ACL) 应仅限制到 PC E 的流量，同时允许该网络上的用户进行所有其他流量。实现此目标所需的命令如下：
此访问控制列表 (ACL) 拒绝任何从网络 192.168.1.0/26 发往 PC D 的 IP 流量。
此命令允许其他所有流量通过网络：
扩展ACL应该应用于最接近源网络的位置，这样路由器就不需要处理那些最终会被丢弃的数据包。因此，我们将把这个ACL应用于连接到192.168.1.0/26局域网的接口，并设置为入方向。这样，R1将丢弃它接收到的目的IP地址为PC D的数据包，同时允许其他所有流量。
以下是将此ACL应用于FastEthernet 0/0接口入方向的命令：
任务2
网络 172.16.2.128/25 上的用户应该只能访问 HTTP 服务器。这个任务可以通过仅允许 172.16.2.128/25 网络访问 R2 上的 HTTP 服务器来轻松完成，并且应该丢弃所有其他流量。
上面显示的命令允许网络 172.16.2.128/25 中的用户访问 HTTP 服务器。由于这个场景没有说明我们只限制 HTTP 流量，因此我们将允许所有流量。
上面的命令用于将此 ACL 应用到连接到 172.16.2.128/25 网络的入站接口。在第二个任务中，我们只使用了一个 ACL 条目。由于隐含的拒绝语句，流向 HTTP 服务器以外其他目的地的流量将被阻止。
任务 3
本任务演示了如何基于端口进行流量过滤。Web 服务使用端口 80（HTTP）和端口 443（安全 HTTP，即 HTTPS）进行访问。该任务要求我们仅阻止安全的 Web 服务，因此，我们将仅阻止 PC A 的端口 443。这个配置将在 R1 上完成，使用如下命令：
这个 ACL 将应用于 R1 的 FastEthernet 0/0 接口的入站方向，如下所示：
任务四
PC A 可以使用 telnet，而 PC B 不能使用 telnet。
本任务要求我们阻止这两台 PC 的 telnet 流量。我们需要阻止 PC B 使用 telnet（端口 23）。下面的命令旨在完成这个任务：
将 ACL 应用到接口：
任务5
网络 192.168.30.0/24 上的用户不应该能够 ping 到 HTTP 和 HTTPS 服务器，但他们应该能够访问网站。
这个任务非常棘手，考察了对协议的理解，使 ping 操作成为可能的协议是 ICMP。在本任务中，我们应该阻止 ICMP 流量到达 HTTP 和 HTTPS 服务器，同时允许所有其他流量。为了在 R3 上完成此任务，所需的命令如下：
前两个命令将阻止指定的流量，在本例中是 ICMP，第三个命令将允许其他协议和端口的流量通过网络。下面的命令用于将此 ACL 应用到最靠近 192.168.30.0/24 网络的接口。
ACL_152">命名 ACL
还有其他类型的 ACL 可以配置。使用数字并不能清楚地描述已配置的 ACL，因此，命名 ACL 是一种更好的方法来跟踪所有配置。标准和扩展 ACL 都支持命名 ACL。下面的命令展示了配置命名 ACL 时使用的结构：
执行上述命令后，将启用 ACL 配置模式，从这里可以配置允许和拒绝的语句，如下所示：
应用这些 ACL 的方式与编号标准 ACL 相同，唯一的区别是访问组号被 ACL 名称替代，如下所示：
注意：这些规则对于扩展 ACL 也是相同的，只是第一个命令中的关键字从 “standard” 改为 “extend”。
ACL_174">复杂 ACL
复杂的 ACL 通常是在标准或扩展 ACL 的基础上进行增强，以实现更多的功能。以下是几种常见的复杂 ACL 类型：
- 动态 ACL：通过要求用户使用 Telnet 连接到路由器进行身份验证，动态 ACL 可以控制哪些数据包能够通过路由器。它通常用于需要身份验证的网络环境中，确保只有经过验证的用户才能访问网络资源。
- 基于时间的 ACL：这种 ACL 根据设定的时间参数来控制流量。例如，可以配置 ACL 规则限制某个网络在特定的时间段内访问互联网。这样的 ACL 适用于需要按时间管理访问权限的场景，比如办公时间内允许访问，而下班时间则禁止访问。
ACL_182">验证和故障排除 ACL
由于 ACL 配置通常会影响网络流量的正常运行，因此验证和故障排除至关重要。可以通过多种方式来验证和排查 ACL 配置，本文将重点介绍两个常用的命令：Show access-lists 和 show ip access-lists
这两个命令用于查看已配置的 ACL 以及每个 ACL 的过滤操作情况。在输出中，我们可以看到每个 ACL 条目的匹配次数，这有助于验证 ACL 是否按预期工作：
show running-config 命令对于验证 ACL 配置非常有用。通过查看当前配置，我们可以检查是否正确地应用了 ACL 规则。尤其是在配置了 ACL 来阻止某些流量时，使用此命令可以确认 ACL 是否按预期进行过滤。
通过观察实际流量的行为来验证配置的正确性也是一种有效的方式。例如，如果我们配置了 ACL 来阻止主机 A 的 Web 流量，而允许主机 B 的 Web 流量，那么如果主机 A 无法访问 Web，而主机 B 能够正常访问，说明 ACL 配置是正确的。
