GRE隧道技术

Keywords 关键词：VPN GRE 隧道PDSN WAPGW
Abstract 摘要：在传统的VPN组网场合中，GRE隧道技术得到了广泛的应用。

本文介绍了GRE基本原理以及GRE的应用等，可供使用GRE技术的人员参考。

List of abbreviations 缩略语清单：
一、概述
在传统的VPN 组网场合中，GRE 隧道技术得到了广泛的应用。

本文介绍了GRE 基本原理以及GRE 的应用等，可供使用GRE 技术的人员参考。

二、VPN 简介
VPN（Virtual Private Network，虚拟专用网）是一种基于公共数据网的服务，它依靠ISP （Internet Service Provider）和NSP（Network Service Provider），在公共网络中建立虚拟专用通信网络。

VPN 可以极大地降低用户的费用，并且提供比传统专线方式更强的安全性和可靠性。

1. 隧道技术
在VPN 中广泛使用了各种各样的隧道技术，有二层隧道技术，也有三层隧道技术。

那么，什么是隧道呢？
隧道是一种封装技术，它利用一种网络协议来传输另一种网络协议，即利用一种网络传输协议，将其他协议产生的数据报文封装在它自己的报文中，然后在网络中传输。

实际上隧道可以看作一个虚拟的点到点连接。

例如，GRE 隧道仅支持点到点的业务接入。

隧道技术简单地说就是：原始报文在A 地进行封装，到达B 地后把封装去掉，还原成原始报文，这样就形成了一条由A 到B 的通信隧道。

隧道技术就是指包括数据封装、传输和解封装在内的全过程。

隧道是通过隧道协议实现的，隧道协议规定了隧道的建立，维护和删除规则，以及怎样将原始数据封装在隧道中进行传输。

2. 隧道协议分类
隧道协议可分为：
（1）第二层隧道协议，如PPTP、L2TP
（2）第三层隧道协议，如GRE、IPsec
三、GRE 简介
GRE（Generic Routing Encapsulation，通用路由封装协议）是由Cisco 和Net Smiths 公司于1994 年提交给IETF，标号为RFC 1701、RFC 1702。

2000 年，Cisco 等公司又对GRE 协议进行了修订，称为GRE V2，标号为RFC 2784。

GRE 是对某些网络层协议（如：IP，IPX，AppleTalk 等）的数据报文进行封装，使这些被封装的数据报文能够在另一个网络层协议（如IP）中传输。

这是GRE 最初的定义，最新的GRE 封装规范，已经可以封装二层数据帧了，如PPP 帧、MPLS 等。

在RFC2784 中，GRE 的定义是“X over Y”，X 和Y 可以是任意的协议。

GRE 真的变成了“通用路由封装” 了。

GRE 协议实际上是一种封装协议，它提供了将一种协议的报文封装在另一种协议报文中的机制，使报文能够在异种网络中传输。

异种报文传输的通道称为tunnel（隧道）。

GRE 隧道不能配置二层信息，但可以配置IP 地址。

GRE 利用为隧道指定的实际物理接口完成转发，转发过程如下：
（1）所有发往远端VPN 的原始报文，首先被发送到隧道源端
（2）原始报文在隧道源端进行GRE 封装，填写隧道建立时确定的隧道源地址和目的地址，然后再通过公共IP 网络转发到远端VPN 网络
四、GRE 的封装过程
无论是何种隧道协议，其数据包格式都是由乘客协议、封装协议和运输协议3 部分组成的。

例如，以GRE 为例，GRE 协议栈如下：
图1 GRE协议栈
原始IP 报头
净荷
1. GRE 的封装过程
图 2 说明了 GRE 的封装过程：
原始IP 报文
新IP 报头
GRE 头
原始IP 报头 净荷
GRE 封装后的IP 报文
图2 GRE 的封装过程
图 2 中的原始数据包，可以是 IP 报文。

当然，GRE 也可以封装其它的协议报文，如 IPX 报文、PPP 、MPLS 等。

总结起来，GRE 的封装过程如下：当报文需要经由隧道接口处理时，IP 层的输出函数 调用 tunnel 接口的输出函数进行加封装处理。

加封装处理结束后，再进行 IP 转发。

