云中网络：GRE

什么是 GRE 协议？

GRE（Generic Routing Encapsulation，通用路由封装）*是一种网络隧道协议，由 IETF 在 RFC 2784 中定义。它的核心作用是*"封装"：将一种网络层协议的报文（如 IPv4、IPv6、OSPF 报文）完全包裹在另一种网络层协议（通常是 IPv4）中，使得原本因为路由不通、地址冲突或协议不兼容的报文，能够穿透中间的复杂网络（如同公路、公网 Internet）安全、透明地传输。

在云网络（如 AWS、阿里云、腾讯云、OpenStack 架构）中，GRE 是实现 VPC（虚拟私有云）隔离、跨地域私网互通（VPC Peering/混合云上云）以及 SD-N（软件定义网络） 流量导向的关键底层技术之一。

GRE 的报文结构与工作原理

要透彻理解 GRE，必须看清它的数据包是如何被"套娃"的。GRE 属于网络层协议（IP 协议号为 47），它没有传输层（没有 TCP/UDP 端口号的概念）。

报文结构

一个完整的 GRE 封装报文由三部分组成：

外层 IP 头部（Delivery Header）：负责在公共网络（如公网、云物理物理底层网络 Underlay）中进行路由转发。其源/目的 IP 是 GRE 隧道的两端物理接口（或 Outer IP）。
GRE 头部（GRE Header）：标识被封装的乘客协议类型，并提供序列号、密钥等控制信息（标准长度为 4 字节，根据可选字段可扩展）。
内层负载（Payload / Passenger Header）：原本要发送的原始数据包（如租户 VPC 内部的私网 IP 报文）。

GRE 头部字段详解（RFC 2890 扩展标准）

bash 复制代码

0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| |K|S| Reserved0       | Ver |         Protocol Type         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Checksum (Optional)      |       Reserved1 (Optional)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Key (Optional)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Sequence Number (Optional)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

C (Checksum Bit)：校验和标志位。为 1 时，表示存在 Checksum 字段，用于验证报文完整性。
K (Key Bit) ：密钥标志位。为 1 时，表示存在 Key 字段。在云网络多租户环境下，Key 字段非常重要，常被用作 Tenant ID（租户标识）或虚拟网络 ID，用以区分同一隧道内不同 VPC 的流量。
S (Sequence Number Bit)：序列号标志位。为 1 时，表示存在 Sequence Number 字段，用于防止报文乱序或重放攻击。
Protocol Type (协议类型) ：2 字节。指定被封装的"乘客协议"的以太网类型类型（EtherType）。例如：0x0800 代表内层是 IPv4，0x86DD 代表内层是 IPv6。这使得 GRE 具备了极强的多协议支持能力。

数据转发三部曲（工作流）

假设云端 VPC-A 内的实例 A（10.0.0.1）要向跨地域 VPC-B 内的实例 B（192.168.0.1）发送数据，中间经过公网，两端边界各有一个支持 GRE 的云网关（GW-A: 202.1.1.1，GW-B: 211.2.2.2）。

入隧道（Encapsulation - 封装）

实例 A 发出原始报文：Src: 10.0.0.1 -> Dst: 192.168.0.1。
报文到达云网关 GW-A，网关查找路由表，发现去往 192.168.0.0/24 的下一跳是 GRE 隧道接口（Tunnel 0）。
GW-A 为报文打上 GRE 头部（设置协议类型为 0x0800），再在外面套上外层 IP 头部：Src: 202.1.1.1 -> Dst: 211.2.2.2。

中间传输（Transit - 传输）

封装后的报文进入中间的公网或 Underlay 物理网。
中间的所有路由器只看外层 IP 头部 （202.1.1.1 -> 211.2.2.2），将其视作普通的公网流量进行标准逐跳转发。中间设备完全不知道、也不需要知道内层私网 IP 的存在。

出隧道（Decapsulation - 解封装）

报文到达目的云网关 GW-B。GW-B 检查外层 Dst IP 发现是发送给自己的，且 IP 协议号为 47（GRE）。
GW-B 剥离外层 IP 头部和 GRE 头部，露出原始报文：Src: 10.0.0.1 -> Dst: 192.168.0.1。
GW-B 查找本地 VPC-B 的内层路由表，将原始报文精准送达实例 B。

云中网络（Cloud Networking）为什么需要 GRE？

在现代云计算（IaaS）的虚拟化网络中，GRE 是构建 Overlay 网络（叠加网络）的功臣。虽然现在 VXLAN 大行其道，但 GRE 依然占有不可替代的地位。

1. 实现异构协议穿透与"孤岛"互通

在企业混合云场景中，企业本地 IDC 可能还在运行一些非 IP 协议或特定的多播协议（如 OSPF 路由协议、组播视频流）。云公网环境通常只支持单播的 IPv4/IPv6。

解决痛点：GRE 可以封装多播/组播报文（而纯 IPsec VPN 默认不支持动态路由协议的组播）。利用 GRE 隧道，企业可以在云端与本地 IDC 之间顺畅运行 OSPF、BGP，实现路由自动学习。

2. 多租户网络隔离与地址复用（Overlapping IP）

在公有云中，不同的租户可能都喜欢使用 192.168.1.0/24 这个私网网段。如果直接在物理网转发，会导致严重的路由冲突。

解决痛点 ：通过 GRE 封装，将不同租户的重叠私网报文包裹在外层唯一的物理网（Underlay）IP 中。再利用 GRE Header 中的 Key 字段（Tenant ID） 来打上租户标签。当报文到达宿主机或网关时，网络设备根据 Key 字段就能准确判断该报文属于哪个 VPC，完美解决地址冲突。

