简介面向网络管理员与安全运维人员的华为防火墙综合配置案例集覆盖USG6000、USG9500、Eudemon等V500R005C00及V600R006C00系列内容为典型项目场景下的应用与配置方法适合具备以太网基础、希望系统掌握FW部署的中级读者对照实践。资源包共1个PDF约4.88MB体积轻便便于随行查阅和全文检索。已有556人学习下载说明其在同类资料中具备一定参考认可度。文档按“前言—场景案例—配置说明”组织正文含产品版本对应表、读者对象与内容约定并具体提示加密算法选型建议如优选AES、RSA 2048位以上、SHA2/HMAC-SHA2以及AV、IPS、URL过滤、审计、五元组抓包等特性的隐私与合规注意事项同时给出Telnet/STelnet、FTP/SFTP、SNMPv1/2c/v3的安全使用指引可作为项目配置与安全加固的对照范本。1. 出口防火墙上线前的三个必答题链路、策略边界与不断网有个做网管的读者丢过来一份自己攒的防火墙配置案例设备是新的链路是通的接口地址也 ping 得通可内网用户就是上不了网。翻到最后发现安全策略写的是 trust 到 untrust 放通但接口没划进安全区域默认区域里留着两个物理口策略一条都不命中。这类问题在出口安全方案的落地阶段反复出现问题通常出在配置顺序和模块边界没理清而不在命令记不住。一份能直接拿去改的综合配置案例通常要回答三件事出口有几条链路、内网按什么维度做策略控制、故障时靠什么保证不断网。这三件事分别落到路由与智能选路、安全策略与用户识别、双机热备与 NAT 上。下面按这个顺序拆从校园、广电、金融数据中心三类典型出口一路走到命令级实现和验收动作。2. 三类出口场景的方案选型校园、广电与金融数据中心的差异设计出口防火墙的配置没有一套通用模板可以套差别来自三处出口链路是一条还是多条、内网用户是固定工位还是流动性极强的无线接入、业务对外发布是靠 NAT Server 还是靠反向代理。选型阶段把这三处定下来后面的配置量能差出一倍。我在做方案阶段会先画一张业务规划表把安全区域、接口、网段、用途和默认策略方向逐行写死再进设备敲命令。这张表是后面所有配置的唯一依据改一处就要同步改否则一定出现「策略写了但网段写错」这种低级返工。安全区域接口网段用途默认策略方向trustGE1/0/1192.0.2.0/24教学办公trust→untrust 按应用放通dmzGE1/0/2192.0.2.128/25对外服务untrust→dmz 按端口放通untrustGE1/0/3203.0.113.0/29主用出口默认拒绝untrustGE1/0/4198.51.100.0/29备用出口默认拒绝2.1 校园出口基于 IP 与基于用户的两种策略路线校园出口的典型特征是用户密度高、身份杂、并发会话多而且无线侧地址基本靠 DHCP 动态下发。针对这种场景有两套思路选哪套取决于内网地址规划是否稳定。方案一是基于 IP 地址的策略控制。把教学区、办公区、宿舍区、服务器区切成固定网段安全策略按源网段匹配配合带宽管理做每网段限速。优点是设备不需要对接任何认证系统策略条数可控转发性能几乎不受影响缺点是地址一变动策略就失效无线终端换个位置拿到别的网段权限跟着变运维得靠地址规划纪律撑着。方案二是基于用户的策略控制。设备与认证系统对接用户上线后生成用户表安全策略直接按用户组匹配比如「教师组」允许访问全部应用「访客组」只允许 HTTP 和 DNS。这种方式对无线和移动办公友好人走到哪权限跟到哪代价是要额外维护认证链路认证服务一挂新用户上不了线而且策略匹配多了一层查表高并发下要关注设备规格。我的做法是混合主干用基于 IP 的策略兜底保证认证故障时业务不中断对访客网络和无线办公区叠加基于用户的策略做精细控制。两条路线并存时策略匹配顺序要先用户后 IP把例外写在前面通用规则沉到后面。2.2 广电出口多链路智能选路与 NAT Server 的组合广电类出口的特点是链路多、带宽大、上下行不对称而且往往对外承载一批业务系统需要域名解析和公网发布配合。这种场景下配置重心不在策略精细度而在链路可用性和发布链路的对称性。智能选路要做三件事按带宽比例分担流量、按链路质量做故障切换、按目的地址做分流。常见做法是给每条链路配置探测目标链路质量劣化到阈值以下自动摘除流量回切到健康链路。分流策略一般按运营商地址段或按业务类型走把大流量下载类业务压到便宜链路上把低时延业务钉在质量好的链路上。NAT Server 与智能 DNS 必须成对出现。外网用户通过域名访问内网服务解析到公网地址内网用户访问同一个域名时如果解析结果还是公网地址流量会绕到出口再折回来形成回环轻则时延翻倍重则直接被策略拦掉。解决办法是智能 DNS 让内网用户解析到服务的内网地址或者在出口设备上开启 NAT 回流hairpin让内网访问公网地址的流量在设备内部直接转成访问内网服务器。这部分配置如果做漏了最典型的现象是「外网访问正常、内网访问转圈」排查时先看会话表里这条流的源和目的地址一眼就能看出是不是绕出去了。2.3 金融数据中心三层防火墙的分区职责数据中心场景和前面两类最大的不同是防火墙不止一台而且每台的策略粒度完全不同。按位置一般分三层互联网出口防火墙、数据中心出口防火墙、内网接入区防火墙。互联网出口防火墙面对的是不可信流量策略以「最小放通」为原则只开放明确发布的端口其余一律拒绝并记录日志同时承载入侵防御、反病毒这类安全防护。数据中心出口防火墙位于核心与业务区之间做南北向流量的边界控制策略按业务系统维度组织一个系统一组规则方便按系统上下线。内网接入区防火墙做的是东西向微隔离同一数据中心内不同业务区之间的访问都要经过它策略条数最多、变更最频繁通常要靠地址对象和服务对象把规则收敛否则几个月就膨胀到几千条。三层的配置顺序也有讲究先配最靠近终端的接入区把内网互通打通再配数据中心出口验证业务系统之间的调用最后配互联网出口此时前面两层已经稳定出问题时能快速定位到是不是出口策略的问题。反过来配一旦业务不通三台设备都要查排查成本直接翻倍。3. 配置骨架落地从接口与安全区域到策略命中的先后顺序真正进设备敲命令时顺序比内容更重要。防火墙的配置是有依赖关系的接口不配地址区域挂不上区域挂不上策略写了也不匹配策略不匹配NAT 做了也不生效。我一般按「接口 → 区域 → 路由 → 对象 → 策略 → NAT」这个顺序走每一步做完做一次验证避免错误累积到最后无法定位。3.1 接口与安全区域先把门和房间对上第一步永远是接口地址和安全区域。这段配置看着简单但它是后面所有模块的地基接口名抄错一位后面全盘皆输。# 进入配置视图后先配内网侧接口 interface GigabitEthernet 1/0/1 description to-LAN-teach # 描述写清楚对端排障时省一半时间 ip address 192.0.2.1 255.255.255.0 service-manage ping permit # 只对管理面放通 ping业务面仍走策略 quit # 再配外网侧接口 interface GigabitEthernet 1/0/3 description to-ISP1-primary ip address 203.0.113.2 255.255.255.248 quit # 把接口挂进对应安全区域 firewall zone trust add interface GigabitEthernet 1/0/1 quit firewall zone untrust add interface GigabitEthernet 1/0/3 quit这段配置里有两个参数值得说明。description不是可选项出口设备往往有六到八个口没有描述半年后没人分得清哪个口对哪条链路。service-manage ping permit控制的是设备自身管理面的可达性和业务流量放通是两回事很多人以为配了这条内网就能上网实际上业务流量仍然要走安全策略。配置完立刻验证查一次区域成员列表确认每个物理口都有归属默认区域里应该是空的。这一步花三十秒能省掉后面两小时的排查。3.2 路由与策略的先后关系为什么先通再控路由必须在策略之前配好原因是防火墙的策略匹配依赖到达报文的路由可达性。路由缺失时即使策略放通报文也会因为查不到出接口被丢弃而设备日志里未必有明确提示很容易误判成策略问题。# 主用默认路由优先级采用默认值 ip route-static 0.0.0.0 0.0.0.0 203.0.113.1 # 备用默认路由优先级数值更大主链路失效后自动生效 ip route-static 0.0.0.0 0.0.0.0 198.51.100.1 preference 70 # 回程路由服务器区网段指向内网核心 ip route-static 192.0.2.128 255.255.255.128 192.0.2.254静态路由的preference是主备切换的关键参数数值越小优先级越高主用链路用默认值备用链路抬高到 70 左右主链路一旦不可达备用路由自动进入转发表。这里有个容易忽略的点如果主备两条链路对接的是同一台对端设备路由切换后回程流量可能还走原路径形成非对称路由防火墙默认会丢弃这类报文。要么在主备链路上都放通要么开启会话的正反向检查豁免。配完路由先用display ip routing-table确认两条默认路由都在再用tracert从内网侧测一下出口地址确认三层可达。这一步通了策略才有意义。3.3 安全策略的五元组写法与匹配顺序安全策略是整份配置里最需要克制的地方。默认策略是拒绝所以每一条 permit 都是在开口子口子开得越少越好而且必须带日志。security-policy rule name teach-to-internet source-zone trust destination-zone untrust source-address 192.0.2.0 24 application http https dns action permit session-timeout 1800 # 办公场景会话老化时间平衡并发数和及时性 log rule name dmz-publish-web source-zone untrust destination-zone dmz destination-address 192.0.2.130 32 service tcp 80 8080 action permit log rule name default-deny source-zone any destination-zone any action deny log这段策略有三个设计点。第一规则从上往下匹配命中第一条即停止所以具体的规则必须写在宽泛规则前面teach-to-internet这种带应用限定的规则要放在最上面兜底的拒绝规则永远在最后。第二application比service更精确前者按应用层协议识别后者只看端口用应用匹配可以避免业务跑到非标准端口时误判。第三每条 permit 都要带log出口设备的价值一半在放通一半在留痕没有日志的策略等于黑匣子。策略配完不是结束要验证命中情况。用display security-policy rule all看每条规则的命中计数业务跑起来之后计数不涨说明流量根本没走到这条规则上先回头查区域和路由别急着改策略。4. NAT 与双机热备实现两个最容易返工的模块怎么落命令出口防火墙上返工率最高的两个模块一个是 NAT一个是双机热备。前者的问题往往出在「配了但不生效」或者「生效了但回程丢了」后者的问题集中在「主备状态起来了但会话没同步」。这两个模块的共同点是依赖前置配置的正确性前面区域和路由有偏差这里一定出问题。4.1 源 NAT 与 NAT Server别让回程流量掉在门外源 NAT 解决内网访问外网的地址转换NAT Server 解决外网访问内网服务的端口映射。两者方向相反配置上必须分开写安全策略也要分别放通。nat-policy rule name snat-internet source-zone trust destination-zone untrust source-address 192.0.2.0 24 action source-nat easy-ip # 地址池复用出接口地址适合内网用户上网 nat server web-publish protocol tcp global 203.0.113.5 80 inside 192.0.2.130 8080 nat server mail-publish protocol tcp global 203.0.113.5 25 inside 192.0.2.131 25easy-ip是多对一的地址复用所有内网用户共用一个公网地址出网靠端口区分会话适合用户量大但公网地址紧张的场景。如果业务需要对端看到真实源 IP或者有大量长连接就要改成 no-pat 方式一对一或一对多绑定公网地址。这个选择在方案阶段就要定上线后再改会涉及会话中断。NAT Server 最容易翻车的地方是安全策略只放了一个方向。外网访问进来是 untrust 到 dmz放通了服务器回包走 dmz 到 untrust如果默认拒绝且没有对应规则回包被丢现象就是「连接建立不起来或者连上就断」。稳妥的写法是给 dmz 到 untrust 单独加一条只允许已建立会话回程的规则利用状态检测机制不要图省事把 dmz 到 untrust 全放通。还有一个隐蔽问题NAT Server 的端口映射如果和外网侧接口的地址冲突或者映射的公网地址不在接口同网段需要额外配 ARP 应答。这类问题表现为「内网能访问、外网访问不通」抓包能看到 SYN 到了设备但没回检查映射地址和 ARP 表基本能定位。4.2 双机热备主备还是负载分担双机热备的选型分两种主备模式一台转发一台待命切换时会话中断但状态清晰负载分担模式两台同时转发利用率高但故障时流量要重新分布且要求两台设备的状态同步非常可靠。主备模式适合出口链路少、对状态一致性要求高的场景配置上通过 VRRP 提供虚拟网关地址主机优先级高备机监听。负载分担模式适合带宽压力大的出口两台设备各自承载一部分会话通过 VRRP 分组实现互为备份。# 心跳接口单独划一个区域不要和业务口混用 interface GigabitEthernet 1/0/0 description heartbeat-direct ip address 10.10.10.1 255.255.255.252 quit # 开启热备绑定心跳口同步会话与配置 hot-standby enable hot-standby interface GigabitEthernet 1/0/0 hot-standby sync connection hot-standby sync config # VRRP 提供虚拟网关主设备优先级更高 vrrp vrid 1 virtual-ip 203.0.113.1 active vrrp vrid 1 priority 120不同厂商的命令字面差异很大但模块顺序是一致的先有心跳口再有热备开关再有会话与配置同步最后才是 VRRP 的虚拟地址和优先级。心跳口必须独占不能和业务接口共用也不能让心跳流量走业务链路否则业务一拥塞心跳超时两台设备同时认为对方挂了出现双主这是最严重的一类故障。验证热备状态要看三样东西两台设备的热备角色是否一主一备、会话表同步条数是否接近、VRRP 状态是否稳定。切换测试建议在业务低峰做一次手动主备倒换观察会话是否重建、业务中断时长是否在可接受范围内。4.3 用户溯源让日志里的 IP 对上人出口设备做完 NAT 之后所有内网用户在日志里都是同一个公网地址出了安全事件根本对不上人。用户溯源要解决的就是这条链路从公网地址和端口反查到内网地址再反查到具体用户。# 开启会话与 NAT 日志送到审计服务器 session logging enable nat logging enable info-center loghost 198.51.100.200 # 时间必须同步否则日志时间戳错乱反查直接失效 ntp-service unicast-server 198.51.100.201这条链路有三个环节不能断。第一NAT 日志必须开只开会话日志不够端口映射关系记不下来。第二时间同步必须做设备和日志服务器的时间偏差超过一分钟跨设备关联就不可靠。第三日志服务器容量要预留出口设备的日志量按每用户每天几百条估算一个千兆出口一天下来是 GB 级别硬盘写满之后日志静默丢失比没开还危险。5. 避坑与排查出口防火墙上最容易翻车的五个点下面这五条都是从实际配置里踩出来的现象看起来五花八门根因往往就一句话。排查顺序建议统一成「先看状态、再看表项、最后看策略」从设备自身的运行状态往下查比一上来就怀疑策略高效得多。5.1 双机热备建立不起来现象两台设备的热备状态都显示为独立运行或者一台主一台也是主心跳口指示灯正常但状态始终不同步。原因通常有三个心跳口没有划进独立的安全区域导致心跳报文被默认策略丢弃心跳口地址配在了业务网段里和业务路由冲突两台设备的软件版本或补丁不一致同步协商直接失败。解决方式是先查心跳口的区域归属和接口状态再确认心跳网段没有出现在业务路由表里最后核对两端版本。版本不一致这条最容易被忽略因为设备能正常启动、能正常转发只有热备状态起不来属于典型的隐性不一致。5.2 策略放通了业务还是不通现象安全策略里明明写了一条 permit源地址、目的地址、端口都对可业务就是不通策略命中计数一直是零。原因可能是接口没划区域、路由缺失导致报文根本没到策略匹配这一层也可能是流量走了非对称路径去程经过防火墙、回程从别的设备绕回防火墙的状态检测认为报文非法直接丢弃。解决方式是先在设备上抓包看去程报文进没进来、回程报文出没出去。如果去程有回程没有问题在回程路由如果去程都没有问题在区域或路由。另外检查有没有开严格的反向路径检查多出口场景下这一项经常误杀正常流量。5.3 NAT Server 外网访问时通时不通现象内网访问映射后的服务完全正常外网访问时好时坏有时候刷新几次能通一次有时候一直超时。原因集中在两处一是双机热备环境下 NAT 表项没有实时同步流量被负载到了没有表项的那台设备上二是映射的公网地址和接口地址不在同一网段缺少 ARP 代答外网设备的 ARP 请求得不到响应。解决方式是先确认两台设备的 NAT 会话表是否一致不一致就查同步配置一致的话再查 ARP 表里有没有映射地址的条目没有就补静态 ARP 或者调整映射地址到接口同网段。5.4 日志与用户溯源断链现象安全事件发生后从审计系统里只能查到公网地址反查不到具体的内网用户或者查到的用户和实际不符。原因一般是 NAT 日志没开、时间没同步、日志服务器磁盘写满导致丢日志还有一种情况是会话老化时间设得太短会话表里的记录已经老化掉了日志服务器上却还在等关联。解决方式是逐个环节验证先在设备上确认日志是否真的发出去了再在服务器上确认收到了最后抽查一条会话做端到端反查。时间同步这一项建议直接配成强制同步不允许设备自己走本地时钟。5.5 配置脚本直接粘贴跑不起来现象从文档或者旧设备上导出的配置脚本整段粘到新设备上一条条报错最后配了一半。原因有三个脚本是在系统视图下执行的但当前会话还停在用户视图接口命名规则不同老设备是 GE0/0/1新设备是 GE1/0/1脚本里包含大量undo语句执行顺序错了会互相覆盖。解决方式是分段执行按「接口 → 区域 → 路由 → 对象 → 策略 → NAT」拆成六段每段执行完用display current-configuration对比差异确认无误再进下一段。图省事整段粘贴最后往往要花更多时间回滚这个后悔药不好吃。6. 验收与答辩用三张表把配置案例讲成可复现的方案配置做完不等于方案交付验收环节才是把「我配通了」变成「这套方案可复现」的地方。我一般用三张表来验逻辑简单但覆盖了出口防火墙八成以上的故障面。第一张是路由表。查默认路由是否主备齐全、回程路由是否覆盖所有内网网段、有没有意外的明细路由抢占转发。第二张是会话表。抽样几条业务流看去程和回程是否都经过本机、NAT 转换是否按预期发生、会话老化时间是否符合业务特征。第三张是策略命中表。每条 permit 规则的命中计数都应该在涨长期为零的规则要么是冗余的要么是配置有偏差。验收项判定方法合格标准区域归属查区域成员列表默认区域为空所有物理口有归属路由完整性查路由表默认路由主备齐全回程路由覆盖内网网段策略收敛查策略规则列表没有 any 到 any 的 permit每条 permit 带日志NAT 覆盖查 NAT 策略所有内网网段都有对应源 NAT 规则双机状态查热备状态一主一备会话同步条数差异在 5% 以内溯源可用抽一个公网地址反查五分钟内能定位到内网地址和用户答辩时最容易被问到的不是命令细节而是「为什么这么设计」。比如为什么选主备不选负载分担、为什么这条策略放通的是应用而不是端口、为什么心跳口要单独划区域。这些问题的答案都在方案阶段的那张业务规划表里把表讲清楚配置自然就讲清楚了。有个习惯我保持了几年每次交付前强制走一遍「断开主链路、手动倒换、模拟心跳中断」这三个破坏性测试测完再恢复。血泪经验是配置看起来完全正确的双机热备有相当一部分是经不起真实断链的。希望这套结构能帮到你把手上那份配置案例从「能跑」做成「能交」。本文还有配套的精品资源点击获取