【防火墙技术连载20】强叔侃墙 VPN篇之GRE

fcm

在上一期，强叔为大家拉开了VPN技术的帷幕，从本期开始强叔将带领小伙伴们逐一认识VPN家族中的各个成员。今天我们先来认识一下VPN家族中的第一位成员GRE。

要说起这个GRE，我们还得把时间的镜头拉回到20年前，回顾一下当年发生的故事。在那个年代，Internet已经开始快速发展，越来越多的资源被网络所连接，从而使人们的联系更为便捷，这本是一件皆大欢喜的事情。然而看似和谐的网络世界，也充斥着各种不幸。有时就像人生，欢乐大抵相似，痛苦各有不同。被Internet互联以后的私有网络就面临着以下几个痛苦：

1. 私有IP网络之间无法直接通过Internet互通。

这个不用强叔多说，私有网络中使用的都是私有地址，而在Internet上传输的报文必须使用公网地址。

                               
登录/注册后可看大图

2. 异种网络（IPX、AppleTalk）之间无法通过Internet直接进行通信。

这个痛苦是先天性造成的，IPX和IP本就不是同一种网络协议，因此IP网络不转发IPX报文，这倒也情有可原。

                               
登录/注册后可看大图

3.私网之间部署的动态路由无法跨越Internet。

   …

或许悲催的故事还有很多，强叔在此就不一一列举了。总之当各种痛苦交织、汇聚在一起之后，形成了一股强大的推动力，迫使网络攻城狮们绞尽脑汁的寻求一种解决之道，终于在1994年GRE协议问世了，它被IETF纳入以后，RFC标号为RFC1701和RFC1702。

GRE（General Routing Encapsulation）即通用路由封装协议，它的出现使得上面的那些悲情故事在今天不再重演。好奇的小伙伴肯定就要问了，GRE到底是用了什么方法竟然能够一一化解上述难题。其实说穿了也很简单，GRE用的就是当下流行的“马甲”技术。既然私有网络发出的报文由于种种原因不能在Internet上进行传输，那何不给这些报文穿上能让Internet识别的“马甲”（GRE封装），再让它在Internet上传输。反正对于Internet而言，它是只认“马甲”不认人。这种“马甲”技术在网络中的专用术语就是“封装”。

但凡一种网络封装技术，其基本的构成要素都可以分为3个部分：乘客协议、封装协议、运输协议，GRE也不例外。

• 乘客协议：为了便于理解封装技术，我们用邮政系统打个比方。乘客协议就是我们写的信，信的语言可以是汉语、英语、法语等，具体如何解释由写信人、读信人自己负责。
• 封装协议：封装协议可以理解为信封，可能是平信、挂号或者是EMS，这对应于多种封装协议。
• 运输协议：运输协议就是信的运输方式，可以是陆运、海运或者空运，这对应于不同的运输协议。
  

OK，理解了这个以后，我们再来看看GRE中都用到了哪些协议。

                               
登录/注册后可看大图

从图中我们可以很清晰的看到，GRE能够承载的协议包括IP协议、IPX协议，GRE所使用的运输协议是IP协议。
了解了GRE的一些基本概念和应用以后，下面强叔将为大家讲解一下GRE的封装原理。

                               
登录/注册后可看大图

GRE的封装过程可以细分成两步，第一步是在私有数据中添加GRE头，第二步是在GRE头前面再加上新的IP头。加上新的IP头以后，就意味着这个私有网络的报文在经过层层封装以后就可以在Internet上传输了。

从产品实现的角度来讲，上述的封装操作是通过一个逻辑接口来实现的，这个逻辑接口就是鼎鼎有名的Tunnel接口。Tunnel即隧道，从名字就可以看出来这个逻辑接口就是为隧道而生。由于Tunnel接口是一个通用的隧道接口，所以GRE协议在使用这个接口的时候，我们会要求将这个接口的封装协议设置为GRE协议。

下面强叔将结合Tunnel接口介绍一下防火墙对GRE流量的转发过程，见下图。

                               
登录/注册后可看大图

1．  企业的私网流量到达防火墙的入接口，防火墙查询路由表对此流量进行转发。

2．  防火墙根据路由查找结果，将此流量引导到Tunnel接口进行GRE封装。

3．  封装后的GRE报文再次查找路由进行流量转发。

4．  防火墙根据路由查找结果，找到出接口，并将流量发送到Internet。

这就是防火墙对私网流量进行GRE封装和转发的全过程，很简单吧。

有些小伙伴肯定在想了，强叔这里只介绍了封装过程，那隧道对端是如何解封装的？

其实解封装也很简单。首先隧道对端在接收到报文以后，先根据该报文目的地址判断是不是发给自己的，在

明确报文是发给自己以后，再去判断这个报文是不是GRE报文。怎么判断呢？在封装原理那幅图中我们可以看

到封装后的GRE报文会有个新的IP头，这个新的IP头中有个Protocol字段，字段中标识了内层协议类型，如果这

个Protocol字段值是47，就表示这个报文是GRE报文。

上面强叔从原理角度为大家讲解了报文进入隧道、加封装、解封装的过程。想必小伙伴更想知道的是，在防

火墙中GRE隧道应该怎么配置呢？莫要着急，下面强叔就来结合实例讲讲GRE隧道的配置方法。

                               
登录/注册后可看大图

GRE隧道的配置也很简单，可以分为两个步骤。

1．  配置Tunnel接口的封装参数（配置数据以Firewall_A为例）。

interface Tunnel 1

ip address 1.1.1.1 24

