IPSEC 003 ---- IPSEC携手IKE，珠联璧合显神威

落日映苍穹つ 2024-04-18 22:28 60阅读 0赞

## 密钥管家IKE登场 ##

上回说到手工方式的IPSec VPN帮助天地会解决了总舵和分舵之间秘密通信的问题，但随着分舵数量的增加新的问题又出现了。手工方式下防火墙的加密和验证所使用的密钥都是手工配置的，为了保证IPSec VPN的长期安全，需要经常修改这些密钥。分舵数量越多，密钥的配置和修改工作量越大。随着天地会的壮大，IPSec VPN的维护管理工作越来越让人吃不消了。  
为了降低IPSec VPN管理工作量，天地会总舵主再访高人寻求灵丹妙药。灵丹已练，妙药天成――原来IPSec协议框架中早就考虑了这个问题――智能的密钥管家IKE（Internet Key Exchange）协议可以帮助解决这个问题。

IKE综合了三大协议：ISAKMP（Internet Security Association and Key Management Protocol）、Oakley协议和SKEME协议。ISAKMP主要定义了IKE伙伴（IKE Peer）之间合作关系（IKE SA，跟IPSec SA类似）的建立过程。Oakley协议和SKEME协议的核心是DH（Diffie-Hellman）算法，主要用于在Internet上安全地分发密钥、验证身份，以保证数据传输的安全性。有了IKE加盟，IPSec VPN的安全和管理问题不再困扰天地会，各地分舵申请建立VPN的流程终于可以进入“实施”状态了。

## 揭开ISAKMP本来面目 ##

IKE协议的终极目标是通过协商在总舵和分舵之间动态建立IPSec SA，并能够实时维护IPSec SA。为建立IPSec SA而进行的IKE协商工作是由ISAKMP报文来完成的，所以在部署IKE之前，强叔先领大家认识一下ISAKMP报文。ISAKMP报文封装如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70][]

**IP报文头**

*  源地址src：本端发起IKE协商的IP地址，可能是接口IP地址，也可能是通过命令配置的IP地址。
 *  目的IP地址Dst：对端发起IKE协商的IP地址，由命令配置。

**UDP报文头**  
IKE协议使用端口号500发起协商、响应协商。在总舵和分舵都有固定IP地址时，这个端口在协商过程中保持不变。当总舵和分舵之间有NAT设备时（NAT穿越场景），IKE协议会有特殊处理（后续揭秘）。

**ISAKMP报文头**

*  Initiator’s Cookie（SPI）和responder’s Cookie（SPI）：在IKEv1版本中为Cookie，在IKEv2版本中Cookie为IKE的SPI，唯一标识一个IKE SA。
 *  Version：IKE版本号1。
 *  Exchange Type：IKE定义的交互类型2。交换类型定义了ISAKMP消息遵循的交换顺序。
 *  Next Payload：标识消息中下一个载荷的类型。一个ISAKMP报文中可能装载多个载荷，该字段提供载荷之间的“链接”能力。若当前载荷是消息中最后一个载荷，则该字段为0。
 *  Type Payload：载荷类型，ISAKMP报文携带的用于协商IKE SA和IPSec SA的“参数包”。载荷类型有很多种，不同载荷携带的“参数包”不同。不同载荷的具体作用我们后面会结合抓包过程逐一分析。

说明：

1：IKE诞生以来，有过一次大的改进。老的IKE被称为IKEv1，改进后的IKE被称为IKEv2。二者可以看做是父子关系，血脉相承，基本功能不变；但青胜于蓝，后者有了长足的进步。  
2：IKEv1版本中可以在交换类型字段查看协商模式，阶段1分为两种模式：主模式和野蛮模式，阶段2采用快速模式。主模式是主流技术，野蛮模式是为解决现实问题而产生的。IKEv2版本中定义了查看创建IKE SA和CHILD SA（对应IKEv1的IPSec SA）的IKE\_SA\_INIT、IKE\_AUTH（创建第一对CHILD SA）、CREATE\_CHILD\_SA（创建后续的CHILD SA）。  
IKEv1和IKEv2的精华之处正是本文的重点，各位看官莫急，容强叔一一道来。

