IPSec VPN工作原理

## 一、IPSec VPN工作原理
昨天我们大致了解了IPSec是什么，今天来学习下它的工作原理。

IPsec的**基本工作流程**如下：
- 通过IKE协商第一阶段协商出IKE SA。
- 使用IKE SA加密IKE协商第二阶段的报文，即IPsec SA。
- 使用IPsec SA加密数据。

![IPsec基本工作流程](/media/202412/2024-12-05_105003_5891960.7577863234935128.png)

简单理解就是先创建一条安全协商的道路（IKE SA），然后通过IKE SA经过算法达到一个秘钥（IPSec SA）,接着使用IPSec SA对传输的流量进行加密与验证，这第三步就涉及到哪些流量需要加密，我们需要通过一些方式将对应流量引入到IPSec VPN隧道中来进行传输。

## 二、IKE 协商
前面我们学习了IPSec双方需要协商出一个SA来进行算法的匹配，一般情况下我们使用**IKE方式建立IPsec SA**。IKE是建立在ISAKMP定义的框架上，是基于UDP的应用层协议。它为IPsec提供了自动协商密钥、建立IPsec安全联盟的服务，能够简化IPsec的配置和维护工作。

简单说就是我们通过IKE这个框架协商出双方认可的加密算法、认证算法、传输模式等等。而IKE目前有两个版本：IKEv1和IKEv2。

### 2.1 IKEv1
采用IKEv1协商安全联盟主要分为两个阶段：
- 第一阶段：通信双方协商并建立IKE协议本身使用的安全通道，即建立一个IKE SA；
- 第二阶段：利用第一阶段已通过认证与安全保护的安全通道，建立一对用于数据安全传输的IPsec SA。

![IKEv1](/media/202412/2024-12-05_105019_8144600.46394833372378597.png)

**IKEv1协商第一阶段介绍：**

IKEv1协商**第一阶段的目的是建立IKE SA**。IKE SA建立后对等体间的所有ISAKMP消息都将通过加密和验证，这条安全通道可以**保证IKEv1第二阶段的协商能够安全进行。**

IKEv1协商第一阶段支持两种协商模式：**主模式（Main Mode）** 和**野蛮模式（Aggressive Mode）**。

![IKEv1协商模式](/media/202412/2024-12-05_105043_9423590.8549038906712915.png)

**主模式：**

主模式包含三次双向交换，用到了六条ISAKMP信息，协商过程如图1所示。这三次交换分别是：
- 消息①和②用于提议交换，发起方发送一个或多个IKE安全提议，响应方查找最先匹配的IKE安全提议，并将这个IKE安全提议回应给发起方。匹配的原则为协商双方具有相同的加密算法、认证算法、认证方法和Diffie-Hellman组标识。
- 消息③和④用于密钥信息交换，双方交换Diffie-Hellman公共值和nonce值，用于IKE SA的认证和加密密钥在这个阶段产生。
- 消息⑤和⑥用于身份和认证信息交换（双方使用生成的密钥发送信息），双方进行身份认证和对整个主模式交换内容的认证。

**野蛮模式：**

野蛮模式只用到三条信息，前两条消息①和②用于协商IKE安全提议，交换Diffie-Hellman公共值、必需的辅助信息以及身份信息，并且消息②中还包括响应方发送身份信息供发起方认证，消息③用于响应方认证发起方。

与主模式相比，野蛮模式减少了交换信息的数目，提高了协商的速度，但是没有对身份信息进行加密保护。

实际情况下**如果双方都有公网IP使用主模式，如果一方是拨号网络使用野蛮模式，因为IP不固定**，而且野蛮模式需要协商发起方主动向固定IP的一端发起，野蛮模式安全性相对较低。

**IKEv1协商第二阶段介绍：**

IKEv1协商第二阶段的目的是建立用来安全传输数据的IPsec SA，并为数据传输衍生出密钥。

第二阶段采用快速模式（Quick Mode）。该模式使用IKEv1协商第一阶段中生成的密钥对ISAKMP消息的完整性和身份进行验证，并对ISAKMP消息进行加密，故保证了交换的安全性。

![快速模式协商过程](/media/202412/2024-12-05_105103_1378330.1959152518440418.png)

至此IKEv1就成功协商出了IKE SA和IPSec SA用于数据加密。

### 2.2 IKEv2
IKEv2简化了IKEv1协商SA的过程。**IKEv2通常使用2次交换共4条消息就可以完成一对IPsec SA的建立**，如果要求建立的IPsec SA大于一对时，每一对IPsec SA只需额外增加1次创建子SA交换，也就是2条消息就可以完成。

IKEv2定义了三种交换：**初始交换**（Initial Exchanges）、**创建子SA交换**（Create_Child_SA Exchange）以及**通知交换**（Informational Exchange）。

#### 2.2.1 初始交换
IKEv2通过初始交换就可以完成第一对IPsec SA的协商建立。初始交换包含两次交换四条消息。