tunnel-protocol gre

source 202.38.167.1

destination 202.38.163.1

首先设置Tunnel接口的封装类型为GRE，然后指定GRE隧道的源和目的就OK了。GRE隧道中大家容易产生疑惑的地方在配置Tunnel接口的IP地址。有很多小伙伴会有这么几个问题。

a．Tunnel接口的IP地址是否必须配置？

b．隧道两端的Tunnel接口IP地址是否有所关联？

c． Tunnel接口使用的是公网IP地址还是私网IP地址？

首先Tunnel接口的IP地址必须配置，如果不配置IP地址，Tunnel接口就无法UP起来。其次，从GRE的封装过

程来看，Tunnel接口的IP地址并没有参与报文封装，所以隧道两端的Tunnel接口没有任何关联，各配各

的。再者，既然Tunnel接口不参与封装，所以也就没有必要用公网地址了，配置成私网就可以了。

2．  配置路由，将要进行GRE封装的流量引流到Tunnel接口。

    把流量引入到GRE隧道有两种方法，一种是静态路由，一种是动态路由。

    静态路由配置： ip route-static 192.168.2.0 24 Tunnel 1

    动态路由配置：如果私网内部使用的是动态路由（例如OSPF），则只要把私网地址和Tunnel接口地址一起通过OSPF发布出去即可。

    ospf 1

area 0

network 1.1.1.0 0.0.0.255

        network 192.168.2.0 0.0.0.255

此时有一个特殊的地方需要注意，就是如果GRE隧道对应的公网接口也使用了OSPF，那我们就需要用一个新的OSPF进程来发布私网地址和Tunnel接口地址。

GRE的配置很简单，强叔就不多说了。结合平时遇到的一些GRE问题，强叔再做一些扩展。

有些小伙伴可能会有担忧，说如果Internet上的恶意有用户伪装成Firewall_A向Firewall_B发送GRE报文，那伪装者不就可以访问Firewall_B中的资源了呢？那么Firewall_A和Firewall_B在建立GRE隧道时，是如何做到互信的呢？下面强叔讲一下GRE的安全机制。

防火墙配置了GRE隧道，并不是说防火墙收到所有的GRE报文它都会进行处理。它只处理与本防火墙建立GRE隧道的对端设备发过来的GRE报文。具体做法就是建立GRE隧道的两台设备要设置一个“密钥”，这个密钥就是身份凭证，密钥信息被封装在GRE报文的头部。当一端收到一个GRE报文以后，都会检查该密钥，只有在密钥一致时，才认为是隧道对端发过来的GRE报文。“身份校验”不通过，该GRE报文会被丢弃。下图就是一个GRE报文，其中GRE报文头中的key字段为1表示用户设置了身份验证功能，下面的GRE key：0x0001e240是用户配置的密钥值。

                               
登录/注册后可看大图

虽然身份校验机制可以保证GRE隧道两端可以实现互信，但是如果报文在Internet传输途中被其他用户恶意篡改，这又该怎么办？这里我们还得用到GRE头中的另一个字段checksum。GRE封装报文时，会根据报文信息计算校验和，并将这个校验和插入到checksum字段中。

当隧道对端收到该报文时，对端也会根据报文信息计算校验和，并与报文中携带的校验和进行比较，如果校验结果一致，则接受此报文；如果不一致，则丢弃。下图中checksum为1，表示启用了校验和功能，下面checksum:0x6dbd是校验和对应的值。

                               
登录/注册后可看大图

GRE的安全机制可以实现隧道两端的互信，并保证报文传输的完整性。但是这里还有一个问题，就是如果隧道对端设备出现故障时，隧道本端如何感知的呢？

GRE隧道是一种无状态类型的隧道，所谓的无状态类型是指隧道本端并不维护与对端的状态。换句话说假如隧道对端出现故障，那隧道本端是感受不到的。为了解决这个问题，GRE隧道提供了一种保活机制（keepalive）。GRE隧道源会周期性的向隧道对端发送keepalive报文，以检测隧道对端状态。如果GRE隧道对端出现问题，则隧道源的Tunnel接口状态会被置为Down，即本端关闭GRE隧道。这就避免了因对端不可达而造成的数据黑洞。GRE的Keepalive功能是单向的，对端是否支持或启用Keepalive功能不影响本端的Keepalive功能。实际配置时，建议隧道两边都配置上保活功能。

                               
登录/注册后可看大图

小伙伴们看到这里觉得是不是有了GRE隧道就万事大吉了，其实不然。强叔要告诉大家的是GRE自身有个缺陷，就是GRE技术不带有安全加密功能。没有加密功能的GRE报文，只能说是穿了个透明的马甲，它所要传输的数据别人可以看得一清二楚。所以我们在实际使用时，很少单纯使用GRE，而是经常与IPSec技术联用。由于IPSec技术具备很强的加密功能，就解决了GRE的安全性问题。这也就是我们经常听到的GRE over IPSec技术。

GRE over IPSec技术本质并不复杂，就是在GRE将报文封装后，再经过IPSec封装，就是穿了两层“马甲”而已。GRE over IPSec的详细内容强叔准备放在IPSec技术中再进行详细讲解，到时候大家就会一目了然了。下期强叔将带领大家认识VPN的下一位成员：L2TP VPN，敬请期待。

更多好文，更多精彩，尽在强叔汇总贴：http://support.huawei.com/ecommunity/bbs/10184167.html

转载自：http://support.huawei.com/ecommunity/bbs/10211551.html

fcm

欢迎交流