晚上十一点我刚洗完澡准备躺下手机弹出一条告警内网某台服务器的SSH端口在短时间内被连续扫了上百次。这不是第一次了之前都是临时改防火墙策略治标不治本。那晚我打开路由器配置文件一条一条核对访问控制列表ACL的规则边看边后悔如果当初做网络规划时把ACL设计清楚现在根本不用半夜爬起来翻配置。这不是什么高端技巧但能把ACL用明白的人一半网络问题都能提前解决。这篇文章就把我这些年用标准ACL、扩展ACL和命名ACL的完整经验写出来。从ACL是什么、三种类型怎么选到Packet Tracer里的完整配置实验再到那些配置完才发现怎么不通了的常见坑一次性讲透。适合正在备考网络工程师认证的初学者也适合在项目里接手过别人老配置、想彻底理清ACL逻辑的同行。1. ACL到底是什么一个网络门禁的完整工作逻辑在动手敲命令之前先把ACL的本质搞清楚。1.1 从一次半夜告警说起前面提到的SSH暴力扫描事件最终解决方式就是在核心设备上做了一条规则只允许办公网段和运维跳板机的IP访问服务器的22端口其他统统拒绝。这条规则的本质就是访问控制列表——一个由允许/拒绝规则组成的报文过滤器。ACL的全称是Access Control List中文叫访问控制列表。它定义了一组条件路由器或交换机收到报文后会按照预先设定的顺序去匹配这些条件匹配上了就执行对应的动作放行permit或者丢弃deny。这个动作就是网络层面最基础的门禁。1.2 ACL的三个核心组成规则、方向、动作理解ACL只需要抓住三个要素。第一是规则。每条规则包含匹配字段和动作比如拒绝来自192.168.1.0网段的流量这就是一条标准规则。匹配字段可以精细到协议、端口、源地址、目的地址甚至可以加上时间范围。第二是方向。ACL必须绑定在接口的某个方向上才能工作。方向只有两个in流量进入接口时和out流量离开接口时。同一个接口可以分别配置两个方向的ACL互不干扰。第三是动作。只有两种permit和deny。没有第三种没有犹豫一下的选项。有意思的是ACL在IOS里的行为是命中即停——报文从第一条规则开始逐条匹配一旦命中某条规则就立刻执行该规则的动作后面所有规则都不再检查。这个特性决定了规则的顺序安排极其重要稍后我专门讲。1.3 为什么ACL必须绑定接口才生效这是新手最常问的问题我明明配置了ACL怎么一点反应都没有原因大概率是你写完ACL规则但没有把规则组绑定到接口上。ACL本身只是一个规则清单它存在于设备的配置里但并不会主动对流量产生任何影响。你必须通过 ip access-group 命令把规则组挂到接口的方向上流量经过这个接口时才会被规则过滤。打个比方ACL规则是小区门口的访客名单但名单不送到保安手里访客照样进出。绑定接口就等于把名单递到了保安面前。1.4 ACL分类与编号范围速查常见的ACL按类型分至少有三类标准ACL、扩展ACL、命名ACL。基于时间的ACL可以算作前三种的一种扩展能力通过 time-range 配合实现。ACL类型匹配精度经典编号范围典型场景标准ACL只匹配源IP地址1-991300-1999按来源地址整体放行/阻断扩展ACL匹配源IP、目的IP、协议、端口100-1992000-2699精细化端口/协议控制命名ACL匹配精度与标准/扩展相同无编号用名称代替复杂网络中的可维护性需求基于时间的ACL在标准/扩展基础上加时间条件与上述范围一致限时开放如非工作时间阻断老版本IOS的编号范围是硬性规定配置时输错范围设备直接报错。到了新版本命名ACL出现后这一限制逐渐被淡化但认证考试里编号范围仍是高频考点该记还是得记。2. 标准ACL与扩展ACL两条命令背后完全不同的过滤哲学很多教材把标准ACL和扩展ACL分开讲但真正在工程里做选型时你会发现它们的区别不只是匹配字段多与少而是两种完全不同的过滤哲学。2.1 标准ACL的边界只认源IP标准ACL的匹配条件只有一个源IP地址。它不关心你要访问谁、用什么协议、走哪个端口。只要你来自被deny的网段不管目的地址是服务器还是打印机一律拒绝。标准ACL的配置语法非常简洁Router(config)# access-list 10 permit 192.168.1.0 0.0.0.255 Router(config)# access-list 20 deny host 10.1.1.5 Router(config)# access-list 30 permit any这种简洁是一种优势也是一种巨大局限。优势在于配置简单对设备性能压力小局限在于无法区分流量的具体目的。比如你想让某个网段不能访问数据库服务器但允许它访问Web服务器标准ACL做不到。正因为标准ACL只认来源不认去向它通常用在边界设备上做整段网段的隔离而不是做服务级别的精细控制。2.2 扩展ACL的维度五元组完整匹配扩展ACL把匹配维度从源地址扩展到了五元组源IP、目的IP、协议类型TCP/UDP/ICMP等、源端口、目的端口。这意味着你可以写出拒绝来自192.168.1.0/24的流量访问服务器192.168.2.100的SSH服务这种精确描述。看一条典型的扩展ACL规则Router(config)# access-list 100 deny tcp 192.168.1.0 0.0.0.255 host 192.168.2.100 eq 22 Router(config)# access-list 100 permit ip any any这条规则拆解下来协议是TCP源网段是192.168.1.0/24目的地址是192.168.2.100这台主机目的端口是22SSH动作是拒绝。后面再补一条 permit ip any any 作为兜底避免把其他流量也误伤。能匹配的维度多意味着能精确控制到某个用户、访问某个服务、通过某个端口的粒度。这就是生产环境里最常用的控制方式。代价是规则数量变大处理时需要逐条匹配对设备CPU也有额外消耗——不过在现在的硬件水平下普通企业级设备跑几百条ACL规则毫无压力。2.3 放哪一头的门派之争标准靠近目的扩展靠近源这是一个老生常谈、但实际项目中仍然经常翻车的原则。标准ACL只有一个匹配维度——源IP。如果你把标准ACL放在靠近源端的位置它会把从该接口出去的所有流量统统过滤一遍无论发往何处只要源地址匹配了就会被处理这就很容易误伤。所以标准ACL的放置原则是尽量靠近目的端。让流量先尽量走完路径到最终目标附近再做准入判断减少误伤范围。扩展ACL恰好相反。既然它匹配精度高就应该尽量靠近源端部署。这样不好的流量刚进入网络就被丢掉不会白占中间链路的带宽也避免流量一路传过去才在最后一跳被拦截造成链路资源浪费。这里有个真实案例某公司有两栋楼A楼用户通过核心路由器访问B楼的财务系统需求是禁止A楼某几个IP访问财务服务器的3389端口。如果按扩展ACL放源端原则应该把ACL挂在A楼接入层设备上。但当时执行工程师图省事把ACL挂在B楼出口朝内的方向结果A楼那些IP发往财务服务器的其他服务也全部被拦截了——因为方向判定为in时设备看的是进入该接口的流量规则中的目的地址匹配粒度没问题但配置上没有同时写允许其他目的加上隐含deny直接全拒。这个坑我下面会展开详细说。2.4 标准ACL和扩展ACL的配置选型对照对比项标准ACL扩展ACL匹配源IP支持支持匹配目的IP不支持支持匹配协议不支持支持匹配端口不支持支持推荐位置靠近目的端靠近源端配置复杂度低中高常用场景网段级隔离、路由过滤服务级访问控制、高危端口封禁选型口诀只要管谁能否访问用标准ACL只要管某个服务能否被访问用扩展ACL。绝大多数生产需求都落到了后者。3. 命名ACL才是工程首选可读性与可维护性完胜数字编号如果说标准ACL和扩展ACL的差别是匹配精度那么命名ACL和数字ACL的差别就是工程可维护性。在真实项目里我几乎不用纯数字ACL写复杂策略理由很现实半年后你回来看自己写的配置数字ACL根本想不起来每一条是干嘛的。3.1 数字ACL的痛点一百条规则肉眼根本分不清在一个中大型网络里ACL规则数量轻松超过几十条。全部用 access-list 100 ... 这种形式堆在一起没有任何语义提示。你只能凭记忆知道第10条是在管什么第55条又是在放行什么。一旦设备重启、配置重新导入或者同事接手排查效率极低。而且数字ACL在传统配置方式下不支持单条插入。想改一条规则往往要把整个ACL删掉重写。操作期间流量处于裸奔状态生产环境下相当危险。3.2 命名ACL的底层语法结构命名ACL的配置分成两步先创建一个命名的规则组进入子配置模式再在子模式下逐条添加规则。标准命名ACLRouter(config)# ip access-list standard BLOCK_DEPT Router(config-std-nacl)# deny 192.168.10.0 0.0.0.255 Router(config-std-nacl)# permit any扩展命名ACLRouter(config)# ip access-list extended BLOCK_SSH Router(config-ext-nacl)# deny tcp 192.168.1.0 0.0.0.255 host 192.168.2.100 eq 22 Router(config-ext-nacl)# permit ip any any注意进入子配置模式后提示符会从 Router(config)# 变成 Router(config-ext-nacl)#这表示你已经在一组ACL的内部后面输入的规则会自动归属到这个命名ACL之下。这种结构化配置方式也降低了把规则写错位置的概率。命名并不是随便起的建议使用能表达业务含义的名称比如 BLOCK_SSH、PERMIT_OA、DENY_P2P。业界没有强制标准但一个好名字能让排错效率提升一个量级。3.3 命名ACL如何优雅地插入和删除单条规则命名ACL最大的工程优势是支持按序列号sequence number精确操作单条规则。每条规则在创建时前面都会有一个序号默认从10开始每增加一条步长加10Router(config)# ip access-list extended OFFICE_POLICY Router(config-ext-nacl)# 10 permit tcp host 192.168.1.10 host 192.168.2.100 eq 80 Router(config-ext-nacl)# 20 permit tcp host 192.168.1.10 host 192.168.2.100 eq 443 Router(config-ext-nacl)# 30 deny ip any any如果之后想在20和30之间插入一条新规则不需要动其他规则Router(config)# ip access-list extended OFFICE_POLICY Router(config-ext-nacl)# 25 permit tcp host 192.168.1.11 host 192.168.2.100 eq 443想删除某条规则直接 no 序列号Router(config-ext-nacl)# no 20这种能力在数字ACL上是做不到的。数字ACL你只能整组删除再重建。所以凡是我经手的项目只要ACL规则超过三条一律用命名ACL。一个小技巧故意把序列号步长设大一些比如设成10、20、30也可以使用 ip access-list resequence 命令重排。预留间隔的好处就是给后期插入规则留空间不会出现想插在3和5之间但4已经被占了的尴尬。3.4 查看与排错命令show access-lists的高级用法配置完ACL第一件事永远是验证而不是等着用户来报障。查看ACL的命令有两个一个是 show access-lists一个是 show ip access-lists后者在路由器上更常用。Router# show ip access-lists BLOCK_SSH Extended IP access list BLOCK_SSH 10 deny tcp 192.168.1.0 0.0.0.255 host 192.168.2.100 eq 22 (4 matches) 20 permit ip any any (128 matches)注意输出里每行规则后面的 (matches) 计数。这个数字表示自ACL挂载以来有多少个报文命中过这条规则。排错时如果某条规则匹配数为0说明对应流量根本没走到这个方向或者规则位置放得不对导致提前被其他规则拦截了。看完匹配数别忘了看绑定关系。ACL写好了没绑定接口等于白写。验证绑定用Router# show ip interface GigabitEthernet0/0 GigabitEthernet0/0 is up, line protocol is up ... Inbound access list is BLOCK_SSH如果这里显示的Access list是空的说明没绑上或者绑定命令没写对。4. Packet Tracer里一小时跑通完整实验从拓扑设计到流量验证理论讲完上实际操作。我下面用Cisco Packet Tracer Student演示一个完整的ACL实验从搭拓扑到最后验证每一步都写清楚。4.1 实验环境准备与Cisco Packet Tracer Student获取Cisco Packet Tracer Student是思科官方推出的网络模拟器主要面向学生和网络初学者支持路由、交换、无线、物联网等多种场景模拟。它的最大价值在于零成本就能在一个虚拟环境里复现真实网络设备的配置逻辑对练手ACL这类实验非常合适。获取方式很简单Packet Tracer Student版本通过思科网络技术学院Cisco NetAcad的学生账号免费下载。注册并加入一门课程后就能在资源列表里找到对应平台的安装包支持Windows和Linux。安装过程无特殊技巧默认下一步到底即可。如果你还没注册建议先注册账号登录NetAcad后搜索Packet Tracer按官方指引下载。版本建议选择8.2.x以上界面更友好设备类型也更全。4.2 实验拓扑设计与需求拆解为了把标准ACL、扩展ACL、命名ACL三种用法都覆盖到我设计了一个很典型的三段拓扑PC1(192.168.1.10/24) ── R1 G0/0(192.168.1.1/24) PC2(192.168.1.20/24) ── R1 G0/0(192.168.1.1/24) R1 G0/1(10.0.0.1/30) ── R2 G0/0(10.0.0.2/30) R2 G0/1(192.168.2.1/24) ── Server0(192.168.2.100/24)需求如下PC1192.168.1.10可以访问Server0的Web服务80端口PC1不允许访问Server0的SSH服务22端口PC2192.168.1.20不允许访问Server0的任何服务其他流量允许通行这个需求如果用标准ACL写写不出来——因为标准ACL匹配不了目的端口。所以禁止PC1访问SSH、允许访问Web必须用扩展ACL。而PC2完全禁止也可以用标准ACL顺手覆盖。为了让三种ACL都在实验里出现我把实验拆成两部分第一部分用标准ACL实现PC2整段阻断第二部分用扩展命名ACL实现PC1的Web/SSH差异化控制。4.3 第一部分标准ACL实现整段阻断第一步先把两台PC和服务器的基础IP配置好。PC1、PC2的IP分别是192.168.1.10和192.168.1.20网关指向192.168.1.1Server0的IP为192.168.2.100网关指向192.168.2.1。两个路由器接口地址按拓扑配好。直连网段互通测试一下PC1 ping Server0能通说明链路没问题。接下来写标准ACL。需求是PC2不允许访问Server0的任何服务。标准ACL只匹配源IP所以在R1的出接口方向挂一条规则即可R1(config)# access-list 10 deny 192.168.1.20 R1(config)# access-list 10 permit any R1(config)# interface GigabitEthernet0/1 R1(config-if)# ip access-group 10 out这里R1的G0/1是去往Server0方向的出口挂out方向。PC2的包到达R1后源地址是192.168.1.20命中 deny丢弃PC1或其他源地址放行。注意如果不写那句 permit anyR1会把所有从G0/1出去的流量全部拒绝。这个隐含deny all特性是ACL新手最容易踩的坑后面专门展开。4.4 第二部分命名扩展ACL实现精细化控制标准ACL只能笼统地阻断整个源。要控制PC1能访问Web但不能访问SSH必须用扩展ACL。我直接用命名ACL的方式写在R2上因为这个ACL离服务器更近策略方向也更清晰。在R2的G0/1接口上流量是进入接口后到达服务器的所以挂in方向R2(config)# ip access-list extended SERVER_POLICY R2(config-ext-nacl)# 10 permit tcp host 192.168.1.10 host 192.168.2.100 eq 80 R2(config-ext-nacl)# 20 deny tcp host 192.168.1.10 host 192.168.2.100 eq 22 R2(config-ext-nacl)# 30 permit ip any any R2(config-ext-nacl)# exit R2(config)# interface GigabitEthernet0/1 R2(config-if)# ip access-group SERVER_POLICY in逐条解析第10条允许PC1访问Server0的80端口。第20条拒绝PC1访问Server0的22端口。第30条放行其他所有流量确保不是来自PC1的流量比如PC2虽然已被R1上的标准ACL拦截但其他合法流量不受影响。注意规则顺序如果把第20条 deny 放在第10条之前那PC1访问Web目的端口80时会先匹配deny吗不会因为第20条明确写了目的端口 eq 2280端口匹配不上这条规则会继续往下走到第10条时匹配permit正常放行。所以顺序并不会产生反转问题。但如果你想用宽松规则先放行大多数再精确拒绝少数就必须把精确拒绝放在宽松放行之前。4.5 验证实验是否真正生效配置完成后验证分三步走。第一步在PC1上用浏览器访问Server0的Web服务能通。在Packet Tracer里PC1的Desktop面板有Web Browser输入Server0的IP即可看到页面。第二步在PC1的命令行里输入C:\ telnet 192.168.2.100会连接超时或被拒绝说明22端口被ACL拦截了。第三步在PC2上执行ping 192.168.2.100返回超时。因为PC2在R1的G0/1出口就被标准ACL丢弃了。第四步在R2上跑 show ip access-lists SERVER_POLICY看每一条规则的匹配计数是否和预期一致。如果第10条匹配数在增长说明PC1的Web流量确实走了这条规则如果第20条匹配数为0说明没有PC1的SSH流量进来符合预期。这个实验跑完标准ACL、扩展ACL、命名ACL在什么场景下用、怎么用基本就清楚了。5. 真正容易翻车的四个细节通配符、隐含Deny、方向与顺序配置ACL的命令就那几条真正让工程师翻车的永远是那些藏在命令背后的默认行为和细节逻辑。这里把我踩过最深的四个坑拿出来讲透。5.1 通配符掩码写反ACL为什么完全失灵通配符掩码wildcard mask和子网掩码是相反的逻辑。子网掩码里1表示必须匹配0表示无关通配符掩码里0表示必须匹配1表示无关。让人最容易错的是很多人配置ACL时顺手写成了子网掩码。比如想匹配192.168.1.0这个网段正确写法是access-list 10 permit 192.168.1.0 0.0.0.255意思是最前面24位必须精确匹配最后8位随意。如果写成了 255.255.255.0规则就变成了前面24位随意最后8位必须匹配即只匹配 192.168.1.0 这个主机地址后面所有 .1、.2、.100 的流量全都不匹配。配置看似没报错但实际流量全走不到这条规则上极易造成放行失效或拦截失效。记不住的通配符换算死记这几个常用值就够了想匹配的对象通配符写法等价简写单台主机0.0.0.0host 1.1.1.1整个网段/240.0.0.255无整个网段/160.0.255.255无所有地址255.255.255.255any5.2 被忽略的尾部隐含Deny All每次配置ACL我几乎都要提醒一遍所有ACL的末尾都隐藏着一条拒绝所有规则不管你在配置里看不看得到它。如果你写了access-list 10 permit 192.168.1.0 0.0.0.255没有追加 permit any 或 permit ip any any那么192.168.1.0可以放行但其他所有来自不同网段的流量全部都会被最后那条隐藏规则拒绝。这条设计本意是安全兜底——没有明确允许的默认都是拒绝。但在实际项目里它经常导致配置完ACL整个网络都断了我才知道的惨剧。所以养成一个习惯写ACL时先想清楚除了我明确允许的其他流量要不要放行如果要就在规则最后显式加一条 permit any 或 permit ip any any。而且这条兜底规则一定要写在最后放在中间会比它靠前的流量全部被放行后面的规则直接失去意义。5.3 方向选错in与out的因果倒置方向是ACL里最隐蔽的翻车点。同一个接口流量进入接口和离开接口看到的报文方向完全不同。画个简单拓扑帮助理解PC ── [G0/0] Router [G0/1] ── Server假设你要禁止PC192.168.1.10访问Server192.168.2.100的22端口。如果ACL挂在R2的G0/1接口上in方向流量从Server所在网段进入R2的G0/1不对。流量方向是PC→Server进入R2 G0/1时已经到达服务器一侧了——实际上对于R2来说来自PC的流量是进入G0/0从G0/1出去。所以挂在G0/1 in反向就错了。正确做法要么挂在R2 G0/0的in方向流量从R1进来时拦截要么挂在R2 G0/1的out方向流量离开R2去往Server时拦截。很多人配置时只想着哪个接口连着服务器就挂哪个接口却忽略了流量方向。结果就是ACL规则写得很完美绑定后却毫无效果。排错时先问自己三个问题流量路径是什么它进入哪个接口、离开哪个接口我的ACL绑在哪个接口的哪个方向5.4 匹配顺序陷阱宽松优先还是严格优先ACL是自上而下逐条匹配的一旦命中立即执行。所以规则顺序直接决定最终效果。举一个反面案例。需求是拒绝PC1访问服务器的22端口其他流量全部放行。有人这写access-list 100 permit ip any any access-list 100 deny tcp host 192.168.1.10 host 192.168.2.100 eq 22第一条 permit ip any any 已经把PC1访问22端口的流量放行了第二条 deny 永远匹配不到。配置不会报错但效果全无。这也叫宽松规则吞噬严格规则。解决方案是具体、严格的规则放在前面宽泛的兜底规则放在最后。规则顺序的本质是把匹配范围小的规则提前让它们有优先裁量权。我自己的习惯是每次写ACL先把规则按匹配范围从小到大排一遍再检查最多匹配的那条兜底规则是不是在最后。写完以后跑两次 show ip access-lists观察每条规则的匹配计数是否符合预期。6. 从Cisco到华为/华三ACL配置思维的迁移很多人学完Cisco的ACL到了华为、华三设备上就懵了。其实只要是同一个网络功能底层逻辑都是互通的区别主要在于命令风格和编号体系。这里把迁移要点梳理一下。6.1 华为与华三ACL编号体系华为Huawei和华三H3C的ACL分类方式和Cisco不同厂商基本ACL高级ACL二层ACL华为2000-29993000-39994000-4999华三2000-29993000-39994000-4999基本ACL对应Cisco的标准ACL只匹配源IP高级ACL对应Cisco的扩展ACL匹配五元组等多种字段。华为的配置语法长这样[Huawei] acl number 2001 [Huawei-acl-basic-2001] rule 5 deny source 192.168.1.20 0 [Huawei-acl-basic-2001] rule 10 permit source 192.168.1.0 0.0.0.255 [Huawei-acl-basic-2001] quit [Huawei] interface GigabitEthernet0/0/1 [Huawei-GigabitEthernet0/0/1] traffic-filter inbound acl 2001这里 rule 5 和 rule 10 就是规则的匹配顺序编号类似Cisco命名ACL里的序列号。华为也支持在基本ACL后面写source 192.168.1.0 0.0.0.255通配符的0/1逻辑与Cisco一致。华三的命令更接近华为。接口下发时华为用 traffic-filter华三同系列也支持老版本叫 packet-filter。核心思路完全一致先建规则 → 绑接口方向 → 验证。6.2 核心语法对比access-list对比rule/traffic-filter操作Cisco华为/华三创建标准ACLaccess-list 10 permit 192.168.1.0 0.0.0.255acl number 2001rule 5 permit source 192.168.1.0 0.0.0.255创建扩展ACLaccess-list 100 deny tcp host 1.1.1.1 host 2.2.2.2 eq 80acl number 3001rule 5 deny tcp source 1.1.1.1 0 destination 2.2.2.2 0 destination-port eq 80接口绑定ip access-group 100 intraffic-filter inbound acl 3001查看规则show ip access-listsdisplay acl 3001华为的扩展ACL写法相比Cisco多了 source 和 destination 关键字但五元组匹配逻辑没变。如果你有一张Cisco的扩展ACL规则基本可以逐字翻译成华为语法。从Cisco迁移过来的重点不是背命令而是绑定接口方向、隐含拒绝、匹配顺序这些思维模型完全一致。6.3 单向访问控制、双向访问控制与端口隔离很多实际需求里会出现单向和双向的说法。华为设备上ACL默认只对指定方向的流量生效比如 inbound 或 outbound。如果你只配了入方向的ACL那从外部主动发起的访问被拦住了但从内部主动访问外部、以及外部返回的应答流量能不能通要看设备是否状态化——华为大部分交换机、路由器的ACL是不记录连接状态的也就是说ACL只检查单个报文不关心这个报文是不是某个已建立连接的回应包。这就带来一个经典问题如果你在接口l入方向拒绝了所有外部IP访问内部但内部主动发起的连接需要经过同一个接口出方向出去出方向ACL如果什么都没配那么应答流量回来时如果是走同一接口的另一个方向可能就不会被检查。但如果你只在入方向做了限制那么外部返回的报文通常也能正常回到内部。真正麻烦的是你需要单向允许——比如内部能访问外部某服务但外部不能主动发起连接。这种情况下仅凭ACL控制几个端口往往不够更需要状态化防火墙或者配合反向ACL策略。这就是单向和双向访问控制的本质差异。再说基于交换机端口的ACL隔离。这个场景多见于接入交换机需求通常是同一台交换机上不同端口之间的设备互相不能访问。实现思路有两种一种是配置端口隔离Port Isolation直接把端口之间二层流量隔开另一种就是在交换机端口下发ACL比如[Huawei] interface GigabitEthernet0/0/2 [Huawei-GigabitEthernet0/0/2] traffic-filter inbound acl 3000把需要禁止互访的源、目的地址写进ACL就能做到指定设备之间的隔离。端口隔离更适合同VLAN内全隔离ACL适合指定设备/服务维度的隔离两者各有适用场景。7. 环境获取Cisco Packet Tracer Student的下载与安装这篇文章的实验部分全程跑在Cisco Packet Tracer Student上。标题里说附下载资源那我最后把这个事讲清楚。7.1 官方获取渠道与版本选择Packet Tracer Student由思科官方提供主要用于网络教学和学习实践。获取路径是思科网络技术学院NetAcad官网注册账号后即可从课程资源中免费下载不需要额外付费。正因为是官方渠道版本更新和系统兼容性都有保障。版本方面只要不是太老的机器直接下载官网提供的最新版即可。8.2.x以上版本在设备型号、ACL语法支持上都很完整足够支撑本文涉及的全部实验。安装过程没有太多可讲的Windows版本一路NextLinux版本注意给安装包加执行权限。装完后打开软件如果提示登录直接用NetAcad账号登录就行。7.2 安装后的第一个热身动作验证ACL配置环境装完Packet Tracer先别急着搭大拓扑做一个最小验证拖一台2911路由器、一台PC、一台服务器按第4章的拓扑连接做一次ACL配置并观察匹配计数是否增长。这一步能确认你对接口、方向、规则语法的理解有没有走偏同时也能快速检验软件环境是否正常。如果你在Packet Tracer里配置ACL时发现命令输入不进去大概率是设备型号太老或处于模拟模式下。可以切换实时模式或者换一台较新的路由器/交换机型号再试。另外Packet Tracer对部分新版本IOS的命令支持不全如果遇到某个命令提示% Invalid input优先检查设备选型而不是怀疑自己写错了。最后分享一个我自己的习惯每完成一组ACL配置我都会在工程文档里画一张ACL规则与接口方向对照表列明规则名称、绑定的设备、绑定的接口、方向、规则摘要、负责人和日期。这张表在半年后排查谁的流量被谁挡了时比任何配置备份都好用。ACL本身不复杂复杂的是它在长周期、多人协作的网络里如何保持清晰可维护。希望这篇文章能帮你把ACL真正吃透少走我当年走过的弯路。