GRE隧道与IPSec结合配置实战指南

1. 为什么要把GRE和IPSec“绑”在一起用？

如果你之前配置过GRE隧道，可能会觉得它挺方便的，就像在两个网络之间拉了一条“直通线”，什么路由协议、组播数据都能在里面跑，畅通无阻。但用久了，或者稍微敏感一点，你就会发现一个问题：这条“直通线”是透明的。GRE本身只管封装和传输，数据在公网上跑的时候是“裸奔”的，没有任何加密和完整性保护。这意味着，只要有人能接触到你的网络路径，他就能看到、甚至篡改你隧道里跑的所有数据。想象一下，你公司的财务数据、研发代码就这么明晃晃地在网上传，是不是后背一凉？

这时候，IPSec就该上场了。IPSec是一套成熟的安全协议族，它能给IP数据包提供加密、身份验证和完整性检查。简单说，就是给你的数据穿上“防弹衣”并贴上“封条”，确保只有对端能解密，并且传输途中没人能动手脚。但是，IPSec配置起来相对复杂，尤其是对动态路由协议或者组播数据的支持，有时候会让人头疼。

所以，一个很自然的想法就出来了：能不能让GRE和IPSec“结婚”，优势互补？答案是肯定的，而且这简直是“天作之合”。GRE over IPSec，或者说 IPSec保护下的GRE隧道，就成了一个非常经典的组合。它的工作模式通常是：先用GRE把各种需要传输的原始数据（可能是私网IP、路由协议报文等）封装成一个新的IP包；然后，把这个GRE封装后的整个IP包，交给IPSec来处理。IPSec会对这个包进行加密和认证，最后再扔到公网上去传输。

这样做的好处太明显了：

1. 安全无忧：最核心的，敏感数据被IPSec牢牢保护，解决了GRE裸奔的安全隐患。
2. 兼容性满分：GRE隧道内部爱跑什么就跑什么（OSPF、BGP、组播、IPv6），IPSec只负责最外层的安全护送，两者互不干扰。
3. 简化配置（相对纯IPSec策略而言）：你只需要针对两个隧道端点固定的公网IP地址建立一条IPSec安全联盟（SA），就能保护隧道内的所有流量。不用为隧道内可能出现的无数个私网IP地址对去配置复杂的IPSec策略。

我自己在帮客户搭建跨地域数据中心互联（DCI）或者总部与分支安全通信时，这个组合是首选方案。下面，我就带你从零开始，手把手配置一套。

2. 实战前的准备：理清思路与规划网络

在敲命令之前，花十分钟把网络拓扑和地址规划好，能省掉后面几小时的排错时间。我们用一个最典型的场景来举例：公司总部和分部需要安全地互联，两边的内部网络需要能互相访问。

假设我们有以下环境：

• 总部侧：一台Linux服务器（比如Ubuntu 22.04），充当网关和隧道端点。
  • 公网IP：203.0.113.10
  • 内网网段：10.1.1.0/24
  • 计划使用的GRE隧道内点对点IP：172.16.0.1/30（给总部）
• 分部侧：一台企业级防火墙（这里以开源的StrongSwan作为IPSec实现，同样运行在Linux上，模拟防火墙功能）。
  • 公网IP：198.51.100.20
  • 内网网段：10.2.2.0/24
  • 计划使用的GRE隧道内点对点IP：172.16.0.2/30（给分部）