企业官网建设流程全解析

去年我帮一家分公司做出口改造，客户提出的需求很典型：双ISP接入，电信和联通两条专线，内网PC按运营商自动分流，电信流量走电信、联通流量走联通，任意一条断了还能自动切到另一条。这台设备选的是华为USG6000E系列防火墙，核心解法就是大家熟知的策略路由，也就是PBR。

这篇就完整复现这次配置过程，把我踩过的坑、调试时看的重点、验证方法全部写出来。内容不只贴命令，还会解释每个配置项为什么要这么写。如果你手头正好有同等场景，完全可以照着抄作业。

1. 双ISP场景分析与方案选型思路

1.1 为什么双ISP会让普通路由方案露怯

很多刚开始接触出口网络的兄弟习惯性认为：两条运营商线路，各写一条默认路由，然后调个优先级不就行了？在只有一条出口的办公网里，静态默认路由确实够用，可一旦涉及双运营商，问题马上冒出来。

最常见的情况是内网既有访问电信网络的业务，也有访问联通网络的业务。如果只按默认路由的优先级走，所有流量都会从优先级高的那条线路出去，另一条线路常年闲置。更要命的是，运营商之间互访存在明显的延迟和丢包问题，电信用户访问联通服务器、联通用户访问电信机房，跨网绕行不仅慢，高峰期丢包能到两位数。客户其实根本不在意你用了什么技术，他们要的就是“访问哪个运营商就走哪个运营商的出口”，这时候普通静态路由就无能为力了，因为它只能看目的地址，看不到也不关心流量到底是谁发起的。

还有一层，就是链路的冗余切换。客户虽然口头说“断了自动切”，但如果只在防火墙上配两条默认静态路由，没有任何探测机制，路由器就只能靠接口物理状态判断线路是否可用。运营商专线断链有时光端机依然通着，只是业务不通，物理链路根本不会down，流量照样往黑洞里扔。所以要解决的不只是分流，还有故障感知和自动切换。

1.2 静态路由+NQA、策略路由、智能选路怎么选

我在现场评估过三种方案，简单做个对比，你看了就能少走弯路。

第一类是静态路由加NQA联动。华为设备上的NQA可以周期性探测指定IP的连通性，探测失败就把路由失效掉，触发备份路由接管。这个方案胜在配置简单，在USG系列上不过十几条命令，适合只有一条主线一条备线的场景。但它的缺点是只能按目的地址选路，做不到内网不同网段走不同运营商。比如财务系统走电信、办公网段走联通，这活儿它干不了。

第二类就是本文重点讲的策略路由PBR。华为的策略路由可以在报文转发前先做一次策略匹配，匹配条件包括源地址、目的地址、服务端口、时间段等，命中之后再指定下一跳或者出接口。双ISP最重要的“按源地址分流”场景，用PBR属于一击必中。再加上它仍然可以配合NQA做探测，实现链路故障自动切换，是当前双出口场景里最通用、最可控的方案。

第三类是华为较新版本里集成的智能选路功能。界面化操作，选路策略也比较智能，能根据链路质量动态分配流量。但实际项目中我发现，很多客户手里设备版本还是几年前的，智能选路能力取决于设备型号和License，并不是所有USG都支持。而且PBR在防火墙上可以通过命令行快速配置，出问题也好排查，比起图形界面的黑盒逻辑更让我放心。

所以最终我选的是PBR加NQA联动。一个负责智能分流，一个负责故障感知，两者配合，既能实现流量自动切换，又能最大程度把转发逻辑握在自己手里。

2. 华为防火墙PBR核心原理拆解

2.1 PBR到底改动了什么转发逻辑

先聊清楚PBR在防火墙里是怎么工作的，后面配命令你才不会一头雾水。

普通路由转发可以说是一条流水线：报文进入防火墙，防火墙查目的IP，匹配路由表，然后按路由表出接口转发。这段流程里，谁发的包、从哪个接口进来的，路由统统不关心，它的世界里只有目标地址。

