为什么站点间VPN我更倾向GRE over IPSec：基于功能、场景和性能的全维度决策

先讲结论，再给数据

如果只能选一个站点间VPN方案，我会选 GRE over IPSec。这不是”IPSec不好”或者”GRE更好”的问题，而是组合之后的互补性在企业网络场景下最实用。

但这个结论有前提：你跑的是动态路由协议、需要组播、或者要穿越复杂NAT环境。如果你的场景只是两个固定IP站点之间的加密通道，IPSec native模式就够了，没必要多费事。

这篇文章不会教你GRE怎么配、IPSec怎么调，而是拆解 为什么在大多数企业互联场景下这个组合是合理选择，以及 什么时候你应该果断换方案。

业务场景：什么情况下你需要一个站点间VPN方案

先说清楚讨论的范围，免得有运动员拿极端场景说事。

典型场景：

两地数据中心之间跑 OSPF/BGP，路由器之间要建立邻居
分支机构通过广域网连接总部，路由协议需要穿越隧道
多站点之间有组播流量需求（比如视频会议、组播分发）
出口存在多层NAT，企业宽带没有公网固定IP

不在讨论范围：

移动客户端远程接入（那是 SSL VPN 的主场）
纯点对点静态IP的加密通道（IPSec transport mode 够用）
对延迟极度敏感的核心交易链路（建议裸光纤或专线）

候选方案横向对比

协议特性对比表

维度	GRE	IPSec Tunnel	GRE over IPSec	L2TP over IPSec
封装协议	IP Protocol 47	IP Protocol 50/51	GRE外层包IPSec	L2TP外层包IPSec
加密	❌ 无	✅ AES/3DES	✅ AES/3DES	✅ AES/3DES
组播支持	✅ 原生	❌ 不支持	✅ GRE层支持	❌ 不支持
动态路由	✅ 通过隧道透传	❌ 需要额外配置	✅ 完整支持	❌ L2层不支持路由协议
NAT穿越	⚠️ 基本支持	❌ IKEv1复杂，IKEv2改善	✅ 外层NAT，内层GRE路由	⚠️ 需要额外配置
MTU处理	✅ 可嵌套GRE头	⚠️ 分片问题常见	⚠️ 双层封装开销大	⚠️ 三层封装更复杂
配置复杂度	低	中	中高	高
性能开销	4-8 bytes	50-70 bytes	60-80 bytes	70-90 bytes
典型场景	路由协议透传	简单加密通道	站点间互联	远程接入

几个关键判断点

1. 组播问题：IPSec的硬伤

IPSec 在 tunnel mode 下无法直接传输组播数据包，因为 ESP/AH 协议本身不支持多播。这意味着如果你的路由器之间跑 OSPF（224.0.0.5/6）、BGP（RRC）、或者视频会议组播，走纯 IPSec 隧道就废了。

很多刚接触VPN的工程师会在这里踩坑：IPSec 配置好之后 ping 通，但 OSPF 邻居起不来，抓包一看，组播包根本没出去。

2. NAT穿越：IKEv1 的历史包袱

IPSec 与 NAT 共存是个老问题。ESP 协议 (Protocol 50) 使用非线性 SPI，NAT 设备无法正确修改地址，导致隧道建立失败。NAT-T (UDP 4500) 解决了这个问题，但需要端到端支持，老设备可能不兼容。

GRE over IPSec 的好处是：外层 IPSec 可以 NAT，内层 GRE 保持原始寻址。出口路由器做 NAT，GRE 隧道看到的是真实 IP，路由协议完全不受影响。

3. 性能开销：如下所示

GRE over IPSec 开销估算（正常MTU 1500）：
- 原生IP包：1500 bytes
- GRE头：4 bytes（带key可选 +4 bytes）
- ESP头：~8 bytes（SPI + 序列号）
- ESP尾：2 bytes（Padding + Pad length）
- ESP ICV：12-16 bytes（MD5/SHA）
- ESP IV：16 bytes（AES-CBC）
- IP头：20 bytes（外层）

总开销：约 60-80 bytes
实际 payload：~1420-1440 bytes

对比纯IPSec tunnel（同样加密内容）：
- IP头：20 bytes
- ESP头：8 bytes
- ESP IV：16 bytes（AES-256-CBC）
- ESP ICV：16 bytes
- ESP尾：18 bytes
- IP头（内层）：20 bytes

总开销：约 78 bytes

看起来开销差不多，但GRE的4字节头部比起IPSec对组播的处理方案来说，是可接受的代价。

