1. 从一个真实需求说起：为什么还要折腾GRE隧道

很多人第一次听到GRE隧道这个词，反应都是"这玩意儿不是早就有了吗"。确实，GRE（Generic Routing Encapsulation，通用路由封装）诞生于上世纪九十年代，论资历比很多读者的网龄都长。但有意思的是，我在实际项目里发现，越是成熟的网络架构，越容易在某个角落藏着一条GRE隧道在默默干活。它就像网络世界里的老黄牛，不显山不露水，但关键时刻真能顶上去。

先把这个东西说清楚。GRE本质上是一种三层隧道协议，核心思路是把一种网络层协议的数据包，整个包裹进另一种网络层协议的数据包里，然后在两端之间传输。打个生活化的比方：你要把一台冰箱从A城运到B城，但B城的道路只允许跑标准集装箱卡车。怎么办？把冰箱装进标准集装箱，到了B城再拆箱取出冰箱。GRE干的就是这个"装箱"和"拆箱"的活，冰箱是原始数据包，集装箱是GRE封装后的外层包，两端的"装卸工人"就是隧道端点设备。

那它到底能解决什么问题？我总结下来主要是三类场景。第一类是跨网段互联，比如两个办公区各自有独立的私有网段，想互相访问但中间隔着一段不受控的网络，GRE可以把私有包封装后穿过中间网络。第二类是承载非IP协议，比如某些工业设备还在跑IPX或者AppleTalk，现代网络设备早就不认这些协议了，GRE可以把它们封装成IP包传过去。第三类是配合动态路由协议，这是我认为最有价值的一点，后面会展开讲。

适合谁来参考这篇内容？如果你是有一定网络基础、正在做多站点互联或者混合云组网的运维人员，这篇东西应该能帮你少走弯路。如果你刚接触隧道技术，也没关系，我会把原理和实操都掰开揉碎讲。但有一点要说在前面：GRE本身不提供任何加密能力，它只管封装和传输，安全性要靠其他机制来补。这个认知很重要，很多新手会误以为"隧道"就等于"安全通道"，这是两码事。

2. 核心原理拆解：GRE到底在数据包上做了什么手脚

2.1 封装结构逐层剖析

要真正理解GRE，得从数据包的封装结构入手。一个原始数据包被GRE封装后，会变成这样一层套一层的结构：

• 最外层：新的IP头，源地址和目的地址是隧道两端的公网或可达地址
• GRE头：包含协议类型、校验和等字段，告诉对端"我里面装的是什么"
• 原始IP头：被封装的内层数据包的IP头
• 原始载荷：真正的业务数据

这里有个关键点容易被忽略：GRE头本身只有4个字节的基础部分（如果不带校验和和key字段），加上外层IP头最少20个字节，意味着每个数据包至少增加24字节的开销。这个数字看着不大，但在小包居多的场景下影响就很明显了。我实测过一个VoIP场景，平均包长只有80字节左右，加上24字节开销后，带宽利用率直接掉了两成多。所以做容量规划时，这个开销必须算进去。

2.2 为什么是"无状态"的

GRE是一种无状态协议，这是它和很多现代隧道协议的重要区别。所谓无状态，就是隧道端点不维护任何会话状态，收到一个包就封装转发，收到对端的包就解封装，仅此而已。这带来两个直接后果：一是实现简单、资源消耗低，一台普通设备就能扛住大量隧道；二是它无法感知对端是否存活，隧道一端挂了，另一端可能还在傻傻地发包。

这个特性决定了GRE必须搭配其他机制才能用于生产环境。我通常的做法是配合路由协议的邻居检测，或者用BFD（双向转发检测）来做快速故障感知。单纯裸跑GRE，出了问题排查起来会很痛苦，因为你看不到任何"隧道断了"的明确信号，只能从业务不通反推。

2.3 与同类技术的横向对比

很多人会问，既然有IPsec、有各种现代隧道方案，为什么还要用GRE？我把几个常见方案拉出来对比一下：

从表里能看出来，GRE的核心优势就是简单、通用、支持组播和非IP协议。它最大的短板是没有加密。所以实际项目里最常见的组合是"GRE over IPsec"——用GRE做封装，用IPsec做加密保护。这个组合既保留了GRE的灵活性，又补上了安全短板，是很多企业站点互联的经典方案。

3. 实操环境搭建：从零配通一条GRE隧道

3.1 拓扑设计与地址规划

理论讲再多不如动手配一遍。我设计一个最简但完整的实验拓扑：两台路由器R1和R2，各自连接一个私有网段，中间通过一个"公网"网段互联。目标是让两个私有网段能互相通信。