## IKEv1小试牛刀 ##

IKE最适合于在总舵和众多分舵之间建立IPSec VPN的场景，分舵越多IKE的优势越能凸显。为了讲解方便，这里仅给出总舵和一个分舵之间建立IPSec VPN的组网图。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 1][]  
   
相比手工方式，IKE方式仅增加了两步：配置IKE安全提议和IKE对等体。IKE安全提议主要用于配置建立IKE SA用到的加密和验证算法。IKE对等体主要配置IKE版本、身份认证和交换模式。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 2][]

<table> 
 <tbody> 
 <tr> 
 <td style="vertical-align:top;"> 配置项 </td> 
 <td style="vertical-align:top;"> 网关A </td> 
 <td style="vertical-align:top;"> 网关B </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> IKE安全提议 </td> 
 <td style="vertical-align:top;"> ike proposal 10 </td> 
 <td style="vertical-align:top;"> ike proposal 10 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> IKE对等体 </td> 
 <td style="vertical-align:top;"> ike peer b &nbsp;ike-proposal 10 &nbsp;undo version 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//IKEv1 exchange-mode&nbsp;main//主模式（缺省） &nbsp;remote-address 2.2.3.2//对端发起IKE协商的地址 &nbsp;pre-shared-key tiandihui2 </td> 
 <td style="vertical-align:top;"> ike peer a &nbsp;ike-proposal 10 undo version 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//IKEv1 exchange-mode&nbsp;main//主模式（缺省） remote-address 1.1.1.1//对端发起IKE协商的地址 &nbsp;pre-shared-key tiandihui2 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> ACL </td> 
 <td style="vertical-align:top;"> acl number 3001 rule 5 permit ip source 192.168.0.0 0.0.0.255 destination 172.16.2.0 0.0.0.255 </td> 
 <td style="vertical-align:top;"> acl number 3000 rule 5 permit ip source 172.16.2.0 0.0.0.255 destination 192.168.0.0 0.0.0.255 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> IPSec安全提议 </td> 
 <td style="vertical-align:top;"> ipsec proposal a transform esp &nbsp;encapsulation-mode tunnel &nbsp;esp authentication-algorithm md5 &nbsp;esp encryption-algorithm des </td> 
 <td style="vertical-align:top;"> ipsec proposal a transform esp &nbsp;encapsulation-mode tunnel &nbsp;esp authentication-algorithm md5 &nbsp;esp encryption-algorithm des </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> IPSec安全策略 </td> 
 <td style="vertical-align:top;"> ipsec policy policy1 11 isakmp &nbsp;security acl 3001 &nbsp;proposal a &nbsp;ike-peer b </td> 
 <td style="vertical-align:top;"> ipsec policy policy1 1 isakmp &nbsp;security acl 3000 &nbsp;proposal&nbsp;a &nbsp;ike-peer a </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 应用IPSec安全策略 </td> 
 <td style="vertical-align:top;"> interface GigabitEthernet0/0/1 ip address 1.1.1.1 255.255.255.0 ipsec policy policy1 </td> 
 <td style="vertical-align:top;"> interface GigabitEthernet0/0/1 ip address 2.2.3.2 255.255.255.0 ipsec policy policy1 </td> 
 </tr> 
 </tbody> 
</table>

说明：两条红色命令表示本例采用了IKEv1版本主模式。缺省同时开启IKEv1和IKEv2，关闭IKEv2后采用IKEv1版本进行协商。  
配置完成之后，总舵和分舵之间有互访数据流时即可触发建立IPSec VPN隧道，下面强叔通过抓包来为大家详解一下IKEv1的精妙之处。

## IKEv1招式拆解 ##

IKEv1版本分两个阶段来完成动态建立IPSec SA的任务：  
**阶段1-建立IKE SA：**阶段1采用主模式或野蛮模式协商。  
**阶段2-建立IPSec SA：**阶段2此采用快速模式协商。  
下面先介绍主模式+快速模式下的IPSec SA建立过程。