PBR则是在路由查找前面强行插了一道关卡。报文进来之后，防火墙先做一次策略路由匹配，匹配上了就直接按策略里指定的下一跳或出接口转发，压根不给路由表机会。匹配不上，才掉头回到普通路由表的流程。这里的顺序很关键：PBR的优先级高于普通路由表，所以只要策略匹配条件写对了，分流行为一定能生效。

但这里有个新手容易忽略的细节：PBR策略本身是有匹配顺序的，防火墙从上到下逐条匹配，命中即停止。所以在写多业务分流规则时，顺序必须从特殊到普遍来排列，把最细的规则放前面，最宽的兜底放最后。否则内网用户访问目标IP同时命中了前一条宽泛规则，后面的精细规则就永远没机会执行了。

PBR里头还有一个比较隐蔽的设计，就是“本地路由表”。在传统路由器上，PBR指定下一跳后，设备自身要能递归查到该下一跳的路由。如果你PBR里指定的下一跳地址没有对应路由，策略是生效不了的。华为防火墙在这里引入了一个接口下的本地IP路由表概念，让PBR的下一跳可以独立于全局路由表存在，避免某些场景下路由不连通导致策略失败。这个细节很容易被忽略，等下文配置时我会再强调。

2.2 PBR与NAT、会话表的配合方式

只配PBR而不动NAT，流量大概率还是不通，这里面的坑我当年踩过，必须单独拿出来讲。

防火墙的转发流程里，PBR负责决定“往哪走”，NAT策略负责决定“以什么身份走”。两条电信链路和联通链路分别有独立的公网IP地址，如果内网流量被PBR引到电信出口，但NAT策略只做了电信方向的源地址转换，联通方向的流量匹配不到NAT规则，就会以私网源地址直接往外送，运营商那边直接就给你丢了。

所以在双ISP场景里，PBR和NAT策略必须一一对应。PBR里有一条“电信网段走电信出口”，NAT策略里就必须有一条“电信网段在电信出口做easy-ip”，两条规则的条件要能闭环对上。

还有一个会话表的问题。防火墙是状态化设备，报文进来会建立会话，后续报文直接查会话转发。这意味着PBR只在会话首包建立时生效，如果一条会话已经建立，之后即使你改了PBR策略，已存在的会话也不会被调度到新的路径上，必须等会话老化或者手动清理。我第一次调策略时改了配置后发现流量还在走老链路，折腾了半天才想起看会话表，清掉会话后新流量马上走了新路径。

3. 实战配置：华为USG防火墙双出口完整实现

3.1 需求确认与组网规划

在动设备之前，我习惯先把组网图画在纸上，把关键信息列清楚。这次客户环境如下：

• 设备型号：华为USG6300E，软件版本V600R007C20SPC601
• 内网网关：192.168.1.1/24，核心交换下挂办公终端和服务器
• 电信出口：GigabitEthernet1/0/0，运营商分配IP 100.64.0.2/24，网关100.64.0.1
• 联通出口：GigabitEthernet1/0/1，运营商分配IP 100.65.0.2/24，网关100.65.0.1
• 内网PC访问电信目标网段要走电信出口，访问联通目标网段要走联通出口，其余流量走电信兜底

PBR可以做基于源地址的分流，也可以做基于目的地址的分流，客户这里既想让内网访问特定运营商网段时走对应出口，又不想内网所有用户被强制绑定某一条线路，所以我选择“源地址+目的地址联合限定”的思路。也就是说，允许网络管理员在后续根据业务需要，把指定的用户网段精确调度到指定出口上，灵活性更高。

3.2 配置接口IP和安全区域

这一步没什么技术含量，但容易跟安全区域混淆。华为USG上，接口加入untrust区域才能配合策略放通公网流量，防火墙默认只放通同区域互访，跨区域默认禁止。

firewall zone untrust add interface GigabitEthernet1/0/0 add interface GigabitEthernet1/0/1

这两条命令看着简单，实际现场经常有人漏了。漏了之后现象很诡异：PBR规则看着全部正确，静态路由也在，但流量就是通不了，因为安全策略默认拦截了跨域流量。所以后面配置安全策略时，这几个接口属于哪些区域必须心里有数。

接口IP直接在接口视图下配：

