网络运输层之(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头部字段解释如下：
字段长度描述C1 bit校验和验证。如果该位为1，表示GRE头插入了校验和（Checksum）字段。如果该位为0，表示GRE头不包含校验和字段。K1 bit关键字。如果该位为1，表示GRE头插入了关键字（Key）字段。如果该位为0，表示GRE头不包含关键字字段。Recursion3 bits用来表示GRE报文被封装的层数。完成一次GRE封装后将该字段加1，如果封装层数大于3，则丢弃该报文。该字段的作用是防止报文被无限次的封装。Flags5 bits预留字段。当前必须设为0。Version3 bits版本字段，必须置为0。Version为1是使用在RFC2637的PPTP中。Protocol Type16 bits乘客协议的协议类型，比如0x0800表示IPv4，0x86DD表示IPv6。Checksum16 bits对GRE头及其负载的校验和字段。Key31 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。Flags5保留，必须为0。Ver (Version)3GRE版本，当前必须为0。Protocol Type16封装在GRE中的协议类型，如0x0800表示IPv4。Checksum (可选)16GRE头部及payload的校验和。Offset (可选)16GRE头部后附加字段的偏移量。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:
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:
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:
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:
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
也信美人终作土，不堪幽梦太匆匆......
如果这篇文章为您带来了帮助或启发，不妨点个赞和关注，再加上一个小小的收藏⭐！
(｡◕‿◕｡)感谢您的阅读与支持~~~
相关链接
您阅读本篇文章共花了：
发表评论