网络运输层之(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 IPv6Device Drivers --->[*] Network device support ---><*> IP: GRE over IP<*> IPv6: GRE over IPv6<*> IP: IPIP tunnelNetfilter 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 1000link/ether 08:00:27:93:6f:37 brd ff:ff:ff:ff:ff:ffinet 6.6.6.6/24 scope global enp0s9valid_lft forever preferred_lft foreverinet6 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 1000link/gre 6.6.6.6 peer 6.6.6.7inet 10.10.5.1/30 scope global gre1valid_lft forever preferred_lft foreverinet6 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 1000link/ether 08:00:27:56:7b:06 brd ff:ff:ff:ff:ff:ffinet 6.6.6.7/24 scope global enp0s9valid_lft forever preferred_lft foreverinet6 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 1000link/gre 6.6.6.7 peer 6.6.6.6inet 10.10.5.2/30 scope global gre1valid_lft forever preferred_lft foreverinet6 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 88IP (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 88IP (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
也信美人终作土,不堪幽梦太匆匆......
如果这篇文章为您带来了帮助或启发,不妨点个赞👍和关注,再加上一个小小的收藏⭐!
(。◕‿◕。)感谢您的阅读与支持~~~