GRE 隧道对端的解封装过程如下：当 IP 层接收到 GRE 报文，检查到外层 IP 报文头部 中的协议号是 47 时，那么，IP 层输入入口函数会根据协议开关表，直接调用 GRE 的解封 装处理函数，对 GRE 解封装。

解封装完成后，再将原始数据报文送入 IP 输入队列中，以便 进行进一步的传输。

为了对 GRE 报文有一个更好的理解，我们重点学习 GRE 报文头部的格式。

五、GRE 报文头部格式
实际上，GRE 报文头部没有一个统一的格式，每个厂家具体实现的GRE 头部格式会有所差别。

但基本上都是以RFC1701 定义的GRE 头部格式为基础的。

1. RFC1701 定义的GRE 报文头部
根据RFC1701，GRE 数据报文的头部有下面的格式：
0 5 8 13 16 31
图3 RFC1701定义的GRE报文头部格
式下面，我们对GRE 报文头部进行详细的说明。

（1）C、R、K、S、s：GRE 报文头部的最前5 位，是一些标志位。

其含义如下：
表1 GRE报文头部的最前5位的含义
（2）Recur：bits 5-7。

Recur 域是记录允许的封装次数的计数器。

GRE 提供了一种特定的机制来防止递归封装。

如果路由器想对经过GRE 封装的数据包作进一步封装，应在封装前检查这个域。

如果Recur 域为非0，那么数据包还可以进行封装，新的GRE 报头中的Recur 域取值将减1；否则，如果Recur 域的值已经是0 了，那么这个包不可以再进行封装（3）Flags：bits 8-12。

在RFC1701 中没有定义
（4）Ver：bits 13-15。

版本号。

在RFC1701 中，Ver 必须为0
（5）Protocol Type：2 byte。

Protocol Type 指出GRE 报文净荷的协议类型。

RFC1701 定义的常见值如下：
0x0800：IP
0x8137：Novell IPX
（6）Offset：2 byte。

Offset 域指出Routing 域到净荷的字节偏移
（7）Checksum：2 byte。

Checksum 包括GRE 头部和净荷的IP 校验和。

当Checksum Present 位为1 时，Checksum 域有效
（8）Key：4 byte。

Key 域用来标识隧道内部单个的业务流。

属于同一个业务流的数据报文使用同一个Key 值来封装，隧道的拆封点根据Key 域的值识别属于某个业务流的数据报文。

当Key Present 位为1 时，KEY 域有效
（9）Sequence Number：4 byte。

Sequence Number 域用来维持GRE 隧道内数据报文的顺序。

当Sequence Number Present 位为1 时，Sequence Number 域有效
（10）Routing：4 byte。

Routing 域是可选的，当Routing Present 位为1 时，Routing 域有效
（11）Payload：净荷。

GRE 所封装的协议报文
以上介绍的GRE 头部格式，是在最早的RFC1701 中定义的。

GRE 最新RFC 文档是：RFC2784。

2. RFC2784 定义的GRE 报文头部
RFC2784 规定的GRE 头部格式如下：
0 1 14 16 31
图4 RFC2784定义的GRE报文头部格式
可见，RFC2784 定义的GRE 报文头部格式，比RFC1701 定义的更加简单，更加通用。

我们把RFC1701 定义的GRE 头部的前几个标志位置为0，相应地，GRE 头部中的Key、Sequence Number 等域就没有了，于是就变成了RFC2784 定义的GRE 通用头部格式。

3. 其它厂家规定的GRE 报文头部
由于GRE 已经发展为可以封装任意协议了，协议本身变得比较复杂。

GRE 协议在实际应用中，一般是和其它协议一起结合使用。

不同厂家定义的GRE 头部格式，和RPC1701、RFC2784 规定的格式又有着细微的不同，可以说是扩展的GRE。

例如，微软等公司定义的封装PPP 帧的GRE 头部，是在RFC1701 的基础上定义的。

只要保证封装方和解封装方采用相同的GRE 规范，甚至是厂家自己定义的私有GRE 头部格式（比如在标准GRE 头部中加入“A”标志位等），一般在应用时不会出现问题，只是不同厂家设备的互联互通性差一点而已。

所以，GRE 头部没有一个统一的封装格式，不同的GRE 头部，与RFC1701、RFC2784 定义会有所差别。

