1. 先搞清楚这个实例到底在解决什么问题企业网络里有一种很常见的需求总部和分支机构之间跑着两条链路一条是主用的专线一条是备用的宽带。平时业务流量走专线专线断了自动切到宽带同时分支内部还有一批设备需要访问互联网但出口只有一个公网地址内网一堆私有地址怎么出去这就同时牵扯到三个技术点——策略路由决定谁走哪条路GRE隧道把两个分散的私网缝成一个逻辑上的直连网络NAT负责让内网地址能跟公网对话。单独看这三个技术随便一本教材都能讲明白。但把它们揉在一个拓扑里问题就来了策略路由的下一跳指向隧道口还是物理口GRE封装后的流量会不会被NAT提前改写导致隧道起不来NAT的inside和outside接口该怎么划这些细节才是实际配置时真正卡人的地方。这篇内容就是围绕一个典型的双站点互联互联网出口场景把策略路由、GRE、NAT三者的配合关系拆开讲透。适合已经懂一点路由交换基础、能敲基本命令、但一遇到多技术叠加就理不清顺序的网络运维人员。我会把拓扑设计思路、每一步配置背后的原因、参数怎么算、以及我自己踩过的坑都摊开来说你照着搭一遍就能跑通。2. 拓扑设计与技术选型的底层逻辑2.1 为什么是这三个技术组合而不是别的方案先说说为什么这个场景会同时用到策略路由、GRE和NAT而不是用更高级的方案。有人会问站点互联直接上IPsec不就行了确实IPsec能加密能互联但它有个特点它主要解决安全传输的问题对流量选路这件事本身不提供灵活控制。而策略路由的价值在于你可以基于源地址、目的地址、协议类型甚至报文长度来决定流量走向这种颗粒度是纯路由表做不到的。当分支有财务系统走专线、普通上网走宽带这类需求时策略路由是绕不开的。那GRE在这里的角色是什么GRE的核心价值是把私网报文封装进另一个IP报文里。两个站点的内网如果都用了相同的私有网段比如都用192.168.1.0/24直接路由是冲突的但通过GRE隧道两端的隧道接口可以重新编址形成一个独立的传输网络私网网段就被隔离在隧道两端了。而且GRE对上层协议透明跑组播、跑非IP协议都没问题这是它比很多隧道技术灵活的地方。NAT则是出口的刚需。内网一堆192.168开头的地址运营商那边根本不认必须做源地址转换。但NAT和GRE放一起就有讲究了——如果NAT作用在GRE封装之前隧道两端的公网地址会被改写隧道直接起不来。所以顺序和接口划分必须想清楚。提示这三个技术的叠加顺序本质上是先选路、再封装、后转换的流水线关系配置时脑子里要有这条数据包的加工链路。2.2 拓扑结构与地址规划我用的拓扑是这样的两个站点分别叫站点A和站点B各自有一个边界设备就叫R1和R2。R1和R2之间通过运营商网络互联R1侧有一条专线链路用G0/0/0模拟和一条宽带链路用G0/0/1模拟R2侧只有一条链路连到运营商。地址规划上我做了一个刻意的设计两个站点的内网都用192.168.1.0/24这个网段。这不是偷懒而是故意制造地址冲突的场景逼着GRE隧道来解决问题。如果两端网段本来就不同那直接写静态路由就行了根本用不上GRE。具体地址分配如下表设备接口地址说明R1G0/0/0100.1.1.1/30专线出口对端运营商100.1.1.2R1G0/0/1200.1.1.1/30宽带出口对端运营商200.1.1.2R1G0/0/2192.168.1.1/24站点A内网网关R1Tunnel010.0.0.1/30GRE隧道接口R2G0/0/0100.1.1.5/30站点B出口对端运营商100.1.1.6R2G0/0/2192.168.1.1/24站点B内网网关R2Tunnel010.0.0.2/30GRE隧道接口注意R2的出口地址100.1.1.5和R1的专线地址100.1.1.1不在同一网段中间隔着运营商的路由器。这样设计是为了更贴近真实场景——两个站点通常不会直连而是各自连到运营商的PE设备上。隧道接口用10.0.0.0/30这个网段两端各占一个地址。这个网段是隧道内部的传输网段跟两端的业务网段完全独立互不干扰。2.3 数据包的处理流程预演在动手配置之前我习惯先在脑子里把数据包的旅程走一遍这样配置时才知道每条命令是在哪个环节起作用。假设站点A的一台PC192.168.1.100要访问站点B的一台服务器192.168.1.200。数据包从PC出来到达R1的内网口G0/0/2。R1查路由表发现去往192.168.1.200的下一跳应该是隧道口。但这里有个问题R1自己的内网也是192.168.1.0/24直连路由会优先匹配导致数据包被本地消化而不是送进隧道。所以必须用策略路由强制把去往站点B的流量引到隧道口这就是策略路由在这里的第一个作用。数据包进入隧道后GRE会把它封装成一个新的IP包外层源地址是10.0.0.1目的地址是10.0.0.2。这个外层包再根据路由表找到出接口——比如走专线G0/0/0。到了G0/0/0出口NAT要把外层包的源地址10.0.0.1转换成100.1.1.1这样运营商才认。数据包穿过运营商网络到达R2R2解封装取出内层包发现目的地址192.168.1.200是自己内网的直接转发给服务器。回程流量同理只是方向反过来。这个流程里策略路由管进不进隧道GRE管怎么封装NAT管外层地址怎么转换。三者各司其职顺序不能乱。3. 核心配置逐段拆解与参数计算3.1 策略路由的匹配规则与下一跳选择策略路由的配置核心是定义一个traffic classifier流分类和一个traffic behavior流行为然后用traffic policy把它们绑在一起最后应用到接口上。这套逻辑在华为设备上叫MQC模块化QoS命令行虽然名字里有QoS但策略路由只是它的一个应用场景。先定义流分类匹配去往站点B内网的流量。这里有个细节因为两端网段相同不能用目的地址192.168.1.0/24来匹配否则会把去往本地内网的流量也匹配上。我的做法是用ACL匹配源地址是站点A内网、目的地址是站点B内网特定服务器的流量。实际环境中如果两端网段冲突通常会用具体的服务器地址来区分。acl number 3000 rule 5 permit ip source 192.168.1.0 0.0.0.255 destination 192.168.1.200 0然后定义流行为指定下一跳为隧道口。这里有个关键选择下一跳是写隧道口的IP地址10.0.0.2还是写隧道接口本身我建议写隧道口的IP地址因为这样策略路由会先查路由表找到去往10.0.0.2的路由再决定出接口。如果直接写接口万一隧道状态异常流量可能被黑洞掉。traffic behavior PBR_TO_B redirect ip-nexthop 10.0.0.2接着把分类和行为绑成policy应用到R1的内网口G0/0/2的入方向。traffic policy PBR_POLICY classifier PBR_CLASS behavior PBR_TO_B interface GigabitEthernet0/0/2 traffic-policy PBR_POLICY inbound注意策略路由应用在入方向也就是流量进入R1的第一个接口。如果应用在出方向流量已经经过路由决策了策略路由可能不生效。3.2 GRE隧道的建立与关键参数GRE隧道的配置看起来简单但有几个参数直接决定隧道能不能起来。interface Tunnel0 ip address 10.0.0.1 255.255.255.252 tunnel-protocol gre source 100.1.1.1 destination 100.1.1.5source和destination分别填R1和R2的公网地址。这里有个坑source地址必须是R1上真实存在的、能到达destination的地址。如果R1有多个公网地址选错了source隧道可能起不来或者不稳定。隧道建立后还需要在隧道接口上配置路由让R1知道去往站点B内网的流量应该从隧道走。但因为我们用了策略路由这条路由其实可以省略——策略路由会强制把匹配的流量送到隧道口。不过为了保险我还是加了一条静态路由作为兜底ip route-static 192.168.1.200 255.255.255.255 Tunnel0这条路由的优先级比直连路由低所以不会影响本地内网通信只在策略路由失效时起作用。3.3 NAT的接口划分与转换规则NAT的配置最容易出错的地方是接口的inside和outside划分。原则很简单流量从内网出去的方向靠近内网的接口是inside靠近公网的接口是outside。在R1上G0/0/2是内网口划为insideG0/0/0和G0/0/1是公网口划为outside。interface GigabitEthernet0/0/2 nat inside interface GigabitEthernet0/0/0 nat outside interface GigabitEthernet0/0/1 nat outside然后定义NAT规则。这里有个关键问题NAT要转换的是GRE封装后的外层地址还是内层地址答案是外层。因为GRE封装后内层地址被包在里面NAT设备看不到。所以NAT的ACL应该匹配隧道接口的地址10.0.0.1而不是内网的192.168.1.0/24。acl number 2000 rule 5 permit source 10.0.0.0 0.0.0.3 interface GigabitEthernet0/0/0 nat outbound 2000这样配置后从隧道出来的流量外层源地址10.0.0.1会被转换成G0/0/0的地址100.1.1.1。R2收到后解封装看到内层包正常转发。提示如果NAT的ACL匹配了内网地址192.168.1.0/24那GRE封装前的流量会被转换隧道两端的内层地址就变了隧道直接失效。这是最常见的配置错误。3.4 双链路切换的策略路由设计前面只讲了走专线的情况现在加上宽带备用链路。需求是专线正常时走专线专线断了自动切宽带。实现方式是用策略路由的track功能关联一个NQA网络质量分析探测。NQA定期探测专线对端地址100.1.1.2如果探测失败track状态变为down策略路由自动切换到备用下一跳。nqa test-instance admin track_primary test-type icmp destination-address ipv4 100.1.1.2 frequency 5 timeout 2 probe-count 2 start now track 1 nqa admin track_primary traffic behavior PBR_TO_B redirect ip-nexthop 10.0.0.2 track 1但这里有个问题隧道口的下一跳10.0.0.2是固定的不管走专线还是宽带隧道口都是同一个。所以策略路由的下一跳不需要变变的是隧道外层包走哪条物理链路。这就要靠路由表来控制了。我在R1上配置两条去往R2公网地址100.1.1.5的静态路由一条走专线一条走宽带专线的优先级更高。当专线断了路由表自动切换到宽带。ip route-static 100.1.1.5 255.255.255.255 100.1.1.2 preference 60 ip route-static 100.1.1.5 255.255.255.255 200.1.1.2 preference 100preference值越小优先级越高60比100优先。专线正常时走第一条专线断了第一条失效自动走第二条。注意NQA的探测目标要选一个真实可达的地址。如果探测运营商网关可能网关禁ping导致误判。我一般探测隧道对端的公网地址这样能真实反映隧道是否可用。4. 完整实操流程与现场记录4.1 基础配置与接口地址先把两端的接口地址配好这是所有后续配置的基础。我在R1上依次配置三个物理接口和隧道接口。system-view sysname R1 interface GigabitEthernet0/0/0 ip address 100.1.1.1 255.255.255.252 interface GigabitEthernet0/0/1 ip address 200.1.1.1 255.255.255.252 interface GigabitEthernet0/0/2 ip address 192.168.1.1 255.255.255.0 interface Tunnel0 ip address 10.0.0.1 255.255.255.252 tunnel-protocol gre source 100.1.1.1 destination 100.1.1.5R2侧类似只是接口少一个隧道source和destination对调。system-view sysname R2 interface GigabitEthernet0/0/0 ip address 100.1.1.5 255.255.255.252 interface GigabitEthernet0/0/2 ip address 192.168.1.1 255.255.255.0 interface Tunnel0 ip address 10.0.0.2 255.255.255.252 tunnel-protocol gre source 100.1.1.5 destination 100.1.1.1配完后用display interface Tunnel0检查隧道状态看到Line protocol current state : UP就说明隧道起来了。如果显示DOWN先检查source和destination是否可达用ping -a 100.1.1.1 100.1.1.5测试。4.2 策略路由与NAT的联动配置隧道起来后配置策略路由把流量引进去。这里我把ACL、流分类、流行为、策略和应用接口的配置一次性列出来方便对照。acl number 3000 rule 5 permit ip source 192.168.1.0 0.0.0.255 destination 192.168.1.200 0 traffic classifier PBR_CLASS operator or if-match acl 3000 traffic behavior PBR_TO_B redirect ip-nexthop 10.0.0.2 traffic policy PBR_POLICY classifier PBR_CLASS behavior PBR_TO_B interface GigabitEthernet0/0/2 traffic-policy PBR_POLICY inboundNAT部分先划接口再配ACL和outbound。interface GigabitEthernet0/0/2 nat inside interface GigabitEthernet0/0/0 nat outside interface GigabitEthernet0/0/1 nat outside acl number 2000 rule 5 permit source 10.0.0.0 0.0.0.3 interface GigabitEthernet0/0/0 nat outbound 2000 interface GigabitEthernet0/0/1 nat outbound 2000配完后从站点A的PC ping站点B的服务器应该能通。如果ping不通按下面的顺序排查先看隧道状态再看策略路由是否命中最后看NAT转换表。4.3 验证与调试命令实录验证分三步走。第一步确认隧道状态和路由。display interface Tunnel0 brief display ip routing-table 10.0.0.2第二步确认策略路由命中情况。华为设备可以用display traffic policy statistics查看策略匹配计数。display traffic policy statistics interface GigabitEthernet0/0/2 inbound如果匹配计数为0说明流量没被策略路由捕获检查ACL是否写错、应用方向是否正确。第三步确认NAT转换。用display nat session all查看会话表应该能看到源地址10.0.0.1被转换成100.1.1.1的记录。display nat session all我在实测时遇到过一个现象隧道起来了策略路由也命中了但ping不通。查NAT会话表发现根本没有转换记录。后来发现是NAT的ACL写成了192.168.1.0/24导致GRE封装前的流量被转换隧道内层地址变了。改成10.0.0.0/30后立刻正常。4.4 双链路切换的实测过程为了验证专线断掉后能否自动切宽带我直接在R1上把G0/0/0接口shutdown模拟专线故障。interface GigabitEthernet0/0/0 shutdown然后观察NQA的track状态和路由表变化。display track 1 display ip routing-table 100.1.1.5track状态应该在几秒内变为Down路由表里去往100.1.1.5的下一跳从100.1.1.2切换到200.1.1.2。此时从PC ping服务器应该仍然能通只是延迟可能略有增加。再把G0/0/0恢复等NQA探测成功后流量自动切回专线。interface GigabitEthernet0/0/0 undo shutdown这个切换过程我实测下来NQA的frequency设为5秒、timeout设为2秒、probe-count设为2时故障检测时间大约在10秒左右。如果对切换速度要求更高可以把frequency降到3秒但会增加探测报文的开销需要权衡。5. 常见问题排查与避坑经验5.1 隧道起不来的几种典型原因隧道DOWN是最常见的问题我整理了一个排查表现象可能原因排查方法隧道协议状态DOWNsource地址不可达ping测试source到destination隧道协议状态DOWN中间设备拦截GRE协议检查运营商是否放行IP协议号47隧道UP但ping不通隧道接口未配地址display interface Tunnel0隧道UP但业务不通策略路由未命中display traffic policy statistics隧道UP但业务不通NAT转换了内层地址display nat session allGRE的协议号是47有些运营商的设备默认会拦截非TCP/UDP的IP报文。如果隧道一直起不来但source和destination能互相ping通大概率是这个问题。解决办法是换一种封装方式或者跟运营商确认策略。5.2 NAT与GRE的顺序陷阱这是我最想强调的一个坑。很多人配NAT时习惯性地把内网网段写进ACL觉得内网出去都要转换。但在GRE场景下内网流量先被GRE封装外层地址是隧道地址内层地址才是内网地址。NAT设备只能看到外层所以ACL必须匹配隧道地址。如果你把ACL写成匹配192.168.1.0/24会发生什么GRE封装前的原始报文会被NAT转换源地址从192.168.1.100变成100.1.1.1。然后这个被转换过的报文再进入GRE隧道封装后的内层源地址变成了100.1.1.1。R2收到后解封装发现内层源地址是100.1.1.1回包时找不到去往100.1.1.1的路由因为R2的路由表里没有这个地址回包失败。所以记住一句话GRE场景下NAT的ACL匹配隧道地址不匹配内网地址。5.3 策略路由不生效的排查思路策略路由不生效通常有三个原因ACL没匹配上、应用方向错了、或者被其他策略覆盖了。先检查ACL匹配计数display acl 3000如果匹配计数为0说明流量没被ACL捕获。检查源地址、目的地址、掩码是否写对。特别是通配符掩码0.0.0.255对应/240.0.0.0对应/32写错了就匹配不上。再检查应用方向。策略路由应用在接口的inbound方向也就是流量进入接口的方向。如果应用在outbound流量已经经过路由决策了策略路由不会生效。最后检查是否有其他策略路由或PBR规则优先级更高。华为设备上策略路由按接口应用的顺序匹配如果多个策略应用在同一接口先匹配到的生效。5.4 双链路切换的抖动问题NQA探测频率设得太高专线轻微抖动就会触发切换导致流量频繁在两条链路之间跳来跳去。我遇到过专线质量不稳定NQA每隔几分钟就切换一次业务虽然没断但延迟忽高忽低。解决办法是调整NQA参数增加probe-count和timeout让探测更宽容。比如frequency设为10秒timeout设为3秒probe-count设为3这样需要连续3次探测失败才判定为Down能有效过滤瞬时抖动。另外可以配置track的delay让状态变化后延迟一段时间再生效避免抖动。track 1 nqa admin track_primary delay down 10 up 30down 10表示探测失败后延迟10秒才切换up 30表示探测恢复后延迟30秒才切回。这样给网络一个缓冲期避免频繁切换。5.5 实操心得与独家技巧分享几个我在实际项目中总结的小技巧。第一个配置前先画数据包流程图。把流量从哪进、经过哪些处理、从哪出画清楚配置时就知道每条命令在哪个环节起作用。我见过太多人配置时东敲一条西敲一条出了问题完全不知道从哪查。第二个NAT的ACL尽量写精确。不要图省事写0.0.0.0 0.0.0.0那样所有流量都会被转换包括隧道流量和路由协议报文容易出问题。精确匹配隧道地址段既安全又高效。第三个策略路由的下一跳优先写IP地址而不是接口。写IP地址时策略路由会先查路由表如果路由表里没有去往该IP的路由策略路由不生效流量走默认路由。写接口时策略路由直接指定出接口不管路由表容易造成黑洞。第四个GRE隧道建议配置keepalive。华为设备支持在隧道接口上配置keepalive定期发送探测报文如果连续几次收不到回应就认为隧道故障自动down掉隧道接口触发路由切换。interface Tunnel0 keepalive period 5 retry-times 3这样隧道故障时路由表能快速感知比单纯依赖NQA探测更直接。第五个测试时用扩展ping指定源地址。从R1 ping R2的内网地址时如果不指定源地址可能走的是默认路由而不是隧道。用ping -a 10.0.0.1 192.168.1.200强制从隧道口发出能准确验证隧道连通性。6. 方案扩展与场景延伸6.1 多分支场景下的隧道设计如果分支不止一个而是有多个分支都要跟总部互联GRE隧道可以做成hub-spoke结构。总部作为hub每个分支作为spoke分别跟总部建立隧道。策略路由在总部侧根据目的地址把流量引到对应的隧道口。这种场景下NAT的配置要注意总部出口的NAT ACL要匹配所有隧道的地址段不能只匹配一个。如果隧道地址段规划得好比如用10.0.0.0/24统一编址每个分支占一个/30那ACL写10.0.0.0/24就能覆盖所有隧道。6.2 隧道内跑动态路由的考虑如果分支数量多静态路由和策略路由维护起来很麻烦可以考虑在隧道内跑OSPF或BGP。隧道接口配置OSPF后两端的内网路由会自动交换不需要手工写静态路由。但要注意OSPF的hello报文是组播GRE隧道默认支持组播所以OSPF能正常跑。如果换成IPsec隧道组播支持就麻烦了这也是GRE的一个优势。跑动态路由后策略路由的角色会弱化因为路由表已经能正确选路了。但策略路由仍然有用——比如需要基于源地址做流量工程时动态路由做不到还是得靠策略路由。6.3 安全加固的几点建议GRE本身不加密隧道里的流量是明文的。如果业务对安全性有要求可以在GRE外面再套一层IPsec形成GRE over IPsec的架构。这样既有GRE的灵活性又有IPsec的安全性。配置顺序是先建GRE隧道再在物理接口上配置IPsec策略匹配GRE流量。IPsec会把整个GRE报文加密包括内层和外层。另外NAT的ACL要加上对隧道流量的保护避免隧道流量被意外转换。可以在ACL里加一条deny规则明确拒绝隧道地址段然后再permit其他流量。acl number 2000 rule 5 deny ip source 10.0.0.0 0.0.0.3 destination 10.0.0.0 0.0.0.3 rule 10 permit ip source 10.0.0.0 0.0.0.3这样隧道内部的流量不会被NAT转换只有隧道外层流量才会被转换。6.4 性能与开销的权衡GRE封装会增加报文长度通常增加24字节4字节GRE头20字节新IP头。如果原始报文接近MTU封装后可能超过MTU导致分片。建议在隧道接口上调整TCP MSS让TCP协商时主动减小报文长度。interface Tunnel0 tcp adjust-mss 14001400这个值是这样算的物理接口MTU通常是1500减去GRE的24字节再减去IP和TCP头各20字节剩下1436。取1400留一点余量比较稳妥。NAT会话表也会占用设备内存会话数量多的时候要注意设备规格。策略路由的ACL匹配也会消耗CPU如果ACL规则太多建议用MQC的流分类做精确匹配减少逐条匹配的开销。整个方案搭下来我最大的体会是多技术叠加时顺序比配置本身更重要。先想清楚数据包的处理流程再决定每条命令放在哪个环节比盲目敲命令然后到处排查要高效得多。这个实例里的策略路由、GRE、NAT单独拎出来都不难难的是让它们协同工作。把数据包的旅程在脑子里走通了配置就是水到渠成的事。