interface GigabitEthernet1/0/0 ip address 100.64.0.2 255.255.255.0 interface GigabitEthernet1/0/1 ip address 100.65.0.2 255.255.255.0

办公网段所在的GigabitEthernet1/0/2则加入trust区域，这里不再赘述。

3.3 配置内网地址簿

PBR策略里引用地址簿比直接写IP直观得多，尤其是地址段变化频繁的场景，只改地址簿不动策略，对现网影响最小。我这里需要三个地址簿：

• 内网用户网段：192.168.1.0/24
• 电信目标网段：这里用一条聚合路由配合运营商提供的地址段清单
• 联通目标网段：同样按运营商提供清单来

地址簿配置示例如下：

ip address-set lan_subnet type object address 0 192.168.1.0 mask 24 ip address-set telecom_dest type object address 0 61.128.0.0 mask 10 address 1 112.0.0.0 mask 10 ip address-set unicom_dest type object address 0 123.125.0.0 mask 16 address 1 202.106.0.0 mask 16

需要注意的是，地址簿里的目标网段并不需要写得面面俱到，只要覆盖主要业务访问目标即可，因为不匹配PBR的流量最终还会落到兜底路由上。把几百条运营商明细逐条敲进防火墙不现实，也没必要。

3.4 配置NQA与备份链路联动

流量要自动切换，必须让防火墙知道链路什么时候断了。NQA就是干这个的。我分别配置了两个NQA实例，一个探测电信网关，一个探测联通网关，然后通过track关联到静态路由上。

nqa test-instance admin telecom_probe test-type icmp destination-address ipv4 100.64.0.1 frequency 5 probe-count 2 start now nqa test-instance admin unicom_probe test-type icmp destination-address ipv4 100.65.0.1 frequency 5 probe-count 2 start now

这里探测的目标我选的是运营商网关地址，不是公网DNS。原因是运营商网关地址稳定性最高，不容易因为运营商内部维护导致误报。DNS地址虽然也能通，但各地DNS响应策略不同，偶尔会丢一两个包，NQA判定时把抖动当成了断线，切换就容易误触发。

然后配置两条静态默认路由，分别绑定track：

ip route-static 0.0.0.0 0.0.0.0 100.64.0.1 track nqa admin telecom_probe ip route-static 0.0.0.0 0.0.0.0 100.65.0.1 track nqa admin unicom_probe

这段配置要记住一个关键点：两条默认路由的优先级必须相同，华为默认优先级是60，让它们各自通过NQA决定是否有效。如果电信NQA探测失败，电信默认路由自动从路由表消失，流量自然落到联通默认路由上；反过来也一样。这样只要PBR里引用的下一跳出现故障，流量就会自动切换，不会出现“策略优先把流量送进黑洞”的尴尬。

3.5 配置PBR策略

终于到了核心环节。PBR策略的配置逻辑是：先定义一个策略名，再在策略体里逐条写规则，每条规则包含匹配条件和动作。

policy-based-route rule 5 name to_telecom permit source-address address-set lan_subnet destination-address address-set telecom_dest action pbr next-hop 100.64.0.1 rule 10 name to_unicom permit source-address address-set lan_subnet destination-address address-set unicom_dest action pbr next-hop 100.65.0.1 rule 15 name to_default permit source-address address-set lan_subnet action pbr next-hop 100.64.0.1

注意看规则编号，我留了5、10、15的间距，这样下次加需求时可以在中间插入新规则而不需要重新编号，生产环境的配置文件讲究的就是可扩展性。

规则顺序为什么这样排？因为PBR是逐条匹配、命中即停。如果我把to_default规则放在最前面，所有内网流量都会匹配到它，后面两条to_telecom和to_unicom就永远没有执行机会。正确写法一定是精确规则在前，兜底规则在后。这个顺序问题在策略路由里几乎称得上头号翻车点。

还有一点，很多朋友会问：如果PBR不匹配，是不是就走普通路由表？答案是对的。PBR只是策略，不是路由替代品。所有未被PBR命中的流量，仍然走全局路由表，这也是为什么默认路由必须存在的原因。

3.6 配置NAT策略

