去年我帮一家分公司做出口改造客户提出的需求很典型双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判定时把抖动当成了断线切换就容易误触发。然后配置两条静态默认路由分别绑定trackip 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策略路由的项目我前后做过好几个把高频故障和排查思路整理成一张速查表你现场调试遇到问题直接对号入座。故障现象可能原因排查命令 / 处理方式PBR命中计数为0策略未应用到入接口、匹配条件错误display policy-based-route statistics检查接口下是否已应用策略流量全部走一条链路PBR规则顺序错误兜底规则在前检查rule编号顺序精确规则必须在前链路断开后不自动切换NQA探测失败或track未绑定路由display nqa resultsdisplay ip routing-table查看track状态内网PC无法上网NAT策略和PBR不对应源地址未转换display session table查看会话详情检查NAT规则顺序防火墙自身无法上网本地路由表异常默认路由丢失display ip routing-table检查静态路由是否还处于active状态会话切换不生效状态化防火墙特性老会话不重新匹配PBR手动执行reset session等会话老化或重启业务回程流量被丢弃回程路径和会话出接口不一致检查服务器侧回程路由确保运营商线路回程路径一致PBR指定下一跳不可达本地路由表无递归路由检查防火墙到PBR下一跳的连通性确认全局路由表有对应直连路由除了表格里这些我再补充几个实际调试中容易忽略的点。第一个是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策略里的每条规则都加详细注释描述这条规则是给哪个业务用的。这种注释在配置回滚和故障排查时能省下大量时间千万别小看这几行备注。