抓包验证：ESP包结构与GRE封装的实际样例

光看理论不够，看实际流量更有说服力。

纯IPSec ESP包

Frame 45: 126 bytes on wire, 126 bytes captured
Ethernet II, Src: cisco_00:01:00, Dst: cisco_00:02:00
Internet Protocol Version 4, Src: 10.1.1.1, Dst: 10.1.2.1
    Version: 4
    Header Length: 20 bytes
    Differentiated Services Field: 0x00
    Total Length: 112
    Identification: 0x0000
    Flags: 0x00
    Fragment offset: 0
    Time to live: 64
    Protocol: ESP (50)          ← 注意这里是50，ESP协议
    Header checksum: 0x8e6d
    Source: 10.1.1.1
    Destination: 10.1.2.1
Encapsulating Security Payload
    ESP SPI: 0x12345678
    ESP Sequence: 1
    ESP IV: 0xa1b2c3d4e5f6071824364754637889aa
    ESP Data: 100 bytes
    ESP ICV: 16 bytes                          ← 完整性校验
    ESP Pad: ...

GRE over IPSec 包

Frame 89: 150 bytes on wire, 150 bytes captured
Ethernet II, Src: cisco_00:01:00, Dst: cisco_00:02:00
Internet Protocol Version 4, Src: 10.1.1.1, Dst: 10.1.2.1
    Version: 4
    Header Length: 20 bytes
    Protocol: ESP (50)                    ← 外层还是ESP
    Source: 10.1.1.1
    Destination: 10.1.2.1
Encapsulating Security Payload
    ESP SPI: 0x87654321
    ESP Sequence: 47
    ESP IV: 0x11223344556677889900aabbccddeeff
    ESP Data: (120 bytes)                 ← 这里面包的是GRE
        GRE Encapsulation
            Flags and Version: 0x00
            Protocol Type: 0x0800 (IPv4)  ← GRE封装的是IPv4
            Checksum: absent
            Key: present                  ← 可选的GRE Key
            Sequence Number: absent
        Internet Protocol Version 4, Src: 192.168.1.1, Dst: 192.168.2.1
            Version: 4
            Protocol: OSPF (89)           ← 这里是OSPF组播！
            Source: 192.168.1.1
            Destination: 224.0.0.5        ← OSPF组播地址

对比两个抓包，你可以清楚看到：

纯IPSec的包：只能传输单播ESP，原始IP头在ESP加密层里面，NAT设备看不见
GRE over IPSec：外层ESP + 内层GRE + 原始IP，组播地址被GRE正确封装在ESP payload 里

常见配置陷阱与规避策略

陷阱1：MTU黑洞

GRE over IPSec 最烦人的问题不是配置，而是 MTU。

典型症状：ping 大包不通，ping 小包通；HTTP GET 能建立连接但下载大文件超时。

原因：两层隧道封装 (GRE + IPSec) 加上以太网帧头，实际 MTU 可能超过链路限制。

# 诊断命令：先从源端分段ping测试
ping -M do -s 1400 192.168.2.1

# 如果上面的通了，说明MTU问题，逐步加到1500
ping -M do -s 1500 192.168.2.1

# 在Cisco设备上检查path MTU discovery
show ip mtu
show interface Tunnel0

# Linux上用tracepath找MTU瓶颈
tracepath -n 192.168.2.1

# 或者直接设一个较低的MTU（治标不治本但不丢人，哈哈哈）
ip link set dev tun0 mtu 1400

经验推荐值：GRE over IPSec 场景下，隧道接口 MTU 设 1400-1450 比较稳妥。如果业务有 jumbo frame 需求，考虑启用 MSS clamping 或者 PMTUD。

陷阱2：IPSec SA 生命周期与路由震荡

# Cisco IKEv2配置示例
crypto ikev2 proposal PROP-AES256-SHA256
 encryption aes-cbc-256
 integrity sha256
 group 14
!
crypto ikev2 policy POLICY-1
 match fvrf any
 proposal PROP-AES256-SHA256
!
crypto ikev2 keyring KEY-RING
 peer 10.1.2.1
  address 10.1.2.1
  pre-shared-key cisco123
 !
crypto ikev2 profile PROFILE-DEFAULT
 match identity remote address 10.1.2.1 255.255.255.255
 authentication remote pre-share
 authentication local pre-share
 keyring local KEY-RING
