尧图网页设计 
简介华为官方出品的防火墙综合配置案例文档收录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初始密码是 Admin123V5 之后的版本首次登录会强制要求修改密码。要注意的是修改后密码如果忘记恢复流程比较痛苦——这也是我在第 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 静态路由和默认路由的配置模板下面是我常用的一段出口静态路由配置场景是防火墙接运营商固定公网 IPip 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确认默认路由和明细路由都存在于路由表。如果默认路由一直在路由表里但流量不通检查一下接口是否 updisplay interface GigabitEthernet1/0/1能直接看到物理状态和协议状态。3.3 接口联动和探测链路断了路由却还活着这是现网里最常见的“静默故障”运营商的光线断了防火墙的上联物理接口因为接的是运营商交换机所以仍然 up默认路由也还在路由表里但数据实际已经出不去。用户反馈“网断了”你查设备看路由表一切正常这就是只配静态路由、没配链路探测的典型症状。华为 USG 的解法是配置链路探测NQANetwork 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 上网流量源 NATeasy-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 防火墙才能真正从“能通”变为“好用”。希望这篇整理能帮你在下一个项目里少踩几个坑。本文还有配套的精品资源点击获取 华为防火墙综合配置实战：从开局、路由策略到NAT排障全流程
简介华为官方出品的防火墙综合配置案例文档收录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初始密码是 Admin123V5 之后的版本首次登录会强制要求修改密码。要注意的是修改后密码如果忘记恢复流程比较痛苦——这也是我在第 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 静态路由和默认路由的配置模板下面是我常用的一段出口静态路由配置场景是防火墙接运营商固定公网 IPip 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确认默认路由和明细路由都存在于路由表。如果默认路由一直在路由表里但流量不通检查一下接口是否 updisplay interface GigabitEthernet1/0/1能直接看到物理状态和协议状态。3.3 接口联动和探测链路断了路由却还活着这是现网里最常见的“静默故障”运营商的光线断了防火墙的上联物理接口因为接的是运营商交换机所以仍然 up默认路由也还在路由表里但数据实际已经出不去。用户反馈“网断了”你查设备看路由表一切正常这就是只配静态路由、没配链路探测的典型症状。华为 USG 的解法是配置链路探测NQANetwork 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 上网流量源 NATeasy-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 防火墙才能真正从“能通”变为“好用”。希望这篇整理能帮你在下一个项目里少踩几个坑。本文还有配套的精品资源点击获取