### 阶段1-建立IKE SA（主模式） ###

主模式下IKEv1采用3个步骤6条ISAKMP消息建立IKE SA。下面以网关A主动发起IKE协商为例进行讲解。  
 ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 3][]

**1. 协商IKE安全提议。**  
协商分两种情况：

*  发起方的IKE Peer中引用了IKE Proposal
 *  发起方的IKE peer中没有引用IKE Proposal

二种情况下响应方都会在自己配置的IKE安全提议中寻找与发送方相匹配的IKE安全提议，如果没有匹配的安全提议则协商失败。IKE Peer双方安全提议匹配的原则为协商双方有相同的加密算法、认证算法、身份认证方法和DH组标识（不包括IKE SA生存周期）。  
**说明：**通过IKEv1协议协商建立IPSec安全联盟时，采用本地生存周期和对端生存周期中较小的一个，不必保证隧道两端设备配置的生存周期相同（sa duration）。  
通过抓包可以看出ISAKMP消息的SA载荷中携带用于协商的IKE安全提议。以消息1为例：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 4][]  
   
**2. 使用DH算法交换密钥材料，并生成密钥。**  
网关A和B利用ISAKMP消息的Key Exchange和nonce载荷交换彼此的密钥材料。Key Exchange用于交换DH公开值，nonce用于传送临时随机数。由于DH算法中IKE Peer双方只交换密钥材料，并不交换真正的共享密钥，所以即使黑客窃取了DH值和临时值也无法计算出共享密钥，这一点正是DH算法的精髓所在。从抓包中可以看到IKE Peer双方交换密钥材料，以消息3为例：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 5][]  
   
密钥材料交换完成后，IKE Peer双方结合自身配置的身份验证方法各自开始复杂的密钥计算过程（预共享密钥或数字证书都会参与到密钥计算过程中），最终会产生三个密钥：

*  SKEYID\_a：ISAKMP消息完整性验证密钥――谁也别想篡改ISAKMP消息了，只要消息稍有改动，响应端完整性检查就会发现！
 *  SKEYID\_e：ISAKMP消息加密密钥――再也别想窃取ISAKMP消息了，窃取了也看不懂！

**以上两个密钥保证了后续交换的ISAKMP消息的安全性！**

*  SKEYID\_d：用于衍生出IPSec报文加密和验证密钥――最终是由这个密钥保证IPSec封装的数据报文的安全性！

**整个密钥交换和计算过程在IKE SA超时时间的控制下以一定的周期进行自动刷新，避免了密钥长期不变带来的安全隐患。**

**3. 身份认证**  
IKE Peer通过两条ISAKMP消息（5、6）交换身份信息，进行身份认证。目前有两种身份认证技术比较常用：

*  预共享密钥方式（pre-share）：设备的身份信息为IP地址或名称。
 *  数字证书方式：设备的身份信息为证书和通过证书私钥加密的部分消息Hash值（俗称签名）。

以上身份信息都由SKEYID\_e进行加密，所以在抓包中我们只能看到标识为“Encrypted”的ISAKMP消息，看不到消息的内容（身份信息）。以消息5为例：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 6][]  
   
预共享密钥是最简单、最常用的身份认证方法。这种方式下设备的身份信息可以用IP地址或名称（包括FQDN和USER-FQDN两种形式）来标识。当IKE Peer两端都有固定IP地址的时候，一般都用IP地址作为身份标识；当一端为动态获取IP地址的时候，没有固定IP地址的一端只能用名称来标识。本篇强叔给大家展示的案例为前者，后者晚些再讲。  
**这里有个小问题提醒大家关注：**  
总舵收到分舵1发来的身份信息后，需要用密钥（SKEYID\_a和SKEYID\_e）进行完整性验证和解密，只有先找到正确的预共享密钥才能计算出这两个密钥。但总舵网关为每个IKE Peer都配置了一个预共享密钥。怎么找呢？此时只能根据IKE Peer发来的ISAKMP报文的源IP地址（src）来查找预共享密钥，只要报文源地址与本端IKE Peer视图下remote-address命令配置的IP地址一致，就认为该视图下配置的pre-shared-key是分舵1的预共享密钥。  
以上是IPSec协议内部处理过程，不需要大家操心。**大家只要记住在IKE Peer两端都有固定IP地址的场景下，remote-address命令配置的IP地址要跟对端发起IKE协商的IP地址保持一致即可。这个IP地址的作用不仅仅是指定了隧道对端的IP地址，还参与了预共享密钥的查找。**  
阶段1协商完成后，进入阶段2。