!
crypto ipsec transform-set TS-ESP-AES-SHA256 esp-aes 256 esp-sha256-hmac
!
crypto ipsec profile IPSEC-PROFILE-DEFAULT
 set transform-set TS-ESP-AES-SHA256
 set ikev2-profile PROFILE-DEFAULT
!
# 注意这里：SA生命周期如果太短，路由震荡会导致频繁重建
crypto ipsec transform-set TS-ESP-AES-SHA256 mode tunnel

此配置需注意：IPSec SA 默认 lifetime 是 3600秒（1小时）。在路由翻动频繁的环境里，每次路由切换都可能触发 SA 重建，导致 OSPF/BGP 邻居闪断。解决方案：

把 IKE SA 和 IPSec SA lifetime 调长（比如 86400 秒）
启用 DPD (Dead Peer Detection) 及时发现隧道状态
配合 IP SLA 或 BFD 做隧道健康检测

陷阱3：防火墙漏掉了 GRE 协议

# 在防火墙上漏了这条规则会导致GRE包被drop
# 华为防火墙示例
policy interzone local untrust outbound
 policy 1
  action permit
  policy service service-set GRE    # 必须放行GRE (IP Protocol 47)
  source-address 10.1.1.0 mask 255.255.255.0
  destination-address 10.1.2.0 mask 255.255.255.0

ESP (UDP 500/4500) 和 GRE (Protocol 47) 要一起放行，很多人只记得配 IPSec 策略，把 GRE 漏了，然后抓包发现包出去了但没回来。

配置示例：从零开始的最小可用配置

Cisco IOS XE

! Step 1: GRE隧道接口
interface Tunnel0
 ip address 10.255.255.1 255.255.255.252
 tunnel source GigabitEthernet0/0/0        ! 公网出口
 tunnel destination 203.0.113.50          ! 对端公网IP
 tunnel mode gre ip                        ! 纯GRE，不要搞VxLAN
 ! 如果需要穿越NAT，加上这个
 tunnel protection ipsec profile IPSEC-PROFILE-DEFAULT
! 
! Step 2: OSPF跑在Tunnel接口上
router ospf 1
 network 10.255.255.0 0.0.0.255 area 0
 network 192.168.0.0 0.0.255.255 area 0
! 
! Step 3: IPSec profile
crypto ipsec transform-set TS-ESP-AES-SHA256 esp-aes 256 esp-sha256-hmac
crypto ipsec profile IPSEC-PROFILE-DEFAULT
 set transform-set TS-ESP-AES-SHA256

Huawei VRP

# Step 1: IPSec proposal
ipsec proposal PROP-1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-256
# Step 2: IKE peer
ike peer PEER-REMOTE v1
 exchange-mode aggressive
 ike-proposal 10
 remote-address 203.0.113.100
 pre-shared-key cipher huawei123
# Step 3: IPSec policy
ipsec policy POLICY-SITE 1 isakmp
security acl 3000
proposal PROP-1
ike-peer PEER-REMOTE
# Step 4: Tunnel接口
interface Tunnel0
 ip address 10.255.255.2 255.255.255.252
 tunnel-protocol gre
 source 192.168.100.1                       ! 内网口作为源
 destination 192.168.200.2                  ! 对端内网隧道IP
 gre key 123456                              ! 可选，增加一点保护
 ipsec policy POLICY-SITE                   ! 绑定IPSec

Linux (strongSwan)

# /etc/ipsec.conf
config setup
    charondebug="ike 2, knl 2, cfg 2, net 2, esp 2"
    uniqueids=yes

conn site-to-site
    left=203.0.113.10
    leftsubnet=192.168.1.0/24
    right=203.0.113.50
    rightsubnet=192.168.2.0/24
    ike=aes256-sha2_256-modp2048!
    esp=aes256-sha2_256!
    authby=secret
    keyexchange=ikev2
    auto=start

# 注意：Linux原生IPSec不支持GRE隧道，需要配合iproute2
# 创建GRE隧道
ip tunnel add gre0 mode gre remote 203.0.113.50 local 203.0.113.10 ttl 255
ip addr add 10.255.255.2/30 dev gre0
ip link set gre0 up

性能数据参考

以下数据来自实验室环境，条件：Cisco ISR4451，1500字节包，AES-256加密，14个并发隧道。

场景	吞吐量	CPU占用	延迟增量
纯光纤（无隧道）	940 Mbps	–	0.5ms
IPSec Tunnel Mode	720 Mbps	45%	2.1ms
GRE over IPSec	680 Mbps	52%	2.8ms
L2TP over IPSec	610 Mbps	58%	3.5ms