地址规划如下：

• R1公网接口：192.0.2.1/30
• R2公网接口：192.0.2.2/30
• R1隧道接口：10.255.255.1/30
• R2隧道接口：10.255.255.2/30
• R1侧私有网段：192.168.10.0/24
• R2侧私有网段：192.168.20.0/24

隧道接口的地址我特意选了10.255.255.0/30这个不常用的段，目的是和业务网段区分开，避免路由冲突。这个习惯是我踩过坑之后养成的——早期我图省事用业务网段做隧道地址，结果路由表里出现两条来源不同的相同前缀，排查了半天才发现是隧道接口惹的祸。

3.2 隧道接口配置详解

先看R1的配置。以常见的网络设备命令行风格为例：

interface Tunnel0 ip address 10.255.255.1 255.255.255.252 tunnel source 192.0.2.1 tunnel destination 192.0.2.2 tunnel mode gre ip

逐行解释一下。interface Tunnel0创建一个虚拟隧道接口，这个接口在物理上不存在，但系统会像对待真实接口一样对待它。ip address给隧道接口配地址，这个地址是隧道两端的"内部地址"，用于隧道内的通信。tunnel source指定封装后外层包的源地址，可以是接口也可以是具体IP。tunnel destination指定对端地址，这个必须是可达的。tunnel mode gre ip明确隧道模式，表示用GRE封装IP包。

R2的配置对称：

interface Tunnel0 ip address 10.255.255.2 255.255.255.252 tunnel source 192.0.2.2 tunnel destination 192.0.2.1 tunnel mode gre ip

配完这两段，隧道本身应该就起来了。但此时业务还不通，因为缺少路由。

3.3 路由配置与验证

隧道建好后，需要告诉设备"去对端私有网段的路怎么走"。有两种方式：静态路由和动态路由。

静态路由最简单，在R1上加一条：

ip route 192.168.20.0 255.255.255.0 Tunnel0

意思是去192.168.20.0/24的包，从Tunnel0发出去。R2上加对称的一条：

ip route 192.168.10.0 255.255.255.0 Tunnel0

验证的时候，我习惯按这个顺序查：先ping隧道对端地址（10.255.255.2），确认隧道本身通；再ping对端私有网段的地址，确认路由生效；最后用traceroute看路径，确认包确实走了隧道。这三步能快速定位问题出在哪一层。

提示：如果隧道对端ping不通，先检查tunnel source和destination是否可达，再检查两端tunnel mode是否一致。我遇到过一端配了gre ip另一端配了gre multipoint的情况，隧道死活起不来，查配置才发现模式不匹配。

4. 进阶玩法：GRE配合动态路由的实战价值

4.1 为什么要在隧道上跑路由协议

静态路由适合拓扑固定的场景，但一旦站点多了、链路多了，手工维护路由表就是灾难。这时候在GRE隧道上跑动态路由协议就成了刚需。OSPF、EIGRP、BGP都可以跑在GRE隧道上，其中OSPF最常见。

这里有个关键问题：为什么不能直接在公网上跑OSPF，非要套一层GRE？原因是OSPF这类协议依赖组播（224.0.0.5和224.0.0.6），而公网通常不允许组播流量通过。GRE支持组播，把OSPF的组播包封装进单播的GRE隧道里，问题就解决了。这是GRE配合动态路由的核心逻辑，也是它至今不可替代的重要原因。

4.2 OSPF over GRE配置要点

在已经建好的隧道上启用OSPF，配置大致是这样：

router ospf 1 network 10.255.255.0 0.0.0.3 area 0 network 192.168.10.0 0.0.0.255 area 0

注意隧道网段和业务网段都要宣告进OSPF。隧道网段宣告进去是为了让OSPF邻居关系能建立，业务网段宣告进去是为了让对端能学到路由。

这里有个坑要特别提醒：OSPF在隧道接口上的网络类型默认可能是点到点，也可能是广播，取决于设备实现。如果两端不一致，邻居关系会卡在EXSTART或者一直重传。我一般会显式指定：

interface Tunnel0 ip ospf network point-to-point

点到点类型不需要选举DR/BDR，收敛更快，配置也更简单，在只有两个端点的隧道场景下是最优选择。

4.3 隧道稳定性保障机制

前面说过GRE是无状态的，隧道断了它自己不知道。所以在生产环境里，必须加检测机制。我常用的方案是BFD：

interface Tunnel0 bfd interval 300 min_rx 300 multiplier 3

这表示每300毫秒发一次检测包，连续3次收不到就认为隧道故障。配合路由协议的快速收敛，整个切换过程能控制在1秒以内。实测下来，这个配置在链路抖动时表现很稳，比单纯依赖路由协议的hello超时要快得多。