### 阶段2-建立IPSec SA ###

在阶段2中IKEv1采用快速交换模式通过3条ISAKMP消息建立IPSec SA。由于快速交换模式使用IKEv1阶段1中生成的密钥SKEYID\_e对ISAKMP消息进行加密，所以我们抓到的报文都是加密的，看不到载荷里面的具体内容。故下面只能文字介绍一下每一步的作用。  
下面以网关A发起IPSec协商为例进行讲解。  
 ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 7][]

**1. 发起方发送IPSec安全提议、被保护的数据流（ACL）和密钥材料给响应方。**  
**2. 响应方回应匹配的IPSec安全提议、被保护的数据流，同时双方生成用于IPSec SA的密钥。**

IPSec对等体两端协商IPSec安全提议的过程跟协商IKE安全提议的过程类似，不再赘述。  
**IKEv1不协商ACL规则，建议两端设备配置的ACL规则互为镜像，避免IPSec SA协商失败。**  
IPSec对等体两端交换密钥材料（SKEYID\_d、SPI和协议1、nonce等参数），然后各自进行密钥计算生成用于IPSec SA加密验证的密钥，这样可以保证每个IPSec SA都有自己独一无二的密钥。由于IPSec SA的密钥都是由SKEYID\_d衍生的，一旦SKEYID\_d泄露将可能导致IPSec VPN受到侵犯。为提升密钥管理的安全性，**IKE提供了PFS（完美向前保密）功能**。启用PFS后，在进行IPSec SA协商时会进行一次附加的DH交换，重新生成新的IPSec SA密钥，提高了IPSec SA的安全性。  
说明：1、协议指AH和/或ESP协议。  
**3. 发起方发送确认结果。**  
协商完成后发送方开始发送IPSec（ESP）报文。  
 ![2019091711030391.png][]

检查IPSec VPN状态信息  
以总舵显示信息为例。

* **在总舵和分舵上查看IKE SA的建立情况。** 
 <FW\_A> **display ike sa** 
 current ike sa number: 2 
 \--------------------------------------------------------------------- 
 conn-id    peer                    flag          phase vpn 
 \--------------------------------------------------------------------- 
 40129      2.2.3.2                 RD|ST         v1:2  public 
 40121      2.2.3.2                 RD|ST         v1:1  public 
 这里统一显示了IKE SA（v1:1）和IPSec SA（v1:2）的状态，RD表示SA状态为READY。IKE Peer之间只有一个IKE SA，IKE SA是双向逻辑连接（不区分源和目的）。
 * **在总舵和分舵上查看IPSec SA的建立情况。** 
 <FW\_A> **display ipsec sa brief** 
 current ipsec sa number: 2 
 current ipsec tunnel number: 1 
 \--------------------------------------------------------------------- 
 Src Address     Dst Address     SPI        Protocol  Algorithm 
 \--------------------------------------------------------------------- 
 1.1.1.1         2.2.3.2         4090666525 ESP       E:DES;A:HMAC-MD5-96; 
 2.2.3.2         1.1.1.1         2927012373 ESP       E:DES;A:HMAC-MD5-96; 
 IPSec SA是单向的（区分源和目的），两个方向的IPSec SA共同组成一条IPSec隧道。 
 **说明：一般来说一条数据流对应一个IPSec SA。但当IPSec同时采用了ESP+AH封装时，一条数据流会对应两个IPSec SA。**
 *  在总舵和分舵上查看会话表。 
 <FW\_A > **display firewall session table** 
 11:01:45  2014/07/08 
  Current Total Sessions : 6 
   esp  VPN:public --> public 1.1.1.1:0-->2.2.3.2:0 
   icmp  VPN:public --> public 172.16.2.2:7264-->192.168.0.2:2048 
   icmp  VPN:public --> public 172.16.2.2:7520-->192.168.0.2:2048 
   icmp  VPN:public --> public 172.16.2.2:7776-->192.168.0.2:2048 
   icmp  VPN:public --> public 172.16.2.2:8032-->192.168.0.2:2048 
   icmp  VPN:public --> public 172.16.2.2:8288-->192.168.0.2:2048 
 防火墙会为IPSec VPN建立了会话表（1.1.1.1:0-->2.2.3.2:0）。