PBR把流量引到对应出口后，NAT必须跟上，不然流量出不去。华为USG的NAT策略同样支持rule匹配，而且条件可以和PBR对齐。

nat-policy rule name nat_to_telecom source-address address-set lan_subnet destination-address address-set telecom_dest action source-nat easy-ip interface GigabitEthernet1/0/0 rule name nat_to_unicom source-address address-set lan_subnet destination-address address-set unicom_dest action source-nat easy-ip interface GigabitEthernet1/0/1

这里用easy-ip直接借用接口地址做PAT，小规模办公网最省事。如果外网有映射需求，可以改成公网IP池，但原理一致。

NAT策略也有匹配顺序的问题，跟PBR一样，精确优先。我见过有人把NAT策略写反，结果电信访问流量被NAT成联通出口的公网IP，对端服务器做了反向DNS解析，发现来源IP归属地和实际业务逻辑不符，业务就莫名其妙被拒绝。所以NAT规则和PBR规则的顺序必须保持同样的逻辑，调试时会轻松很多。

3.7 在接口上应用PBR并验证

策略配置完成后，PBR并不会自动生效。华为USG需要在流量的入接口上应用PBR策略，应用之后的瞬间，策略就开始对从该接口进入的报文生效。

interface GigabitEthernet1/0/2 policy-based-route

这里GigabitEthernet1/0/2是内网接口，从它进来的流量会先做PBR匹配。千万不要把策略应用在出接口上，那样方向就反了。曾经有同事把PBR挂在电信出口上，结果从电信接口收到的回程报文也去匹配策略，搞得回程路由整个乱掉。

应用完策略后，先检查一下PBR的命中情况：

display policy-based-route display policy-based-route statistics

正常情况能看到to_telecom和to_unicom的匹配计数在增长。如果计数恒为0，基本可以断定策略匹配条件写得有问题，或者策略没有正确应用在入接口上。这一步的排查效率远高于直接抓包。

4. 测试验证：流量自动切换到底灵不灵

4.1 分流效果验证

配置全部做完，别急着收工。我习惯用一台内网测试机逐项验证分流效果，方法很朴素：先用ping测连通性，再用tracert看路径走向。

比如在内网PC上访问电信目标服务器：

ping 61.128.x.x tracert -d 61.128.x.x

如果PBR分流成功，tracert第一跳出去的网关应该是电信网关100.64.0.1。同理，访问联通目标服务器时，第一跳应该是联通网关100.65.0.1。看到这个结果，说明PBR的路径选择已经生效。

然后再到防火墙上确认NAT转换后的源地址。通过display session table查看会话信息，能看到源NAT后的公网地址与出接口是否对应。如果这条会话的源地址被转换成了电信公网IP且出接口是电信接口，说明PBR和NAT配合得天衣无缝。

4.2 灾备切换演练

这里有一个我特别想强调的习惯：链路切换功能一定要在项目验收前做实际演练，而不是等故障发生了才第一次验证。

我当时的做法是直接联系运营商，请他们在机房侧把电信链路做一次闪断。这里注意，闪断时间不要太短，最好持续30秒以上，方便观察NQA的探测周期和路由收敛过程。华为NQA默认探测间隔是5秒，连续两次探测失败才会判定链路不可用，所以从链路中断到路由切换会有10秒左右的延迟，这是正常现象。

切换过程中可以同时在内网PC上持续ping外网地址，观察丢包情况。理想状态下，PBR引到电信出口的流量在电信链路断开后会自动切换到联通出口，中间丢失几个探测包是可以接受的，但业务不能长时间中断。如果超过一分钟还没恢复，就要看NQA状态和路由表，排查是不是track关联没有生效。

演练结束后切回电信链路，同样观察自动回切。这里有个细节要注意：回切时华为防火墙会优先选择PBR里的下一跳，如果NQA探测已经恢复，流量会自然回到电信出口，不需要手动干预。但已建立的会话不会立刻切换，必须等会话老化后才会走新的路径，这也是状态化防火墙的普遍行为。

4.3 防火墙自身出网验证