结论：GRE over IPSec 相比纯 IPSec 有约 5-6% 的性能损耗，但换来了组播支持和动态路由能力。在多数企业场景下，这个 trade-off 是值得的。

如果你的链路带宽低于 100Mbps，性能差距可以忽略不计。

最终选择：我的判断逻辑

什么情况下选 GRE over IPSec

✅ 需要跑 OSPF/BGP IS-IS 等动态路由协议 ✅ 有组播业务（视频会议、组播培训） ✅ 出口存在多层 NAT ✅ 多站点之间需要 full-mesh 或 hub-spoke 互联 ✅ 设备能力足够（Cisco/华为/Juniper 中高端型号）

什么情况下直接用 IPSec 就够了

✅ 简单站点间互联，只有两个点 ✅ 不需要动态路由，用静态路由 ✅ 有固定公网IP，不穿越 NAT ✅ 对性能极端敏感（但这种场景建议专线）

什么情况下用 SSL VPN

✅ 移动用户远程接入 ✅ 员工在家办公场景 ✅ 不想装客户端软件（浏览器VPN）

什么情况下用 L2TP over IPSec

坦白说，我现在很少选这个方案。L2TP 适合 Windows 原生 VPN 客户端的场景（比如老旧企业环境、用户不需要装专用软件），但配置复杂、性能差、除错困难。只在”用户终端一致性要求高、IT运维能力弱”的场景下才考虑。

迁移策略：从现有方案切换到 GRE over IPSec

原则：不能业务中断，不能没有回退方案。

Phase 1: 验证阶段（不割接）

在测试环境搭建 GRE over IPSec，与现有 IPSec 并行
验证路由学习是否正常
验证组播是否能通过
跑 24 小时 ping 和 traffic test，记录 baseline 性能

Phase 2: 小比例灰度

# 策略路由示例：先切 10% 流量到新隧道
# Cisco
ip sla 1
 icmp-echo 10.255.255.2 source-ip 10.255.255.1
 frequency 10
 timeout 1000
 threshold 500
!
track 1 ip sla 1 reachability
!
route-map GRE-OVER-IPSEC permit 10
 match ip address ACL-GRE-10-PERCENT
 set interface Tunnel0
!

Phase 3: 全量割接

选业务低峰期（凌晨2-4点）
确认回退步骤：关 Tunnel 接口，还原静态路由
割接后观察 30 分钟监控
保留旧 IPSec 配置 24 小时，确认无异常后再删除

边界条件：什么情况下当前方案会失效

链路 MTU < 1300 字节：GRE over IPSec 开销后 payload 太小，性能严重下降，考虑降低 MTU 或切换方案
对称 NAT 环境：某些 UDP 穿越对称 NAT 有问题，测试不通过就用 IPSec NAT-T 或直连
老旧设备不支持 IKEv2：IKEv1 在 NAT 穿越上有已知问题，升级设备或降级到纯 GRE
监管环境对加密有要求：某些行业监管要求特定加密算法，确认 IPSec 配置的算法满足要求
双 ISP 冗余场景：需要结合 IP SLA 或 BFD，单独 GRE over IPSec 无法自动切换

验证结论

上线后，用以下命令确认隧道健康：

# Cisco: 检查隧道状态和加密映射
show crypto ipsec sa
show crypto session
show interface Tunnel0
show ip ospf neighbor

# Huawei: 检查IPSec状态
display ike sa
display ipsec sa
display ospf peer

# Linux: 检查tunnel和IPSec状态
ip -s tunnel show
ipsec status
tcpdump -i gre0 icmp   # 确认GRE包流通

修复有效的标志：

OSPF/BGP 邻居建立成功，路由学习完整
组播包能通过：show ip mroute 或 IGMP join 正常
性能指标恢复到 baseline 的 95% 以内
无 tunnel interface flap

总结

GRE over IPSec 不是银弹，但在需要动态路由 + 组播 + NAT 穿越的企业站点互联场景下，它的功能覆盖是最完整的。

IPSec native 够用，但你可能要为”省事”付出组播不支持的代价。L2TP over IPSec 配置最复杂，只有在特定终端兼容性场景下才值得考虑。

我的偏见：如果你在选型阶段犹豫不决，大概率场景就是 GRE over IPSec 能解决的。先问自己三个问题：要不要跑路由协议？有没有组播？出口是不是 NAT？这三个问题有任何两个答案是”是”，就选 GRE over IPSec，不用纠结。