IPSec VPN

IPSec VPN是一种三层隧道协议，IPSec VPN可以将感兴趣流直接封装到隧道之中，使该数据流依据隧道进行转发，保障数据报文的机密性、完整性以及防重放。IPSec的三种安全机制如下：

认证机制：使IP通信的数据接收方能够确认数据发送方的真实身份

加密机制：通过对数据进行加密运算来保证数据的机密性，以防数据在传输过程中被窃听。

数据完整性：使IP通信的数据接收方能够确认数据在传输过程中是否遭篡改。

IPSec不是一种单独的协议，而是一种框架。包括用于提供安全服务的网络认证协议AH、ESP、用于密钥交换（自动协商AH、ESP使用的加密算法）的IKE协议和用于网络认证及加密的一些算法等。

一、IPSec VPN基本概念

  1.1、SA简介

SA（Security Association，安全联盟）是IPSec的本质，也是IPSec的基础，SA是IPSec对等体间对某些要素的约定。eg：使用哪种协议（AH、ESP还是两者结合使用）、协议的封装模式（传输模式和隧道模式）、加密算法（DES、3DES和AES）、特定流中保护数据的共享密钥以及密钥的生存周期等。 建立 SA 的方式有手工配置和IKE自动协商两种。

SA 是单向的，在两个对等体（IPSec 在两个端点之间提供安全通信，这两个端点被称为 IPSec 对等体）之间的双向通信，最少需要两个 SA 来分别对两个方向的数据流进行安全保护。同时，如果两个对等体希望同时使用AH和ESP来进行安全通信， 则每个对等体都会针对每一种协议来构建一个独立的 SA。SA由一个三元组来唯一标识，这个三元组包括 SPI（Security Parameter Index，安全参数索引）、目的IP地址、安全协议号（AH 或 ESP）。SPI是用于唯一标识SA的一个 32 比特数值，它在 AH 和 ESP 头中传输。SPI一般在 SA 协商期间由接收方指定，发送方在发送数据包时，将流量对应的 SA 所持有的 SPI 写入安全协议的首部。接收方提取首部中的SPI，用于为该流量查找合适的 SA。在手工配置 SA 时，需要手工指定 SPI 的取值。使用IKE协商产生SA时，SPI 将随机生成。 通过IKE协商建立的SA具有生存期限，手工方式建立的SA永不老化。IKE协商建立的SA的生存期限有两种定义方式：

生存周期，基于时间定义了一个SA从建立到失效的时间。

生存大小，基于流量定义了一个SA允许处理的最大流量。

生存期限到达指定的时间或指定的流量，SA就会失效。SA失效前，IKE将为IPsec协商建立新的SA，这样，在旧的SA失效前新的 SA 就已经准备好。在新的 SA 开始协商而没有协商好之前，继续使用旧的 SA 保护通信。在新的 SA 协商好之后，则立即采用新的 SA 保护通信。 当通信的对等体设备数量较少时，或是在小型静态环境中，手工配置 SA 是可行的。对于中、大型的动态网络环境中，推荐使用 IKE 协商建立 SA

  1.2、IKE简介

在 IPSec 的过程中，可以使用 IKE 协议来建立 SA，该协议建立在由 ISAKMP （密钥管理技术的主要任务是如何在公用数据网上安全地传递密钥而不被窃取。现行密钥管理技术又分为 SKIP 与 ISAKMP/OAKLEY 两种。SKIP 主要是利用 Diffie-Hellman 算法在网络上传输密钥；在 ISAKMP 中，双方都有两把密钥，分别用于公用、私用。ISAKMP是 IKE 对等体之间协商、建立、修改和删除SA的协议。使用 UDP 或者 TCP，端口号均为 500，一般使用UDP。 ）定义的框架上。IKE 为 IPSec 提供了自动协商交换密钥、建立 SA 的服务，能够简化 IPSec 的使用和管理，大大简化 IPSec 的配置和维护工作。

IKE 不是在网络上直接传输密钥，而是通过一系列数据的交换，最终计算出双方共享的密钥，并且即使第三者截获了双方用于计算密钥的所有交换数据，也不足以计算出真正的密钥。IKE 具有一套自保护机制，可以在不安全的网络上安全地认证身份、分发密钥和建立 IPSec SA。

