网络运输层之(3)GRE协议
Author: Once Day Date: 2024年4月8日
一位热衷于Linux学习和开发的菜鸟，试图谱写一场冒险之旅，也许终点只是一场白日梦…
漫漫长路，有人对你微笑过嘛…
全系列文档可参考专栏：通信网络技术_Once-Day的博客-CSDN博客。
参考文章:
- 什么是 GRE 隧道？| GRE 协议如何工作 | Cloudflare (cloudflare-cn.com)
- GRE技术介绍-新华三集团-H3C
- 浅析GRE协议（通用路由封装协议）_gre协商过程-CSDN博客
- 什么是通用路由封装（GRE）？ - 华为 (huawei.com)
- 通用路由封装协议GRE 是什么？ - 知乎 (zhihu.com)
- 通用路由封装协议GRE - 杨灏 - 博客园 (cnblogs.com)
- GRE VPN 技术原理笔记分享-云社区-华为云 (huaweicloud.com)
- 通用路由封装 - 维基百科，自由的百科全书 (wikipedia.org)
- GRE Keepalive如何工作 - Cisco
- 解决 GRE 和 IPsec 中的 IPv4 分段、MTU、MSS 和 PMTUD 问题 - Cisco
- 了解GRE隧道Keepalive - Cisco
- 配置 GRETAP 隧道来通过 IPv4 传输以太网帧 Red Hat Enterprise Linux 8 | Red Hat Customer
Portal- 虚拟网络gretap创建实例与流程分析-CSDN博客
- Linux下ip link创建gre隧道，为什么会连带创建gretap0和gre0 ？ - 知乎 (zhihu.com)
文章目录
- 网络运输层之(3)GRE协议
- 1. 概述
- 1.1 GRE协议介绍
- 1.2 GRE使用场景
- 1.3 GRE和VPN/IPsec/L2TP/PPTP之间的关系
- 1.4 GRETAP介绍
- 1.5 相关RFC文档
- 2. 报文格式
- 2.1 GRE报文格式
- 2.2 旧GRE报文格式(RFC1701)区别
- 2.3 GRE隧道对MTU和MSS的影响
- 3. 工作流程
- 3.1 报文封装和解封装流程
- 3.2 GRE隧道keepalive检测
- 4. Linux Ubuntu配置GRE接口
- 4.1 Linux内核支持GRE选项配置
- 4.2 Linux上配置GRE接口
- 5. 总结
1. 概述
1.1 GRE协议介绍
GRE通用路由封装协议（Generic Rrouting Encapsulation）是一种网络协议，主要用于封装不同网络协议的数据包。
- 这种技术允许数据包在一个异种网络中被传输，即使这些网络原生不支持正在传输的数据包协议。
- GRE支持对组播报文的封装，这是一些其他隧道技术（如IPsec）无法做到的。
- GRE可以运行动态路由协议，允许异地设备之间动态地交换路由信息，这对于维护大规模分布式网络的连通性至关重要。
- GRE本身不提供加密或其他安全保护，因而通常不会单独使用于需要高安全性的环境。
例如，如果一个企业需要在使用不同版本互联网协议（如IPv6与IPv4）的两个局域网（LAN）之间建立连接，而连接这两个网的中间网络仅支持IPv4，那么GRE可以将IPv6的数据包封装在IPv4数据包中进行传输。这样，IPv6的数据包就可以“搭乘”IPv4网络，绕过协议不兼容的问题。
GRE协议的优缺点如下表所示:
| 优点 | 缺点 |
|---|---|
| 基于IP协议，可以在互联网上使用 | 隧道模式下封装开销较大，影响效率 |
| 支持点对点和点对多点通信 | 不支持组播和广播 |
| 支持多种承载网络，包括IP、MPLS等 | 配置较为复杂，对网络管理要求较高 |
| 采用隧道技术，能够穿越NAT和防火墙 | 缺乏流量控制和拥塞控制机制 |
| 路由可扩展性好，支持动态路由协议 | 隧道集中终结易形成单点故障和性能瓶颈 |
1.2 GRE使用场景
GRE 协议有三种主要的应用场景。
（1）多协议本地网络通过单一协议骨干网实现互联。
- 需求：不同协议的本地网络（如 IP、IPX、AppleTalk 等）需要通过单一协议（通常是 IP）的骨干网进行互联。
- 解决方案：在本地网络的边界路由器上启用 GRE，将不同协议的数据帧封装在 GRE 隧道内，通过骨干网传输。在另一端的边界路由器上解封装，恢复原始的数据帧并转发到目标网络。这样就实现了不同协议网络之间的透明互联。
（2）扩大步数受限网络（如 RIP）的范围。
- 需求：由于路由协议（如 RIP）的步数限制，导致网络规模受到限制，无法实现大规模网络的互联。
- 解决方案：在需要互联的网络之间建立 GRE 隧道，将 RIP 路由更新报文封装在 GRE 隧道内传输。由于 GRE 隧道本身不增加路由步数，因此可以突破原有的步数限制，实现大规模网络的互联。同时，通过在隧道上配置静态路由或动态路由协议，可以实现隧道两端网络的路由学习和转发。
（3）与 IPsec 结合使用，提供安全的 VPN 服务。
- 需求：远程接入用户或分支机构需要通过公共网络（如互联网）安全地接入总部网络，并保护数据的机密性和完整性。
- 解决方案：在远程接入设备（如 PC、路由器）和总部网络的 VPN 网关之间建立 GRE over IPsec 隧道。首先，在隧道两端之间协商 IPsec 安全联盟（SA），对 GRE 隧道的数据进行加密和认证。然后，将需要传输的数据封装在 GRE 隧道内，再将 GRE 数据包封装在 IPsec 隧道内进行传输。这样就实现了数据在公共网络上的安全传输，防止了窃听和篡改。
GRE协议虽然传输的流量是不加密的，但可以通过结合IPSec技术，先建立GRE隧道对报文进行GRE封装，然后再建立IPSec隧道对报文进行加密，以保证报文传输的完整性和私密性。下面是一种常见的GRE使用拓扑图:
1.3 GRE和VPN/IPsec/L2TP/PPTP之间的关系
VPN是通过公共网络建立的虚拟专用通信网络的统称，用于连接远程用户、公司分支机构到公司内部网。主要有以下几种类型:
- VPDN(Virtual Private Dial Network)：通过PSTN/ISDN等拨号方式接入，主要使用L2TP、PPTP等隧道协议实现。
- VPRN(Virtual Private Routing Network)：通过IP网络构建，使用GRE或MPLS实现网络层的VPN。
- VPWS(Virtual Private Wire Service)：通过IP网络模拟传统租用线，提供点到点二层VPN。
- VPLS(Virtual Private LAN Service)：多点接入的二层VPN，在IP网上延伸局域网。
GRE、L2TP、IPsec、PPTP都是VPN常用的隧道技术，用于在公网上建立点到点的逻辑通道，它们的区别在于:
- GRE是通用路由封装协议，用于在两个不同协议的网络间创建未加密的隧道，常与IPsec结合使用。
- L2TP二层隧道协议，支持认证，多用于远程拨号VPN接入，比PPTP安全性更高。
- IPsec在IP层对数据进行加密认证，确保安全性，但只能对单播不能对组播加密。
- PPTP点到点隧道协议，是早期的VPN隧道协议，安全性相对较低。
在典型VPN组网中，GRE/IPsec常用于骨干网的隧道构建，L2TP/PPTP用于接入层用户拨号接入，通过结合使用来构建全面的VPN网络。
例如，GRE和L2TP都是一种隧道协议，但侧重很不同，如下表所示：
| GRE协议 | L2TP协议 | |
|---|---|---|
| 协议类别 | 网络协议 | 用户接入协议 |
| 关注领域 | 只关注网络端的隧道连通 | 除网络连通外还涉及到用户侧的接入 |
| 报文 | 报文结构比较简单，仅包含GRE头和隧道负载 | 报文结构复杂，隧道模式下需要封装PPP协议， 网络模式下需要封装以太网帧 |
1.4 GRETAP介绍
GRETAP (Generic Routing Encapsulation Transparent Aggregation Protocol) 是一种网络协议，用于在以太网链路上透明地聚合和转发数据包。
GRETAP则是GRE的一种变体，专门用于封装以太网帧，主要特点和应用如下:
-
基于GRE (Generic Routing Encapsulation) 隧道技术，可以在两个以太网交换机之间建立点对点的隧道连接。
-
通过GRETAP隧道，可以将一个以太网网段扩展到另一个物理位置，实现二层网络的扩展和互联。
-
支持多种上层协议，如IP、IPX、AppleTalk等，具有很好的兼容性。
-
提供数据封装和解封装功能，在隧道入口将以太网帧封装在GRE报文中，在隧道出口解封装并还原原始帧。
-
采用类似于VLAN的标签(Tunnel ID)来标识不同的GRETAP隧道，支持多条隧道并行传输。
-
主要应用场景包括:连接物理位置分散的局域网、实现数据中心或企业网络二层互联、构建overlay网络等。
-
与VXLAN、NVGRE等其他隧道协议相比，GRETAP的优势是配置简单、兼容性好，但缺点是隧道数量受限，扩展性不如VXLAN等协议。
GRETAP在某些特定场合下为以太网扩展和互联提供了一种灵活的解决方案，不过随着大二层技术的发展，越来越多的场景开始采用VXLAN等新型隧道协议。
1.5 相关RFC文档
下面是与GRE协议相关的主要RFC文档列表：
- RFC 1701 - Generic Routing Encapsulation (GRE)，定义GRE的基本封装格式和协议字段。
- RFC 1702 - Generic Routing Encapsulation over IPv4 networks，描述如何在IPv4网络上应用GRE封装进行数据传输。
- RFC 2784 - Generic Routing Encapsulation (GRE)，对GRE进行了扩展和修订，成为新的GRE协议标准规范。
- RFC 2890 - Key and Sequence Number Extensions to GRE，定义GRE的序号和密钥扩展，用于实现更可靠和安全的GRE隧道传输。
- RFC 7676 - IPv6 Support for Generic Routing Encapsulation (GRE)，将GRE扩展到IPv6，定义在IPv6网络上应用GRE的封装格式和传输方式。
- RFC 8086 - GRE-in-UDP Encapsulation，指定将GRE封装在UDP内的方法，解决一些网络对GRE报文的过滤和阻塞问题。
2. 报文格式
2.1 GRE报文格式
GRE报文格式(RFC 2784)如下图所示:
GRE报文分为三个组成部分，每层对应一个协议概念，如下所示：
-
传输协议头部(Transport Protocol或者Delivery Protocol)，即隧道外部协议，通常是IP报文头部。
-
封装协议头部(Encapsulation Protocol)，这里就是GRE报文头部，也称为运载协议(Carrier Protocol)
-
净荷(载荷，Payload Packet)，封装前的报文称为净荷，封装前的报文协议称为乘客协议(Passenger Protocol)。
GRE头部字段解释如下：
| 字段 | 长度 | 描述 |
|---|---|---|
| C | 1 bit | 校验和验证。 如果该位为1，表示GRE头插入了校验和（Checksum）字段。 如果该位为0，表示GRE头不包含校验和字段。 |
| K | 1 bit | 关键字。 如果该位为1，表示GRE头插入了关键字（Key）字段。 如果该位为0，表示GRE头不包含关键字字段。 |
| Recursion | 3 bits | 用来表示GRE报文被封装的层数。 完成一次GRE封装后将该字段加1，如果封装层数大于3，则丢弃该报文。 该字段的作用是防止报文被无限次的封装。 |
| Flags | 5 bits | 预留字段。当前必须设为0。 |
| Version | 3 bits | 版本字段，必须置为0。Version为1是使用在RFC2637的PPTP中。 |
| Protocol Type | 16 bits | 乘客协议的协议类型，比如0x0800表示IPv4，0x86DD表示IPv6。 |
| Checksum | 16 bits | 对GRE头及其负载的校验和字段。 |
| Key | 31 bits | 关键字字段，隧道接收端用于对收到的报文进行验证。 |
2.2 旧GRE报文格式(RFC1701)区别
RFC2784移除了一些旧GRE协议的字段，如下所示：
- Routing Present ®位
- Strict Source Route (S)位
- 递归控制字段
- 确认号字段
RFC 1701规定的GRE头部格式如下:
RFC 1701的GRE头部字段描述如下:
| 字段名 | 位数 | 描述 |
|---|---|---|
| C (Checksum Present) | 1 | 校验和标志位。 1: Checksum和Offset字段存在 0: Checksum和Offset字段不存在 |
| R (Routing Present) | 1 | 路由标志位。 1: Routing字段存在 0: Routing字段不存在 |
| K (Key Present) | 1 | 密钥标志位。 1: Key字段存在 0: Key字段不存在 |
| S (Sequence Number Present) | 1 | 序列号同步标志位。 1: Sequence Number字段存在 0: Sequence Number字段不存在 |
| s (Strict Source Route) | 1 | 严格源路由标志位。 1: 严格源路由 0: 宽松源路由 |
| Recur (Recursion Control) | 3 | 控制GRE递归封装的最大层数，0-7。通常为0。 |
| Flags | 5 | 保留，必须为0。 |
| Ver (Version) | 3 | GRE版本，当前必须为0。 |
| Protocol Type | 16 | 封装在GRE中的协议类型，如0x0800表示IPv4。 |
| Checksum (可选) | 16 | GRE头部及payload的校验和。 |
| Offset (可选) | 16 | GRE头部后附加字段的偏移量。 |
| Key (可选) | 32 | 用于身份验证的密钥。 |
| Sequence Number (可选) | 32 | 序列号,用于报文重组和去重。 |
| Routing (可选) | 变长 | 源路由列表，支持严格/宽松源路由。 |
相比RFC 2784 ，RFC 1701的GRE提供了更多特性，如:
- 支持源路由选择(R/S位及Routing字段)
- 支持递归封装(Recur字段)
- 支持认证/加密(Key字段)
- 支持排序和去重(Sequence Number)
- 支持校验(Checksum)
这些附加特性也增加了GRE的复杂度和开销，所以在后续的RFC 2784中简化并移除了一些不常用的特性。
2.3 GRE隧道对MTU和MSS的影响
MTU和MSS都是用来限制通过网络传输的数据包最大长度的度量单位：
- MTU测量数据包的总大小，包括报文头部(从Ether帧的负载开始计算，比如IP报文头部)。超过 MTU 值的数据包将被分成几段或分解成较小的数据包，使之适合在网络上传输。
- MSS仅测量有效负载，比如TCP协议的负载，这个会去掉IP和TCP头部的开销。
GRE隧道协议会在数据包原有大小基础上增加几个字节，在数据包的MSS和MTU设置中必须考虑这个因素。
如果MTU设为1500 字节，MSS设为1460 字节，则增加GRE 12字节头部后将导致数据包超过MTU限值：
1460 字节 [有效负载] + 20 字节 [TCP 标头] + 20 字节 [IP 标头] + 12 字节 [GRE 标头+ IP 标头] = 1512字节
因此，数据包将被分段，减慢数据包传递，并增加算力开销，因为超出 MTU 的数据包必须分解然后重新组合。
通过减少 MSS 长度以包含 GRE 标头，可以避免这种情况。
如果将MSS设置为1448而不是1460，那么加上GRE 12字节头部后的数据包不会超过MTU 值 1500：
1448 字节 [有效负载] + 20 字节 [TCP 标头] + 20 字节 [IP 标头] + 12 字节 [GRE 标头+ IP 标头] = 1500 字节
尽管避免了分段，但结果却是有效载荷变小，这意味着需要额外的数据包来传递数据，并增加毫秒级的数据传输延迟。不过，使用 GRE 比不使用 GRE 可以使这些数据包选择更快的网络路径，进而可以弥补损失的时间。
3. 工作流程
3.1 报文封装和解封装流程
GRE报文传输流程示意图如下:
上述流程以一个Ping Request报文为例子，介绍了如何从10.10.4.0/24网络里通过Gre0和Gre1这对GRE隧道到达10.10.6.0/24网络。
- 主机A创建ICMP REQUEST报文，源IP为主机A的IP(
10.10.4.4)，目的IP为主机B的IP(10.10.6.6)。 - 主机A将此ICMP报文发送给网络A的网关设备(Device A)。
- 网关设备Device A从物理接口(Eth0)收到这个ICMP报文后，通过路由查找，发现其下一跳地址是Gre0接口(隧道接口)。
- 报文进入网关设备Device A的Gre0接口，开始创建GRE头部:
- Protocol Type字段设为0x0800，表示封装的是IPv4报文
- 其他字段如Checksum、Key、Sequence Number等根据配置添加。
- GRE头部添加在原始的ICMP报文之前。
- Gre0接口给报文创建新的IP头部:
- 源IP为Gre0接口的local IP(本端地址)。
- 目的IP为Gre0接口的remote IP(对端地址)。
- 协议字段设为47，表示这是一个GRE封装报文。
- 新的IP头部添加在GRE头部之前。
- 网关设备Device A通过路由查找(查找
6.6.6.7的下一跳地址)，将此GRE over IP报文从相应的物理接口(Eth0)发送出去。 - GRE报文通过公网到达另一端网关设备Device B。
- 网关设备Device B剥离外层IP头，根据协议字段47判断这是一个GRE报文，然后送入Gre1隧道接口里解封装处理。
- 网关设备Device B的Gre1隧道接口会剥离报文的GRE头部，根据Protocol Type 0x0800判断内层是一个IPv4报文。
- 现在Device B得到了原始的ICMP REQUEST报文，它根据报文的目的IP(查找
10.10.6.6的下一跳)，将其转发给Host B。 - Host B收到ICMP REQUEST报文，并回复ICMP REPLY报文。ICMP REPLY报文将再次通过GRE隧道返回给Host A，流程与请求方向类似。
整个过程可以概括为：原始IP报文被添加上GRE头部、新的IP头部，形成GRE over IP的封装报文，通过隧道传输。隧道出口解封装，得到原始IP报文，再转发给目的主机。
需要注意，Gre接口需要配置路由条目才能将流量导入到接口中，路由的下一跳地址为Gre接口的私网地址，而不是local/remote等公网地址。
3.2 GRE隧道keepalive检测
通用路由封装（GRE）的Keepalive功能是一种网络协议机制，旨在确保网络连接的持续性和可靠性。在GRE隧道中，Keepalive机制通过定期发送探测消息来检测和维持隧道两端的活动状态。
- 避免形成数据黑洞，Keepalive检测功能用于在任意时刻检测隧道链路是否处于Keepalive状态，即检测隧道对端是否可达。如果对端不可达，隧道连接就会及时关闭，避免形成数据空洞。
- 定期探测，Keepalive检测功能开启后，GRE隧道本端会定期(例如，每次间隔5秒)向对端发送Keepalive探测报文。若对端可达，则本端会收到对端的回应报文，若对端不可达，则收不到对端的回应报文。
- 支持单端启用，如果在隧道一端配置了Keepalive功能，无论对端是否配置Keepalive，配置的Keepalive功能在该端都生效；隧道对端收到Keepalive探测报文，无论是否配置Keepalive，都会给源端发送一个回应报文。
GRE的keepalive探测包构成如下:
- 内层IP头：源IP为隧道目的端IP，目的IP为隧道源端IP。
- 内层GRE头，协议类型PT字段为0。
- 外层IP头和GRE头，封装原始的keepalive包，用于在公网上传输。
隧道对端接收到keepalive包后，会解封装，检查内层GRE头的PT字段。若为0，则识别为keepalive包，并丢弃它，同时重置keepalive计数器。
4. Linux Ubuntu配置GRE接口
4.1 Linux内核支持GRE选项配置
Linux 内核支持GRE接口需要启用以下相关配置。
| 功能 | 配置宏 | 描述 |
|---|---|---|
| GRE 隧道支持 | CONFIG_NET_IPGRE | 启用通用 GRE 隧道支持,是使用 GRE 的基础。 |
| GRE 隧道设备支持 | CONFIG_NET_IPGRE_DEMUX | 启用此选项可以支持多个 GRE 隧道设备，每个设备可以单独配置。 |
| GRE 广播和组播支持(可选) | CONFIG_NET_IPGRE_BROADCAST | 启用 GRE 隧道的广播和组播支持,允许 GRE 隧道传输广播和组播数据包。 |
| Netfilter 连接跟踪支持(可选) | CONFIG_NF_CT_PROTO_GRE | 如果需要对 GRE 数据包进行连接跟踪和状态检查(如防火墙规则)，则需要启用此选项。 |
| GRE IPv6报文支持 | CONFIG_IPV6_GRE | 启用GRE over IPv6支持。 |
| IP 隧道驱动程序(可选) | CONFIG_NET_IPIP | 虽然此选项主要用于 IPIP 隧道，但某些 GRE 实现可能也依赖于它。 |
在 Linux 内核的 make menuconfig 配置界面中，这些选项通常位于以下位置:
Networking support --->
Networking options --->
[*] IP: GRE demultiplexer
[*] IP: broadcast GRE over IP
-*- The IPv6 protocol --->
[*] IPv6: GRE demultiplexer
[*] IPv6: broadcast GRE over IPv6
Device Drivers --->
[*] Network device support --->
<*> IP: GRE over IP
<*> IPv6: GRE over IPv6
<*> IP: IPIP tunnel
Netfilter Configuration --->
[*] IP virtual reassembly in netfilter
[M] "conntrack" connection tracking match support
[M] "conntrack" connection tracking match support for GRE
在实际运行的ubuntu服务器上，可以检查/boot目录下配置文件，如下:
onceday@ubuntu1:~$ cat /boot/config-5.15.0-100-generic |grep GRE
CONFIG_NET_IPGRE_DEMUX=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IPV6_GRE=m
CONFIG_NF_CT_PROTO_GRE=y
CONFIG_OPENVSWITCH_GRE=m
在这台ubuntu设备上，可以看到相关的GRE功能Linux内核都已经支持了。
4.2 Linux上配置GRE接口
测试和验证GRE功能需要两台Linux服务器，这里使用VirtualBox的虚拟机来搭建环境(3.1节报文封装和解封装流程所示拓扑)。
(1) 在服务器ubuntu1和ubuntu2上配置物理接口enp0s9(或者其他接口)的地址，两者之间要能Ping通(内部网络或者网卡桥接)。
# ubuntu1配置6.6.6.6/24地址
onceday@ubuntu1:~$ ip link set enp0s9 up
onceday@ubuntu1:~$ ip addr add 6.6.6.6/24 dev enp0s9
# ubuntu2配置6.6.6.7/24地址
onceday@ubuntu1:~$ ip link set enp0s9 up
onceday@ubuntu2:~$ ip addr add 6.6.6.7/24 dev enp0s9
# 两者之间可以Ping通
onceday@ubuntu1:~$ ping 6.6.6.7
PING 6.6.6.7 (6.6.6.7) 56(84) bytes of data.
64 bytes from 6.6.6.7: icmp_seq=1 ttl=64 time=0.807 ms
(2) 在两个服务器上分别配置GRE虚拟子接口，local和remote就是enp0s9接口的IP地址。
-
创建GRE隧道接口，gre1是隧道接口名称，remote指定对端隧道IP，local指定本端隧道IP，ttl设置封装包的TTL。
ip tunnel add gre1 mode gre remote 6.6.6.7 local 6.6.6.6 ttl 255 -
配置隧道接口的IP地址。
ip addr add 10.10.5.1/30 dev gre1 -
启用隧道接口。
ip link set gre1 up -
配置路由，将相应网段的流量引导到GRE隧道上。
ip route add 10.10.0.0/16 dev gre1
服务器ubuntu1配置操作输出信息如下:
onceday@ubuntu1:~$ ip tunnel add gre1 mode gre remote 6.6.6.7 local 6.6.6.6 ttl 255
onceday@ubuntu1:~$ ip addr add 10.10.5.1/30 dev gre1
onceday@ubuntu1:~$ ip link set gre1 up
onceday@ubuntu1:~$ ip route add 10.10.0.0/16 dev gre1
onceday@ubuntu1:~$ ip addr
4: enp0s9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 08:00:27:93:6f:37 brd ff:ff:ff:ff:ff:ff
inet 6.6.6.6/24 scope global enp0s9
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fe93:6f37/64 scope link
valid_lft forever preferred_lft forever
8: gre1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN group default qlen 1000
link/gre 6.6.6.6 peer 6.6.6.7
inet 10.10.5.1/30 scope global gre1
valid_lft forever preferred_lft forever
inet6 fe80::606:606/64 scope link
valid_lft forever preferred_lft forever
最终可以看到gre1接口上面有接口IP(10.10.5.1)，这个IP用于流量引流的下一跳地址。
同理完成ubuntu2的配置操作：
onceday@ubuntu2:~$ ip tunnel add gre1 mode gre remote 6.6.6.6 local 6.6.6.7 ttl 255
onceday@ubuntu2:~$ ip addr add 10.10.5.2/30 dev gre1
onceday@ubuntu2:~$ ip link set gre1 up
onceday@ubuntu2:~$ ip route add 10.10.0.0/16 dev gre1
onceday@ubuntu2:~$ ip addr
3: enp0s9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 08:00:27:56:7b:06 brd ff:ff:ff:ff:ff:ff
inet 6.6.6.7/24 scope global enp0s9
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fe56:7b06/64 scope link
valid_lft forever preferred_lft forever
7: gre1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN group default qlen 1000
link/gre 6.6.6.7 peer 6.6.6.6
inet 10.10.5.2/30 scope global gre1
valid_lft forever preferred_lft forever
inet6 fe80::606:607/64 scope link
valid_lft forever preferred_lft forever
完成以上配置之后，可以尝试进行ping操作，并且用TCP抓包看看GRE隧道报文。
onceday@ubuntu1:~$ ping 10.10.5.2
PING 10.10.5.2 (10.10.5.2) 56(84) bytes of data.
64 bytes from 10.10.5.2: icmp_seq=1 ttl=64 time=0.810 ms
64 bytes from 10.10.5.2: icmp_seq=2 ttl=64 time=0.991 ms
......
下面是对enp0s9接口抓包，可以看到外层报文和内层报文交互情况：
onceday@ubuntu1:~$ sudo tcpdump -vv -i enp0s9
tcpdump: listening on enp0s9, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:19:29.285962 IP (tos 0x0, ttl 255, id 4763, offset 0, flags [DF], proto GRE (47), length 108)
6.6.6.6 > 6.6.6.7: GREv0, Flags [none], length 88
IP (tos 0x0, ttl 64, id 1897, offset 0, flags [DF], proto ICMP (1), length 84)
ubuntu1 > 10.10.5.2: ICMP echo request, id 7, seq 1, length 64
17:19:29.286757 IP (tos 0x0, ttl 255, id 10776, offset 0, flags [DF], proto GRE (47), length 108)
6.6.6.7 > 6.6.6.6: GREv0, Flags [none], length 88
IP (tos 0x0, ttl 64, id 65215, offset 0, flags [none], proto ICMP (1), length 84)
10.10.5.2 > ubuntu1: ICMP echo reply, id 7, seq 1, length 64
到此，GRE隧道接口测试就完成了，操作很简单，重点是理解GRE报文的传输流程。
5. 总结
GRE协议比较简单，但是具体的报文传输流程和路由寻路就比较难以理解。对于终端，需要设置一个GRE接口，同时配置Local IP和remote IP，这两个IP用于封装GRE报文的外层IP头。
此外，GRE接口本身还需要一个接口IP，注意这个接口IP不能直接作为外部设备的下一跳(NextHop)，因为这是一个三层虚接口，没有MAC等链路层地址，所有是无法作为邻居表项存在的。
在终端上，需要对应的物理接口IP完成外部路由过程，而GRE接口IP，主要用于将物理接口的入流量(即准备进行封装的报文)导入到GRE接口中。
对于出流量(即准备进行解封的报文)，则不需要依赖路由导入，而是在解析IP协议时就可以分流到GRE模块中处理。所以GRE两个方向的流量路径是不一致的，这个一开始可能不好理解，建议多多手动实践来理解。
Once Day
也信美人终作土，不堪幽梦太匆匆......
如果这篇文章为您带来了帮助或启发，不妨点个赞👍和关注，再加上一个小小的收藏⭐！
(｡◕‿◕｡)感谢您的阅读与支持~~~