这也是我们在和不同厂家设备进行GRE 隧道对接时，需要考虑的GRE 头部格式不一致的问题。

所以，在实际应用GRE 时，请参考相关厂家的GRE 文档。

六、普通GRE 隧道配置
GRE 作为一种通用的封装技术，本身涉及到很多方面的知识，比较复杂。

但普通GRE 隧道的配置比较简单，如果我们对RFC1701 规定的GRE 头部格式比较熟悉，那么，对配置命令也很好理解。

1.创建Tunnel 接口
创建一个隧道（Tunnel）接口很简单，只要指定好Tunnel 接口的编号就可以了。

例如，在PDSN 上创建一个Tunnel 1/0/1，如下：
R outer#conf t// 进入全局配置模式
Router(config)#interface Tunnel 0 // 创建Tunnel 接口
2. 配置Tunnel 接口的网络地址
Tunnel 接口的网络地址可以不是公网地址，可以配置为私网IP 地址。

但隧道两端的网络地址应该在同一网段。

假设我们我们配置T unnel 接口的网络地址为：192.168.0.2，掩码：255.255.255.0。

配置命令行如下：
R outer(config-if)#ip add 192.168.0.2 255.255.255.0// 配置Tunnel 接口的网络地址
3. 配置Tunnel 接口的源端地址和目的端地址
在创建Tunnel 接口后，还需要指定隧道的源端地址和目的端地址，一个包含这些都是真实的公网IP 地址，前者是发出GRE 报文的接口IP 地址，后者是接收GRE 报文的接口IP 地址。

在这里，我们要明白，为什么要配置Tunnel 接口的源端地址和目的端地址呢？我们知道，最终的GRE 报文还要加上一个含有公网IP 地址的IP 头部，配置的Tunnel 接口的源端地址和目的端地址就是用于运输协议----IP 协议给GER 报文加上新的公网IP 头部。

Router(config-if)#tun source源端IP 地址// 配置Tunnel 接口的源端地址
Router(config-if)# tun destination 目的端IP 地址// 配置Tunnel 接口的目的端地址 Router(config-if)#no shutdown // 开启端口
4. 配置Tunnel 的路由
在源端路由器和目的端路由器上，都必须存在经过Tunnel 转发的路由。

隧道路由可以配置静态路由或配置动态路由，这样，需要进行GRE 封装的报文才能正确转发。

配置静态路由时，需要注意：目的地址不是Tunnel 的目的端地址，而是未进行GRE 封装的报文的目的地址，下一跳是对端Tunnel 接口。

Router(config)#ip route ip dest-ip-address { mask | mask-length } tunnel0// 配置静态路由
私网地址 10.0.0.8/24
七、GRE 应用和分析
GRE 在传统的 VPN 网络中应用很广泛。

我们常见的私网穿越公网的 GRE 隧道应用， 一般是私网 IP 报文封装成 GRE 报文，再用 IP 运输。

1. 私网穿越公网的 GRE 隧道应用
GRE 在简单的 VPN 组网中有着比较广泛的应用。

例如，一般，企业私有网络的 IP 地 址通常是私网 IP 地址（例如以 10 开头的 IP 地址），只是在企业网络出口处有一个公网 IP 地址。

私网 IP 报文是不可以在 Internet 上路由的，但经过 GRE 封装后，再加上一个公网 IP 头部，就可以在 Internet 上路由了。

在接收方，将收到的报文的 IP 头部和 GRE 头部解开后， 将原始的私网 IP 报文发送到远程的私有网络上，从而实现了访问远程企业的私有网络的目 的。

这种技术也是最简单的 VPN 技术，它没有对数据进行加密，实用性不高。

例如，深圳公司基地的一台 PC 机，IP 地址是：10.0.0.8/24，北京一台 PC 机的 IP 地址 是：10.1.1.9/24。

两台 PC 机的 IP 地址都是私网地址。

如下：
深圳
北京
图5 私网穿越公网的GRE 隧道
公网地址 58.60.220.149
公网地址 202.189.80.2
GRE 隧
道
Internet
PC1 Router A
Router B
PC2 私网地址 10.1.1.9/24
Tunnel 接口网络地址
192.168.0.3/24 Tunnel 接口网络地址
192.168.0.2/24
我们要实现PC1 和PC2 的互通，深圳和北京这么远，私网IP 报文沿途经过的所有路由器，是不会帮你转发报文的（而且私网IP 报文不能出现在公网上，路由器会直接丢弃）。

