兴盛优选1. 一台防火墙当多台用，先理解虚拟系统的真实价值
我接触华为防火墙虚拟系统实验，最早不是从实验室开始的，而是被一个实际需求逼着去研究的。当时手头只有一台USG6000系列设备，但待办的网络隔离需求却有两套：一套是办公网和生产网之间要严格互控，另一套是给外部合作单位单独划区域做访客接入。两套需求的安全策略完全不同，互访规则也互相牵制，如果硬塞在同一台防火墙里，策略表会越堆越乱，后期谁都不敢改。重新采购一台设备，预算周期又跟不上。后来发现华为防火墙本身支持虚拟系统（VSYS）功能，才意识到这件事从一开始就应该往这个方向设计。
所谓虚拟系统，简单说就是把一台物理防火墙按逻辑切分成多台“虚拟防火墙”。每一台虚拟系统拥有自己独立的接口、路由表、会话表、安全策略和管理权限。从网络转发角度看，虚拟系统内部跑的流表、策略、会话都互相隔离，数据在一个虚拟系统里被放行或阻断，完全不影响其他虚拟系统。可以这样理解：同一台物理防火墙上，管理员A在虚拟系统1里做策略配置，管理员B在虚拟系统2里做策略配置，两个人互不看见对方的配置，也互不干扰对方的转发。这种隔离性是多租户场景的核心诉求。
很多人会把虚拟系统和VRF、VLAN这类概念混淆。我的理解是，VLAN解决的是二层广播域隔离，VRF解决的是三层路由表隔离，而虚拟系统解决的层次更靠上——它做的是防火墙业务能力的隔离。给某个虚拟系统分配接口和策略配额后，它就像一台独立防火墙一样工作；如果其中一个虚拟系统遭受大量攻击导致会话表耗尽，它也只能消耗自己被分配的资源份额，不会把整台设备拖垮。这也是虚拟系统在政企网络、运营商接入、云安全资源池里被大量使用的原因。
这个实验适合什么人做？我觉得有三类人最合适：刚学完防火墙基础配置、想进一步理解“多租户隔离”概念的网络初学者；正在设计园区网或政企网出口方案，需要评估一台防火墙能否承载多套安全域规划的工程师；还有准备数通或安全方向认证考试，想把虚拟系统配置过程完整跑一遍的备考人员。实验本身并不复杂，只要理解了设计逻辑，命令操作反而很机械。
这里要先明确一点：虚拟系统的配置入口在“根系统”里。物理防火墙和设备自身的全局管理配置，属于根系统；而所有新创建的虚拟系统都是根系统派生的子设备。一台USG系列防火墙最多能创建多少个虚拟系统，取决于设备型号和处理性能。实验环境里用模拟器，资源限制会宽松一些，但真机上要注意License和设备款型规格，不是所有型号默认都能开启虚拟系统功能。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 实验环境准备：eNSP里搭VSYS，真机与模拟器的几个关键差异
2.1 我用的实验拓扑和设备选择
做这个实验，首选是华为eNSP模拟器。模拟器里自带的防火墙设备是USG6000V，型号完整，支持虚拟系统功能。我的建议是把它作为核心实验设备：一台USG6000V，再准备三台PC或三台AR路由器，分别模拟三个不同的业务区域。
我给这个实验规划的拓扑大概是这样：
| 角色 | 设备 | 接口 | 规划网段 | 归属 |
|---|---|---|---|---|
| 物理防火墙 | USG6000V | GE0/0/0 | 10.10.10.1/24 | 根系统管理网 |
| 虚拟系统A-业务口 | USG6000V | GE0/0/1 | 192.168.10.1/24 | VSYS_A |
| 虚拟系统B-业务口 | USG6000V | GE0/0/2 | 192.168.20.1/24 | VSYS_B |
| 终端1 | PC1 | - | 192.168.10.10/24 | 接入VSYS_A |
| 终端2 | PC2 | - | 192.168.20.10/24 | 接入VSYS_B |
注意，USG6000V上虚拟系统绑定的物理接口，和根系统里配置的接口IP不能冲突。接口一旦分配给虚拟系统，根系统视图下就不能再对这个接口配置三层地址，只能看到接口被占用。这个特征在配置时要特别留意，否则接口IP明明没配过，却总是提示地址冲突，就是因为接口已经被某个虚拟系统占用了。
2.2 模拟器版本和防火墙版本带来的“隐形坑”
eNSP里USG6000V的系统版本不同，命令会有差异。我在较新版本eNSP上实验时，虚拟系统相关的命令入口基本是固定的，大致流程是通过vsys命令进入虚拟系统管理视图。但部分旧版本镜像或部分企业设备版本，需要先在根系统执行vsys enable开启虚拟系统总开关，或者使用不同的启动命令，这个差异很容易让初次实验的人卡住。
如果你在模拟器里完成实验后，打算把同样命令搬到真机上执行，需要留意下面几个区别：
- 真机的接口命名可能是
10GE1/0/1、GigabitEthernet1/0/1加槽位号，模拟器里常见的GigabitEthernet0/0/x只是简化接口编号。 - 部分低端款型防火墙自带的虚拟系统授权不足，创建第二、第三个虚拟系统时会提示License不足。
- 真机版本V500R005以后，安全策略默认按“白名单”思路处理，没有匹配到规则默认deny，模拟器里同样如此。这个特性在验证实验时会很有用。
2.3 WEB管理界面的登录预备
很多人在模拟器里想通过WEB界面管理虚拟系统，结果发现浏览器打不开防火墙管理页面。我的经验是：在eNSP的USG6000V上，如果刚启动完设备马上访问WEB页面，十有八九会失败，因为设备的web服务进程还没完全起来。更稳妥的办法是先用CLI确认WEB服务正常，再配置管理口的service-manage权限。
如果打算用WEB管理虚拟系统，最好给G0/0/0这个管理口开一个额外地址作为网关，或者把WEB管理绑定到其他接口，否则终端没有路由能到防火墙管理地址，浏览器自然无法打开页面。以下是自己实验时习惯性的最小WEB准备：
code复制sys
interface GigabitEthernet0/0/0
ip address 10.10.10.1 255.255.255.0
service-manage https permit
service-manage ping permit
quit
web-manager enable
注意，service-manage https permit相当于放行管理面的HTTPS访问，如果没有这条命令，即使WEB服务本身已经开启，接口也不会响应来自该方向的HTTPS请求。这个细节在排错时经常被忽略，我至少见过三次有人在论坛问“防火墙WEB页面打不开”，结果就是忘了配置service-manage。
3. 创建虚拟系统的完整操作逻辑：先分配资源，再启动业务
3.1 从根系统的自查开始
实验不能一上来就狂敲命令。我建议先花一分钟检查防火墙当前状态。
先进入系统视图，查看根系统下已经存在的虚拟系统：
code复制display vsys
如果只显示根系统本身的信息，那说明还没有创建任何虚拟系统，环境是干净的。接着查看接口状态，确认G0/0/1和G0/0/2目前都没有配置IP，没有加入任何安全区域：
code复制display ip interface brief
接下来要规划好虚拟系统的资源分配。默认情况下，虚拟系统如果没有显式分配资源，通常只能使用设备默认预留的少量会话数和策略数。如果实验里打算跑大流量，或者模拟比较复杂的策略数量，就要用resource命令给虚拟系统分配足够的CPU权重或会话数。模拟器环境默认配置已经够用，但如果实验中发现虚拟系统无法启动，多半就是资源配额不够导致的。
3.2 创建两个虚拟系统：VSYS_A与VSYS_B
根系统模式下，使用系统视图创建虚拟系统并给它们命名：
code复制system-view
sysname USG-FW
部分版本需要先开启虚拟系统功能（根据版本决定是否需要）：
code复制vsys enable
创建两个虚拟系统：
code复制vsys name vsys_a
执行后进入的是vsys_a的配置视图。这个阶段可以先把它需要的接口分配给它。分配接口的命令是assign interface：
code复制assign interface GigabitEthernet0/0/1
同样完成vsys_b的创建和接口分配：
code复制vsys name vsys_b
assign interface GigabitEthernet0/0/2
quit
然后启动已经创建好的虚拟系统：
code复制start vsys name vsys_a
start vsys name vsys_b
quit
启动操作很容易被漏掉。创建虚拟系统但没执行启动命令，虚拟系统会一直处于“已创建但未运行”的状态，数据面根本不会转发任何流量。我遇到过很多次，配置全部敲完，PC之间却ping不通，最后发现是忘记执行start vsys了。
如果要删除实验配置重来，可以用：
code复制undo vsys name vsys_a
不过要注意，删除虚拟系统之前，需要先把该虚拟系统停止，并解除它所占用接口的分配关系。否则系统会提示删除失败。
3.3 虚拟系统内部的三件事：接口地址、安全区域、安全策略
虚拟系统启动完成后，后续配置就需要“进入”虚拟系统内部完成。切换命令是：
code复制switch vsys vsys_a
进入后命令行提示符会变成类似[USG-vsys_a]的样式。此时你面对的就是一台独立防火墙，接下来要做的和你配置普通防火墙完全一样：给接口配IP、把接口加入安全区域、写域间安全策略。
首先给VSYS_A的内部接口配置地址：
code复制interface GigabitEthernet0/0/1
ip address 192.168.10.1 255.255.255.0
quit
然后把接口加入安全区域。我习惯把接PC的接口划入trust区域，把和根系统或外部互访的接口划入untrust区域，方便演示策略：
code复制firewall zone trust
add interface GigabitEthernet0/0/1
quit
接着写安全策略。为了让PC1访问PC2或其他外部任意地址时能成功，需要在VSYS_A内部配置一条trust到untrust的转发策略：
code复制security-policy
rule name trust_to_untrust
source-zone trust
destination-zone untrust
source-address 192.168.10.0 24
action permit
quit
在VSYS_B里做一套对等的操作：
code复制switch vsys vsys_b
interface GigabitEthernet0/0/2
ip address 192.168.20.1 255.255.255.0
quit
firewall zone trust
add interface GigabitEthernet0/0/2
quit
security-policy
rule name trust_to_untrust
source-zone trust
destination-zone untrust
source-address 192.168.20.0 24
action permit
quit
3.4 如果虚拟系统之间需要互访
实际场景中，多个虚拟系统很多时候不是完全隔离的，而是有条件的互访。比如VSYS_A里的用户需要访问VSYS_B里的某台服务器，这时就需要在虚拟系统之间建立路由。
这里有一个容易被绕晕的地方：虚拟系统之间的流量，通常需要经过根系统“中转”。物理防火墙从VSYS_A的接口收到流量，识别是发往另一个虚拟系统的数据，就会把流量交到根系统做路由判断，再由根系统引导到VSYS_B的接口。因此在配置互访时，不光要在两个虚拟系统内写合理的安全策略，还要注意根系统的路由表是否可达。
模拟器环境测试虚拟系统互访，最省事的方法是给两台终端各自配静态路由去指向所属虚拟系统的网关接口IP，然后在需要互访的虚拟系统里放行对应的域间策略。如果采用更复杂的多区域拓扑，把所有互访路径全部建立起来，其实还要考虑根系统是否配置了相应的安全策略和路由，这对刚接触VSYS的人来说确实要费一番功夫。
4. 验证环节不能只测“通不通”，要测“隔离不隔离”
配置完成不等于实验成功。虚拟系统实验最有价值的部分，恰恰是验证环节——你不光要证明“能通”，更要证明“不该通的一定不通”。
建议按这个顺序做验证：
4.1 先验证同一虚拟系统内不同终端能通
VSYS_A里如果挂了多台PC，先让它们互相ping。这个步骤能确认VSYS_A内部转发正常，接口、区域、策略已经没有问题。
4.2 再验证虚拟系统间默认不通
从PC1发起ping到PC2的地址192.168.20.10，预期结果应该是请求超时。原因是VSYS_A和VSYS_B是两个独立防火墙实例，即使物理上在同一台设备上，路径和策略表也都是分离的。只要没有显式配置虚拟系统间互访，默认情况下数据不会穿越过去。
哪怕真的在网络层存在路由能来回，只要安全策略没有放行，流量依然会被阻断。这也是虚拟系统隔离性和纯路由协议隔离的根本差异：路由可达不代表业务可达，安全策略才是最终裁决者。
4.3 查看虚拟系统独立会话表
验证隔离性时，查看会话表是最直观的手段。先登录VSYS_A，执行：
code复制display firewall session table
然后从PC1发起访问流量。如果VSYS_A内能看到会话记录，而VSYS_B内看不到任何相关会话，说明虚拟系统之间的会话是独立维护的。这一步比单纯的ping结果更有说服力——它证明了数据面隔离真实生效了。
4.4 尝试在虚拟系统内管理自己的配置
从根系统切换进VSYS_A，随便增加或修改一条策略，再切换到VSYS_B，执行：
code复制display current-configuration
你会看到VSYS_B的配置里完全没有VSYS_A的影子。这是虚拟系统的管理隔离特性：配置视图分离，管理员只要通过switch vsys切换，就只能看到当前所在虚拟系统的配置。对多租户业务来说，这个特性意味着不同业务团队可以自行管理自己的防火墙规则，不必担心误操作其他区域的策略。
4.5 验证安全策略的默认拒绝
在VSYS_A里如果我把那条trust_to_untrust规则临时失配或删除，再去PC1上访问外部地址，应该不通。这个验证能帮助理解华为防火墙策略匹配机制：策略列表按顺序从上到下匹配，一旦所有规则都不匹配，最终被deny。所以实验里要养成一个习惯：测试前先确认策略规则是否存在，如果通信意外通了，先查有没有全放通的宽松规则；如果不通，先查策略有没有写到对应方向。
我在做这个验证时发现一个常见错误：习惯性把根系统的安全策略和虚拟系统里的安全策略混在一起看。因为虚拟系统里的策略需要进入switch vsys后才能查看，如果你留在根系统里执行display security-policy，看不到的是虚拟系统里的策略配置。这不是设备出问题了，而是你根本切错了管理视图。
5. 实验过程中的高频故障与排查思路，一条条对号入座
5.1 创建虚拟系统时提示资源不足，怎么办
如果实验里创建第二个或第三个虚拟系统时，系统提示资源不足，说明设备分配给虚拟系统的默认资源配额已经用完。登录根系统，用资源分配命令手动调大各个虚拟系统的上限。
USG系列防火墙的资源分配通常涉及这几个维度：会话数、策略数、用户数、CPU权重。模拟器里资源总数相对宽松，但真机上不能随便乱调，要给所有虚拟系统保留合理的冗余，尤其是设备自身需要预留资源管理SSH、SNMP、日志等进程，若把资源全部切给虚拟系统，设备管理都可能变得不稳定。
5.2 虚拟系统里策略已经放行，但还是不通
遇到“配置了策略仍然不通”的问题，可以不要上来就怀疑安全策略，按这个顺序排查：
- 先检查物理接口是否已经成功划入虚拟系统。如果接口状态仍然在根系统下，虚拟系统里的接口IP配置可能无法生效。
- 再确认虚拟系统是否已经启动。执行
display vsys查看虚拟系统运行状态。如果状态不是running，后面所有操作都没有意义。 - 检查终端PC的网关地址是否指向虚拟系统的接口IP，PC和防火墙之间链路是否up。
- 在虚拟系统里执行
display ip routing-table确认出接口路由是否正确。 - 再执行
display security-policy检查策略命中和命中次数。
这里特别补充一句：策略命中次数是排错利器。发一次测试流量后，回来看规则命中次数是否增加，就能判断流量到底有没有走到这条规则。如果命中次数没变化，说明流量根本没走到这条策略，问题多半在路由或接口归属上。
5.3 eNSP里防火墙设备起不来或者WEB页面打不开
这个话题几乎出现在每一个华为防火墙实验的评论区。我自己在eNSP里遇到的场景，很大程度是两件事：一是安装目录路径不能有中文，二是模拟器版本和镜像版本不匹配。USG6000V设备启动失败时，先看CPU和内存占用是不是已经被其他设备占满了；用eNSP跑实验时同时开太多AR路由器和交换机，防火墙镜像加载会非常吃力，启动速度极慢甚至直接启动失败。
WEB管理页面打不开则要先回到CLI确认：
- 管理接口有没有配置IP，是否up。
- 是否已执行
web-manager enable。 - 管理接口是否配置了
service-manage https permit。 - 终端的IP和防火墙管理IP是否在同一个广播域，能否ping通管理地址。
- 实在不行，在PC上用命令测试防火墙管理IP的443端口是否开放。
5.4 修改了区域归属导致虚拟系统业务中断
实验中途如果我临时把一个接口从trust区域移到了untrust区域，业务会立刻中断。因为安全策略匹配是依赖源区域和目的区域的。区域一变，原本“trust到untrust”的策略可能不再匹配“untrust到untrust”的流量。这类问题排查思路非常简单：每次调整区域后，重新审视域间策略是不是覆盖了新的转发路径。很多莫名其妙的“断网”都是这样造成的。
6. 顺着实验再往前走一步：从虚拟系统到实际网络设计
虚拟系统实验做成什么样才算真正吃透了？我给自己定的标准是：不仅能照着命令敲一遍，还能脱离文档独立完成一个合理的资源规划和故障排查。做到这一步，你会发现虚拟系统的设计思路非常接近云安全资源池和SASE的底层逻辑——都是把一套物理资源按业务需求切成可独立运维的逻辑单元。不同之处只是规模：VSYS是在防火墙内部做切片，云安全资源池是用控制器编排多个虚拟化安全组件。
做个资源规划上的建议。如果有一天真机环境要用虚拟系统，不要把接口资源平均分配给每个虚拟系统。比如一台防火墙有6个业务口，根系统至少保留1到2个接口做管理运维；两个虚拟系统可以根据流量重要程度分配3:1的接口数量，而不是机械地2:2:2。会话资源和策略配额也要按实际业务预估，不能拍脑袋。我给客户做规划踩过这样的坑：一个虚拟系统负责人为了保险，给自己申请了设备90%的会话资源，导致另一个虚拟系统上线后频繁丢会话，最后靠动态调整配额才恢复。为了避免这个坑，建议建立一张资源分配表，把每个虚拟系统使用的接口、网段、会话峰值、策略条数列清楚，这样不仅方便你实验演示，后期做真机割接也会从容很多。
实验做完了，可以顺手把虚拟系统内部的配置导出备份，以及把根系统的全局配置也做一次导出。两种配置建议分开管理、分开归档。虚拟系统的配置是逻辑业务的一个切面，根系统配置是整套设备的地基。以后如果设备需要重启或者更换硬件，这个备份习惯能让你快速恢复整个虚拟系统架构，不至于临时抓瞎。
这个实验做到这里基本到了一个比较完整的收尾状态。我个人操作中的体会是：虚拟系统实验最大的门槛不是那些命令行，而是切换思维——你要时刻清楚自己当前在哪个管理视图里，当前操作会影响哪个虚拟系统的转发行为。搞懂了这一层，后面无论换成USG6000V还是CloudEngine安全业务板，操作逻辑都是相通的。