3. SD-N 集中化流量调度（Service Chaining）

在云数据中心内部，当需要把流量强制引导到某些安全设备（如 Web 应用防火墙 WAF、深度包检测 DPI、流控设备）时。

解决痛点：SDN 控制器可以通过下发流表，在计算节点（Compute Node）上将特定流量通过 GRE 隧道直接"点对点"投递到安全网关，而不需要修改中间物理交换机的配置。

GRE 的核心技术缺陷与应对方案

GRE 并不是万能的，它是一把双刃剑，在具备强大通用性的同时，也暴露出明显的死穴：

1. 安全性完全缺失（无加密）

缺陷：GRE 协议本身没有任何加密机制 。这意味着被封装的内层数据、私网 IP 甚至应用层数据，在公网传输时全部是明文。黑客如果通过光纤监听或路由劫持抓取到外层 GRE 包，可以轻易将其解开并窃取隐私。
云端方案：GRE over IPsec 由于 GRE 具备"支持组播/动态路由"的优势，而 IPsec 具备"高强度加密认证"的优势，云网络通常将两者结合。
- 做法：先用 GRE 封装原始数据包（解决路由与组播问题），再用 IPsec 对整个 GRE 报文进行加密（解决安全问题）。这在混合云连接（VPC 到本地 IDC）中是极其标准的方案。

2. MTU 与 MSS 导致的报文分片问题（性能杀手）

这是日常运维和云网络排查中最常遇到的巨坑。

缺陷分析 ：标准的以太网 MTU（最大传输单元）是 1500 字节。当一个 1500 字节的原始 IP 报文到达 GRE 网关时，网关需要为其塞入：
- GRE 头部：4 ~ 12 字节
- 外层 IP 头部：20 字节
这导致封装后的总长度超出了 1500 字节（通常变成 1524 字节）。如果中间的物理网络设备（如运营商路由器）不支持大于 1500 的 MTU（没有开启 Jumbo Frame），并且报文设置了 DF（Don't Fragment，不可分片）标志，该报文就会被直接丢弃 ，并返回 ICMP 错误。如果允许分片，网关和接收端就需要消耗大量 CPU 资源进行分片与重组，导致网络吞吐量暴跌、延迟飙升、大文件传输卡死。
云端方案：
1. 调整内层终端的 MSS（Maximum Segment Size） ：在云网关上强制修改 TCP 握手时的 MSS 值（通常将其限制在 1400 或 1360 字节以下）。这样终端在发包时就会主动留出富余空间，避免外层封装后超过 1500。
2. 物理网开启巨型帧（Jumbo Frames） ：在云服务商控制的内部物理网络中，将交换机和宿主机的物理 MTU 统一调大至 9000 字节，彻底消除 Overlay 封装带来的溢出问题。

GRE 与其他常见隧道协议（VXLAN、IPsec）的横向对比

在现代云网络架构中，GRE 时常拿来与 VXLAN 和 IPsec 放在一起比较。它们各司其职，其核心差异如下表所示：

特性 / 协议	GRE (Generic Routing Encapsulation)	VXLAN (Virtual Extensible LAN)	IPsec (IP Security)
工作OSI层级	网络层（Layer 3，IP 协议号 47）	传输层之上（Layer 4，UDP 封装，端口 4789）	网络层（Layer 3，AH/ESP 协议）
封装对象	Layer 3 报文（IPv4/IPv6 等）	Layer 2 以太网帧（包含 MAC 地址）	Layer 3 IP 报文
多播/组播支持	支持（完美运行 OSPF/BGP）	支持（通过底层组播或头端复制）	不支持（只能传单播）
数据加密	无（明文传输）	无（明文传输）	有（3DES, AES 强加密）
网络规模/容量	依赖 Key 字段（32位），理论空间大	24位 VNI，支持 1600万+ 虚拟网络	不适用（点对点安全隧道）
硬件负载均衡	差。因为没有 UDP 端口，传统交换机无法基于四元组哈希，易导致单链路拥堵。	极好。外层采用随机 UDP 源端口，物理交换机可通过 L4 完美实施 ECMP 负载均衡。	较差（多依赖 SPI 识别）。
典型云场景	混合云上云（GRE over IPsec）、跨地域 VPC 轻量互通。	数据中心内部（SDN 核心）、大二层虚拟机迁移、多租户隔离。	安全跨境/跨地域互联、合规要求的安全通道。

总结与技术演进

GRE 是一个高效、结构简单、通用性极强的"管道"协议。它在云网络发展的前期（如早期 OpenStack 架构）承担了多租户 Overlay 网络的核心角色。通过在 IP 报文中套入 GRE 头，云服务商能够轻松越过物理网络的限制，编织出一张张解耦的虚拟私有网。

为什么现在的公有云内部更倾向于使用 VXLAN / Geneve，而不是 GRE？ 根本原因在于流控与性能（ECMP 负载均衡） 。在大规模数据中心里，成千上万的链路需要做流量负载均衡。传统的物理交换机依靠查看"TCP/UDP 端口号"来进行 Hash 分流。由于 GRE 没有 UDP 端口，所有经过 GRE 隧道的报文在交换机看来"长得完全一样"（都是 IP 协议 47），导致极易集中在某一条物理链路上，引发长尾延迟和局部拥堵。而 VXLAN 因为在外层包裹了 UDP 头部，完美迎合了现代硬件交换机的高速转发特性。

然而，在云外边界（如混合云连接、跨厂商多云互联、企业异构网络对接），由于需要兼容各种老旧路由设备、需要运行动态路由协议，GRE 凭借其"包容一切网络层协议"的特性，搭配 IPsec 安全盾牌，依然是不可动摇的一线核心技术。