## ##

### 下面简单介绍一下野蛮模式 ###

配置命令**exchange-mode aggressive**即可将IKEv1的协商模式改为野蛮模式。抓包看一下野蛮模式的情况：

![20190917110404977.png][]

野蛮模式只用了3条ISAKMP消息就完成了阶段1的协商过程，阶段2仍旧是快速模式不变。  
 ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 8][]

发起方和响应方把IKE安全提议、密钥相关信息和身份信息一股脑地全放在一个ISAKMP消息中发送给对方，IKE协商效率提高了。但由于身份信息是明文传输，没有加密和完整性验证过程，IKE SA的安全性降低了。**既然这样不够安全，为什么野蛮模式还会出现？**  
在IPSec VPN出现的早期，由于主模式+预共享密钥身份认证方式下，IPSec需要通过对端的IP地址来在本地查找预共享密钥（主模式中已经详细解释了这个问题）。这种密钥查找方式在对端没有固定IP地址的情况下（比如IPSec NAT穿越场景，网络出口动态获取IP地址场景）行不通。此时，野蛮模式可以“野蛮”地解决这个问题。野蛮模式中“身份信息”没有加密，IPSec就直接用对端发送来的身份信息来查找预共享密钥即可。所以在IPSec VPN应用初期，野蛮模式主要用于解决没有固定IP地址的节点部署IPSec VPN的问题。**现在，IPSec VPN解决这个问题有很多方法，不安全的野蛮模式已经不是最好的选择了。**具体方法待后续再呈现给大家。

# #

## IKEv2应运而生 ##

IKEv1似乎已经很完美了，但用得久了仍旧会发现不尽人意之处。

*  协商建立IPSec SA的时间太长

IKEv1主模式协商一对IPSec SA，需要6（协商IKE SA）+3（协商IPSec SA）=9条消息。  
IKEv1野蛮模式协商一对IPSec SA，需要3（协商IKE SA）+3（协商IPSec SA）=6条消息。

*  不支持远程用户接入

IKEv1不能对远程用户进行认证。若想支持远程用户接入，只能借助L2TP，通过PPP来对远程用户进行AAA认证。  
这些问题怎么解决呢？办法总比问题多！IKEv2中完美的解决了这些问题。

IKEv2相比IKEv1：

*  协商建立IPSec SA的速度大大提升  
    正常情况IKEv2协商一对IPSec SA只需要2（协商IKE SA）+2（协商IPSec SA）=4条消息。后续每建立一对IPSec SA只会增加2条消息。
 *  增加了EAP（Extensible Authentication Protocol）方式的身份认证。  
    IKEv2通过EAP协议解决了远程接入用户认证的问题，彻底摆脱了L2TP的牵制。目前IKEv2已经广泛应用于远程接入网络中了。今天强叔只介绍IKEv2的基本协商过程，EAP认证留待后续再讲。

IKEv2的配置思路与IKEv1完全相同，只是细节稍有不同：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 9][]

