1. 先说这个实验到底要解决什么问题做网络这块时间长了你会发现一个很有意思的现象很多刚接触网络的同学对VLAN的理解就停留在VLAN能隔离广播域不同VLAN不能直接通信这两句话上。但真到了实际场景比如公司里要允许研发部门访问服务器又要禁止访客网络访问内网资源或者财务系统只对指定网段开放这时候光靠划分VLAN是远远不够的。这正是做这个基于VLAN标签的网络访问控制实验的初衷把一个看起来很基础的二层技术延伸到三层策略控制层面让VLAN从能隔离变成能管控。这个实验适合谁参考一种是正在学网络技术、准备考证或者做课程设计的在校同学另一种是刚入职、需要接手公司网络维护的初级工程师。它的核心价值在于不只是教你敲命令而是把VLAN设计、标签转发原理、三层路由、访问控制策略这条链路完整串起来让你看明白流量是怎么从一台PC出发被打上标签、穿过Trunk链路、经过三层设备决策最终到达目标设备的。看完之后你拿到一张网络拓扑图至少能说出为什么这里要用Trunk为什么ACL要配在三层接口上这类问题。实验环境不复杂一台三层交换机加上两台二层交换机就可以如果手头只有GNS3、EVE-NG这类模拟器也能完整跑通。我这次用的是三台交换机组的小型拓扑分别模拟办公区、研发区和服务器区在三层交换机上做VLAN间路由再用ACL访问控制列表绑定VLAN标签来做细粒度的流量管控。整个过程从二层配置、三层路由到策略控制每一步都有明确的验证手段不是配完就完事而是反复抓包、PING、跟踪路径去确认效果。2. VLAN隔离与访问控制的整体设计思路2.1 为什么单纯划分VLAN还不够先回到最基础的问题VLAN到底做了什么。从数据链路层角度看VLAN通过在二层帧里插入802.1Q标签4字节让交换机能识别帧属于哪个逻辑网络从而把一台物理交换机切成多个逻辑交换机。这种方式最直接的好处是隔离广播域——VLAN 10里的广播帧不会传到VLAN 20去每个VLAN独立维护MAC地址表避免了广播风暴互相干扰。但问题在于VLAN天生只解决东西向隔离不解决南北向访问需求。企业网络永远存在一个矛盾既要隔离不同部门又要在合规前提下允许部分跨部门访问。比如行政部需要访问ERP服务器研发部需要访问代码库但人事部的薪资系统只准特定几个IP访问。这种需求用二层VLAN是表达不出来的你必须引入三层转发然后在三层设备上做策略。很多初学者在这一点上会走弯路以为在交换机上把端口划分到不同VLAN就完成隔离了然后发现不同VLAN之间通过三层交换机或路由器还是能互访于是纳闷我明明做了VLAN为什么还是能通这里的本质是二层隔离能挡住广播和数据帧直达但挡不住路由决策。一旦设备配置了VLANIF接口地址并开启路由VLAN间流量就会走三层转发默认是互通的。要真正实现选择性访问必须依靠ACL在路由路径上做过滤。2.2 实验拓扑与VLAN规划的考虑我这套实验的拓扑是这样设计的三台设备核心交换机三层接两台接入交换机二层每台接入交换机上划分不同VLAN的端口组然后通过Trunk链路把带标签的帧送到核心交换机。具体规划如下表设备VLAN编号网段用途接入端口接入交换机AVLAN 10192.168.10.0/24办公区PCGE0/0/1 - GE0/0/10接入交换机BVLAN 20192.168.20.0/24研发区PCGE0/0/1 - GE0/0/10核心交换机VLAN 10192.168.10.254办公网关VLANIF 10核心交换机VLAN 20192.168.20.254研发网关VLANIF 20核心交换机VLAN 30192.168.30.0/24服务器区VLANIF 30这里有个很关键的选型问题为什么服务器区单独用一个VLAN 30而不是跟某个部门混在一起因为服务器的访问需求跟终端完全不一样——终端是被管理对象需要严格限制服务器是资源提供方要按端口和协议开放。单独划一个服务器VLAN方便在核心交换机上用一条ACL规则统一控制谁能访问服务器、能访问服务器的什么端口不用针对每个部门单独建服务VLAN规则维护成本低很多。另外Trunk链路的规划同样有讲究。接入交换机A和B上联核心交换机的接口必须配置为Trunk并且允许VLAN 10和20以及将来可能新增的VLAN通过。但在配置时我特意做了精简只放行实际用到的VLAN而不是用port trunk allow-pass vlan all一刀切。这样做的好处是当某个VLAN出现广播风暴或环路问题时不会通过Trunk链路扩散到所有接入交换机。这个习惯在企业网运维里非常重要——Trunk链路放行范围越大故障爆炸半径越大。2.3 控制策略的配置思路与匹配逻辑做访问控制之前先要搞清楚流量路径。以办公区PC要访问服务器为例路径是PC发出目标IP为192.168.30.10的数据帧到达接入交换机A的Access口后被打上VLAN 10的标签帧通过Trunk链路送到核心交换机核心交换机看到目标是192.168.30.0/24网段不属于VLAN 10于是做三层路由决策——查路由表找到VLANIF 30的直连路由把帧从二层模式切到三层路由模式重新封帧后从VLAN 30对应的端口转发出去。ACL要拦截的正是这个路由决策过程。华为设备上ACL可以应用在VLANIF接口的入方向inbound或出方向outbound。我在这个实验里全部用了出方向策略理由很直白核心交换机是VLAN间流量的必经之路出方向过滤可以统一管控离开某个VLAN网段的流量。比如在VLANIF 10的接口上应用出方向ACL就是要管控从办公区出去的所有流量在VLANIF 30上应用出方向ACL就是管理所有VLAN对服务器区发起的访问规则语义更集中。ACL匹配顺序是另一个必须讲透的点。华为设备默认的匹配顺序是config-mode配置顺序规则从上到下逐条匹配一旦命中了某条规则就停止继续匹配不再往后看。这意味着你写规则时的先后顺序就是生效顺序。我在这个实验中把精确允许的规则放在前面把大范围拒绝的规则放在后面最后再放一条隐式拒绝兜底华为设备ACL末尾自带deny any无需手动写。如果不注意顺序把deny any提前到规则列表前面所有放行规则都会被它遮蔽直接导致全网不通——这是个非常经典的配置坑。3. 核心配置实操从二层隔离到三层管控3.1 接入层与核心层的VLAN基础配置实操部分先从接入交换机A开始。进入系统视图后先批量创建VLAN再把端口划入对应VLAN。这一步我用的命令如下# 接入交换机A办公区 system-view vlan batch 10 interface gigabitethernet 0/0/1 port link-type access port default vlan 10 # 重复配置GE0/0/2至GE0/0/10此处省略重复命令接入交换机B做同样的操作只不过VLAN编号改成20# 接入交换机B研发区 system-view vlan batch 20 interface gigabitethernet 0/0/1 port link-type access port default vlan 20接下来把两台接入交换机的上联口配置为Trunk并放行对应VLAN# 接入交换机A上联口 interface gigabitethernet 0/0/24 port link-type trunk port trunk allow-pass vlan 10 # 接入交换机B上联口 interface gigabitethernet 0/0/24 port link-type trunk port trunk allow-pass vlan 20这里有个细节值得单独说明Trunk接口在默认情况下有Native VLAN缺省VLAN的概念华为设备默认Native VLAN是VLAN 1。如果对端设备Native VLAN配置不一致就会导致带标签和不带标签的帧被错误接收。所以建议实验环境里明确设置Trunk的缺省VLAN例如port trunk pvid vlan 10保证两端PVID一致否则排查问题时会非常痛苦。核心交换机上需要同时创建三个VLAN并给VLANIF接口配置IP地址同时开启三层路由功能# 核心交换机 system-view vlan batch 10 20 30 interface vlanif 10 ip address 192.168.10.254 255.255.255.0 interface vlanif 20 ip address 192.168.20.254 255.255.255.0 interface vlanif 30 ip address 192.168.30.254 255.255.255.0 # 开启IPv4路由转发 undo ip routing-mode注意undo ip routing-mode这种写法取决于设备型号。部分款型上默认就支持三层路由不需要这条命令但有些设备上必须手动打开IP转发功能。配置完可以执行display ip routing-table看到三个直连网段出现在路由表里说明VLAN间路由的基础已经通了。这时不配ACL的话三个VLAN之间全部互通。3.2 VLANIF网关接口与DHCP地址分配实测在实际网络里终端IP地址一般靠DHCP分配免得每台PC手动配IP。在三层交换机上配置DHCP Server很简单核心交换机做法如下# 核心交换机DHCP配置 dhcp enable interface vlanif 10 dhcp select global interface vlanif 20 dhcp select global # 配置全局地址池 ip pool vlan10_pool gateway-list 192.168.10.254 network 192.168.10.0 mask 255.255.255.0 excluded-ip-address 192.168.10.1 192.168.10.10 dns-list 223.5.5.5这里做个关键说明一定要把网关IP放入排除地址池。如果不排除DHCP服务器有可能把地址池里的IP随机分出去一旦把网关IP分配给了某台PC这台PC和网关之间就会出现IP冲突表现为时通时断的诡异故障。这类问题在实验里最容易复现也最容易让人怀疑是VLAN配置问题其实是DHCP地址池规划问题。验证DHCP是否生效可以在一台接入交换机A下的PC上执行ipconfigWindows或者dhclientLinux确认拿到的IP在192.168.10.0/24网段内、网关是192.168.10.254。如果拿到的是169.254.x.xWindows或者没拿到地址多半是DHCP请求广播没有跨VLAN传到核心交换机的VLANIF接口。二层广播只能在VLAN 10内部传递核心交换机的DHCP服务监听的接口就是VLANIF 10正常情况下能收到。如果接入交换机上连口VLAN配置错了广播帧就不会送达。3.3 ACL规则编写怎么写才能精确控制而不误伤访问控制策略是本实验的重心。先梳理需求办公区VLAN 10可以访问服务器区VLAN 30的HTTP和HTTPS服务研发区VLAN 20可以访问服务器区的所有服务服务器区VLAN 30不能主动访问办公网和研发网办公区和研发区之间默认不通。需求梳理完ACL策略其实可以分解为允许谁、拒绝谁、放在哪三个问题。从交换机视角来看问题更简单——所有跨VLAN流量都经过核心交换机的VLANIF接口只要在接口上做规则就行。这里我选了高级ACL编号3000系列因为要对TCP/UDP端口做精细匹配# 核心交换机ACL配置 acl number 3001 rule 5 permit ip source 192.168.10.0 0.0.0.255 destination 192.168.30.0 0.0.0.255 rule 10 permit ip source 192.168.20.0 0.0.0.255 destination 192.168.30.0 0.0.0.255 # 把这个ACL应用在服务器VLAN的入方向意思是控制从其他VLAN进入服务器区的流量 interface vlanif 30 traffic-filter inbound acl 3001等等这里我其实想示范一个看似合理但有问题的思路再解释为什么要改成出方向。很多初学者会想把规则配在服务器区接口上意图是看清楚谁进了服务器。但实际测试时发现这有个缺点如果未来服务器区内部也需要做访问控制比如服务器A和服务器B之间互访ACL规则就会变得冗余复杂而且需要维护的ACL数量会跟着VLAN数量增加。更好的做法是把ACL配在发起访问的源VLAN接口上做源区域出口控制# 核心交换机ACL配置调整为出方向 acl number 3001 rule 5 permit tcp source 192.168.10.0 0.0.0.255 destination 192.168.30.0 0.0.0.255 destination-port eq 80 rule 10 permit tcp source 192.168.10.0 0.0.0.255 destination 192.168.30.0 0.0.0.255 destination-port eq 443 rule 15 permit ip source 192.168.20.0 0.0.0.255 destination 192.168.30.0 0.0.0.255 # 应用在办公网VLANIF出口 interface vlanif 10 traffic-filter outbound acl 3001 # 注意VLANIF 20不应用ACL研发区默认可访问服务器区这里就出现一个明显的差异点办公区只能访问服务器的80/443端口研发区不做任何限制。如果用核心交换机做统一网关这个策略完全可以分散到各VLANIF接口上发生在出口比发生在入口更好地表达了管控意图。实践中我建议按这个思路组织规则ACL条数反而更少语义也更清晰。但有一个场景例外如果网络里有防火墙或者核心交换机上有多个方向流量交汇入方向策略inbound能更好地实现统一白名单式管控因为你可以站在受保护资源的角度把所有允许的来源列成一张表。具体选择哪一侧取决于你的网络架构和可维护性没有绝对的对错。3.4 连通性测试与抓包验证配置完成后进入验证环节。测试计划分成两步先验证VLAN间路由基础可用再验证ACL控制是否真正生效。第一步在办公区PC上PING服务器区地址192.168.30.10ping 192.168.30.10如果通说明VLAN间路由和Trunk链路都正常。如果不同优先检查接入交换机A上联口的Trunk放行列表是否包含VLAN 10检查核心交换机VLANIF接口是否UP。我可以用display interface vlanif 10看接口状态display port vlan看端口VLAN分配。第二步PING通之后进行端口策略验证。在办公区PC上分别测试访问服务器的不同端口# 访问HTTP服务应该通 curl http://192.168.30.10 # 访问HTTPS服务应该通 curl -k https://192.168.30.10 # 尝试PING服务器应该不通。因为ACL只放行了TCP 80/443ICMP被隐式拒绝 ping 192.168.30.10有意思的来了前面刚PING通过加上ACL之后PING就失败了这就是ACL在VLANIF 10出方向上过滤掉了ICMP流量。而研发区PC去PING服务器依然能通因为VLANIF 20接口没有绑定ACL。如果你在办公区PC上测试结果为80和443通、ICMP不通说明ACL生效了如果所有都通说明ACL没绑对接口或者应用方向写反了。这个测试逻辑本身就是一份很好的排查手册。4. 影响范围分析与几种典型故障排查4.1 策略生效后的流量影响范围实验做完后我重点分析了一下影响范围这个问题这也是网络变更前必须考虑的事情。ACL下发给VLANIF接口后影响的是所有从这个VLAN发出去的流量吗答案是取决于你的匹配条件。我上面配置的ACL 3001写的是源192.168.10.0/24去往192.168.30.0/24的TCP 80/443所以办公区访问服务器以外网段的流量比如访问公网或访问VLAN 20仍然会被隐式拒绝或者由其他路由策略决定不会因为这条ACL而产生预期外的影响。但如果你写的是rule 5 permit tcp source 192.168.10.0 0.0.0.255 destination any destination-port eq 80那办公区所有发往任何目标的80端口流量都会被放行。从管控粒度看两者差别很大。这里我有两条建议一是ACL源地址必须精确到VLAN网段不要图省事用any二是把服务器区域作为专门的资源网段所有对服务器的访问策略集中规划。文中的服务器网段是192.168.30.0/24后续如果有数据库服务器、备份服务器可以考虑按服务内容拆分成VLAN 31、VLAN 32而不是全塞在VLAN 30里。另一个影响范围容易被忽略Trunk链路上传输的帧。配置ACL前VLAN 10的PC发的广播帧还是可以正常到达核心交换机加ACL后ACL只过滤三层数据包不影响二层广播帧如ARP、DHCP发现报文。所以同一VLAN内部的通信完全不受影响。这个点特别容易在排查时造成误解——有人加了ACL之后发现办公区PC不能上网了第一反应是ACL阻断了一切实际上如果办公区访问互联网是从核心交换机做NAT出去那么需要放行的是去往公网的流量ACL里没放行NAT后面的流量自然就断了。ACL不是全局防火墙它管不到接口上的所有流量只审核它自己被调用的那一条转发路径。4.2 从实验结果归纳的故障排查顺序实操过程中我先后踩了三个坑这里逐个复盘每个坑都对应一个排查方向。第一个坑出现在Trunk链路。接入交换机A上联口的Trunk放行列表里漏了VLAN 10导致办公区PC的DHCP请求到了不了核心交换机的VLANIF 10接口PC一直拿不到地址。排查过程是这样先看接入交换机端口状态display port vlan发现GE0/0/24的PVID是VLAN 1而VLAN 10未放行。这里补充一个技巧不要把Trunk放行列表默认为所有VLAN都通实际工程项目里上联口放行哪些VLAN、放行到什么范围必须严格按拓扑和业务需求来。第二个坑是ACL应用方向。一开始我把ACL绑定到VLANIF 30的inbound方向结果办公区PC访问服务器时被正常放行但研发区PC访问服务器也被拦截了。研究后发现规则列表里根本没写研发区允许规则是隐式拒绝把它拦了。这个现象很好理解——inbound方向站在服务器入口所有进来的流量都过这道闸口。随后我调整了策略把ACL分散绑定到各源VLAN的outbound方向研发区不绑ACL办公区只绑限制性的ACL。这样规则数量没有增加但是控制灵活性更高每一条规则只管一个区域出口。第三个坑是ICMP测试带来的错觉。配置完ACL后我从办公区PC持续PING服务器IP过了一会儿PING不通了但网页还能打开。一开始怀疑是链路闪断查了一圈才发现是ACL规则没放行ICMP。后来我总结出一个经验实验环境里不要用单一的PING结果判断网络是否通要结合业务端口、路由表、ARP表等综合判断。特别是在有ACL的场景里PING不通不代表服务不可达PING通也不表示所有端口都放行了。验证网络策略必须分层、分协议测试否则很容易误判。4.3 几类高频故障对应的排查速查表为了让这个实验报告对你更有复用价值我把排查中用到的命令和思路整理成表。执行命令时通常需要进入用户视图或系统视图这里标注了视图类型。故障现象可能原因快速排查命令PC无法获取IP地址接入交换机端口未正确划分VLANTrunk放行列表缺失DHCP地址池不包括该VLAN网段display port vlandisplay vlan summarydisplay ip pool跨VLAN ping不通VLANIF接口IP未配置或接口未UPTrunk允许VLAN不匹配路由表缺直连路由display ip interface briefdisplay interface vlanif xdisplay ip routing-table同VLAN能通但跨VLAN不通ACL策略拦截路由策略问题三层转发未开启display acl configdisplay traffic-filter applied-record部分协议通部分协议不通ACL规则未放行特定协议如ICMPACL规则顺序配置不当display acl 3001display traffic-filter statisticsDHCP地址冲突地址池未排除网关IP地址池范围过宽display ip pool conflictreset ip pool conflictTrunk接口收包错误计数暴增PVID不匹配对端Trunk放行列表不同步display interface trunkdisplay counters这里补充一条非常有用的现场排查技巧华为设备上用display traffic-filter applied-record能直接看到ACL被应用在了哪些接口、什么方向上。如果确认ACL已经应用到位还怀疑规则逻辑有问题可以把rule编号递减/递增逐条核对确认规则优先级顺序。规则匹配顺序在生产环境里是大事——写错一条顺序放行规则被后面的拒绝规则顶掉就会复现配置了允许但就是不通的怪事。4.4 实验延伸把访问控制从网段级细化到主机级基础的VLANACL实验做完后可以往两个方向扩展这两个方向也是企业网络中真正会涉及的内容。第一个扩展方向是主机级控制。当前的ACL匹配到的是192.168.10.0/24整个网段如果只想允许某台办公PC访问服务器可以把源地址精确到主机IP例如rule 10 permit tcp source 192.168.10.25 0 destination 192.168.30.0 0.0.0.255 destination-port eq 80。这种精确到主机的方式尤其适合服务器运维IP白名单场景。缺点是规则数量上升IP地址一变就要同步改ACL所以建议做成集中管理或者结合DHCP静态绑定使用。第二个扩展方向是时间策略。华为ACL支持基于时间段生效例如time-range workday 09:00 to 18:00 working-day acl number 3002 rule 5 permit tcp source 192.168.10.0 0.0.0.255 destination 192.168.30.0 0.0.0.255 destination-port eq 80 time-range workday这个功能很实用比如公司设定了下班后禁止办公PC访问服务器的合规要求一条带时间段的ACL就能解决。很多工程师在实验里容易忽略这个能力但它对企业安全策略落地特别有帮助。更进一步如果你需要的是状态防火墙级别的能力比如允许外部发起HTTPS连接但不允许内部通过HTTP回连单靠ACL就不够了必须引入安全区域、状态检测等机制。华为设备上的安全策略Security Policy比传统ACL高级一个层级支持状态检测、应用识别、用户绑定。有条件的话可以继续在模拟器里实验但理解VLAN标签三层路由ACL这条主线仍然是一切策略控制的基础。5. 实验之外我对VLAN访问控制的几点体会如果要把这次实验沉淀成一句话VLAN标签是隔离的基础设施ACL是访问控制的执行者而真正决定安全效果的是你对流量路径的深刻理解。没有路径理解配置再多VLAN也只是在堆砌隔离的壳子控制策略依然会漏风有了路径理解哪怕只用一条高级ACL也能覆盖核心的管控诉求。回到实验本身我在配置过程中最深刻的体会是——现在很多模拟器或真机的默认配置已经做了大量自动化初学者反而容易忽略底层的原理。以Trunk为例现在很多操作者习惯直接输入port trunk allow-pass vlan all看似省事实际上把VLAN隔离的效果打了折扣出了问题也难以定位。我在实际训练中会刻意要求自己逐条放行VLAN、逐条标注ACL规则用途。这个习惯一开始觉得繁琐后来越发觉得值得配置的可读性直接决定了故障时的排查效率。最后分享一个实际的排障小技巧如果你在某台PC上PING不通服务器但PC的业务应用却正常先去核心交换机上查看ACL命中的计数值。display acl 3001观察规则5、10等编号下的命中次数是否在实时增长。如果命中次数没变化说明流量根本没走到ACL所在路径上应去查路由表、Trunk放行列表如果命中次数在涨说明ACL生效中问题更可能出在ACL规则内容本身放行条件不足、匹配顺序错误。这个分流思路能帮你省下大量排查时间。做这个实验时我反复提醒自己一句话不要只满足于通了要多问几个为什么通为什么不通行。VLAN标签本身是网络世界里非常微小的一帧变化但围绕它展开的二层、三层访问控制设计几乎是每个企业网络都要面对的基础命题。把这一块吃透了后面再看防火墙策略、零信任网络设计、SDN控制平面都会有更踏实的根基感。