当前位置：首页 > article >正文

GRE隧道在实际部署中的优化、局限性与弊端

article 2024/11/15 8:45:23

GRE的其他特性

上一篇光讲解配置就花了大量的篇幅，还一些特性没有讲解的，这里在来提及下。

1、动态路由协议

在上一篇中是使用的静态路由，那么在动态路由协议中应该怎么配置呢？

undoip route-static 192.168.20.0 255.255.255.0 Tunnel0

undo ip route-static 192.168.10.0 255.255.255.0 Tunnel1

[BJ_FW]ospf 1 router-id10.1.1.1

[BJ_FW-ospf-1-area-0.0.0.0]network10.1.1.1 0.0.0.0

[BJ_FW-ospf-1-area-0.0.0.0]network192.168.10.0 0.0.0.255

[CS_FW]ospf 1 router-id10.1.1.2

[CS_FW-ospf-1-area-0.0.0.0]network10.1.1.2 0.0.0.0

[CS_FW-ospf-1-area-0.0.0.0]network192.168.20.0 0.0.0.255

OSPF建立成功了，查看是否收到路由。

在实际中，常见组网场景使用静态路由即可满足，比较复杂的网络结构则推荐使用动态路由 OSPF之类，减轻工作量，也方便部署（这里留一个提问：如果把Local与gre的策略去掉，OSPF还能建立起来吗？）

2、验证功能

默认情况下GRE是没有开启认证的，那么假设有人伪装成BJ防火墙来跟CS的防火墙通信，CS防火墙是识别不到的，这个时候可以开启GRE的验证功能。（先开启抓包）

这个是没有开启认证情况下的报文，待会开启认证后来对比下有什么不一样。

[BJ_FW]interface Tunnel 0

[BJ_FW-Tunnel0]gre key 123456

当只有BJ_FW这边输入验证key后，会发现OSPF的邻居down了

接口还是up的

数据已经不通了。

[CS_FW]interface Tunnel 1

[CS_FW-Tunnel1]gre key 123456

当CS_FW配置认证key后，OSPF立马就建立了，也能互通，这里说明认证的关键是两边的key要完全一致。

这个时候在看抓包的的认证前跟认证后对比能发现开启认证后key的字段变成1了，并且下面多了一个GRE key 0x0001e240

这个字段是十六进制，换算成十进制就是123456了。

3、校验功能

GRE的虽然使得两个局域网之间互通了，但是在internet不安全的环境中可能被恶意攻击者篡改，就需要用到GRE中的一个功能：checksum，一旦开启后，在发送的时候会把报文的信息计算校验和，并附带在报文里面，对端收到后也会重新计算跟携带的结果做比较，如果一致则通过，不一致丢弃。

[BJ_FW]interface Tunnel 0

[BJ_FW-Tunnel0]gre checksum

[CS_FW]interface Tunnel 1

[CS_FW-Tunnel1]gre checksum

另外强调下，校验功能是单向的，一端开，另外一端不开也是不影响隧道，但是在实际中建议两边都开启。

4、Keepalive

假设CS_FW的tunnel口被关闭了会发生什么事情？

[CS_FW]interface Tunnel 1

[CS_FW-Tunnel1]shutdown

从BJ_FW这边看除了OSPF邻居信息down掉外，tunnel口没任何反应，这里说下GRE是一个无状态类型的隧道，也就是只维护自己的隧道，对于对端是不会去关心的，为了解决这个问题，就提供了一个keepalive机制，它会周期性的发送探测报文给对方来检测对方状态，如果对方回应了，则认为隧道正常，如果持续一定时间没回应则把隧道关闭。

[BJ_FW]interface Tunnel 0

[BJ_FW-Tunnel0]keepalive

当配置完毕后，这个时候tunnel就down了，因为对方没有回应。

这里又出现了一个经典的地方，只把CS_FW的接口打开了，并没有配置keepalive，但是BJ_FW的隧道起来了，这说明keepalive也是可以单向开启的功能，只是在实际中建议是双方都开。

5、MTU优化

GRE封装是会产生新的IP头部跟GRE报文头部，那可能会造成IP分片的问题，因为本身MTU1500，这个时候又加了新的IP头部20个字节，加4~12个字节的GRE头部，这里GRE的头部大小根据配置机制有所不同，正常GRE隧道是4个字节，如果加了key验证是8个字节，如果开了checksum则是12个字节，原因key验证跟checksum都会产生数据，所以字节增加了，但是有一个功能不会增加就是keepalive。所以足足的多出来了最少24个字节，最多32个，所以在实际中配置的话建议MTU改成 1500-IP头部-GRE占用，比较建议直接用1450（两边建议一致）

GRE的弊端

GRE隧道虽然帮助两个局域网在互联网之间进行了互通，它实现的方式其实就是给原始数据打上了一个新的“马甲”，但是带来的问题是GRE是没有加密功能的。

抓包软件就很能体现出来了，内容里面它直接显示是192.168.10.1到20.2的，具体内容都可以抓包看到，但是看详细的，会发现其实在前面有一层新的IP头部的（新的马甲），但是里面的内容只要被抓取的包，就能看的一清二楚，所以在实际中GRE单独使用会相对较少，以博主的来说，只有在IPSEC对接的时候出现问题，客户又急需要互通可能会提前用GRE先打通，把业务对接起来，在实际中用的更多的是gre over ipsec，用ipsec来加密保护GRE隧道。（这里只说局域网之间互通的情况，不讨论在MPLS中的使用）

GRE的局限性

从上个案例中可以看出来，GRE一个很大的局限性就是两边都是要是公网IP，因为tunnel指定是必须写固定地址的，如果地址是可变的话则建立不起来。这在实际实施中就增加了难度，大部分时候往往就是有一端没有公网IP，或者两边都是动态的公网IP，在这种情况下GRE就显得没办法了，在华为防火墙里面算是一个特例，它支持动态的，但是需要配合DDNS功能，其余设备一律不支持。