一、IKE简介
安全联盟SA
定义： 安全联盟是要建立IPSec 隧道的通信双方对隧道参数的约定，包括隧道两端的IP地址、隧道采用的验证方式、验证算法、验证密钥、加密算法、共享密钥以及生命周期等一系列参数。
SA由三元组来唯一标识，这个三元组包括安全参数索引SPI（Security Parameter Index）、目的IP地址和使用的安全协议号（AH或ESP）。其中，SPI是为唯一标识SA而生成的一个32位比特的数值，它在AH和ESP头中传输。在手工配置SA时，需要手工指定SPI的取值。使用IKE协商产生SA时，SPI将随机生成。
SA是单向的逻辑连接，因此两个IPSec对等体之间的双向通信，最少需要建立两个SA来分别对两个方向的数据流进行安全保护。
SA是IPSec的一个基本组成部分，SA是SADB的一个条目，它包含双方关于IKE和IPSec已经协商完毕的安全信息。
- IKE or ISAKMP SA：双向的，决定了IKE协议处理相关细节
- IPSec SA：单向的，与封装协议相关，决定了具体加密流量的处理方式。
两种类型的SA都是由IKE协议协商产生的。
建立IPSec SA的方式
有两种方式建立IPSec安全联盟：手工方式和IKE自动协商方式。二者的主要区别为：
-
密钥生成方式不同
手工方式下，建立SA所需的全部参数，包括加密、验证密钥，都需要用户手工配置，也只能手工刷新，在中大型网络中，这种方式的密钥管理成本很高；IKE方式下，建立SA需要的加密、验证密钥是通过DH算法生成的，可以动态刷新，因而密钥管理成本低，且安全性较高。
-
生存周期不同
手工方式建立的SA，一经建立永久存在；IKE方式建立的SA，其生存周期由双方配置的生存周期参数控制。
IKE介绍
IKE是一个复合协议。
因特网密钥交换IKE（Internet Key Exchange）协议建立在Internet安全联盟和密钥管理协议ISAKMP定义的框架上，是基于UDP（User Datagram Protocol）500 端口号，的应用层协议。
IKE协商两种SA：
-
IKE(ISAKMP) SA (阶段一）
-
IPSEC SA（阶段二）
IKE负责建立和维护IKE SAs 和 IPSec SAs。功能主要体现在如下几个方面：
- 对双方进行认证
- 交换公共密钥，产生密钥资源，管理密钥
- 协商协议参数（封装、加密、验证…..）
IKE的三个组件：
- SKEME：实现公钥加密认证的机制
- Oakley：基于到达两个对等体间的加密密钥的机制
- ISAKMP：在两个实体间进行分组格式及状态转换的消息交换的体系结构。
IKE有两个版本：
- IKEV1
- IKEV2——-华为默认
IKE与IPSec的关系
IKE为IPSec提供了自动协商密钥、建立IPSec安全联盟的服务，能够简化IPSec的使用和管理，大大简化IPSec的配置和维护工作。
IKE与IPSec的关系如上图所示，对等体之间建立一个IKE SA完成身份验证和密钥信息交换后，在IKE SA的保护下，根据配置的AH/ESP安全协议等参数协商出一对IPSec SA。此后，对等体间的数据将在IPSec隧道中加密传输。
IKE SA是一个双向的逻辑连接，两个对等体间只建立一个IKE SA。
IKE的安全机制
IKE具有一套自保护机制，可以在不安全的网络上安全地认证身份、分发密钥、建立IPsec SA：
身份认证
身份认证确认通信双方的身份（对等体的IP地址或名称），包括预共享密钥PSK（pre-shared key）认证、数字证书RSA（rsa-signature）认证和数字信封认证。
- 在预共享密钥认证中，认证字作为一个输入来产生密钥，通信双方采用共享的密钥对报文进行Hash计算，判断双方的计算结果是否相同。如果相同，则认证通过；否则认证失败。
- 在数字证书认证中，通信双方使用CA证书进行数字证书合法性验证，双方各有自己的公钥（网络上传输）和私钥（自己持有）。发送方对原始报文进行Hash计算，并用自己的私钥对报文计算结果进行加密，生成数字签名。接收方使用发送方的公钥对数字签名进行解密，并对报文进行Hash计算，判断计算结果与解密后的结果是否相同。如果相同，则认证通过；否则认证失败。
- 在数字信封认证中，发送方首先随机产生一个对称密钥，使用接收方的公钥对此对称密钥进行加密（被公钥加密的对称密钥称为数字信封），发送方用对称密钥加密报文，同时用自己的私钥生成数字签名。接收方用自己的私钥解密数字信封得到对称密钥，再用对称密钥解密报文，同时根据发送方的公钥对数字签名进行解密，验证发送方的数字签名是否正确。如果正确，则认证通过；否则认证失败。
DH
-
DH是一种公共密钥交换方法，它用于产生密钥材料，并通过ISAKMP消息在发送和接收设备之间进行密钥材料交换。然后，两端设备各自计算出完全相同的对称密钥。该对称密钥用于计算加密和验证的密钥。在任何时候，通信双方都不交换真正的密钥。DH密钥交换是IKE的精髓所在。
MD5、SHA1、DES、3DES、AES等算法都可以采用DH算法来共享对称密钥。
DH使用密钥组定义自己产生的密钥长度。密钥组长度越长，产生的密钥就越强壮。
-
IKE的精髓在于它永远不在不安全的网络上传送密钥，而是通过一些数据的交换，通信双方最终计算出共享的密钥，并且即使第三方截获了双方用于计算密钥的所有交换数据，也无法计算出真正的密钥。其中的核心技术就是DH（Diffie Hellman）交换技术。
PFS
- 短暂的一次性密钥系统称为“完善的前向保密“PFS（Perfect Forward Secrecy）
- 如果加密系统中有个密钥是所有对称密钥的衍生者（始祖），便不能认为那是一个“完美向前保密”的系统。在这种情况下、一旦破解了跟密钥，便能拿到其他衍生的所有密钥，收那些密钥保护的全部数据都会曝光。
- 在IPsec 里，PFS是通过在IPSec SA协商阶段重新进行一个DH交换来实现的。
- 完善的前向安全性PFS（Perfect Forward Secrecy）是一种安全特性，指一个密钥被破解，并不影响其他密钥的安全性，因为这些密钥间没有派生关系。IPSec SA的密钥是从IKE SA的密钥导出的，由于一个IKE SA协商生成一对或多对IPSec SA，当IKE的密钥被窃取后，攻击者将可能收集到足够的信息来导出IPSec SA的密钥，PFS通过执行一次额外的DH交换，保证IPSec SA密钥的安全。
ISAKMP报文格式
8 12 16 24 32
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 发起者 !
! Initiator Cookie !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 应答 !
! Responder Cookie !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 下一个载荷 ! MjVer ! MnVer ! 交换类型 ! 标志 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 消息 ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 长度 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Initiator Cookie ― Initiator Cookie：启动 SA 建立、SA 通知或 SA 删除的实体 Cookie。
- Responder Cookie ― Responder Cookie：响应 SA 建立、SA 通知或 SA 删除的实体 Cookie。
- Next Payload ― 信息中的 Next Payload 字段类型。
- Major Version ― 使用的 ISAKMP 协议的主要版本。
- Minor Version ― 使用的 ISAKMP 协议的次要版本。
- Exchange Type ―
表示所用的交换类型。这表示消息和载荷遵循所用的交换顺序。
交换类型 值
NONE 0
Base 1
Identity Protection 2
Authentication Only 3
Aggressive 4
Informational 5
ISAKMP Future Use 6 - 31
DOI Specific Use 32 - 239
Private Use 240 - 255- Flags ― 为 ISAKMP 交换设置的各种选项。
- Message ID ― 唯一的信息标识符，用来识别第2阶段的协议状态。
- Length ― 全部信息（头＋有效载荷）长（八位）。
IKE版本
IKE协议分IKEv1和IKEv2两个版本。IKEv2与IKEv1相比有以下优点：
1、简化了安全联盟的协商过程，提高了协商效率。
2、IKEv1使用两个阶段为IPSec进行密钥协商并建立IPSec SA：第一阶段，通信双方协商和建立IKE本身使用的安全通道，建立一个IKE SA；第二阶段，利用这个已通过了认证和安全保护的安全通道，建立一对IPSec SA。IKEv2则简化了协商过程，在一次协商中可直接生成IPSec的密钥并建立IPSec SA。IKEv1和IKEv2的具体协商过程请分别参见IKEv1协商安全联盟的过程和IKEv2协商安全联盟的过程。
3、修复了多处公认的密码学方面的安全漏洞，提高了安全性能。
IKE协商
SKEME：定义如何通过公共密钥技术（DH算法）实现密钥交换。
Oakley：提供了IPSec对各种技术的支持，例如对新的加密与散列技术，但并没有具体的定义使用什么样的技术。
ISAKMP：定义了消息交换的体系结构，包括两个IPSec对等体间分组形态和状态转变（定义封装格式和协商包交换的方式）。
二、IKEv1
IKE的两个阶段
采用IKEv1协商安全联盟主要分为两个阶段：
第一阶段，通信双方协商和建立IKE协议本身使用的安全通道，即建立一个IKE SA。IKE SA建立后对等体间的所有ISAKMP消息都将通过加密和验证，这条安全通道可以保证IKEv1第二阶段的协商能够安全进行。
第二阶段，利用第一阶段已通过认证和安全保护的安全通道，建立一对用于数据安全传输的IPSec安全联盟。
IKEv1协商阶段1支持两种协商模式：主模式（Main Mode）和野蛮模式（Aggressive Mode）。
经典版本的IKEv1有两个阶段：
-
阶段一 ： IKE SA
主模式（6个包）
野蛮模式（3个包）
-
阶段二：IPSec SA
快速模式（3个包）
主模式包含三次双向交换，用到了六条ISAKMP信息，野蛮模式只用到三条信息。
IKEv1主模式的协商过程
IKEv1阶段一协商过程
IKEv1的主模式协商：包含了三次双向交换，用到了六条ISAKMP信息。协商过程如下图所示：
IKEv1的协商过程总用用到了9个包。
这三次交换分别是：
-
消息①和②用于策略交换
发起方发送一个或多个IKE安全提议，响应方查找最先匹配的IKE安全提议，并将这个IKE安全提议回应给发起方。匹配的原则为协商双方具有相同的加密算法、认证算法、认证方法和Diffie-Hellman组标识。
-
消息③和④用于密钥信息交换
双方交换Diffie-Hellman公共值和nonce值，用于IKE SA的认证和加密密钥在这个阶段产生。
-
消息⑤和⑥用于身份和认证信息交换（双方使用生成的密钥发送信息），双方进行身份认证和对整个主模式交换内容的认证。
Efficient VPN仅支持野蛮模式。
IKE安全提议指IKE协商过程中用到的加密算法、认证算法、Diffie-Hellman组及认证方法等。
nonce是个随机数，用于保证IKE SA存活和抗重放攻击。
使用预共享秘钥进行身份验证主模式的详细过程
当做一个预共享秘钥认证时，主模式的协商如下：
follows:
Initiator Responder
---------- -----------
1 HDR, SA -->
2 <-- HDR, SA
3 HDR, KE, Ni -->
4 <-- HDR, KE, Nr
5 HDR*, IDii, HASH_I -->
6 <-- HDR*, IDir, HASH_R缩写名词的解释：
-
HDR ：是ISAKMP的标头。当记为 HDR* 表示该流量被加密。
-
SA： 是SA带有一个或多个提议的有效载荷。针对多个提议，只回复一个。
-
KE：秘钥交换
-
IDii和IDir——标识，通常要IP地址
HASH_I = prf(SKEYID,K| Ci | Cr| SAi | IDi )
HASH_R = prf(SKEYID, K| Ci | Cr | SAr | IDr ) -
Ni：第一个随机数，用于生成密钥
-
Nr：第二个随机数，用于生成密钥
-
Ni Nr—-代表随机数，通过KE交换素材得到公共的K值
-
K值为推导SKEYID使用
-
HASH值用进行身份数据验证。
HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b )
HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b )
//prf伪随机函数
//g^xy is the Diffie-Hellman shared secret.
// CKY-I and CKY-R are the Initiator's cookie and the Responder's cookie, respectively, from the ISAKMP header.
// SAi_b is the entire body of the SA payload (minus the ISAKMP generic header)-- i.e. the DOI, situation, all proposals and all transforms offered by the Initiator.报文协商参数拆解：
阶段一: IKE SA
主模式（6个包）
Initiator Responder
---------- -----------
-----------------------------------------------------------
1-2包，用于安全参数协商（明文）
HDR, SA -->
Ci SAi
<-- HDR, SA
Ci Cr SAr
SA安全联盟(协商各种参数 加密算法 验证算法 验证方式【预共享密钥 数字证书】 DH组 密钥有效期）
HDR拆解为Ci，Cr，分别代表Initiator cookie和Responder Cookie。第一个包Cr为0。
------------------------------------------------------------
3-4个包 交换密钥素材，以及产生密钥(明文）
HDR, KE, Ni -->
Ci Cr K Ni
<-- HDR, KE, Nr
Ci Cr k Nr
Ni Nr----代表随机数
通过KE交换素材得到公共的K值
K值为推导SKEYID使用 K = g^xy
SKEYID ------基准密钥
使用预共享密钥
SKEYID = prf(pre-shared-key, Ni|Nr)
使用数字证书
SKEYID = prf(Ni | Nr, K) -----基准密钥
通过SKEYID推导三个密钥
SKEYID_d = prf(SKEYID, K | Ci | Cr | 0) -----------推导密钥，衍生密钥
SKEYID_a = prf(SKEYID, SKEYID_d | K | Ci | Cr | 1)---------验证密钥
SKEYID_e = prf(SKEYID, SKEYID_a | K | Ci | Cr | 2)---------加密密钥
-----------------------------------------------------------
5-6 两个包 做身份验证 （加密）
采用预共享密钥5 6两个包
HDR*, IDii, HASH_I -->
Ci Cr
<-- HDR*, IDir, HASH_R
IDii和IDir------标识，通常要IP地址
HASH_I = prf(SKEYID,K| Ci | Cr| SAi | IDi )
HASH_R = prf(SKEYID, K| Ci | Cr | SAr | IDr )
采用数字证书的5 6两个包
HDR*, IDii, [ CERT, ] SIG_I -->
<-- HDR*, IDir, [ CERT, ] SIG_R
-----------------------------------------------------------------通过DH算法得出密钥：
阶段一的第1个包（明文）
第一包的作用是，协商发起发，发送IKE安全提议，给响应方
主模式的第一个包抓包示例内容：
首先当两个路由器或防火墙启用IPSEC的时候，我们以其中之一为起点。A->B，那么A开始发送IKE的数据报文。报文是UDP的类型，封装在端口500里面。
首先是第一个信息被发送，主要内容是COOKIE号码，标识一个唯一的IPSEC会话，也有防止重放的功能。它的建立是通常是基于IP地址，端口的号码，时间和日期等等进行一个散列算法，生成一个8位的随机数。对方的COOKIE为0。
内容还包含一个SA负载，还有提议负载，转换负载。sa的负载是定位这个ISAKMP是为了IPSEC工作。因为IKE是一个标准的协议，所以在SA负载中通过DOI，解释域，来说明这条消息交换用于IPSEC。
提议负载的内容包含一个提议号，协议ID，SPI，转换号，其中SPI为0，转换号指向了相应的转换负载
转换负载的内容是加密的参数，如des，dh算法，存活时间，hash算法等等。
阶段一的第2个包（明文）
第2个包的作用主要是：通过查找第一个包的安全提议。给发送者回复一个确认的安全提议。
下图是第二个包的抓包内容：
第二个包是响应方响应一个信息，主要内容就是对方的COOKIE号码，和一个提议和一个策略，注意，这个提议和策略是和开始里面的一个对应的，否则，就回一个失败信息。
阶段一的第3个包（明文）
第三个包的作用：如果发起方接受了安全提议，就给对方发送密钥生成信息，对方用来生成IKE的秘钥。
IKEv1主模式协商第三个包抓包示例：
初始方然后回应第三个信息，内容是自己的公钥，发给对方，注意，此处我的理解是素数已经交换完毕，公钥就是根据自己随机产生的私钥加上素数和一个产生器g三者来产生的。同时传输一个随机数NI。
阶段一第四个包（明文）
主要作用：协商相应方给协商发起方发送密钥生成信息，使得协议发起方能生成密钥。
IKEv1主模式协商第4个包抓包：
接收方回应自己的公钥给初始方。包含一个随机数NR。
然后双方各自计算出共享的密钥，一共有三个密钥，SKEYID_a，d，e，其中d是根据z=pfs（pre-shared key，cookie_i，cookie_ni，nl|0），其中d用来给第二阶段提供密钥的素材。a用来对IKE的数据进行认证，e用来加密整个IKE协商的数据。
K值为推导SKEYID使用
SKEYID ------基准密钥
使用预共享密钥
SKEYID = prf(pre-shared-key, Ni|Nr)
使用数字证书
SKEYID = prf(Ni | Nr, K)
通过SKEYID推导三个密钥
SKEYID_d = prf(SKEYID, K | Ci | Cr | 0) -----------推导密钥
SKEYID_a = prf(SKEYID, SKEYID_d | K | Ci | Cr | 1)---------验证密钥,对数据进行验证
SKEYID_e = prf(SKEYID, SKEYID_a | K | Ci | Cr | 2)---------加密密钥当使用预共享密钥认证与主模式时，密钥可以只能通过对等点的IP地址来标识，因为必须使用HASH_I，在启动程序处理IDir之前计算。野蛮模式允许更大范围的预共享密钥标识符被使用。此外，野蛮模式允许双方进行维护多个不同的预共享密钥，并确定正确的密钥一个特定的交换。
阶段一的第5个包（密文）
主要作用：发起方发送身份和验证数据。
IKEv1主模式协商第5个包抓包：
初始方开始继续协商，发送第五个信息，注意，此刻所有的负载信息是被ekey加密过的。信息主要包含两个内容，其中之一是标识负载，另一个是散列负载，标识负载的主要内容是包含自己的IP地址，就是我们所谓的ID_I，或者是主机名称。散列负载主要的内容是使用session_a进行的散列计 算，计算的参数有上述的Z，和两端的cookie，pre-share key ，提议，转换集，SA的内容。
阶段一的第6个包（密文）
主要作用: 协商响应方给发起方发送身份和验证数据。
IKEv1主模式协商第6个包抓包：
然后当接收方收到的时候进行确认，先解密，然后根据ID找到pre-key，然后进行相同的计算，得出散列的值，然后对比接收呼叫。
总结：在这个过程中，所有的数据都是被封装在UDP 500的端口内进行协商的。
IKEv1阶段二 快速模式协商过程
IKEv1协商阶段2的目的就是建立用来安全传输数据的IPSec SA，并为数据传输衍生出密钥。这一阶段采用快速模式（Quick Mode）。该模式使用IKEv1协商阶段1中生成的密钥对ISAKMP消息的完整性和身份进行验证，并对ISAKMP消息进行加密，故保证了交换的安全性。
PSec安全提议指IPSec协商过程中用到的安全协议、加密算法及认证算法等。
IKEv1阶段二协商过程：
阶段二的快速模式的协商如下：
Initiator Responder
----------- -----------
HDR*, HASH(1), SA, Ni
[, KE ] [, IDci, IDcr ] -->
<-- HDR*, HASH(2), SA, Nr
[, KE ] [, IDci, IDcr ]
HDR*, HASH(3) -->HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr )
HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci |
IDcr )
HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b)IKEv1协商阶段2通过三条ISAKMP消息完成双方IPSec SA的建立：
-
协商发起方发送本端的安全参数和身份认证信息。
安全参数包括被保护的数据流和IPSec安全提议等需要协商的参数。身份认证信息包括第一阶段计算出的密钥和第二阶段产生的密钥材料等，可以再次认证对等体。
-
协商响应方发送确认的安全参数和身份认证信息并生成新的密钥。
IPSec SA数据传输需要的加密、验证密钥由第一阶段产生的密钥、SPI、协议等参数衍生得出，以保证每个IPSec SA都有自己独一无二的密钥。
如果启用PSF，则需要再次应用DH算法计算出一个共享密钥，然后参与上述计算，因此在参数协商时要为PFS协商DH密钥组。
-
发送方发送确认信息，确认与响应方可以通信，协商结束。
快速模式第1个包，第2个包，第3个包都除了加密数据格式都相同：
第二阶段，当第一阶段结束后，根据session-d的密钥资源，然后继续进行两次交换：
第一次交换，首先，判断是否启用了PFS（完美转发安全），如果启用的话，根据pfs中定义的参数继续进 行一个协商。PFS是提议者向接收者提供建议 的属性。如果协商就支持，否则就不支持。它的作用是在快速模式中重新协商DH密钥的属性。这允许使用新的密钥进行ipsec加密，而不是使用第一阶段生产的密钥。
快速模式只有一次交换，DH交换必须马上发生。不能几次协商了。因此，两端的DH配置必须匹配。
当执行PFS的时候，再次执行DH算法，然后，重新生产密钥。
配置感兴趣流时的注意事项
在IKEv1中，双方的感兴趣刘必须互为镜像，不能取交集。而在IKEv2中可以取交集。
例如：在1.1.1.1/34 —-> 2.2.2.2/32 与 2.2.2.2/32 ——> 1.1.1.1/32 在IKEv1中可以协商。而1.1.1.1/34 —-> 2.2.2.2/32 与 2.2.2.0/24 —->1.1.1.0/24 在IKEv1中不可以协商，在IKEv2中可以协商成功。
注意：SKEYID-e用来加密包弧ISAMKP的协议的数据，而不是用来保护感兴趣流。
保护数据流的密钥用的是密钥是：KEYMAT。
无PFS
KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b).有PFS
KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b)> If PFS is not needed, and KE payloads are not exchanged, the new
> keying material is defined as
>
> KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b).
>
> If PFS is desired and KE payloads were exchanged, the new keying
> material is defined as
>
> KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b)
>
> where g(qm)^xy is the shared secret from the ephemeral Diffie-Hellman
> exchange of this Quick Mode.
>IKEv1野蛮模式的协商过程
野蛮模式协商过程
野蛮模式只用到三条信息：
消息①和②用于协商IKE安全提议，交换Diffie-Hellman公共值、必需的辅助信息（与密钥生成相关信息）以及身份信息。
消息②中对收到的第一个数据包进行确认，查找并返回匹配的参数，密钥生成信息和身份验证信息。
消息③用于响应方认证发起方，并建立IKE SA。
野蛮模式协商过程：
野蛮模式只用到三条信息：前两条消息①和②用于协商IKE安全提议，交换Diffie-Hellman公共值、必需的辅助信息以及身份信息，并且消息②中还包括响应方发送身份信息供发起方认证，消息③用于响应方认证发起方。
使用预共享秘钥进行身份验证野蛮模式的详细过程
当做一个预共享秘钥认证时，野蛮模式的协商如下：
Initiator Responder
----------- -----------
HDR, SA, KE, Ni, IDii -->
<-- HDR, SA, KE, Nr, IDir, HASH_R
HDR, HASH_I -->野蛮模式（3个包）
Initiator Responder
----------- -----------
第1包-------安全提议（各种协商） 密钥交换素材 随机数 身份ID
HDR, SA, KE, Ni, IDii -->
<-- HDR, SA, KE, Nr, IDir, HASH_R
第2包---------安全提议，密钥交换素材 随机数 身份ID HASH_R
第3包---------加密的环境
HDR*, HASH_I -->野蛮模式协商第一个包报文抓包：
主要携带了安全提议（各种协商） 密钥交换素材 随机数 身份ID等，发送给响应方。
野蛮模式协商第二个报文抓包：
第二个包：主要携带确认双方都支持的安全提议，密钥交换素材 随机数 身份ID HASH_R等，发送给协商发起方。
野蛮模式协商第三个包：
第三个包：的传输过程是加密的。主要用于响应方认证发起方。
主模式与野蛮模式的区别
与主模式相比，野蛮模式减少了交换信息的数目，提高了协商的速度，但是没有对身份信息进行加密保护。
- 交换的消息：主模式为6个包，野蛮模式为3个包，野蛮模式能够更快创建IKE SA
- NAT支持：对预共享密钥认证：主模式不支持NAT转换，而野蛮模式支持。而对于证书方式认证：两种模式都能支持
- 对等体标识：主模式只能采用IP地址方式标识对等体；而野蛮模式可以采用IP地址方式或者Name方式标识对等体。这是由于主模式在交换完3、4消息以后，需要使用预共享密钥来计算SKEYID，当一个设备有多个对等体时，必须查找到该对等体对应的预共享密钥，但是由于其对等体的ID信息在消息5、6中才会发送，此时主模式的设备只能使用消息3、4中的IP报文源地址来找到与其对应的预共享密钥；如果主模式采用Name方式，Name信息却包含在消息5、6中，而设备必须在消息5、6之前找到其对等体的预共享密钥，所以就造成了矛盾，无法完成Name方式的标识。
而在野蛮模式中，ID消息在消息1、2中就已经发送了，设备可以根据ID信息查找到对应的预共享密钥，从而计算SKEYID。但是由于野蛮模式交换的2个消息没有经过加密，所以ID信息也是明文的，也相应造成了安全隐患。 - 提议转换对数量：在野蛮模式中，由于第一个消息就需要交换DH消息，而DH消息本身就决定了采用哪个DH组，这样在提议转换对中就确定了使用哪个DH组，如果第一个消息中包含多个提议转换对，那么这多个转换对的DH组必须相同(和DH消息确定的DH组一致)，否则消息1中只能携带和确定DH组相同的提议转换对。
-
协商能力：由于野蛮模式交换次数的限制，因此野蛮模式协商能力低于主模式。
-
主模式常用，野蛮已经不推荐使用,推荐使用模板方式
-
两者之间的协商过程不同
-
场景不同
野蛮模式的场景：
与主模式相比，野蛮模式减少了交换信息的数目，提高了协商的速度，但是没有对身份信息进行加密保护。虽然野蛮模式不提供身份保护，但它可以满足某些特定的网络环境需求：
- 当IPSec隧道中存在NAT设备时，需要启动NAT穿越功能，而NAT转化会改变对等体的IP地址，由于野蛮模式不依赖于IP地址标识身份，使得采用预共享密钥验证方式时，NAT穿越只能在野蛮模式中实现。
- v 如果发起方的IP地址不固定或者无法预知，而双方都希望采用预共享密钥验证方法来创建IKE SA，则只能采用野蛮模式。
- 如果发起方已知响应方的策略，或者对响应者的策略有全面的了解，采用野蛮模式能够更快地创建IKE SA。
主模式场景：
要求两端都是固定IP地址。
三、IKEv2
IKEV2简介
- 定义在RFC4306 ，更新与 RFC 5996.
- 不兼容IKEv1，IKEv1不支持认证，IKEv2支持认证，EAP。
- 支持NAT穿越。
- IKEv2支持私密性、完整性、源认证。
- 工作在UDP 的 500 /4500端口。NAT-T用的是UDP4500端口。
IKE的安全机制
-
身份认证
确认通信算双方的身份（对等体的IP地址或者名称），包括：
预共享**PSK（pre-shared key）认证。
数字签名RSA（rsa-signature）认证。
-
身份保护
-
DH（Diffie-Hellman）**交换算法
-
完善的向前安全性PFS（Perfect Forward Secrecy）
短暂的一次性**系统称为“完美向前保密”
在IPSec里，PFS是通过在IPSec SA协商阶段重新进行一个DH交换来实现的
IKEv2协商安全联盟的过程
采用IKEv2协商安全联盟比IKEv1协商过程要简化的多。要建立一对IPSec SA，IKEv1需要经历两个阶段：“主模式＋快速模式”或者“野蛮模式＋快速模式”，前者至少需要交换9条消息，后者也至少需要6条消息。而IKEv2正常情况使用2次交换共4条消息就可以完成一对IPSec SA的建立，如果要求建立的IPSec SA大于一对时，每一对IPSec SA只需额外增加1次创建子SA交换，也就是2条消息就可以完成。
IKEv2定义了三种交换：初始交换（Initial Exchanges）、创建子SA交换（Create_Child_SA Exchange）以及通知交换（Informational Exchange）。
IKEv2中所有消息都以 “请求-响应” 的形式出现，响应方对发起方的消息进行确认，如果在规定的时间内没有收到确认报文，发起方需要对报文进行重传处理，提高了安全性。
IKEv2还可以防御拒绝服务Dos（Denial of service）攻击，在IKEv1中，当网络中攻击方一直重放消息，响应方需要通过计算后，对其进行响应而消耗设备资源，造成对响应方的Dos攻击，在IKEv2中，响应方收到请求后，并不急于计算，而是先向发起方发送一个Cookie类型的Notify载荷（即一个特定的数值)，两者之后的通信必须保持Cookie与发起方之间的对应关系，有效防御了Dos攻击。
初始交换
正常情况下，IKEv2通过初始交换就可以完成第一对IPSec SA的协商建立。IKEv2初始交换对应IKEv1的第一阶段，初始交换包含两次交换四条消息。
初始交换过程图：
消息①和②属于第一次交换（称为IKE_SA_INIT交换），以明文方式完成IKE SA的参数协商，包括协商加密和验证算法，交换临时随机数和DH交换。IKE_SA_INIT交换后生成一个共享密钥材料，通过这个共享密钥材料可以衍生出IPSec SA的所有密钥。
消息③和④属于第二次交换（称为IKE_AUTH交换），以加密方式完成身份认证、对前两条信息的认证和IPSec SA的参数协商。IKEv2支持RSA签名认证、预共享密钥认证以及扩展认证方法EAP（Extensible Authentication Protocol）。发起者通过在消息3中省去认证载荷来表明需要使用EAP认证。
IKEv2协商过程抓包，总共四个包：
交换消息
- 2个初始信息
- 2个认证信息
IKEV2报文协商详细过程
Initiator Responder
-------------------------------------------------------------------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2,
TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr}
字段说明：
AUTH Authentication
CERT Certificate，证书
CERTREQ Certificate Request
CP Configuration
D Delete
EAP Extensible Authentication
HDR IKE header (not a payload)，IKE头部
IDi Identification - Initiator
IDr Identification - Responder
KE Key Exchange，发起方提供的**交换材料、有限使用最高安全级别的DH组
Ni, Nr Nonce，随机数
N Notify
SA Security Association，安全关联参数
SK Encrypted and Authenticated
TSi Traffic Selector - Initiator
TSr Traffic Selector - Responder
V Vendor ID
IKEv2中的消息交换都是以IKE_SA_INIT 和 IKE_AUTH开始的。在IKEv1中称为阶段一。这些初始交换通常是由4个消息组成，在大于一对IPSec SA的建立中，可以增加子SA。
IKEv2的所有通信都是以request/response对组成。
第一对消息（IKE_SA_INIT）进行协商密码算法、交换nonces，和DH算法。生成SKEYSEED，后续的消息使用**进行加密和验证。
第二对消息（IKE_AUTH）操作在又IKE_SA_INIT所创建的IKE_SA之上。对前一对消息进行身份验证，交换身份和整数，并建立第一个CHILD_SA，这些消息的一部分是加密和完整的，使用通过IKE_SA_INIT交换建立的**来包加密。
初始交换之后所有的消息都是加密传输的。
IKEV2协商过程的第1个包
第一个包交换的信息如下：
IKE_SA_INIT: Message 1
发起方提供基本的SA（安全关联）参数和**交换材料。等同与IKEv1的主模式的第1和第3个包：
Initiator Responder
-------------------------------------------------------------------
HDR, SAi1, KEi, Ni -->
----------------------------------
KEi：发起方提供的**交换材料，优先级使用最高安全级别的DH组
发起方发送：HDR包含安全参数索引（SPIs）、版本号和flags。SAi1有效载荷声明了发起方支持的IKE SA加密算法。KE有效载荷是发送方的DH值，Ni为发起方的随机数。
第一个包：Responder SPI的值为0，Flags位的Initiator的值为1，标志位发起方。Message ID的值也为0，该值和下一个会回应方的Message ID值相同。用来标即区分一对request/response消息对。
IKEV2协商过程的第2个包
第2个包的信息交换如下：
IKE_SA_INIT: Message 2
接收方会一个可以接受的参数，并附带**交换内容和证书请求(可选)。等同于IKEv1的主模式的第2和第4个包。
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
------------------------------------------------
SAri:接收方选择的密码学算法
KEr：接收方选择的**交换材料
Nr：接收方的随机数
CertReq: 整数请求，可选
回应方：从发起方提供的SAi1负载中选择一个可接受的加密组套件，封装在SAr1中，并发送双方都支持的DH算法的最高级封装在KEr负载中，以及发送回应方的Nr随机值。
在回应方的报文中，SPIi为发起方的SPI,SPIr中填充自己生产的spi。Flags中的Response位置1，表示自己为回应方的报文。Message ID的值同第一个报文的Message ID，为0.
第1个和第2个包交换完成后，每一方都能生成SKEYSEED，所有的**都是从这个**推导出来的。以后的消息除了消息头都会被加密和完整性保护。加密和完整性保护的**都是来自SKEYSEED，分别称为SK_e,用于加密，SK_a,用于认证，做完整性保护。会为每个方向计算单独的SK_a和SK_e。
除了**来自DH算法的SK_e和SK_a之外，还会导出另一个两SK_d,用于生成子SA的**材料。符号SK{…}表示这些有效载荷已加密使用该方向的SK_e和SK_a保护完整性。
SKEYSEED = prf(Ni | Nr, g^ir)
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr }
= prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )
-------------------------------------------------------
IKE SA; SK_ai and SK_ar used as a key to the integrity protection algorithm for authenticating the component messages of subsequent exchanges;
SK_ei and SK_er used for encrypting (and of course decrypting) all subsequent exchanges;
and SK_pi and SK_pr, which are used when generating an AUTH payload.
The lengths of SK_d, SK_pi,
and SK_pr MUST be the preferred key length of the PRF agreed upon.
IKEV2协商过程的第3个包
第3个包的信息如下：
IKE_AUTH: Message 1
创建child SA相关的认证内容和参数（等于与IKEv1的主模式的第5个包和部分快速模式的包）。
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2,
TSi, TSr} -->
-------------------------------------------
SK ：该负载被加密并且完整性保护。
IDi:发起方的身份信息
Cert：发起方的整数，可选
CertReq：发起方的证书请求，可选
IDr：期望的相应方的身份信息，可选
AUTH: 发起方认证数据，没有EAP就没有这个字段，可选
SAi2，发起方Child SA转换集
TSi/TSr: Child SA流量选择器
符号SK{…}表示这些有效载荷已加密使用该方向的SK_e和SK_a保护完整性。
发起方：除了HDR未加密，其余都被加密。IDi是发起方的有效身份载荷，用来证明自己的身份和完整性保护。也可以在CERT中发送整数有效载荷记忆在CertReq有效宰割中的信任列表。如果包含任何CERT有效载荷，必须提供第一个证书，包含用于验证AUTH字段的公钥。
可选的有效负载IDr使发起者能够指定哪个响应者。当在有同一个IP地址的机器上可能有多个身份ID。如果响应者不接受发起方提出的IDr，响应者可能会使用其他一些IDr完成交换。如果发起方不接收相应方提供的IDr，发起方可以关闭这个SA协商。
Tsi，Tsr是流量选择器，可以用来协商双方的感兴趣流。在IKEv2中可以协商，取感兴趣流的交集。但是在IKEv1中不能协商，只能双方互相配置为镜像地址。
发起方使用SAi2负载来协商Child SA，SAi2用来描述CREATE_CHILD_SA的交换参数。
第3个报文中的报文头是明文的，其余都是密文传输。在该报文中的Flags中的Initiator位置1，表示是发起方的报文。Message ID区别于上一对消息，为1。下一个回应的报文的Message ID和这个值相同。其余消息被封装到了Encrypted and Authenticated载荷中。
IKEV2协商过程的第4个包
第4个包信息如下：
IKE_AUTH: Message 2
创建于child SA相关的认证内容和参数。等同于IKEv1主模式的第6个包和部分快速模式的包。
<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}
----------------------------------------------------------
SK: 负载被加密和完整性保护
IDr：相应方的身份信息
Cert：相应方的证书，可选
AUTH：相应方的认证数据，没有EAP就没有这个字段，可选
SAr2：相应方选择的Child SA转换集
TSi/TSr: Child SA流量选择器，感兴趣流
响应方：使用IDr有效载荷声明其身份，可选发送一个或多个证书（同样这个证书需要有用于验证AUTH的公钥），AUTH：验证第二消息的身份和完整性保护。SAr2字段用于发送创建CREATE_CHILD_SA的提议材料。
创建子SA交换
当一个IKE SA需要创建多对IPSec SA时，需要使用创建子SA交换来协商多于一对的IPSec SA。另外，创建子SA交换还可以用于IKE SA的重协商。
创建子SA交换包含一个交换两条消息，对应IKEv1协商阶段2，交换的发起者可以是初始交换的协商发起方，也可以是初始交换的协商响应方。创建子SA交换必须在初始交换完成后进行，交换消息由初始交换协商的密钥进行保护。
类似于IKEv1，如果启用PFS，创建子SA交换需要额外进行一次DH交换，生成新的密钥材料。生成密钥材料后，子SA的所有密钥都从这个密钥材料衍生出来。
通知交换
运行IKE协商的两端有时会传递一些控制信息，例如错误信息或者通告信息，这些信息在IKEv2中是通过通知交换完成的，如下图：
通知交换必须在IKE SA保护下进行，也就是说通知交换只能发生在初始交换之后。控制信息可能是IKE SA的，那么通知交换必须由该IKE SA来保护进行；也可能是某子SA的，那么该通知交换必须由生成该子SA的IKE SA来保护进行。
通知交换过程：
IKE的安全机制
IKE具有一套自保护机制，可以在网络上安全地认证身份、分发密钥、建立IPSec SA：
1）身份认证：
身份认证确认通信双方的身份（对等体的IP地址或名称），包括预共享密钥PSK（pre-shared
key）认证、数字证书RSA（rsa-signature）认证。
Efficient VPN仅支持预共享密钥认证。
2）在预共享密钥认证中，通信双方采用共享的密钥对报文进行Hash计算，判断双方的计算结果是否相同。如果相同，则认证通过；否则认证失败。
当有1个对等体对应多个对等体时，需要为每个对等体配置预共享的密钥。该方法在小型网络中容易建立，但安全性较低。
3）在数字证书认证中，通信双方使用CA证书进行数字证书合法性验证，双方各有自己的公钥（网络上传输）和私钥（自己持有）。发送方对原始报文进行Hash计算，并用自己的私钥对报文计算结果进行加密，生成数字签名。接收方使用发送方的公钥对数字签名进行解密，并对报文进行Hash计算，判断计算结果与解密后的结果是否相同。如果相同，则认证通过；否则认证失败。
使用数字证书安全性高，但需要CA来颁发数字证书，适合在大型网络中使用。
IKE支持的认证算法有：SHA2-256
身份保护：
身份数据在密钥产生之后加密传送，实现了对身份数据的保护。
IKE支持的加密算法有：3DES、AES-128、AES-192、AES-256。
DH
DH是一种公共密钥交换方法，它用于产生密钥材料，并通过ISAKMP消息在发送和接收设备之间进行密钥材料交换。然后，两端设备各自计算出完全相同的对称密钥。该对称密钥用于计算加密和验证的密钥。在任何时候，通信双方都不交换真正的密钥。DH密钥交换是IKE的精髓所在。
DH交换算法：
PFS
完善的前向安全性PFS（Perfect Forward Secrecy）通过执行一次额外的DH交换，确保即使IKE SA中使用的密钥被泄露，IPSec SA中使用的密钥也不会受到损害。
身份认证
在预共享密钥认证中，认证字作为一个输入来产生密钥，通信双方采用共享的密钥对报文进行Hash计算，判断双方的计算结果是否相同。如果相同，则认证通过；否则认证失败。
在数字证书认证中，通信双方使用CA证书进行数字证书合法性验证，双方各有自己的公钥（网络上传输）和私钥（自己持有）。发送方对原始报文进行Hash计算，并用自己的私钥对报文计算结果进行加密，生成数字签名。接收方使用发送方的公钥对数字签名进行解密，并对报文进行Hash计算，判断结果与解密的结果是否相同，相同则认证通过；否则认证失败。
在数字信封认证中，发送方首先随机产生一个对称密钥，使用接收方的公钥对此对称密钥进行加密（被公钥加密的对称密钥称为数字信封），发送方用对称密钥加密报文，同时用自己的私钥生成数字签名。接收方用自己的私钥解密数字信封得到对称密钥，再用对称密钥解密报文，同时根据发送方的公钥对数字签名进行解密，验证发送方的数字签名是否正确。如果正确，则认证通过；否则认证失败。
DH（Diffie-Hellman）密钥交换算法
DH算法是一种公开密钥算法。通信双方在不传送密钥的情况下通过交换一些数据，计算出共享的密钥。即时第三方截获了双方用于计算密钥的所有交换数据，也不足以计算出真正的密钥。DH保证了IKE不在网络上直接传输密钥，而是通过一系列数据交换，最终计算出双方共享的密钥。但DH没有提供双方身份的任何信息，不能确定交换的数据是否发送给合法方，第三方可以通过截获的数据与通信双方都协商密钥、共享通信，从而获取和传递信息，所以IKE需要身份认证对对等体身份进行认证。
密钥材料交换完成后，IKE peer 双方结合自身配置的身份验证方法各自开始复杂的密钥计算过程（预共享秘钥或数字证书都会参与到密钥计算过程中），最终会产生三个密钥（SKEYID为基础密钥，由其推导出其它三个密钥）：
SKEYID_a：ISAKMP消息完整性验证密钥–谁也别想篡改ISAKMP消息了，只要消息稍微有改动，响应端完整性检查就会发现。
SKEYID_e：ISAKMP消息加密密钥–再也别想窃取ISAKMP消息了，窃取了也看不懂
以上两个密钥保证了后续交换的ISAKMP消息的安全性。
SKEYID_d：用于衍生出IPSec报文加密和验证密钥–最终是由这个密钥保证IPSec封装的数据报文的安全性。
整个密钥交换和计算过程在IKE SA超时时间的控制下以一定的周期自动刷新，避免了密钥长期不变带来的安全隐患。
四、IKEv1 vs IKEv2
IKEV1与IKEV2的区别
- IKEv2：支持DPD，EAP认证方式，NAT-T，支持消息的确认（一端删除sa信息，另一端也会删除），支持自动协商感兴趣流，针对DOS的攻击防护，支持远程用户接入，最少4个包协商速度更快。
- IKEv1：远程用户接入必须结合L2TP、主模式9个包，野蛮模式6个包。不能协商感兴趣流，得互相配置为镜像。
可比较的角度：
-
IPsec建立过程，报文角度
阶段比较，IKEv1有两个阶段，IKEv2没有阶段。
-
IKEv1
IKEv1协商安全联盟主要分为两个阶段。
IKEv1阶段1的目的是建立IKE SA，它支持两种协商模式：主模式和野蛮模式。主模式用6条ISAKMP消息完成协商。野蛮模式用3条ISAKMP消息完成协商。野蛮模式的优点是建立IKE SA的速度较快。但是由于野蛮模式**交换与身份认证一起进行无法提供身份保护。
IKEv1阶段2的目的就是建立用来传输数据的IPSec SA，通过快速交换模式（3条ISAKMP消息）完成协商。
-
IKEv2
IKEv2简化了安全联盟的协商过程。IKEv2正常情况使用2次交换共4条消息就可以完成一个IKE SA和一对IPSec SA，如果要求建立的IPSec SA大于一对时，每一对SA只需额外增加1次交换，也就是2条消息就可以完成。
-
-
载荷角度
AUTH，TSi，TSr，EAP
-
认证方法
IKEv2支持EAP身份认证。IKEv2可以借助认证服务器对远程接入的PC、手机等进行身份认证、分配私网IP地址。IKEv1无法提供此功能，必须借助L2TP来分配私网地址。
-
支持远程接入
L2TP OVER IPSEC---------IKEV1解决方案
-
其他功能
NAT -T DPD
IKE SA的完整性算法支持情况不同。
IKE SA的完整性算法仅IKEv2支持，IKEv1不支持。
-
配置不同
-
DPD中超时重传实现不同。
retry-interval参数仅IKEv1支持。表示发送DPD报文后，如果超过此时间间隔未收到正确的应答报文，DPD记录失败事件1次。当失败事件达到5次时，删除IKE SA和相应的IPSec SA。直到隧道中有流量时，两端重新协商建立IKE SA。
对于IKEv2方式的IPSec SA，超时重传时间间隔从1到64以指数增长的方式增加。在8次尝试后还未收到对端发过来的报文，则认为对端已经下线，删除IKE SA和相应的IPSec SA。
-
IKE SA超时时间手工调整功能支持不同。
IKEv2的IKE SA软超时为硬超时的9/10±一个随机数，所以IKEv2一般不存在两端同时发起重协商的情况，故IKEv2不需要配置软超时时间。
IKv1与IKEv2的对比：
IKEv1v1的主要问题：
- 不支持远程用户接入
- 协商建立IPSec SA的时间太长
IKEv2的改进：
- IKEv1是一个混合型协议，其自身的复杂性不可避免地带来一些安全及性能上的缺陷，已经成为目前实现IPSec系统的瓶颈。
- IKEv2协议保留了IKEv1的基本功能，并针对IKEv1研究过程中发现的问题进行修订，同时兼顾简洁性、高效性、安全性和见健壮性的需要，整合了IKEv1的相关文档，由RFC4306单个文档替代。通过核心功能最小化规定，新协议极大提高了不同IPSec VPN系统的互操作性。
IKEv2与IKEv1相比有以下优点：
-
简化了安全联盟的协商过程，提高了协商效率。
IKEv1使用两个阶段为IPSec进行**协商并建立IPSec SA：第一阶段，通信双方协商和建立IKE本身使用的安全通道，建立一个IKE SA；第二阶段，利用这个已通过了认证和安全保护的安全通道，建立一对IPSec SA。IKEv2则简化了协商过程，在一次协商中可直接生成IPSec的**并建立IPSec SA。
-
修复了多处公认的密码学方面的安全漏洞，提高了安全性能。
-
加入对EAP（Extensible Authentication Protocol）身份认证方式的支持，提高了认证方式的灵活性和可扩展性。
EAP是一种支持多种认证方法的认证协议，可扩展性是其最大的优点，即若想加入新的认证方式，可以像组件一样加入，而不用变动原来的认证体系。当前EAP认证已经广泛应用于拨号接入网络中。
-
通过EAP协议解决了远程接入用户的认证问题，彻底摆脱了L2TP的牵制。目前IKEv2已经广泛应用于远程接入网络中了
五、IPSec VPN
IPSec VPN技术因其具有安全性高、成本低、部署灵活、扩展性好等优点，已成为企业站点间VPN部署的第一技术选择。
IPSec VPN不是一个单独的协议，而是由一组协议组成，因其包含的技术多、技术间关联关系多。
常见企业VPN接入拓扑模型：
IPSec中通信双方建立的连接叫做安全关联（IPSec SA），双方通过参数协商完成IPSec SA建立后，通过IPSec SA传输加密的数据报文进行通信。所以两个对等体间要想通过IPSec VPN通信，首先要建立IPSec SA。在进行IPSec SA建立时对等体间要进行IPSec SA参数协商，两端参数相同时才会建立成功。
IPSec VPN基础参数：
IPSec SA生成方式
手动指定生成IPSec SA
对等体通过手动指定IPSec SA协商参数生成IPSec SA，IPSec SA建立后没有生存周期限制，永不过期，除非手工删除，因此存在安全隐患。一般推荐在对等体数量较少且无法通过IKE协商建立IPSec SA场景下使用。
IKE协商生成IPSec SA
IKE用于动态建立并实时维护IPSec SA。IKE通过两个阶段来建立IPSec SA，第一阶段首先要协商建立IKE SA，第二阶段通过IKE SA协商建立IPSec SA。
IKE协商生成IPSec SA比手动指定生成IPSec SA存在以下优势：
- 适用场景丰富：手动指定方式必须对等体两端都有固定的公网IP地址，如一端对等体公网IP地址不固定必须使用IKE协商方式；
- 降低配置复杂度：手动指定方式需要手动配置SPI、密钥等信息，在对等体较多的场景配置量较大而不便于维护，IKE协商方式会通过IKE SA来生成和维护这些信息，降低配置复杂度及维护成本；
- 提高安全性：手动指定方式建立的IPSec SA密钥是静态的，建立后永不过期，IKE协商方式会通过IKE SA生成密钥，并且生命周期到期后进行老化重新生成，提高了安全性。
小提示：IKE协议目前有两个版本IKEv1与IKEv2，IKEv1目前较为常用，IKEv2与IKEv1配置思路相同，但协商过程与IKEv1有所区别，本文不进行讲解，本文中出现的IKE协议均代表IKEv1。
IKE SA协商模式
在IKE第一阶段有两种协商模式可协商建立IKE SA，主模式或者野蛮模式。主模式使用6个报文完成IKE SA建立，而野蛮模式使用3个报文完成IKE SA建立，与主模式相比野蛮模式减少交互报文数量从而加快了协商速度，但因对身份信息和认证信息采用明文交互，没有加密保护，因此不安全，作者不推荐使用。
野蛮模式早期设计主要为解决一端对等体公网IP地址不固定或没有公网IP地址的场景下主模式无法协商建立的问题，目前该问题可以通过“动态隧道”的方法更好地解决，所以推荐使用主模式。野蛮模式仅在锐捷设备与非锐捷设备建立IPSec使用主模式无法建立成功下使用，其他场景下不推荐使用。
IKE SA加密方式
IKE SA使用对称加密算法对数据进行加密和解密，保证数据的安全性。常用的对称加密算法有DES、3DES、AES等，这三个加密算法的安全性由高到低依次是：AES、3DES、DES，安全性高的加密算法实现机制复杂，运算速度慢。
IKE SA常用的对称加密算法：
IKE SA验证方式
IKE SA使用验证算法对报文完整性及来源合法性进行验证，常用的验证方式有MD5-HMAC、SHA1-HMAC等，是HASH算法和HMAC两种技术的结合。
HASH算法实现对报文进行完整性校验，常见的HASH算法有MD5、SHA1等，MD5算法的计算速度比SHA1算法快，而SHA1算法的安全强度比MD5算法高。
IKE SA常用的HASH算法：
HMAC(Hash-based Message Authentication Code)是一种基于HASH算法和密钥进行消息认证的方法，实现对报文来源的合法性进行验证，可以与任何HASH算法捆绑使用。
IKE SA密钥生成方式
DH（Diffie-Hellman）是一种非对称密钥算法，双方可通过仅交换一些数据，即可计算出双方的密钥，并且第三方捕获了其中的数据也无法计算得出密钥。DH产生的密钥用于数据报文加密及HMAC计算中。对等体两端DH组长度需指定为相同，常用的DH组长度有768bit（DH1）、1024bit（DH2）、1536bit（DH5）。
IKE SA认证方式
在IKE对等体之间在进行身份认证时支持通过预共享密钥认证和数字证书认证两种方式来确认对方身份的合法性。预共享密钥认证配置比较简单，是目前比较常用的认证方式。数字证书认证相对复杂但安全性较高，对安全性有较高要求的场景建议使用数字证书认证。
IKE SA身份标识
在IKE SA协商中对等体双方需要使用相同类型的身份标识，常用的身份标识类型有4种，IP地址、FQDN、USER-FQDN、证书DN。数字证书认证通常采用证书DN作为本地身份标识。预共享密钥认证默认采用IP地址作为本地身份标识，通常使用采用IP地址作为本地身份标识即可，若遇到以下两种场景推荐手动修改使用FQDN或USER-FQDN：
- 如果对等体的IP地址为域名形式，则必须使用FQDN或USER-FQDN；
- 对等体较多的场景下，建议采用FQDN或USER-FQDN，便于区分每个对等体对应是哪个分支。
小提示：身份标识类型与协商模式无关，任何身份标识在主模式或野蛮模式下均可使用，比如主模式使用FQDN作为身份标识或野蛮模式使用IP作为身份标识都可正常完成IKE SA协商，只要对等体两端使用相同类型身份标识即可。
IKE SA生命周期
由于IPSec SA协商是建立在IKE SA基础上的，因此为节省协商IPSec SA的时间，一般IKE SA生命周期（60秒到86400秒，缺省86400秒）比IPSec SA生命周期设置的长。当在进行IKE SA协商时，两端对等体设置的IKE SA生命周期不同不会造成IKE SA协商失败，而使用发送方设置的IKE SA生命周期。
IPSec SA安全协议
AH和ESP是IPSec的两种安全协议，用于实现IPSec在身份认证和数据加密的安全机制。
- AH协议（Authentication Header，协议号51），主要提供数据完整性确认、数据来源确认、防重放等安全特性。AH通常使用MD5-HMAC、SHA-HMAC等验证算法实现数据完整性；
- ESP协议（Encapsulating Security Payload，协议号50），主要提供数据完整性确认、数据加密、数据来源确认、防重放等安全特性。ESP通常使用DES、3DES、AES等加密算法实现数据加密，使用MD5-HMAC、SHA-HMAC等验证算法实现数据完整性。ESP协议相比AH协议多了支持数据加密、支持NAT穿越（NAT-T）这两大优势，是目前IPSec VPN较为常用的安全协议。
IPSec SA封装模式
封装模式用于指定安全协议的封装位置，有传输模式和隧道模式两种：
传输（Transport）模式下，AH头或ESP头插入IP头和传输层协议之间，不改变原始报文头，IPSec隧道的源和目的地址就是最终通信双方的源和目的地址，所以只能保护两个IPSec对等体之间相互通信。一般常用在使用GRE over IPSec或L2TP over IPSec协议的场景中，使用IPSec隧道保护GRE或L2TP对等体；
隧道（Tunnel）模式下，AH头或ESP头插在原始IP头之前，并且新生成一个IP头放在ESP头或AH头之前，所以可以保护两个IPSec对等体背后两个网络之间进行通信。一般常用在站点间网络互通的场景，是较常用的封装模式。
ESP协议两种封装模式下报文封装：
IPSec SA加密方式：
IPSec SA支持使用的加密方式与IKE SA相同，参考本文《IKE SA加密方式》小节。
IPSec SA验证方式：
IPSec SA支持使用的验证方式与IKE SA相同，参考本文《IKE SA验证方式》小节。
IPSec SA生命周期：
为了确保安全，IPSec SA将在经过一定时间（0或者120秒到86400秒，缺省3600秒）或达到一定通信量（0或2560KB到536870912KB，缺省4608000KB）之后超时，重新协商，并使用新的密钥。新IPSec SA在生命周期超时前30秒，或经由这条隧道的数据通信量距生命周期还有256KB时开始进行协商（根据哪个先发生）。
当在进行IPSec SA协商时，两端对等体设置的IPSec SA生命周期不同不会造成IPSec SA协商失败，而使用发起方设置的IPSec SA生命周期。
IPSec VPN高级功能
IPSec隧道自动建立（Set Autoup）
在默认情况下IPSec VPN配置完后，IPSec隧道是由数据流量触发后再协商建立的。配置IPSec隧道自动建立（Set Autoup）功能后，不管是否有数据流量触发，只要完成IPSec VPN配置后，设备会自行触发IPSec隧道建立。
IPSec链路探测（DPD/Track）
DPD探测
在默认情况下两端设备建立IPSec隧道后，当一端设备出现问题后另一端是无感知的，另一端设备会继续通过IPSec隧道发送数据给故障设备导致数据通信中断。此时需要等待IPSec隧道超时后故障IPSec隧道才会中断（IPSec隧道默认超时时间为一小时）。
DPD探测是通过发送IKE报文确认对端设备IKE SA状态是否正常的一种探测机制，当探测到对端IKE状态异常时，会清除对应的IKE SA和IPSec SA。
DPD探测有两种工作模式：
- 按需探测模式（On-demand），在超过配置的探测时间且当有数据报文发送时，设备会发送DPD消息探测对端设备是否正常，当发送5次DPD信息都没有收到对端设备回包会认为对端IKE SA状态异常；
- 周期探测模式（Periodic），设备会根据配置的探测时间周期性主动发送 DPD 消息探测对端设备是否正常，当发送5次DPD信息都没有收到对端设备回包会认为对端IKE SA状态异常。
综上按需探测模式比周期探测模式会发送更少的DPD信息只在数据报文发送前检测，节约设备资源及网络带宽资源，但探测到对端设备故障的时间会比周期探测模式长，读者根据自身业务需求使用合适模式进行DPD探测即可。
Track探测
DPD探测通过交互IKE报文可以探测到对端设备IKE SA状态是否正常，对于IKE SA状态正常而IPSec SA异常的情况DPD探测就无能为力了，这种情况同样会导致IPSec业务中断。Track探测通过定期发送ICMP或UDP报文探测IPSec实际业务是否正常，当Track探测到IPSec业务不通时会清除对应的IPSec SA进行重新协商。一般建议同时配置DPD探测和Track探测。
NAT穿越（NAT-T）
设备默认开启NAT穿越（NAT-T）功能，用于解决当建立IPSec VPN的两台设备间存在NAT设备ESP报文无法通过的问题。ESP报头封装在IP层之上IP协议号50所以无法通过NAT设备, NAT-T通过在ESP报文之上封装4500端口的UDP报头解决该问题。
NAT-T在ESP报文之上封装4500端口的UDP报头：
在IKE协商的第一阶段（主模式第1、2个报文、野蛮模式第1个报文）支持NAT-T的设备在发送IKE报文中会携带一个检测NAT-T能力的Vendor ID的载荷，当两端设备都携带这个字段就会进行NAT-T协商。当检测双方都支持NAT-T随后（主模式第3、4个报文、野蛮模式第2个报文）会携带一个NAT-D的载荷，NAT-D载荷中包含自己IP地址和端口的HASH值，对端设备收到这个值后会与收到的实际IP地址和端口的Hash值做对比，如果相同说明中间未经过NAT设备，否则说明中间经过NAT设备。如果NAT-T检测到中间经过NAT设备，设备会在下一个报文（主模式第5、6报文、野蛮模式第3个报文）开始插入一个4500端口的UDP报头，至此NAT-T工作结束。
动态隧道（Crypto Dynamic-map）
一般情况下，两端设备都有公网IP地址，配置时两端使用静态隧道的方式相互指定对端公网IP地址进行IPSec隧道建立。实际中也会遇到一端有公网IP地址而另一端没有固定公网IP地址或者没有公网IP地址的情况，这种情况两端都使用静态隧道的方式就无法建立IPSec隧道。使用动态隧道配置时无需指定对端IP地址、身份、感兴趣流等，有公网IP地址的一端使用动态隧道可解决另一端没有固定公网IP地址或者没有公网IP地址的问题。此外，如果本端需要建立大量IPSec VPN的对等体也可以使动态隧道，减少配置量。
反向路由注入（RRI）
在完成IPSec配置后我们要配置去往对端网段的静态路由，如果感兴趣流网段较多人为手动配置及维护这些路由有些不便。开启反向路由注入功能，当IPSec隧道建立完成后会自动产生相应的静态路由（目的地址是对端感兴趣流地址，下一跳是对端公网IP地址）注入到路由表中，当IPSec隧道断开后对应的路由也会消失。反向路由会结合IPSec隧道的建立信息自动生成对端网段路由，这样便能动态地完成路由的添加与删除，避免大量人为配置。此外，在设备存在多出口场景，还可以通过反向路由注入进行多出口上IPSec隧道的切换。
使用动态路由协议（GRE over IPSec/L2TP over IPSec）
在IPSec网络中只能通过静态路由配置到对端网段的路由，IPSec对等体之间无法使用动态路由协议进行路由学习，反向路由注入可以一定程度上解决感兴趣流网段较多、静态路由维护成本高的问题，如果希望使用动态路由协议进一步降低路由维护成本，可以使用GRE over IPSec VPN或者L2TP over IPSec VPN，使用GRE或者L2TP建立VPN隧道，然后再使用IPSec隧道保护这个VPN隧道，此时既保证了数据安全又可在VPN隧道两端使用动态路由协议。
IPSec VPN典型场景
单总部单分支场景
场景Ⅰ
IPSec VPN典型场景Ⅰ配置表：
场景Ⅱ
IPSec VPN典型场景Ⅱ配置表：
场景Ⅲ
IPSec VPN典型场景Ⅲ配置表：
场景Ⅳ
IPSec VPN典型场景Ⅳ配置表：
场景Ⅴ
IPSec VPN典型场景Ⅴ配置表：
场景Ⅵ
IPSec VPN典型场景Ⅵ配置表 ：
多总部多分支场景
场景Ⅶ
IPSec VPN典型场景Ⅶ配置图 ：
场景Ⅷ
IPSec VPN典型场景Ⅷ配置表：
在多总部多分支场景下，除以上两种单出口情况外，多出口的情况也较为常见。部署时将以上两种多总部多分支场景与单总部单分支场景下多出口的情况结合使用即可。
六、IPSec VPN部署实战
其中IPSec VPN可以实现企业站点之间搭建安全的数据传输通道，将接入Internet的企业分支机构与总部网络通过安全隧道互联，实现资源、信息共享。
无线企业路由器作为功能全面的企业无线VPN路由器，提供多类VPN功能。
某公司需要将北京总部与广州分公司通过VPN互联，实现相互访问内部资源，要求隧道安全。网络情况如下：
保证传输隧道安全，需要配置为隧道模式，详细的IPSec参数设置在设置步骤中规定。
注意：可以选择设置更高级别的加密和验证算法，但需确保总部-分部的安全提议配置相同。
注意：“选择接口”指与对端路由器建立VPN隧道的接口。
选择 启用 并点击 设置，开启IPSec VPN功能。
至此，总公司路由器的IPSec VPN设置完成。
新增之后务必启用IPSec功能。
注意：添加信息需与总部设置的规则对应。
至此，总部与分部的IPSec安全隧道建立成功，两个网络之间相互可以访问。
如果有多个分部需要与总部建立IPSec隧道，需要在总部路由器进行如下配置：
1、为分部设置IKE安全策略（IKE安全提议可以共用）。
2、为分部设置IPSec安全策略（IPSec安全提议可以共用）。
分部路由器进行对应配置即可。
七、IPSec VPN故障排查
IPSec VPN使用时难免会遇到隧道建立失败的情况。一般IPSec VPN故障可分为三类：
IKE SA建立失败；IPSec SA建立失败；IPSec SA建立成功但数据不通。
在遇到IPSec VPN故障时读者可查看发起方和接收方状态并对比如下IPSec对等体状态解析图确认属于哪类故障，然后根据每类故障常见原因进行排查。
查看IPSec对等体状态：
IPSec对等体状态解析：
IKE报文交互知识点回顾
在分析每类故障常见发生原因前，作者首先带大家回顾下IKE报文交互情况，只有知道了每个报文在交互什么内容，在遇到IPSec建立停留在某一阶段时，我们才知道排查的方向。IKE通过两个阶段来建立IPSec SA，第一阶段采用主模式或者野蛮模式建立IKE SA，第二阶段采用快速模式建立IPSec SA。
IKE第一阶段（主模式）：
- 第1-2个报文携带IKE策略，进行IKE策略协商，IKE策略包含：加密算法、HASH算法、DH组、验证方式、IKE SA生命周期，
- 第3-4个报文携带DH算法需要的材料，进行DH算法计算生成密钥，
- 第5-6个报文携带身份信息及认证信息，进行对等体间的认证，完成IKE SA建立。需要注意的是从第5个报文开始有两处变化，第一点是报文开始被加密保护，第二点是如果存在NAT穿越的情况UDP端口号将从500变为4500
主模式报文交互流程及对等体状态：
IKE第一阶段（野蛮模式）：
- 第1个报文发送方发送IKE策略、DH算法需要的材料、身份信息，IKE策略包含：加密算法、HASH算法、DH组、验证方式、IKE SA生命周期；
- 第2个报文接收方回应匹配的IKE策略，发送DH算法需要的材料、身份信息、认证信息；
- 第3个报文发送方发送认证信息完成认证，完成IKE SA建立。如果存在NAT穿越的情况从该报文开始UDP端口号从500变为4500。
野蛮模式报文交互流程及对等体状态：
IKE第二阶段：
- 第1个报文发送方发送IPSec转换集、感兴趣流，进行IPSec参数协商，IPSec转换集包含：封装模式、安全协议、加密算法、HASH算法、IPSec SA生命周期。另外如果开启PFS还会携带DH算法需要的材料，进行DH算法计算生成新的密钥；
- 第2个报文接收方回应匹配的IPSec策略、感兴趣流及DH算法需要的材料(如果开启PFS)；
- 第3个报文发送方进行结果确认，双方完成IPSec SA建立。
小提示：PFS（Perfect Forward Secrecy）是一种安全机制，默认情况下IPSec SA会直接使用IKE SA通过DH算法生成的密钥，开启PFS机制后，IPSec SA在协商时会在额外进行一次DH密钥交换算法，使IPSec SA使用的密钥与IKE SA使用的密钥不同，提高安全性。
IKE SA建立失败故障原因分析
IKE第一阶段IKE SA建立失败原因：
IPSec SA建立失败故障原因分析
IKE第二阶段IPSec SA建立失败原因：
IPSec SA建立成功但数据不通故障原因分析
IPSec SA建立成功但数据不通原因：
