IPsec野蛮模式出现的原因

原因概述

其主要原因是因为在早期IKEv1的相关设备没有实现使用除了IP地址之外的其他标识符去表示一个IPsec隧道的一端，所以这就导致了动态IP地址的IPsec隧道的某一端出现了地址变动之后将无法重新建立IPsec隧道。我们在配置了IPsec的时候，如果没有特定地指定标识符，在报文中发送的identity都是在配置命令中指定的IP地址，这就导致IKEv1的主模式是无法根据它们的标识去找到对应的共享密钥（因为是动态地址，所以地址变换之后先前的配置就无法生效了），但是野蛮模式在早期支持使用除了IP地址的方式去标识自己，这就与IP解绑，所以即便动态IP地址依然可以成功建立IPsec隧道。

那么IKEv1主模式也使用其他标识符会怎么样？

以下实验我是用Linux上的StrongswanVPN软件进行的

在Linux上可以搭建点对点的ikev1到Ikev2的IPsec，或者策略模板式的IPsec

实验拓扑

                                           在主机1与主机2之间搭建Ikev1的IPsec

测试1 一条IPsec配置

主机1：自己标识为fuck，右边标识为cao  共享密钥：fuck

主机2：自己标识为cao，右边标识为fuck  共享密钥：fuck

主机1上配置两条IPsec隧道配置，主机2配置一条IPsec隧道配置，当只有一条用字符串标识的IPsec配置的时候，主机1是可以正常响应主机2发送过来的相关IPsec协商请求的，其主要原因不言而喻，因为我的主机上面就只有一个IPsec配置，除非你的IP配错了，否则怎么会这么巧把相关的IPsec配置发送给我

测试2  两条IPsec配置

主机1：自己标识为fuck  对端为cao 共享密钥为fuck

主机2：自己标识cao，对端为fuck 共享密钥为fuck

主机1上新增一组配置：自己标识为fuck 对端标识为kk（这个是虚假的用于测试捏造的标识符） 共享密钥 fuck

那么当这样配置之后，主机1将会出现共享密钥的选择问题，因为当主机1接受到对端发送过来的isakmp的协商请求的时候，它将无法确定该使用哪个共享密钥，因为共享密钥其实也是依据某个类型的标识，然后再将对应标识的共享密钥取出来并使用。如下图所示：

这是strongswan中保存预共享密钥的文件，可以看到预共享密钥使用隧道两端的标识符作为唯一标识并确定使用哪个预共享密钥。

那么当主机1接收到主机2发送过来的isakmp协商请求之后，它能够知晓的材料仅仅只有IP地址，而且本地的预共享密钥还有两个，那么此时主机1将不知道要使用哪个预共享密钥去进行IPsec隧道的建立。

野蛮模式面对该情况的解决

我们再来总结一下，IEKv1主模式因为IPsec隧道双方身份识别使用的是IP地址，那么这就导致当IPsec某一端的隧道发生了IP地址的变化之后，IPsec的隧道将会被破坏，从而导致IPsec隧道无法正常建立。野蛮模式在第一次数据包的交互过程中就将DH算法所需的材料，身份信息（也就是标识符），还有相关的IKE SA安全套件发送出去，于是对端就可以通过身份信息（也就是标识符）去取出相对应的IPsec预共享密钥。 

真实的情况

虽然说IKEv1使用标识符的时候可能会遇到预共享密钥无法选取的问题，但是其实真实情况是，主机1会针对每个IPsec的连接配置进行IPsec的连接建立，那么你在抓包的时候就会发现会出现一大堆的主模式协商请求报文，也就是说比如就算你配置了多个IPsec配置，它都会针对每个配置发送相对应的主模式的协商报文。（这是针对主机1上的配置是发起方的情况），如果主机1是被动协商方的话，那么主机1就会被动的接受相对应的报文，根据我的推断，应该是从预共享密钥中依次尝试来进行相关的协商的。

以上测试在LInux下的Strongswan软件测试