![IKEv2初始交换介绍](/media/202412/2024-12-05_105122_1356430.7080184252467189.png)

**工作过程：**
- 消息①和②属于第一次交换（称为IKE_SA_INIT交换），以明文方式完成IKE SA的参数协商，包括协商加密和验证算法，交换临时随机数和DH交换。IKE_SA_INIT交换后生成一个共享密钥材料，通过这个共享密钥材料可以衍生出IPsec SA的所有密钥。
- 消息③和④属于第二次交换（称为IKE_AUTH交换），以加密方式完成身份认证、对前两条信息的认证和IPsec SA的参数协商。IKEv2支持RSA签名认证、预共享密钥认证以及扩展认证方法EAP（Extensible Authentication Protocol）。发起者通过在消息3中省去认证载荷来表明需要使用EAP认证。

就是如果是一条IPSec SA的建立只需要初始交换就可以完成，不需要用到子SA交换等等，更加简单快捷。

报文抓包如下：

只需要4个报文即可完成协商。

![IKEv2报文](/media/202412/2024-12-05_105156_5578910.7688475496249013.png)

IKEv2是一次性把需要协商的数据都发送过去的模式。

![报文内容](/media/202412/2024-12-05_105213_0104920.7284385674491876.png)

**IKEv2的初始交换中，并没有直接区分为主模式（Main Mode）和野蛮模式（Aggressive Mode）这两种模式，而是通过初始交换（Initial Exchanges）来完成类似于IKEv1中这两种模式的协商过程。** 在IKEv2中，初始交换包括IKE_SA_INIT交换和IKE_AUTH交换，这两个交换过程顺序完成后，可以建立一个IKEv2 SA和一对IPsec SA。

具体来说，IKEv2的初始交换配置如下：
- IKE_SA_INIT交换：这个交换完成IKEv2 SA参数的协商以及密钥交换。它对应于IKEv1的主模式的第1、3个包，以及野蛮模式的第1、2个包。
- IKE_AUTH交换：这个交换完成通信对等体的身份认证以及IPsec SA的创建。它对应于IKEv1的主模式的第5、6个包，以及野蛮模式的第3个包。

在IKEv2中，通过配置不同的认证方法和参数，可以实现类似于IKEv1中主模式和野蛮模式的功能。例如，如果需要快速完成身份认证和密钥交换，可以使用类似于野蛮模式的配置，减少消息交换的数量。如果需要更安全的身份认证过程，可以使用类似于主模式的配置，增加消息交换的数量以提供更强的安全性。

#### 2.2.2 创建子SA交换介绍
当一个IKE SA需要创建多对IPsec SA时，需要使用创建子SA交换来协商多于一对的IPsec SA。创建子SA交换还可以用于IKE SA的重协商。

创建子SA交换包含一个交换两条消息，对应IKEv1协商阶段2，交换的发起者可以是初始交换的协商发起方，也可以是初始交换的协商响应方。

![创建子SA交换介绍](/media/202412/2024-12-05_105228_9733990.0002124645722563212.png)

用于一个总部对应对个分支的情况。

#### 2.2.3 IKEv2通知交换介绍
运行IKE协商的两端有时会传递一些控制信息，例如**错误信息或者通告信息**，这些信息在IKEv2中是通过通知交换完成的。

通知交换必须在IKE SA保护下进行，也就是说通知交换只能发生在初始交换之后。控制信息可能是IKE SA的，那么通知交换必须由该IKE SA来保护进行；也可能是某子SA的，那么该通知交换必须由生成该子SA的IKE SA来保护进行。

![IKEv2通知交换介绍](/media/202412/2024-12-05_105243_5045810.8779866837733243.png)

就是一些告警信息或者通知报文等的交互。

## 三、定义IPsec被保护流
前面通过IKE已经协商出IPSec SA了，现在需要对分支间的数据进行保护，哪些流量需要进行加密保护呢？我们需要通过一些方式来进行定义。

IPsec是基于定义的感兴趣流触发对特定数据的保护，可以通过以下两种方式定义：
- ACL方式，由ACL来指定要保护的数据流范围，筛选出需要进入IPsec隧道的报文。
- 路由方式，通过IPsec虚拟隧道接口建立IPsec隧道，将所有路由到IPsec虚拟隧道接口的报文都进行IPsec保护。

ACL可以更加精细控制源目地址、源目端口等流量，路由方式比较便捷，但是需要创建tunnel隧道接口方式来实现，支持动态路由协议。

通过IKE协商出IPSec SA秘钥，通过ACL或者路由匹配到感兴趣流量，最后将IPSec策略应用到指定的接口就可以实现IPSec VPN了。

总结：通过IKE协商SA，IKE分v1和v2，一般情况下我用的应该是v1，v2可以快速协商出SA，然后通过ACL或者路由定义感兴趣流量，将IKE提议、IPSec提议、创建IPSec策略、应用到接口串联起来就可以实现IPSec VPN的应用了，其实就是理论比较复杂，实际配置不算太难。