说明：红色命令与IKEv1不同。缺省情况下，防火墙同时开启IKEv1和IKEv2协议。本端发起协商时，采用IKEv2，接受协商时，同时支持IKEv1和IKEv2。可以不关闭IKEv1。  
IKEv2协商IPSec SA的过程跟IKEv1有很大差别：

**1. 初始交换4条消息同时搞定IKE SA和IPSec SA。**  
初始交换包括IKE安全联盟初始交换（IKE\_SA\_INIT交换）和IKE认证交换（IKE\_AUTH交换）。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 10][]  
   
   
**第一个消息对（IKE\_SA\_INIT）：**负责IKE安全联盟参数的协商，包括IKE Proposal，临时随机数（nonce）和DH值。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 11][]   
SA载荷主要用来协商IKE Proposal。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 12][]  
   
KE（Key Exchange）载荷和Nonce载荷主要用来交换密钥材料。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 13][]  
   
IKEv2通过IKE\_SA\_INIT交换后最终也生成三类密钥：  
SK\_e：用于加密第二个消息对。  
SK\_a：用于第二个消息对的完整性验证。  
SK\_d：用于为Child SA（IPSec SA）衍生出加密材料。

**第二个消息对（IKE\_AUTH）：**负责身份认证，并创建第一个Child SA（一对IPSec SA）。  
目前三种身份认证技术比较常用：

*  预共享密钥方式（pre-share）：设备的身份信息为IP地址或名称。
 *  数字证书方式：设备的身份信息为证书和通过证书私钥加密的部分消息Hash值（签名）。
 *  EAP方式：采用EAP认证的交换过程属于扩展交换的内容，将在后面讲解。

以上身份信息都通过SKEYID\_e加密。  
创建Child SA时，当然也要协商IPSec安全提议、被保护的数据流。IKEv2通过TS载荷（TSi和TSr）来协商两端设备的ACL规则，最终结果是取双方ACL规则的交集（这点跟IKEv1不同，IKEv1没有TS载荷不协商ACL规则）。  
当一个IKE SA需要创建多对IPSec SA时，例如两个IPSec对等体之间有多条数据流的时候，需要使用创建子SA交换来协商后续的IPSec SA。  
**2. 子SA交换2条消息建立一对IPSec SA。**  
 ![20190917110941824.png][]

子SA交换必须在IKE初始交换完成之后才能进行，交换的发起者可以是IKE初始交换的发起者，也可以是IKE初始交换的响应者。这2条消息由IKE初始交换协商的密钥进行保护。  
IKEv2也支持PFS功能，创建子SA交换阶段可以重新进行一次DH交换，生成新的IPSec SA密钥。

## IKEv1和IKEv2大PK ##

**IKEv1和IKEv2的细节写了这么多，现在总结一下二者的异同点吧：**

<table> 
 <tbody> 
 <tr> 
 <td style="vertical-align:top;"> 功能项 </td> 
 <td style="vertical-align:top;"> IKEv1 </td> 
 <td style="vertical-align:top;"> IKEv2 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> IPSec SA建立过程 </td> 
 <td style="vertical-align:top;"> 分两个阶段，阶段1分两种模式：主模式和野蛮模式，阶段2为快速模式。 主模式+快速模式需要9条信息建立IPSec SA。 野蛮模式+快速模式需要6条信息建立IPSec SA。 </td> 
 <td style="vertical-align:top;"> 不分阶段，最少4条消息即可建立IPSec SA。 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> ISAKMP </td> 
 <td colspan="2" style="vertical-align:top;"> 二者支持的载荷类型不同 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 认证方法 </td> 
 <td style="vertical-align:top;"> 预共享密钥 数字证书 数字信封（较少使用） </td> 
 <td style="vertical-align:top;"> 预共享密钥 数字证书 EAP 数字信封（较少使用） </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> IKE SA完整性算法 </td> 
 <td style="vertical-align:top;"> 不支持 </td> 
 <td style="vertical-align:top;"> 支持 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> PFS </td> 
 <td style="vertical-align:top;"> 支持 </td> 
 <td style="vertical-align:top;"> 支持 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 远程接入 </td> 
 <td style="vertical-align:top;"> 通过L2TP over IPSec来实现 </td> 
 <td style="vertical-align:top;"> 支持 </td> 
 </tr> 
 </tbody> 
