GRE和IPsec搭配使用，到底是谁over谁？先看GRE over IPsec

╰+哭是因爲堅強的太久メ 2022-08-30 11:59 251阅读 0赞

关于相同的二层子网跨广域网进行互通，目前我们测试了VXLAN、IPsec和GRE三种方式，分别是（[VXLAN小实验：VXLAN头端复制配置][VXLAN_VXLAN]）、（[为什么IPsec两端内网的网段能不能重复？分明可以实现！][IPsec]）和（[GRE隧道也能实现两端配置相同子网了，快来看看！][GRE]）。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加密处理。

# 组网拓扑 #

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d0ajA2MTc_size_16_color_FFFFFF_t_70][]

# 配置步骤 #

开头提到，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口状态。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d0ajA2MTc_size_16_color_FFFFFF_t_70 1][]

可以看到有几个相对关键的指标项：

1、MTU为1468字节；

2、隧道keepalive功能未开启，开启命令如下：

![20210720193214679.png][]

3、隧道TTL值为255；

4、GRE over IPv4隧道中安全功能key已设置，密钥为123321；

5、GRE over IPv4隧道中安全功能checksum已设置。

使用display ike sa命令，可以看到第一阶段的SA正常建立。

![2021072019322031.png][]

使用display ipsec sa命令可以看到IPsec SA的建立情况。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d0ajA2MTc_size_16_color_FFFFFF_t_70 2][]

问题又来了，这个地方的MTU成了1444字节。IPsec在外层，是1444字节，GRE在内层，是1468字节。最后到底会是多少呢？

# 验证隧道MTU #

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d0ajA2MTc_size_16_color_FFFFFF_t_70 3][]

可以发现，实际能通过的最大报文大小为1384字节，比单独使用IPsec封装少了16字节，但是GRE封装长度只有12字节啊，少的4个字节哪里去了？抓个包分析一下。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d0ajA2MTc_size_16_color_FFFFFF_t_70 4][]

这个地方我们捋一下，报文的封装结构应该是\[以太网包头\]\[外层IPv4包头\]\[ESP报文头\]\[GRE报文头\]\[GRE封装\]\[内层IPv4包头\]\[ICMP报文\]\[ESP-T校验字段\]，好像很复杂的样子。

反过来看，普通模式下IPsec SA中显示的MTU是1428字节，本次显示的是1444字节，也是少了16个字节。减掉GRE封装的12字节，还是少4个字节。看样子\[GRE报文头\]这部分应该是没有了，毕竟有20字节。那会不会是加密算法和IKE的问题，只能后面再验证了。

# 验证两端同子网 #

现在已经知道两端相同子网互通是没有问题了，但是上次IPsec实验有个问题就是不能查看traceroute路径，这次我们看一下。

![20210720193244605.png][]

很棒，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封装长度只有12字节，少的4个字节哪里去了？

[VXLAN_VXLAN]: https://blog.csdn.net/gtj0617/article/details/118529137?spm=1001.2014.3001.5501
[IPsec]: https://blog.csdn.net/gtj0617/article/details/118766324?spm=1001.2014.3001.5501
[GRE]: https://blog.csdn.net/gtj0617/article/details/118913088?spm=1001.2014.3001.5501
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d0ajA2MTc_size_16_color_FFFFFF_t_70]: /images/20220829/f7475a29f4124384a7aa36c7494ffe04.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d0ajA2MTc_size_16_color_FFFFFF_t_70 1]: /images/20220829/5fd39c1367f746c1b98c4ce3cb994419.png
[20210720193214679.png]: /images/20220829/b3610d5503df4078aef9ba90380fa0b0.png
[2021072019322031.png]: /images/20220829/0edf4f7d123a43ea857dd11b9809c998.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d0ajA2MTc_size_16_color_FFFFFF_t_70 2]: /images/20220829/227acc0e78fa40aeb3356e0cecf78e77.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d0ajA2MTc_size_16_color_FFFFFF_t_70 3]: /images/20220829/16c0399d9105425aa61ae96ed22c9a57.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d0ajA2MTc_size_16_color_FFFFFF_t_70 4]: /images/20220829/bec2a132d75548c1be9ce1b2a8c525df.png
[20210720193244605.png]: /images/20220829/f978e46ab70247669f7b78b1d88997f6.png