简介：华为官方出品的防火墙综合配置案例文档，收录USG6000V、USG9500、Eudemon系列等产品对应的典型项目配置方法，适用于负责配置和管理防火墙设备的网络管理员，也适合需在真实项目中落地防火墙配置的工程师参考。文档首先梳理产品版本与软件版本的对应关系，明确不同型号的适用场景，随后以典型项目为背景，系统讲解防火墙在组网中的综合配置思路，并详细说明安全算法选型、个人数据保护、特性使用声明、符号约定与内容约定等关键事项，可帮助读者规避部署过程中的常见风险，提升配置方案的安全性与规范性。资源为1个PDF文件，大小4.88MB，内容为官方技术文档原版，排版清晰，结构分明，便于按章节查阅和对照实施。目前已有556人学习，适合作为独立学习或项目交付前的快速参考资料。
1. HUAWEI 防火墙综合配置案例：从开局到上线的完整闭环
一台刚拆箱的 HUAWEI USG 防火墙，很多人习惯先登 Web 把内网口 IP 配上，再照着手册点几条安全策略，感觉“通了”就交付了。可真到现网跑业务时才发现，DNS 解析走不通、内网用户上不了网、服务器映射出去外面访问不了，甚至两台防火墙主备切换后回程路由全乱套。所谓“综合配置案例”，本质上不是某一条命令的演示，而是把接口、安全区域、路由、安全策略、NAT、管理通道、日志审计这七件事按正确顺序串起来，形成一套从开局到上线再到排障的闭环。这篇笔记就是按我平时给客户做交付的顺序来讲：先立框架，再给可复制的命令，最后把那些不撞一次很难长记性的坑列出来。
适合的读者有两类。一类是刚接触华为防火墙、准备从零把设备推上线的网络工程师，照着章节走就能搭出一台能跑业务的出口设备；另一类是已经会配基本策略、但总在 NAT 和策略放通上反复翻车的运维，可以直接跳进第 4 章和第 5 章对照排查。文章里所有命令都基于 USG6000 系列 V5 版本的 CLI 风格，Web 界面路径也同一套逻辑，版本差异我会在用到的地方单独说明。
2. 开局与资源准备：先规划区域和接口，再想策略怎么写
2.1 为什么综合配置的第一个动作不是加策略，而是画一张“区域地图”
防火墙区别于交换机路由器的核心，是它天生就带着“信任/不信任”的偏见过日子。HUAWEI USG 默认划分了 trust、untrust、dmz 三个安全区域，如果设备上有多个 VFP（虚拟防火墙）接口，还会有 local 区域参与流量交互。很多新手拿到设备就急着加策略放通流量，结果发现接口也加入了区域、策略也写了 permit，流量还是不通，问题往往出在“区域归属”和“区域间默认动作”没对齐。
USG 的域间过滤默认动作是拒绝，而且不同区域之间默认没有互相访问的通道。比如办公网在 trust、公网在 untrust，你需要显式地写一条从 trust 到 untrust 的策略，流量才会被放行。这个“默认全拒”的机制是防火墙安全的底线，也是配置时最容易被忽略的先决条件。
我一般拿到设备会先画一张表：哪些接口放置哪些网段、属于哪个区域、里面承载的是办公终端还是服务器、哪些区域之间需要互访。这张表不需要多漂亮，但必须明确三个问题：内网用户是否能访问服务器区、服务器是否能访问外网更新补丁、外网用户是否能通过映射访问服务器的特定端口。问题想问清楚之后，才轮到设备上敲命令，否则策略写一百条也是乱的。
2.2 Console 口初始化和 Web 登录配置
设备上电后第一件事是用 Console 线进 CLI。USG6000 默认的管理员账号是 admin，初始密码是 Admin@123，V5 之后的版本首次登录会强制要求修改密码。要注意的是，修改后密码如果忘记，恢复流程比较痛苦——这也是我在第 5 章要专门讲的一个坑。
基础开局一般会做这几步：改设备名称、设置时区、开 Web 管理服务。下面是一段最小开局配置：
system-view sysname FW-01 clock timezone BJ add 08:00:00 interface GigabitEthernet1/0/0 ip address 192.168.1.1 24 service-manage ping permit service-manage https permit quit firewall zone trust add interface GigabitEthernet1/0/0 quit web-manager enable这段配置的逻辑是先统一设备身份和时间，再给管理网口配上地址并放行管理流量，最后把这个接口划到 trust 区域并开启 Web 服务。service-manage ping permit和service-manage https permit是给管理面放行对应的协议，只影响防火墙自身收到的流量，不影响转发面流量。
需要注意，web-manager enable在部分 V6 版本上默认开启，但老版本可能没有这条命令或者默认关闭。我的习惯是无论要不要 Web 管理，都会显式执行一次，至少在排障时可以多一个入口。
Web 登录本身不复杂，浏览器输入接口 IP 即可，但因为浏览器安全策略、证书过期或管理口不在同一网段，经常有人在这里卡住。如果用 eNSP 做实验来练习，模拟器里的 USG 默认 Web 管理服务和上述命令是兼容的，能直接在模拟器上练熟 Web 登录的流程，对刚入门的人来说是一个零成本环境。
2.3 管理通道的边界：不要让管理服务暴露到 untrust
上面那段配置把https permit加在了 trust 区域的接口上，意味着只有 trust 区域的用户能打开防火墙管理页面。可有人为了图省事，会在 untrust 接口上也加上service-manage https permit，相当于把防火墙管理界面直接暴露给公网，这不是配置技巧，是给自己留后门。
USG 的安全模型里，管理面归 local 区域管，接口上的service-manage就是控制哪些区域的主机能访问 local 区域的服务。真正需要远程管理时，更安全的做法是：用一个指定源地址的 ACL 配合service-manage来限制，或者配置带外管理地址（比如独立的管理网口），而不是直接把管理服务全放给 untrust。
2.4 接口地址与区域归属的常见误配
接口加错区域是新手期最高频的翻车点。比如把内网接口误加到 dmz 区域，策略全写在 trust 和 untrust 之间，内网用户自然无法访问公网；或者接口先加了区域、后来又删了 IP 地址，区域关系还在但接口状态异常，抓包又看不到流量，就是找不到原因。
其实有一个很实用的自查思路：先用display zone查看区域和接口的对应关系，再用display ip interface brief确认接口 IP 和物理状态，把两张表对照看，绝大多数区域归属问题都能在 30 秒内定位。走得多了你会发现，综合配置案例的大部分故障不是策略写错，而是基础信息不一致。
3. 从内网到外网的路由打通：静态路由与接口联动
3.1 网关角色下，防火墙只需要一条默认路由吗
防火墙在综合组网里最常见的角色是“内网网关 + 出口网关”二合一。内网终端的网关指向防火墙的 trust 接口，防火墙要去公网则需要一条默认路由指向上游运营商设备。但很多人只写了这一条默认路由就完事，结果内网互访没问题、上外网时好时坏，原因往往是出在“回程路由缺失”或“明细路由被默认路由吞掉了”。
防火墙作为三层设备转发流量时，会同时检查正向和反向的路由表。如果内网用户访问公网服务器，防火墙把报文从 untrust 口丢出去了，但公网服务器回包到达防火墙时，防火墙需要知道这个回包应该走哪个接口回给内网用户——这时靠的正是 trust 区域内网的直连路由。直连路由会自动生成，一般没问题；但如果内网网段不在 trust 口直连、而是经过了下游三层交换机，就必须在防火墙上写去往这些网段的静态路由。
3.2 静态路由和默认路由的配置模板
下面是我常用的一段出口静态路由配置，场景是防火墙接运营商固定公网 IP：
ip route-static 0.0.0.0 0.0.0.0 100.100.100.1 ip route-static 10.10.0.0 16 192.168.1.254 ip route-static 172.16.0.0 16 192.168.1.254第一条是默认路由，下一跳 100.100.100.1 是对端运营商设备的互联地址。后面两条是去往公司内网里通过汇聚交换机下挂的非直连网段，下一跳 192.168.1.254 是内网汇聚交换机的 VLANIF 地址。
配置完成后建议先做一次display ip routing-table，确认默认路由和明细路由都存在于路由表。如果默认路由一直在路由表里但流量不通，检查一下接口是否 up，display interface GigabitEthernet1/0/1能直接看到物理状态和协议状态。
3.3 接口联动和探测：链路断了路由却还活着
这是现网里最常见的“静默故障”：运营商的光线断了，防火墙的上联物理接口因为接的是运营商交换机所以仍然 up，默认路由也还在路由表里，但数据实际已经出不去。用户反馈“网断了”，你查设备看路由表一切正常，这就是只配静态路由、没配链路探测的典型症状。
华为 USG 的解法是配置链路探测（NQA，Network Quality Analysis）。给默认路由绑一个 NQA 实例，持续探测对端地址，探测失败就自动把默认路由从路由表里拿掉，流量切到备用链路。下面是一段配置示例：
nqa test-instance admin internet-probe test-type icmp destination-address ipv4 223.5.5.5 frequency 10 probe-count 3 quit ip route-static 0.0.0.0 0.0.0.0 100.100.100.1 track nqa admin internet-probe这段配置的意思是：每 10 秒向 223.5.5.5 发一次 ICMP 探测，连续 3 次失败就认为链路故障，关联的默认路由自动失效。等探测恢复后路由会重新激活，整个过程不需要人工参与。
需要注意 NQA 探测的目标地址不要选内网地址，选一个稳定可达的公共 DNS 地址是常见的做法。也不要选运营商互联的网关地址，因为它在某些故障场景下可能仍然可达，起不到真实反映出口链路质量的作用。
3.4 和多厂商设备互通的注意点
在综合配置里，防火墙的对端设备大概率不是你熟悉的华为设备，可能是 H3C 的交换机，也可能是锐捷的出口路由器。我见过很多人配静态路由时写错了掩码格式，把 H3C 风格的32位掩码直接搬过来——HUAWEI 的 VRP 支持32这种写法，但如果你习惯了/32或255.255.255.255的写法，要注意在早期 VRP 版本里掩码可以不写全，默认为 32。为了避免歧义，我一般会显式写清楚掩码，例如ip route-static 10.10.0.0 255.255.0.0 192.168.1.254，这样不管后续交接给谁都少一层误解。
另外，如果对端是静态接入且开启了 ARP 代理，可能出现路由表正常但丢包严重的情况，这时候抓包看 ARP 请求是否得到了响应，比在防火墙上反复查策略有效得多。
4. 安全策略与 NAT 的配合：黑白名单思维与双向转换
4.1 安全策略的匹配逻辑，理解了才配得对
USG 的安全策略按顺序匹配，从上到下逐条执行，命中即停止。这跟 ACL 的逻辑基本一致，只是安全策略多了一层“区域对”的概念：每条策略都要指定源区域、目的区域、源地址、目的地址、服务，五元组缺一不可。
很多人“策略加了还是不通”的根源，是心里只有 IP 和端口，忘了区域。你写了一条 source-zone untrust 到 destination-zone trust 的策略，但实际流量是从 untrust 要到 dmz，策略自然不会被命中。所以我的建议是：每写一条策略，先自问“流量从哪个区域来、要往哪个区域去”，区域关系清楚之后，再谈地址和端口。
黑白名单的思路在策略设计上很有用。白名单模型是“默认全拒，只放明确需要的流量”，适合企业内网出口，安全性高但前期梳理工作量大；黑名单模型是“默认放通，只封已知风险”，配置简单但安全边界模糊。USG 的策略默认就是白名单模型，所以每条放通策略都要有业务依据，凡是说不清楚用途的策略都属于可疑策略，上线前应该清掉。
4.2 上网流量：源 NAT（easy-ip）最小配置
内网用户访问公网必须做源 NAT，把私有地址转换成公网接口地址。USG 里最省事的写法是 easy-ip，直接把出接口的公网地址作为转换后的源地址。假设公网口是 GigabitEthernet1/0/1，配置如下：
firewall zone untrust add interface GigabitEthernet1/0/1 quit nat policy rule name snat-internet source-zone trust destination-zone untrust action source-nat easy-ip quit这段配置的意思是：凡是 trust 区域访问 untrust 区域的流量，都执行源 NAT，把源地址转换为出接口的公网地址。这里只写了源区域和目的区域，没有写地址簿，意味着 trust 里所有网段都能上网——如果你只想让特定网段上网，需要加上source-address参数限定地址范围。
nat policy 的顺序也很重要。USG 的 nat policy 同样是从上到下匹配，命中的第一条规则生效。如果后面还要加公网服务器映射之类的 NAT 规则，一定要把限制更严格的规则放前面，否则会出现“内网用户访问自己映射出去的服务器”这种回流路径问题。
4.3 服务器发布：NAT Server 与回程路径
外网用户访问内网服务器，用的是目的 NAT，在 USG 里直接用 nat server 表达。假设内网有一台 Web 服务器 10.10.0.10:80，公网接口是 100.100.100.2，需要映射到公网的 8080 端口：
nat server name web-server protocol tcp global 100.100.100.2 8080 inside 10.10.0.10 80这条命令把公网地址 100.100.100.2 的 8080 端口映射到内网 10.10.0.10 的 80 端口。配置完成后外网用户访问 http://100.100.100.2:8080 就能到达内网 Web 服务。
但这里有个高频翻车点：内网用户通过公网地址访问自己的服务器，经常不通。原因是流量从 trust 到 untrust，源 NAT 和目的 NAT 同时作用，回包路径会变得复杂。通用的解法是加一条允许从 trust 到 dmz 区域的映射后访问策略，并且让内网用户直接访问服务器的内网地址而不是公网映射地址，从源头上绕开 NAT 回流。
如果真的需要内网用户也能通过公网域名访问服务器，就需要配置 NAT 的 hairpin 特性，在 nat policy 里额外写一条匹配源区域和目的区域都是 trust 的规则，将目的地址从公网映射地址转换为内网地址。这部分配置在 V5 上用nat server加区域联动基本能覆盖，但在某些版本里需要调整 nat policy 的优先级，建议先在测试环境里验证回程路径再推到现网。
4.4 安全策略和 NAT 的配置顺序
USG 的处理流程是先查路由、再做安全策略匹配、最后做 NAT 转换。也就是说，安全策略里的“目的地址”应该写 NAT 转换前的地址（即真实的内网服务器地址），而不是公网映射地址。这一点经常有人写反，目的地址填了公网映射地址，流量到了防火墙发现匹配不到策略，直接被丢弃。
所以写策略的推荐顺序是：先把 NAT 规则理清楚，再回过来写安全策略。哪条流量要做源 NAT、哪条流量要做目的 NAT，转换前和转换后地址分别是什么，画一张小表放在手边，写策略时逐个对照，可以省掉大量“莫名不通”的排查时间。
5. 常见配置故障排查：五个现象，五个根因
5.1 现象一：内网能通，外网不通，默认路由和策略都是对的
表现是终端能 ping 通防火墙内网口地址，但 ping 不通公网地址，防火墙上看默认路由存在、安全策略也放行了。根因往往是接口没有加入到正确的安全区域，或者接口物理状态正常但协议状态异常。我用过一个笨但有效的办法：在防火墙上直接 ping 公网地址，能通说明路由和出口没问题，问题大概率在内网侧或策略方向；不通说明出口链路有问题，先查运营商链路和对端互联，再查策略。
常见解决路径：先display ip interface brief确认协议状态，再display ip routing-table确认默认路由，再从防火墙发起 ping 逐段缩小范围。这里想提醒一句：内网能 ping 通网关只是链路一层通，不代表三层转发没问题，别过早下结论。
5.2 现象二：Web 登录页面打不开，但 ping 管理地址是通的
很多人在设备上配了接口地址、加了区域，内存中管理服务是默认开的，但 Web 页面就是出不来。根因通常是接口上没有执行service-manage https permit，或者浏览器安全级别太高直接拦截。这个问题的隐蔽点在于，ping能通是因为防火墙上默认允许 ping 的管理流量，和 HTTPS 管理流量是两套开关。
解决方式是回到接口视图下补上service-manage https permit，同时确认全局视图下web-manager enable已开启。如果还是打不开，换一个浏览器并清缓存试试，证书导致的访问失败在 Chrome 上比 Edge 更明显。
5.3 现象三：策略命中了，流量还是通不了
表现为在安全策略上能看到命中次数一直在涨，但业务就是不通。这时候要怀疑 NAT 了。我遇到过最典型的场景：内网用户访问公网服务器，安全策略放行、源 NAT 也配了，但忘了目的 NAT 的转换方向，导致内网用户访问被映射的公网地址时流量黑洞。
还有一种常见情况是 nat policy 的顺序不对，先匹配了一条更宽松的规则，后面更严格的规则永远不生效。处理方式是查看display nat-policy查看规则顺序，把限制更严格的规则前置，然后重新测试。
5.4 现象四：忘记管理员密码，console 口也进不去
USG 如果忘记管理员密码，是比较麻烦的。部分型号可以通过 BootROM 菜单进行密码恢复，但不同型号、不同版本的恢复流程有差异，而且操作不当可能导致配置被清空。
我的建议是：把管理员密码和设备的序列号一起记在运维台账里，至少两个人知道；任何密码变更都在变更记录里登记。与其等忘了再折腾恢复流程，不如在流程上避免出现这个场景。如果你已经忘了密码，老实查对应型号的密码恢复文档，按步骤操作，操作前先确认是否会清空配置，做好最坏打算。
5.5 现象五：设备关机重启用不了了，配置文件“丢了”
更有意思的是，有人的设备重启后配置全没了，以为硬件坏了，其实是把配置保存到内存里忘了执行save。USG 的配置修改默认只写在内存中，重启即失。敲完配置不要急着收工，执行save并确认配置保存成功，是投入产出比最高的一个动作。
我在交付时有一个习惯：每完成一个阶段（比如开局、路由、策略、NAT），就执行一次save，并在自己的笔记里记录保存时间点。这和代码提交是一个思路，每一阶段都有后悔药可吃，最多回到上一个时间点，而不是从零开始。
6. 配置组织的进阶技巧：从能用到好用
综合配置案例交付后，日常维护最常做的事不是改策略，而是看日志、查会话和做变更。这时配置组织得好不好，直接决定每次维护要花多少时间。
第一个建议是为所有策略和 NAT 规则取名时带上业务含义，例如rule name permit-oa-to-internet和nat server name web-server，少用 rule1、rule2 这类命名。半年后回来看配置时，一个好名字能让你不用查文档就明白这条规则的用途；坏名字只能让你一条条翻 session 日志猜业务。
第二个建议是学会用会话表排障。display firewall session table可以查看当前设备的全部会话，加上verbose参数还能看到会话对应的策略命中和 NAT 转换详情。遇到“策略放通但业务不通”的情况，先看有没有会话，再看会话里的转换后地址是否正确，这个顺序可以帮你快速定位是策略问题还是 NAT 问题。
第三个建议是白名单策略要定期清理。每半年导出一份策略配置，逐条核对还有没有业务在依赖。这是个体力活，但确实能发现不少历史遗留的“全通”策略。安全设备最怕的就是策略越堆越多，最后没人说得清哪条该删，只能靠定期审计来兜底。
最后说一个我自己的习惯：任何变更操作前，先备份当前配置。USG 的display current-configuration可以直接导出文本存档，把存档文件按日期命名放好；变更后如果出问题，用rollback或重新导入配置就能回到变更前状态。别等到深夜割接翻车了才开始找后悔药，后悔药应该提前备好。
综合配置没有一次搞定的魔法命令，它是一套按顺序做对的基础工作流。把区域、路由、策略、NAT 这些模块梳理清楚，再叠加定期维护习惯，一台 HUAWEI 防火墙才能真正从“能通”变为“好用”。希望这篇整理能帮你在下一个项目里少踩几个坑。
本文还有配套的精品资源，点击获取
