思科ACL配置实例怎么做？，思科ACL配置实例怎么操作

思科ACL配置实例：从原理到实战，一次性掌握访问控制列表的核心逻辑

核心结论：ACL（访问控制列表）是思科设备上实现流量过滤与安全策略的第一道防线，配置的核心在于“先规划、后匹配、再动作”，任何脱离业务需求的ACL都是无效配置，掌握通配符计算、规则顺序、隐含拒绝三大要点，即可解决90%以上的日常过滤问题。

ACL的本质：不是“命令”，而是“流量分类器”

很多初学者把ACL仅仅看作一条条deny或permit语句，但实际上，ACL是一个按顺序匹配的规则集合，设备收到数据包后，从上到下逐条检查规则，一旦匹配就立即执行动作，不再继续往下匹配,这个机制决定了两个关键特性：

• 顺序极其敏感：同一组规则,顺序颠倒可能造成完全不同的过滤结果。
• 末尾隐含拒绝：任何ACL最后都默认拒绝所有未匹配的流量，除非显式添加permit any。

专业建议： 在编写ACL之前，先用纸笔画出“允许谁访问谁、拒绝谁访问谁”的矩阵，再转化为通配符表达式，最后才进入配置界面,这一步能省下大量排错时间。

标准ACL与扩展ACL的选型逻辑

独立见解： 生产环境中，优先使用扩展ACL，标准ACL虽然简单，但无法区分“谁在访问什么服务”，容易造成过度限制或安全漏洞，一条

deny 192.168.1.0会同时封堵该网段的所有流量，而扩展ACL可以做到“只禁止该网段访问内网数据库，但允许其访问网页服务器”。

通配符掩码：反向子网掩码的快速心算法

通配符掩码（Wildcard Mask）用于指定匹配范围，0代表必须匹配，1代表可忽略,常见的换算：

• 255.255.255 → 匹配所有地址，即any
• 0.0.0 → 精确匹配单个IP，即host
• 0.0.255 → 匹配/24网段
• 0.255.255 → 匹配/16网段

实战技巧： 如果要从子网掩码换算通配符，只需要用255.255.255减去子网掩码即可，例如/26的掩码是255.255.192，通配符就是0.0.63,这个减法心算能显著提升配置速度。

配置实例：企业办公网加固

场景描述

某公司有三个网段：

• 办公区：168.10.0/24（员工电脑）
• 服务器区：168.20.0/24（Web服务器、数据库服务器）
• 访客区：168.30.0/24（无线访客）

安全要求：

1. 访客只能访问互联网,不能访问服务器区。
2. 办公区能访问Web服务器（TCP 80/443），但不能访问数据库（TCP 1433）。
3. 只允许内网管理主机0.0.5对路由器进行SSH管理。

配置命令（思科IOS）

access-list 100 permit tcp 192.168.10.0 0.0.0.255 host 192.168.20.10 eq 80
access-list 100 permit tcp 192.168.10.0 0.0.0.255 host 192.168.20.10 eq 443
access-list 100 deny   tcp 192.168.10.0 0.0.0.255 host 192.168.20.20 eq 1433
access-list 100 permit ip 192.168.10.0 0.0.0.255 any
access-list 100 deny   ip 192.168.30.0 0.0.0.255 192.168.20.0 0.0.0.255
access-list 100 permit ip any any

接口应用（在连接办公网的路由器接口入方向）：

interface GigabitEthernet0/0
 ip access-group 100 in

管理SSH的ACL单独配置：

access-list 10 permit host 10.0.0.5
line vty 0 4
 access-class 10 in
 transport input ssh

配置解读：

• 第1-2条：精准放行办公区到Web服务器的HTTP/HTTPS。
• 第3条：显式拒绝访问数据库,隐蔽端口也一并封死。
• 第4条：允许办公区访问其他任意地址（如互联网）。
• 第5条：拒绝访客区进入服务器区。
• 第6条：务必添加的兜底规则,防止隐含拒绝导致所有流量中断。

酷番云经验案例：云上ACL与本地ACL的协同实践

酷番云在为客户迁移混合云架构时，发现某客户的本地防火墙策略与公有云安全组规则存在大量重复和冲突，我们给出的方案是：保持本地ACL负责“粗粒度区域隔离”，云上安全组负责“细粒度应用控制”。

客户在本地路由器上仅保留三条ACL规则：允许办公网访问云VPC、拒绝访客网段、其余拒绝，而在酷番云的安全组中，精确到端口级别对外开放Web服务，这样既避免了跨设备排错的复杂链路，又利用了云平台安全组即改即生效的优势。核心经验是：ACL不是越多越好，规则每增加一条，排错复杂度就会指数上升。 我们的习惯是每季度审计一次全部ACL，删除超过90天未命中的规则，同时用show access-list查看匹配计数,冷规则直接清理。

常见排错与优化技巧

• 

  开启日志匹配：在关键deny规则后加log关键字，例如deny ip 192.168.30.0 0.0.0.255 any log，通过show log实时观察攻击源。

• 使用命名ACL：纯数字编号难以表达业务含义，建议使用ip access-list extended OFFICE_TO_SERVER形式的命名ACL,提升可读性。
• 测试工具： 用telnet或nc测试端口连通性时，注意先确认ACL方向入方向（in）过滤的是从外部进入接口的流量，出方向（out）过滤的是从接口发送出去的流量,方向搞反是最高频配置错误。

相关问答

问1：ACL规则里最后一定要写permit ip any any吗？

不一定，如果ACL是用于限制特定流量，且明确要求禁止其他一切通信，那么不写完全正确，但若ACL用于常规业务接口且没有全局放行策略，建议显式添加，因为隐含拒绝会静默丢弃所有未匹配流量，排查问题时很难察觉，稳妥做法是：在测试环境先不加兜底规则，用ping和telnet验证匹配计数；确认无误后,再决定是否加入兜底允许。

问2：扩展ACL只能部署在源端或离源端最近的地方吗？

不完全是，标准ACL必须靠近目标，因为标准ACL无法匹配目的IP，放得离源太近会误伤经过此路由器的其他流量，而扩展ACL可以匹配目的IP和端口，放在源端更省带宽不允许的流量在源头就被拦截，不会再传输到中间链路，但混合云场景下，考虑安全设备性能，有时也会把扩展ACL放在核心出口，而不是边界路由器。核心原则：在满足业务需求的前提下，让不需要的流量尽早被丢弃，同时避免单点过滤的适用范围过窄。