分支互联场景下，GRE隧道适合承载动态路由协议，而IPSec隧道负责加密数据，两者叠加使用才是兼顾灵活性与安全性的落地答案。这是我们在多个分支组网项目中反复验证过的结论，单纯用GRE，数据明文暴露在公网上；单纯用IPSec，又难以灵活传递路由协议，本文直接拆解这两种隧道在分支互联中的配合方式、配置要点和排错思路。
先搞清楚GRE和IPSec各自在分支互联里扮演什么角色
很多网络工程师纠结“GRE和IPSec隧道选哪个”，其实这个问题本身就问偏了，在实际分支互联场景中，GRE和IPSec不是替代关系，而是搭档关系。
GRE隧道解决的是“能不能通”的问题
GRE（Generic Routing Encapsulation）是一种轻量级的隧道封装协议，它能把组播、广播以及非IP协议包封装进IP报文里，让分支和总部之间跑OSPF、EIGRP这类动态路由协议成为可能，你要知道，普通IPSec隧道默认只支持单播，没法传递路由协议的组播包。
IPSec隧道解决的是“安不安全”的问题
IPSec提供认证、完整性和加密，保护数据在公网上传输不泄露，但IPSec本身不关心你的内网路由怎么走，它只负责把IP包加密后送过去。GRE over IPSec的标准做法就是：先用GRE封装原始数据包，再用IPSec加密整个GRE报文，这样既保留GRE对接动态路由的能力，又获得IPSec的加密保护。
行业共识认为,分支互联场景下，90%以上的生产环境采用的都是这种GRE over IPSec的组合方案，而不是单用一种隧道协议。
分支互联中GRE over IPSec的落地组网流程
不要一上来就敲命令,先梳理清楚需求和网络拓扑，后面配置才不容易翻车，下面这套流程是我们多次实践后整理出来的，适合中小分支和总部互联的典型场景。
第一步：梳理分支与总部的网段和路由协议
假设总部内网是10.0.0/16，分支内网是168.10.0/24，两条隧道需要分别建立：一条GRE隧道用于跑OSPF，一条IPSec隧道用于加密，先画好这张表：
| 项目 | 总部设备 | 分支设备 |
|---|---|---|
| 公网接口IP | 1.1.1 | 1.1.1 |
| 隧道内网IP | 16.0.1/30 | 16.0.2/30 |
| 内网网段 | 10.0.0/16 | 168.10.0/24 |
| 动态路由协议 | OSPF区域0 | OSPF区域0 |
第二步：配置GRE隧道接口
在分支路由器上,核心命令如下：
interface Tunnel0
ip address 172.16.0.2 255.255.255.252
tunnel source 200.1.1.1
tunnel destination 100.1.1.1总部侧同样配置,只是IP地址和源目地址反过来，配置完后，用ping 172.16.0.1验证隧道内网连通性，细节是：GRE隧道接口的IP地址需要规划成独立网段，避免和业务网段冲突。
第三步：配置IPSec保护GRE流量
IPSec配置分两部分：IKE策略和IPSec策略，关键在于，需要把GRE隧道两端的IP地址和协议号47作为受保护流量，如果写成permit ip any any，会把所有流量都拉进隧道里，容易出问题。
分支侧IPSec配置要点：
crypto isakmp policy 10
authentication pre-share
encryption aes 256
hash sha256
group 14
lifetime 86400
crypto isakmp key cisco123 address 100.1.1.1
!
crypto ipsec transform-set TS esp-aes 256 esp-sha256
mode tunnel
!
crypto map CMAP 10 ipsec-isakmp
set peer 100.1.1.1
set transform-set TS
match address GRE_TRAFFIC访问控制列表GRE_TRAFFIC需要精确匹配源和目的IP，以及协议号47：
access-list 100 permit gre host 200.1.1.1 host 100.1.1.1总部侧配置对称,注意一点：无论用哪家设备，配置IPSec时都要把GRE流量放行，否则隧道建立后数据包一到IPSec阶段就会被丢弃，这是分支互联初建时最常见的坑。
第四步：在GRE隧道上跑OSPF
GRE隧道起来后,OSPF配置就很直观了：
router ospf 100
network 172.16.0.2 0.0.0.0 area 0
network 192.168.10.0 0.0.0.255 area 0总部侧除了宣告隧道网段,还要宣告10.0.0网段，OSPF邻居建立后，分支和总部的动态路由自动学习，后续新增网段不需要再改静态路由。
GRE与IPSec隧道在分支互联中的常见故障排查思路
配置完不代表万事大吉,分支互联场景里故障点往往藏在细节里，按下面顺序排查，效率最高。
排查IPSec隧道建立不起来的问题
先查IKE阶段是否正常,在路由器上执行show crypto isakmp sa，如果状态是QM_IDLE说明IKE阶段正常，如果卡在MM_NO_STATE，优先检查预共享密钥、加密算法和策略是否一致。
再查看IPSec阶段：show crypto ipsec sa，如果encapsulation failures计数持续增加，说明GRE流量没有匹配到加密映射，问题大概率在ACL上，还有一条隐性规则：如果不做NAT豁免，公网接口的NAT会把GRE和IPSec报文一并转换，导致加密后的数据包被NAT改写，对端无法解封装，分支互联场景下，需要在NAT配置中排除掉去往对端公网IP的流量。
排查OSPF邻居起不来的问题
OSPF邻居处于DOWN状态时,先确认GRE隧道两端IP能互通，能通但邻居起不来，检查tunnel mode gre是否一致，以及MTU设置是否过小。GRE over IPSec叠加后，报文头额外增加了54字节以上，如果原始MTU是1500，封装后必须调小隧道接口MTU，一般建议设为1400，有些设备默认使用PMTU-D，但公网链路往往会屏蔽ICMP，导致分片异常，稳妥做法是把隧道接口和物理接口的MTU都固定住。
OSPF在GRE隧道上默认使用组播地址224.0.0.5，确保ACL中没有禁止该组播地址，例如下面这条：
access-list 100 deny ospf host 172.16.0.2 host 172.16.0.1这类配置会导致OSPF包被忽略,排查时容易忽略。
分支互联中GRE与IPSec方案对比：什么时候必须叠加
有些场景不用叠加也能干活,但我们要想清楚边界在哪里。
| 场景 | 单独用GRE | 单独用IPSec | GRE over IPSec |
|---|---|---|---|
| 分支跑OSPF或EIGRP | 支持，但明文传输 | 不支持，组播无法穿越 | 支持且加密 |
| 分支只有静态路由 | 明文裸奔 | 支持单播加密 | 稍显冗余但可用 |
| 分支机构数量较多 | 路由表管理方便 | 配置量随隧道增多 | 最佳实践 |
| 对安全性要求高 | 不可接受 | 可满足 | 满足 |
从这个表格能看出来,只要分支互联需要动态路由协议，GRE和IPSec就是必需品，谈不上选择，只有那些分支点少、网段固定、用静态路由就够的场景，才可以直接用IPSec保护路由流量，省去GRE层。
面对越来越多的分支机构,建议统一采用GRE over IPSec模板化配置，把重复的IPSec策略和GRE隧道参数做成模板，新开分支时只需修改IP地址和网段，据工信部近年来发布的企业网络建设指南，分支互联的安全加密已成为企业上云和数字化转型的基础要求，裸奔跑GRE的风险比往年更高。
GRE和IPSec隧道在分支互联中的性能调优细节
配置跑通了,还要关注性能，分支设备往往型号不同，性能差异较大，调优思路要注意平衡。
调整加密算法权重
如果分支设备是低端路由器,CPU不够强，AES-256可能成为瓶颈，业内专家指出，分支侧设备在满足合规要求的前提下，可以优先使用AES-128-GCM，该算法硬件加速支持普遍，CPU开销比CBC模式小得多，SHA-256做完整性校验，性能影响不大，代价是安全性略低于AES-256，但分支互联场景完全够用。
关注IPSec安全关联生命周期
生命周期过短会导致频繁重协商,占用CPU和带宽，建议将IKE生命周期设置为86400秒，IPSec生命周期设置为3600秒以上，如果分支流量突发性很强，可以调低IPSec生命周期的流量阈值，避免单条SA传输过多数据而触发重协商。
使用DPD检测对端状态
分支设备经常因为拨号网络导致动态IP,这时候需要开启DPD（Dead Peer Detection），让对端设备主动检测隧道状态，配置如下：
crypto isakmp keepalive 10 3 periodic这样当分支端公网IP变化时,总部能快速感知并重建SA，业务中断时间控制在秒级。
搭建分支互联隧道前需要确认的硬性条件
不是所有网络环境都适合直接跑GRE和IPSec,动手前先检查下面这些硬性条件，否则大概率白忙一场。
- 分支和总部公网出口必须允许协议号47（GRE）和UDP 500/4500端口通过，有些运营商防火墙会默认拦截这两类报文，需要提前在安全组或防火墙策略中放行。
- 如果分支侧使用NAT上网,需要确认NAT设备支持IPSec NAT-T（端口4500），并且做NAT豁免，很多老设备默认只做普通NAPT，会导致GRE over IPSec隧道建立失败。
- 分支设备的隧道数量上限要算清楚,一台路由器如果只支持50条IPSec隧道，而你规划了60个分支便无法满足需求，需要提前评估设备型号和授权。
- 内网路由表大小影响OSPF收敛速度,分支数量较多时，建议在区域间做路由汇总，避免每条明细路由都传递到所有分支，总部用
area 0 range汇总，分支侧则尽量使用默认路由指向隧道接口。
实际分支互联场景中的配置顺序建议
业内很多次割接失败,都是因为命令配置顺序混乱，我们建议按下面顺序执行，每一步做完都要验证：
- 先配置公网接口地址和默认路由,确认公网互通。
- 再配置GRE隧道接口,隧道两端分别ping通对端隧道IP。
- 配置ACL明确GRE流量,再配置IKE和IPSec策略，确认
show crypto ipsec sa中有加解密计数。 - 在GRE隧道接口上启用OSPF,观察邻居状态到FULL。
- 最后统一检查路由表和业务连通性,分支PC执行
ping 10.10.0.1 -t长ping，同时观察show crypto ipsec sa中的packet计数是否同步增长。
这套顺序能让你在每一步都快速定位问题,避免多个故障点叠加时无从下手。
GRE与IPSec隧道分支互联的Q&A
问：GRE over IPSec和VXLAN over IPSec在分支互联中有啥区别？
GRE over IPSec更多用于传统企业分支，配置简单，设备兼容性广，VXLAN一般应用在数据中心或SD-WAN场景，需要底层网络支持组播或叠加路由协议，分支互联的规模通常不大，网络结构也不复杂，GRE over IPSec基本够用，除非分支数量非常多、需要大规模二层互通，才推荐考虑VXLAN。
问：分支侧是动态IP地址，GRE和IPSec能正常工作吗？
GRE隧道要求隧道目的地址固定,但源地址可以用动态IP，只需配置tunnel source为出接口名而不是具体IP地址，IPSec对端需要配置为动态认证模式，或者使用数字证书，如果设备不支持动态对端，则需分支侧主动发起隧道建立，总部固定监听，这种情况下建议使用SD-WAN方案替代纯手工IPSec配置，因为动态IP下的重协商和故障切换处理起来更省心。
问：隧道建立成功后，分支访问总部内网延迟很高，怎么定位是GRE还是IPSec的问题？
先ping隧道对端内网IP（如172.16.0.1），取RTT基准值，再ping总部内网业务IP（如10.10.0.1），对比两者的延迟差，如果延迟差很小，说明问题在总部内网侧；如果差一大截，检查封装后的报文是否走了正确的公网路径，另外要排除加密带来的CPU处理延迟，查看路由器CPU占用率，如果设备性能不足，延迟升高也正常，必要时关闭IPSec的验证模式，只保留加密，观察延迟变化，但生产环境不建议长时间关闭验证。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/792117.html
