GRE和IPsec搭配使用,到底是谁over谁?先看GRE over IPsec
发布时间:2021-07-06 16:16:50作者:衡水铁头哥阅读:0
VXLAN特性比较新,所以部分场景下需要考虑使用IPsec或者GRE,但是GRE配置简单却不安全,IPsec使用又会有一些小的限制,所以一般会将IPsec和GRE组合使用。
常见的两种类型包括IPsec over GRE和GRE over IPsec,over是在网络模型中的说法,举个例子:GRE over IPsec,就是GRE在IPsec之上,那在报文封装的时候就会先封装GRE,再封装IPsec,从报文结构上看起来就是IPsec封装在GRE封装之外,是用IPsec保护GRE隧道。
所以,over前面的是内层报文封装,后面的才是外层封装,也是直接看到的报文结构,说得不严谨一点:IPsec over GRE就是GRE封装格式的报文,GRE over IPsec就是IPsec封装格式的报文。
刚做完GRE over IPv4,充分利用环境环境,今天先配置一个“GRE over IPsec”的实验。
组网需求
RT2和RT4分别连接IPv4私有网络SUBNET 1和SUBNET 5。这两个私有网络使用相同的私网地址192.168.1.0/24。通过在RT2和RT4之间建立GRE隧道,实现两个相同私有网络的互联,并对通过GRE隧道的数据进行IPsec加密处理。
组网拓扑
配置步骤
开头提到,GRE over IPsec,在报文封装的时候先封装GRE,再封装IPsec,是用IPsec保护GRE隧道。
上个实验中,我们已经做好了所以前面的GRE封装,对应的,我们把之前IPsec实验中的保护数据流更改为GRE隧道流量就可以了。
怎么样,听起来是不是很简单?直接看看配置吧!
RT2
#
sysname RT2
#
interface GigabitEthernet0/0
ip address 192.168.1.2 255.255.255.0
proxy-arp enable
#
interface GigabitEthernet0/1
ip address 23.1.1.2 255.255.255.0
ipsec apply policy GREOIPSEC
#
interface Tunnel0 mode gre
ip address 1.1.1.2 255.255.255.0
source 23.1.1.2
destination 34.1.1.4
gre key 123321
gre checksum
#
ip route-static 34.1.1.0 24 23.1.1.3
ip route-static 192.168.1.4 32 Tunnel0
ip route-static 192.168.1.5 32 Tunnel0
#
acl advanced 3400
rule 0 permit gre source 23.1.1.2 0 destination 34.1.1.4 0
#
ipsec transform-set TRAN
esp encryption-algorithm 3des-cbc
esp authentication-algorithm sha1
#
ipsec policy GREOIPSEC 10 isakmp
transform-set TRAN
security acl 3400
remote-address 34.1.1.4
#
ike keychain KEY
pre-shared-key address 34.1.1.4 255.255.255.0 key simple GREOVERIPSEC
RT-ISP
#
interface GigabitEthernet0/0
ip address 34.1.1.3 255.255.255.0
#
interface GigabitEthernet0/1
ip address 23.1.1.3 255.255.255.0
RT4
#
sysname RT4
#
interface GigabitEthernet0/0
ip address 192.168.1.4 255.255.255.0
proxy-arp enable
#
interface GigabitEthernet0/1
ip address 34.1.1.4 255.255.255.0
ipsec apply policy GREOIPSEC
#
interface Tunnel0 mode gre
ip address 1.1.1.4 255.255.255.0
source 34.1.1.4
destination 23.1.1.2
gre key 123321
gre checksum
#
ip route-static 23.1.1.0 24 34.1.1.3
ip route-static 192.168.1.1 32 Tunnel0
ip route-static 192.168.1.2 32 Tunnel0
#
acl advanced 3400
rule 0 permit gre source 34.1.1.4 0 destination 23.1.1.2 0
#
ipsec transform-set TRAN
esp encryption-algorithm 3des-cbc
esp authentication-algorithm sha1
#
ipsec policy GREOIPSEC 10 isakmp
transform-set TRAN
security acl 3400
remote-address 23.1.1.2
#
ike keychain KEY
pre-shared-key address 23.1.1.2 255.255.255.0 key simple GREOVERIPSEC
配置说明
1、ACL中配置的匹配详细的GRE隧道,实际上本处只有一条隧道,可以直接permit gre即可,但是为了大家看起来方便,还是配置了完整的源目地址;
2、本次使用了IKE(Internet Key Exchange,互联网密钥交换)和ISAKMP(Internet Security Association and Key Management Protocol,互联网安全联盟和密钥管理协议),也就是IKE协议利用ISAKMP语言定义密钥交换,是一种对安全服务进行协商的手段。相比如之前使用的手工方式建立隧道,IKE为IPsec提供了自动建立IPsec SA的服务,简单了一些,本次不展开赘述。
3、环境保留了上次实验中同网段互访的配置,属于上个实验的延伸。
验证配置
查看RT4设备Tunnel口状态。
可以看到有几个相对关键的指标项:
1、MTU为1468字节;
2、隧道keepalive功能未开启,开启命令如下:
3、隧道TTL值为255;
4、GRE over IPv4隧道中安全功能key已设置,密钥为123321;
5、GRE over IPv4隧道中安全功能checksum已设置。
使用display ike sa命令,可以看到第一阶段的SA正常建立。
使用display ipsec sa命令可以看到IPsec SA的建立情况。
问题又来了,这个地方的MTU成了1444字节。IPsec在外层,是1444字节,GRE在内层,是1468字节。最后到底会是多少呢?
验证隧道MTU
可以发现,实际能通过的最大报文大小为1384字节,比单独使用IPsec封装少了16字节,但是GRE封装长度只有8字节啊,少的8个字节哪里去了?抓个包分析一下。
这个地方我们捋一下,报文的封装结构应该是[以太网包头][外层IPv4包头][ESP报文头][GRE报文头][GRE封装][内层IPv4包头][ICMP报文][ESP-T校验字段],好像很复杂的样子。
反过来看,普通模式下IPsec SA中显示的MTU是1428字节,本次显示的是1444字节,也是少了16个字节。减掉GRE封装的8字节,还是少8个字节。看样子[GRE报文头]这部分应该是没有了,毕竟有20字节。那会不会是加密算法和IKE的问题,只能后面再验证了。
验证两端同子网
现在已经知道两端相同子网互通是没有问题了,但是上次IPsec实验有个问题就是不能查看traceroute路径,这次我们看一下。
很棒,traceroute路径显示和上次一样,原来使用GRE隧道能解决这个问题。
总结
1、GRE over IPsec就是用IPsec隧道保护GRE隧道,从报文结构看起来和IPsec报文一样,完全看不到里面还套了一层GRE隧道,但是MTU只有1384字节,比只使用GRE隧道的1444字节少了60字节;
2、套接了GRE隧道之后,比单独使用IPsec隧道,可以看到内层报文的traceroute路径,提高了实用性;
3、套接了GRE隧道之后,比单独使用IPsec隧道,调整保护流量时,只需要在两端调整经过GRE隧道的路由即可,无需调整ACL的兴趣流;
4、留了一个问题,GRE over IPsec实际能通过的最大报文大小为1384字节,比单独使用IPsec封装少了16字节,但是GRE封装长度只有8字节,少的8个字节哪里去了?
以上就是GRE和IPsec搭配使用,到底是谁over谁?先看GRE over IPsec的介绍,Vecloud提供企业用户机房到IDC数据中心、企业私有云和公有云,以及企业多云直连的云专线业务,可以快速、有效的为客户提供高速、稳定的专有通道。如果您有相关的业务场景,欢迎咨询,我们有专业的技术团队可以为您提供更好的建议和方案。
免责声明:部分文章信息来源于网络以及网友投稿,本网站只负责对文章进行整理、排版、编辑,是出于传递 更多信息之目的,并不意味着赞同其观点或证实其内容的真实性,请联系站长邮箱:shawn.lee@vecloud.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。
标题:GRE和IPsec搭配使用,到底是谁over谁?先看GRE over IPsec
TAG标签:
地址:http://www.vecloud.com.cn/hangyedongtai/300.html
常见问题
一般导致Microsoft Teams卡顿延迟是这几个原因 1、防火墙连接。 验证是否在防火墙打开了所需的 URL、IP 地址和端口可最大程度地减少不必要的故障排除。 2、企业办公路由器和计算机性能
中国用户正在访问海外AWS服务器访问缓慢,如何快速访问海外?AWS服务器?首先,为什么中国用户访问海外?AWS会变慢?总结可能有以下原因:1)利用互联网访问海外网络,由于中国网民众多,世界总出口有限,
Github 是 程序员绕不开的网站,里面有大量的资源,既有开源项目,又有各种刷题面经,堪称程序员手中的大明绝顶,每个武功高强都想上去探探究竟。 但是呢,下载速度实在不敢恭维
ZOOM海外会议共享演示PPT掉线:ZOOM视频会议国际版服务器在海外欧美等国家,主要原因是较差的Internet连接海外云服务器,音频和视频质量低,延迟。下载和上传缓慢主要是由于数据传输
RingCentral是一家企业云通信提供商,主要做视频会议产品。 RingCentral网络视频会议终端经常掉线的原因分析 一、硬件问题 电脑内存或者CPU型号老旧造成,可以尝试更换新设备 二、网络
我们一直在讨论使用Internet做为整体广域网(WAN)策略的一部分。但软件定义广域网(SD-WAN)与混合型广域网有何不同?企业通常通过MPLS等专用数据服务连接其分支机构。在使用Inte
许多客户不了解传统的企业专线和这种越来越普遍的云专线有什么区别。今天我们将介绍传统的公共网络连接有一定的局限性,它与传统的公共网络连接有很大的不同。具体来说,云专线与传统公共网络连接有什么区别?那么两
目前,全球员工在企业数字转型时遭遇挫折,尤其是当生产力应用迁移到云时,他们可能总是抱怨:为什么Office 365应用如此缓慢?这些应用程序可能迁移到很远的云中,因此延迟和网络
传真、电子邮件和视频会议三大技术革命改变了企业用户的传统通信方式,有效降低了通信成本,大大提高了通信效率。而微软的office365产品已经成为跨平台办公市场的主流。随着企业
一直都说游戏是受DDoS攻击的重灾区,游戏行业确实是DDoS攻击的热门目标,而且现在海外DDoS攻击真的很强大。 在腾讯安全发布的一份报告中,其表明游戏行业仍是DDoS的首要攻击目标。