【网络协议】ACL（访问控制列表）第二部分
概述
在【网络协议】ACL（访问控制列表）第一部分中，我们介绍了 ACL 的基本概念，讨论了它的工作原理，并以标准 ACL 的配置为结束。第二部分将重点讨论扩展 ACL 以及其他相关的 ACL 概念，接着介绍如何配置扩展 ACL，最后进行 ACL 故障排除。
扩展 ACL
标准 ACL 存在一个局限性，即它仅能根据源地址来过滤流量，这在精细控制上显得不够灵活。如果需要更强大和更灵活的流量控制能力，扩展访问控制列表（扩展 ACL）是更好的选择。正如我们之前提到的，扩展 ACL 不仅能够检查源 IP 地址，还可以基于以下条件进行配置：
在第一部分中，我们提到标准访问控制列表 (ACL) 的编号范围是 1 到 99，而扩展 ACL 的编号范围是 100 到 199。
以下是配置扩展 ACL 的命令语法：
操作符是一个关键字，用于比较源地址和目标地址。操作符包括：
注意：操作符关键字只能用于某些协议，例如 UDP 或 TCP。
下面的语句展示了一个扩展 ACL 的示例：
正如我们在本章第一部分中提到的，扩展 ACL 的最大效果在于尽可能靠近源网络的位置使用。
在接下来的部分中，我们将使用第一部分中的拓扑结构来配置扩展 ACL，但会使用不同的指令。
配置扩展 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
还有其他类型的 ACL 可以配置。使用数字并不能清楚地描述已配置的 ACL，因此，命名 ACL 是一种更好的方法来跟踪所有配置。标准和扩展 ACL 都支持命名 ACL。下面的命令展示了配置命名 ACL 时使用的结构：
执行上述命令后，将启用 ACL 配置模式，从这里可以配置允许和拒绝的语句，如下所示：
应用这些 ACL 的方式与编号标准 ACL 相同，唯一的区别是访问组号被 ACL 名称替代，如下所示：
注意：这些规则对于扩展 ACL 也是相同的，只是第一个命令中的关键字从 “standard” 改为 “extend”。
复杂 ACL
复杂的 ACL 通常是在标准或扩展 ACL 的基础上进行增强，以实现更多的功能。以下是几种常见的复杂 ACL 类型：
- 动态 ACL：通过要求用户使用 Telnet 连接到路由器进行身份验证，动态 ACL 可以控制哪些数据包能够通过路由器。它通常用于需要身份验证的网络环境中，确保只有经过验证的用户才能访问网络资源。
- 基于时间的 ACL：这种 ACL 根据设定的时间参数来控制流量。例如，可以配置 ACL 规则限制某个网络在特定的时间段内访问互联网。这样的 ACL 适用于需要按时间管理访问权限的场景，比如办公时间内允许访问，而下班时间则禁止访问。
验证和故障排除 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 配置是正确的。
原文地址：https://blog.csdn.net/2301_77485708/article/details/145157648
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！