主要功能包括：

1.2.1、数据认证

身份认证：身份认证确认通信双方的身份。

    支持两种认证方法：

    （1）预共享密钥 （Pre-Shared-Key）认证

    （2）基于 PKI 的数字签名（Rsa-Signature）认证。

身份保护：身份数据在密钥产生之后加密传送，实现了对身份数据的保护。

1.2.2、DH

DH（Diffie-Hellman Key Exchange，迪菲－赫尔曼密钥交换）算法是一种公共密钥算法。 通信双方在不传输密钥的情况下通过交换一些数据，计算出共享的密钥。即使第三者（如黑客）截获了双方用于计算密钥的所有交换数据，由于其复杂度很高，不足以计算出真正的密钥。所以，DH 交换技术可以保证双方能够安全地获得公有信息。

1.2.3、PFS

PFS（Perfect Forward Secrecy，完善的前向安全性）特性是一种安全特性，指一个密钥被破解，并不影响其他密钥的安全性，因为这些密钥间没有派生关系。对于 IPsec，是通过在 IKE 阶段 2 协商中增加一次密钥交换来实现的。PFS 特性是由 DH 算法保障的。

1.2.4、IKE协商的两个阶段

第一阶段，通信各方彼此协商并建立一个已通过身份认证和安全保护的通道，即建立一个 IKE SA。第一阶段有主模式和野蛮模式两种 IKE 交换方法。 （主模式交换 6 条消息，因此安全性较好，但协商相对较慢；野蛮模式只交换 3 条消息，不提供身份保护，因此安全性较低，但协商速度较快）

主模式的交换

野蛮模式的交换

以主模式为例

第一阶段的协商过程分别通过 3 组，6 个消息来建立 IKE SA，分别为：

第一组：消息 1（消息 1-回应）：安全参数协商（包括加密算法，HASH 算法， DH 组、身份认证信息等） 。

第二组：消息 2（消息 2-回应）：交换 DH 的公开信息和随机数。

第三组：消息 3（消息 3-回应）：用户双方身份验证以及整个 SA 交换进行验证。

第二个阶段的协商过程分别通过 3 个消息来建立 IPSec SA

消息 1：发送方发送一条报文，其中包含 HASH 值、IPSec 提议、Nonce 随机值和身份 ID 等内容。

HASH 值：用于给对方作完整性检查，认证对等体使用。

IPSec 提议：其中包括了安全协议、SPI、散列算法、隧道模式、IPSec SA 生命周期等内容。

Nonce 随机值：用于防重放攻击，还被用作密码生成的材料，仅当启用 PFS 时用到。

身份 ID：描述 IPSec SA 是为哪些地址、协议和端口建立的。

消息 2：响应方向发起方发送一条消息，同意第一条消息中的属性，同时， 也能起到确认收到对端消息的作用。

消息 3：发起方发送的第二条消息，其中包含一个 HASH 值，其作用是确认接受方的消息以及证明发送方处于 Active 状态（表示第一条消息不是伪造的）

至此，经过IKE SA 和IPSec SA的建立之后，隧道已基本建立成功。

  1.3 IPSec 协议的两种封装模式

传输模式

传输模式中，在IP报文头和上层协议之间插入AH或ESP头。传输模式中的AH或ESP主要对上层协议数据提供保护。

传输模式中的AH：在IP头部之后插入AH头，对整个IP数据包进行完整性校验。

传输模式中的ESP：在IP头部之后插入ESP头，在数据字段后插入尾部以及认证字段。对高层数据和ESP尾部进行加密，对IP数据包中的ESP报文头，高层数据和ESP尾部进行完整性校验。

传输模式中的AH+ESP：在IP头部之后插入AH和ESP头，在数据字段后插入尾部以及认证字段。

隧道模式

隧道模式中，AH或ESP头封装在原始IP报文头之前，并另外生成一个新的IP头封装到AH或ESP之前。隧道模式可以完全地对原始IP数据报进行认证和加密，而且，可以使用IPSec对等体的IP地址来隐藏客户机的IP地址。