另一个经验是给隧道接口配一个较高的路由协议优先级或者较低的cost，让隧道在主链路正常时作为备份，主链路故障时才启用。这种主备架构在双线接入场景里很实用。

5. 常见问题排查：那些年我踩过的GRE坑

5.1 隧道起不来的排查思路

隧道起不来是最常见的问题，我整理了一个排查顺序表：

其中MTU问题最隐蔽。GRE封装会增加24字节，如果原始包是1500字节，封装后就变成1524字节，超过了标准以太网的1500字节MTU，会被分片或者丢弃。解决办法是调整隧道接口的MTU：

interface Tunnel0 ip mtu 1476

1476 = 1500 - 24，这样封装后刚好不超过1500。同时最好开启路径MTU发现，让两端能动态协商。

5.2 隧道通了但业务不通

这种情况通常是路由问题。隧道本身通了说明封装解封装正常，但业务不通说明路由没指对。排查步骤：先看路由表里有没有去对端业务网段的路由，再看这条路由的下一跳是不是隧道接口，最后确认对端有没有回程路由。我遇到过单向通的情况，就是一端有路由另一端没有，包发过去回不来。

还有一种可能是NAT干扰。如果隧道端点设备同时在做NAT，GRE包可能会被NAT规则误伤。解决办法是在NAT配置里排除GRE流量，或者把隧道源地址设为不做NAT的接口地址。

5.3 性能问题的优化经验

GRE隧道的性能瓶颈通常不在封装本身，而在MTU和分片。我做过一组对比测试：同样传输1GB数据，MTU配置正确的情况下耗时约85秒，MTU配置不当导致频繁分片的情况下耗时超过140秒，差距接近一倍。所以MTU优化是性价比最高的性能调优手段。

另外，如果设备支持硬件加速，确认GRE封装是否走了硬件路径。有些低端设备GRE是纯软件转发，性能会差很多。这个在选型阶段就要确认清楚。

注意：GRE隧道数量多了之后，隧道端点的CPU和内存消耗会上升。我建议单台设备上的GRE隧道数量控制在50条以内，超过这个量级要考虑分布式架构或者换用其他方案。

6. 安全加固与生产环境建议

6.1 GRE over IPsec的正确姿势

前面反复强调GRE不加密，生产环境必须补上。GRE over IPsec的配置逻辑是：先配好GRE隧道，再用IPsec的保护策略匹配GRE流量。关键点是IPsec的感兴趣流要匹配GRE协议（协议号47），而不是匹配内层业务流量。

配置顺序上，我建议先确保GRE隧道单独能通，再加IPsec。这样出问题的时候能快速定位是GRE的问题还是IPsec的问题。两者一起配，排查起来就是一团乱麻。

6.2 访问控制与最小权限

隧道建好后，别忘了在隧道接口或者底层物理接口上做ACL，只放行必要的流量。我见过不少案例，隧道建好后没做任何限制，结果内网被当成了跳板。基本的做法是在隧道接口入方向做ACL，只允许业务网段互访，拒绝其他流量。

6.3 监控与告警配置

生产环境的GRE隧道必须纳入监控。我通常监控这几个指标：隧道接口的up/down状态、隧道接口的流量速率、BFD会话状态、路由协议的邻居状态。任何一个异常都触发告警。特别是BFD状态，它是隧道健康度最直接的反映。

监控工具方面，SNMP轮询是最基础的，条件允许的话用流分析工具看隧道内的流量分布，能提前发现异常流量。我有一次就是通过流量分析发现某条隧道半夜有异常大流量，查下来是一个配置错误导致路由环路，及时避免了更大影响。

7. 一些个人体会和后续扩展方向

GRE这个东西，说简单是真简单，几条命令就能配通；说复杂也真复杂，MTU、路由、安全、性能每个环节都有坑。我的体会是，把它当成一个"透明的管道"来理解最准确——它不改变数据包的内容，只负责搬运，所有关于安全、路由、QoS的事情都要在管道之外单独考虑。

后续如果想深入，有几个方向可以扩展。一是研究GRE在多云互联场景下的应用，现在很多混合云架构用GRE来做云上和云下的网络打通。二是研究GRE配合Segment Routing等新技术的组合玩法。三是关注设备厂商对GRE的硬件加速支持情况，这直接决定了大规模部署的可行性。

最后分享一个小技巧：调试GRE的时候，在两端同时开debug或者抓包，对比进出包的数量和内容，能最快定位问题出在封装侧还是解封装侧。这个笨办法我用了很多年，比任何高级工具都管用。