当然，我们可以租用一条专线，但实施工程时间比较长，费用高，不是很现实。

这时候，我们可以考虑在两边的公网出口路由器上，打通一条GRE 隧道，采用RFC1701 定义的GRE 头部格式。

这样在Router A 和Router B 看来，他们之间好像只经过了一条直通的链路。

在Router A 上的GRE 隧道配置如下：
RouterA#interface Tunnel 0
RouterA(config-if)# no shutdown
RouterA(config-if)#IP address 192.168.0.3 255.255.255.0
RouterA(config-if)#tun source 58.60.220.149
RouterA(config-if)#tun destination 202.189.80.2
RouterA(config-if)#ip route-static 10.1.1.0 255.255.255.0 Tunnel 0
在Router B 上的GRE 隧道配置如下：
RouterB#interface Tunnel 0
RouterB(config-if)#no shutdown
RouteBr(config-if)#IP address 192.168.0.2 255.255.255.0
RouteBr(config-if)#tun source 202.189.80.2
RouterB(config-if)#tun destination 58.60.220.149
RouterB#ip route-static 10.0.0.0 255.255.255.0 Tunnel 0
2. PDSN 的A10 链路GRE 隧道分析
在CDMA2000 分组域的简单IP 业务组网中，PDSN 和PCF 之间的RP 接口走的是GRE 隧道。

不同的用户业务，通过GRE 头部中不同的Key 来区分。

RP 接口包括了A11 信令链路和A10 业务链路。

A11 注册请求成功后，A10 业务链路建立。

用户数据以GRE 形式封装，采用RFC1701 的GRE 格式，在A10 上传输。

在A10 链路上采用GRE 封装，是因为GRE 的特性是对转发隧道和负荷协议都没有要求，有防止递归封装的机制，有序列号选项可以使用，满足按照有序方式发送的要求。

RP 接口的GRE 隧道如图6 所示：
BSS/PCF
MS
GRE隧
道PDSN
Internet
业务服务器
图6 PDSN简单IP业务组网模型
RP 接口协议栈如下：
A10 数据A11 信令
GRE UDP
IP
链路层
物理层
图7 RP接口协议栈
下面，我们对A10 链路的GRE 隧道报文进行分析。

例如，在某次普通的PPP 拨号连接中，RP 接口抓到的报文如下。

为了简单起见，我们在ethereal 中输入过滤条件：“gre”，就可以把除GRE 以外的报文过滤掉了，如下：
图8 RP接口GRE隧道报文分析
图8 中，红框内的内容，就是GRE 报文头部的解析。

可以看到，GRE 已经不仅封装网络层协议了，也可以对二层的PPP 协议进行封装。

因为A10 链路的GRE 隧道符合RFC1701 定义，我们就对照着以上介绍的RFC1701 规定的GRE 头部格式，对图8 中的GRE 报文头部进行分析。

根据微软的技术文档，封装PPP 帧的GRE 头部格式，与RFC1701 的标准GRE 头部格式又有着细微的差别，如下：
0 16 31
图9 封装PPP帧的GRE报文头部格式
相应的GRE 头部字段定义如下：
表2 封装PPP帧的GRE报文头部字段解析
根据GRE 报文格式，我们对图8 的封装PPP 帧的GRE报文进行分析。

（1）图8 中，GRE 头部的前16 位，是“Flags and version”字段。

最前的5 位，每位都有其含义，这从表1 可以看出。

例如，第一位“C”为0，表示GRE 头部中没有checksum 域。

第二位“R”为0，表示GRE 头部中没有routing 域。

第三位“K”为1，表示GRE 头部中有key 域。

第四位“S”为1，表示GRE 头部中有Sequence Number 域。

第五位“s”为0，表示GRE 头部中没有“Strict Source Route”。

（2）接下来是3bit 的“Recur”，其值是：0，表示这个GRE 报文不可以再被封装。

（3）第8 位是“Acknowledgment sequence number present”字段，简称“A”。

“A” 的值为0，表示GRE 头部中没有Acknowledgment Number 域。