很多人只验证内网PC，忘了防火墙自身也要上网。防火墙需要访问公网做协议升级、时间同步等操作，如果它自己出不去，也会引发一堆莫名其妙的问题。

这里跟PBR没关系，但和本地路由表有关。华为防火墙对自身发起流量的转发，会优先查找本地路由表，找不到再查全局路由表。所以如果之前有人在接口下配置了本地策略路由的下一跳指向某个不存在的地址，防火墙自己访问公网就会出问题。检查方法很简单：

display ip routing-table

确认两条默认路由都在，且防火墙能ping通公网地址，就说明本地路由表没有问题。

5. 常见问题与排查技巧实录

双ISP策略路由的项目我前后做过好几个，把高频故障和排查思路整理成一张速查表，你现场调试遇到问题直接对号入座。

除了表格里这些，我再补充几个实际调试中容易忽略的点。

第一个是NQA目标的选择。我们给NQA配置的探测目标是运营商网关，但有些运营商网关防火墙可能会禁止ICMP回包，导致NQA误判链路故障。建议配置完成后先手工ping一下探测目标，确认能收到回包再开始使用这个NQA实例。如果确实不通，就换一个运营商的知名DNS作为探测目标。

第二个是PBR和VRF组合的场景。如果防火墙开了多实例虚拟化，PBR策略是跟虚拟系统绑定的，不同虚拟系统之间不能共用策略路由配置。我遇到过客户在根系统里配好了PBR，却发现问题只出现在虚拟系统内部，最后排查到虚拟系统的策略根本没配。所以做多租户场景时，每个虚拟系统的策略路由、NAT策略都要独立检查。

第三个是关于配置备份的习惯。华为防火墙的配置文件有两层，一个叫本地配置文件，一个叫下次启动配置文件。调试过程中我习惯每改完一个阶段就执行一次save，否则设备一重启，所有改动全部丢失。这个习惯看起来很基础，但现场因为忘了保存导致前功尽弃的情况我见得太多了，每次都要特意提醒自己。

6. 双ISP策略路由的后续扩展思路

做完了电信联通双出口，很多客户后面还会提新需求，这里简单说两个常见的扩展方向，给各位留个思路。

第一个是增加运营商线路的数量。比如原来电信联通两条，后来业务扩张又加了一条移动专线。操作逻辑完全一致，只需要在PBR策略里增加一条匹配规则，指定下一跳为移动网关地址，对应配置一条NAT策略即可。三条链路并行，互为备份，NQA探测也分别跟踪各自的链路状态。这种场景下建议把所有默认路由的优先级都设为相同，完全靠NQA的track状态决定哪条路由生效。

第二个是基于应用而非IP地址分流。华为USG较新的版本支持在PBR里匹配应用类型，比如内网流量访问抖音、视频类应用走带宽更大的联通出口，访问企业ERP走稳定优先的电信专线。这种配置在命令行下逐渐变得复杂，但思路仍然是“策略匹配+指定出接口”，原理和我上面讲的完全一致。图形界面上操作更直观，适合对命令行不熟悉的朋友。

还有一个容易被业务方追问的问题：PBR能不能做负载均衡？严格来说PBR本身不等于负载均衡，它只负责按策略分流，每个流只会走一条固定路径。真正意义上的负载均衡需要靠华为的智能选路或链路负载分担功能来实现，可以根据链路带宽比例分配流量。如果客户需求不区分运营商、只要求两条链路都用起来，那直接考虑智能选路更合适，不必硬上PBR。

我在实际使用中发现，双ISP策略路由这个方案最核心的价值不是技术多高深，而是它能用最简单的配置，把复杂的分流逻辑讲得清清楚楚。和客户评审方案时，我直接在白板上画两条线、标几个匹配条件，业务方一听就懂，后期运维接手也容易上手。比起上来就上昂贵链路负载均衡设备，这个小方案已经覆盖了绝大多数中小企业的出口需求。最后再分享一个小技巧：做完所有配置后，一定要把PBR策略里的每条规则都加详细注释，描述这条规则是给哪个业务用的。这种注释在配置回滚和故障排查时能省下大量时间，千万别小看这几行备注。