隧道模式中的AH：对整个原始IP报文提供完整性检查和认证，认证功能优于ESP。但AH不提供加密功能，所以通常和ESP联合使用。

隧道模式中的ESP：对整个原始IP报文和ESP尾部进行加密，对ESP报文头、原始IP报文和ESP尾部进行完整性校验。

隧道模式中的AH+ESP：对整个原始IP报文和ESP尾部进行加密，AH、ESP分别会对不同部分进行完整性校验。

一般的，隧道模式应用在两个安全网关之间的通信，传输模式应用在两台主机之间的通讯，或一台主机和一个安全网关之间的通讯。

  1.4 IPSec NAT 环境

IPSec框架之一的作用就是保护数据包的完整性，如果报文传输过程中经过NAT设备，NAT是需要修改数据包的IP包头的，那这就意味着这个报文到达对端设备的时候解密或完整性认证处理就会失败，报文就会被丢弃。这就是最常见的IPSec VPN过NAT设备的场景。除此之外，IKE协商也会因此发生一些问题，如果IKE协商时使用的ID为IP地址，那么会出现不一致的问题，同时IKE使用的源目端口均为500，如果NAT设备上有端口转换，那么协商也会存在问题。因此，针对以上场景，就出现了NAT穿越。

NAT 穿越（NAT Traversal，NAT-T）就是为解决这个问题而提出的。该方法将 ESP 协议包封装到UDP包中（在原ESP协议的IP报头外添加新的IP头和UDP头）。将ESP报文当作净载荷进行传输，因此经过NAT设备时，不会改变ESP报文中的内容。当对端设备检测报文时，只要剥离外层的UDP头，再对内部的ESP协议包进行检测即可。

IKE 对等体检测链路中是否有NAT设备的步骤如下：

判断双方是否支持 NAT 穿越，这是 IKE 协商的第一阶段，双方通过发送一个 VENDOR ID 来识别是否支持 NAT 穿越。如果自身支持 NAT穿越，在IKE开始交互就发送这种载荷，载荷内容是“RFC 3947”的 MD5 值，也就是十六进制的 “4a131c81070358455c5728f20e95452f”。

判断通信链路上是否存在 NAT 设备，这一步是 NAT 发现，NAT 发现的原理是判断通信方的 IP 地址和端口是否发生了改变，判断的方法是，使用 IP 地址和端口号进行 HASH 运算，送往对方进行校验。一旦发现 NAT，则立即进行端口浮动，也就是在 IKE 协议的第二阶段将 IKE 的 UDP 500 浮动到 UDP 4500 端口。

进行 ESP 处理。

下面是遇到的IPSec VPN隧道无法建立的一些常见处理方法：

一、VPN隧道无法正常建立

检测链路是否正常；

保障VPN配置无误（IP地址、IKE提议协商参数、IPsec提议、隧道保护子流等），如果是防火墙设备，检查安全策略是否放开，端口是否放开；

查看网络配置，确保无误。

二、VPN隧道建立正常，但是无法访问对端内网

检测防火墙是否配置了NAT转换，对进入IPSec VPN隧道的流量进行了地址转换；如果做了那需要地址排除；

检查是否启用了 NAT 穿越功能。当两端防火墙之间有 NAT 设备，但是没有启用 NAT 穿越功能，用户通常只能连接到对端防火墙，但是不能访问防火墙后面的内部网络；

如果是防火墙设备，则检查安全策略以及安全策略顺序是否正确。

三、VPN不稳定，时通时断

查看是否可能为链路故障，看是否有丢包或者高延迟现象；

可能为IPSec SA不同步，可尝试打开两端DPD功能；

如果多条VPN隧道 可查看配置是否重复，尝试配置不同的标识ID；

查看IKE SA 超时时间是否配置过小，可尝试增大时间；

如果是多出口情况下跨运营商传输，需要配置去往对端公网地址的细化路由。

以上就是IPSec VPN的介绍，除了IPsec VPN外，Vecloud还提供全球网络优化服务、MPL专线、SD-WAN组网、IPLC专线等海外专线业务。