（4）第9 到12 位是“Flags”字段。

根据协议标准，Flags 必须为0。

（5）第13 到15 位是“Ver”字段。

根据协议标准，Ver 必须为1。

（但奇怪的是，图8 报文里解析出来的值是0。

前面已经说过，厂家可以自己定义GRE 头部格式，只要实现了隧道就可以了。

所以，在这里的差别可以理解）
（6）GRE 头部的“Protocol Type”值为：0x8881，表示封装的是：CDMA2000 A10 unstructured byte stream。

（7）GRE Key 的值为：0x00000035。

这个Key 标示着每个用户业务，即区分不同用户的业务。

（8）Sequence Number 的值为：0。

不同的GRE 报文有不同的Sequence Number，这是为了接收方能够重建乱序到达的数据报文。

（PDSN 默认在GRE 报文中使用Sequence Number，BSC 默认也支持GRE 报文头部中的Sequence Number。

如果在BSC 上用“MOD PCFAN”命令关闭了GRE 系列号，将会造成PPP 连接在LCP 协商阶段失败）
这样，我们就把封装PPP 帧的GRE 报文头部分析完毕了。

图8 中，还可解析出了被GRE 封装的PPP 帧的详细内容。

有兴趣的人员可以打开看一下，本文不再进行详细分析。

3. WAPGW 的GRE 隧道分析
WAPGW（Wireless Application Protocol Gateway，无线应用协议网关）是华为公司推出的infoX-WING 综合接入网关的其中一种产品形态。

当infoX-WING 作为IPGW 时，支持非WAP 业务的接入，支撑各种基于IP 承载的移动数据业务，完成非WAP 业务的接入控制、用户认证鉴权、SP/CP 认证、内容和流量计费信息采集等功能。

当infoX-WING 作为WAPGW 时，支持WAP 业务的接入，提供OMA（Open Mobile Alliance）定义的标准WAPGW 功能及内容、流量计费功能。

WAP 流量的组网图如下。

其中WAPGW 和Wing-3528-1 之间走的就是GRE 隧道：
WAP流量
Wing-NE20-1
IP G W
WAPGW Wing-NE20-2
YTG E1000-1YTG NE40-1Core NE40-1Wing-3528-1GRE
E1000-1
8505
YTG E1000-2YTG NE40-2Core NE40-2Wing-3528-2E1000-2
Internet
NS500-1
NS500-2
Wing-NE20-3
Wing-NE20-4
FW-IMS
图10 IPGW和Wing3528-1之间的GRE隧道分析
为什么WAPGW 和Wing3528-1 之间要走GRE 隧道？一个最大的原因是，如果不做GRE 封装，WAPGW 将需要保持很多用户业务的TCP 连接，这将占用大量的TCP 端口，以及很大的内存空间。

下面我们对一个IPGW 的GRE 抓包进行分析，如下：
图11 IPGW的GRE隧道报文分析
可以看到，IPGW 的GRE 报文的头部格式是RFC1701 定义的标准格式。

我们可以对照着以上介绍的RFC1701 标准GRE 头部格式，对图11 进行分析，这里不再详述。

图11 的GRE 报文头部相当简单，基本上什么字段都没有，既没有checksum，没有key，也没有Sequence Number，等等。

可能有些人会感到有些奇怪了，在PDSN 的RP 接口GRE 隧道中，GRE 报文是带有key 和Sequence Number 的，以此来区分不同的用户，而序列号用于重组乱序到达的GRE 报文。

但IPGW 的GRE 报文里没有key 和Sequence Number，那么，怎样来区分不同的用户，以及如果GRE 报文乱序了，该如何重组？
其实，图11 中的GRE 头部的“Protocol Type”的值是：0x0800，表示GRE 封装的是IP 报文。

而IP 报文承载的是传输层的TCP 报文段。

在IPGW 对GRE 报文解封装后，IPGW 可以利用GRE 里的IP 报文的源IP 地址，对用户进行区分，利用TCP 的序列号可以对GRE 报文进行标识和乱序重组。

这种现象是很有趣的。

其实很多协议的报文格式都大同小异，例如GRE 报文头部定义了序列号，TCP 报文段头部中也有定义序列号，这样就可以灵活地利用。

其实很多时候协
议报文之间都是相互封装和承载的关系。