</table>

显然IKEv2以其更加快捷、更加安全的服务胜出，长江后浪推前浪又成为了没有任何悬念的事实。

# #

## IPSec协议框架总结 ##

安全协议（AH和ESP）、加密算法（DES、3DES、AES）、验证算法（MD5、SHA1、SHA2）、IKE、DH，好多的缩写，大家搞清楚他们之间的关系了么？强叔做了一下总结，看看能否帮助大家：

l  安全协议（AH和ESP）――IP报文的安全封装。穿上AH或/和ESP马甲的IP报文称为IPSec报文。此“马甲”并非一般的马甲，是**交织了“加密”和“验证”算法的刀枪不入的“软猬甲”。**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 14][]

说明：AH封装的验证范围实际要还更大一些，包括新的IP头。

l  加密算法（DES、3DES、AES）――IPSec报文的易容之术。IPSec数据报文采用对称加密算法进行加密，但只有ESP协议支持加密，AH协议不支持。另外，IKE协商报文也会进行加密。

l  验证（MD5、SHA1、SHA2）――IPSec报文的验明正身之法。加密后的报文经过验证算法处理生成数字签名，数字签名填写在AH和ESP报文头的完整性校验值ICV字段发送给对端；在接收设备中，通过比较数字签名进行数据完整性和真实性验证。

l  IKE――手握密钥管理大权的贴心管家。IPSec使用IKE协议在发送、接收设备之间安全地协商密钥、更新密钥。

l  DH算法――贴心管家的铁算盘。DH被称为公共密钥交换方法，它用于产生密钥材料，并通过ISAKMP消息进行交换，并最终在收发两端计算出加密密钥和验证密钥。

这些概念一一梳理过来，强叔不得不感叹IPSec协议设计者的强大――这么多新的老的协议、算法拼接起来如此天衣无缝，自此Internet的险恶被屏蔽在隧道之外！为了方便大家记忆这些缩写，强叔用一张简图概括之：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 15][]

写到这里，强叔心情舒畅，暗自为天地会网络的顺利推动得意。可是问题又来了――将IKE应用于IPSec VPN之后，那些有固定公网IP地址的大中型分舵的通信问题很快就解决了。但一些小型分舵IP地址不固定或只有私网IP地址，用常规的IKE方式部署IPSec VPN行不通。这种情况下怎么办呢？别担心，IKE的精彩之处还在于不出招则已、出招即能克敌；招招有戏、变化无穷，欲听详解请见下回分解。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/00aa83c97c7a4c8189e2d11eb86506cd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/38f0697d70684f41baac77b3fb257d02.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/7cb5f7aa022b430b9d73fe254e036627.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/0ebf02079b104184a57ef85a285392ca.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/ff236db7cabf40a6a1f4cf910fe5789b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/7e44593b4a9f456b97626b90ec9943d9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 6]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/ccb5528058494661a0a57bdf590e6a2e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 7]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/7c1c881c7e8a4f189076e62746e37757.png
[2019091711030391.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/46c8380dfe734f65a38bfbc9fffe50a4.png
[20190917110404977.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/eecd1b6d11f24c99acdfa24cd0aa76e4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 8]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/15f7e60fcc7944c3b726e8bff69977e0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 9]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/8fb27720b9bc4d54ae7ad00c925026a3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 10]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/5da2b3568b4b4be99a5f9ff281ed9359.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 11]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/14d6e64ce7d341d0aab97f25d4628143.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 12]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/32d142d3ba2641f49e2c0d96f6a5d9e1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 13]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/30871703760749d1ab5c958d945cba83.png
[20190917110941824.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/5b7eb86e970446c7ab3aba4dbd7a416c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 14]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/13f3682523ee42e88fdef7cc5f3bf8a2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 15]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/b58d17f7be0044a19df527272f20a85d.png