技术介绍

IPSEC-VPN对于数据流的保护有两种主流方式，分别是：

1. 基于ACL方式（感兴趣流）
2. 基于虚拟隧道接口方式（接口模式，路由模式）

基于Efficient VPN一般用于client-to-site，最常见的就是手机中就有该类型的VPN，因为云上的IPSEC-VPN主要用于site-to-site的网络模式，所以该方式不做介绍

基于ACL（感兴趣流）方式

基于ACL(感兴趣流)方式是目前百度云ipsec-vpn支持的数据流保护模式，可以基于源/目的IP地址对数据报文进行过滤。在百度云的IPSEC-VPN网关中，基于ACL（感兴趣流）建立的IPSEC最大的特点就是针对每一个IP数据流都建立唯一一对IPSEC SA。

如上图所示，左边的VPN网关有两个网段，右边的VPN网关需要两个网段，如果想要对两端的网段互访做数据保护，需要建四对IPSEC-SA。

源网段	目的网段	加密策略
10.20.1.0/24	192.168.1.0/24	ipsec-sa-1
10.20.1.0/24	192.168.2.0/24	ipsec-sa-2
10.20.2.0/24	192.168.1.0/24	ipsec-sa-3
10.20.2.0/24	192.168.2.0/24	ipsec-sa-4

该种协商模式最大的好处就是安全，不同的数据流采用不用的密钥。但是缺点也很明显，那就是当两端配置不一致的时候，很容易出现密钥匹配不上的情况。
比如说VPN网关A配置本段两个网段，对端两个网段，就像上面的例子，那么应该协商出来四对ipsec sa, 但是另一端的vpn网关却做了网段合并，把10.20.1.0/24，10.20.2.0/24合并成了10.20.0.0/16, 把192.168.1.10/24和192.168.2.0/24合并成了192.168.0.0/16，那么就只会有一对ipsec sa，此时就会出现部分网段能通，部分网段不通的情况，连通性完全靠运气。

基于虚拟隧道接口的方式（接口模式/路由模式）

基于虚拟隧道接口来定义需要保护的数据流，首先就要在两端的IPSec设备创建一个虚拟的隧道接口Tunnel，然后通过配置以该Tunnel接口为出接口的静态路由，以限定到达哪个目的子网的数据流可以通过IPSec隧道进行转发。因为Tunnel接口是点对点类型的接口，是运行PPP链路层协议的，所以以该接口为出接口的静态路由是可不指定下一跳IP地址的。

IPSec虚拟隧道接口是一种三层逻辑接口，采用这种方式时所有路由到IPSec虚拟隧道接口的报文都将进行IPSec保护，不再对数据流类型进行区分。但使用IPSec虚拟隧道接口建立IPSec隧道仍具有以下优点：

1. 简化配置，只需将需要IPSec保护的数据流引到虚拟隧道接口，无需使用ACL定义待加/解密的流量特征。使得IPSec的配置不会受到网络规划的影响，增强了网络规划的可扩展性，降低了网络维护成本。
2. 减少开销，在保护远程接入用户流量的组网应用中，只需在IPSec虚拟隧道接口处进行IPSec报文封装，与IPSec over GRE或者IPSec over L2TP方式的隧道封装相比，无需额外为进入隧道的流量加封装GRE头或者L2TP头，减少了报文封装的层次，节省了带宽。
3. 支持范围更广，点对点IPSec虚拟隧道接口可以支持动态路由协议，同时还可以支持对组播流量的保护。另外，IPSec虚拟隧道接口在实施过程中明确地区分出“加密前”和“加密后”两个阶段，用户可以根据不同的组网需求灵活选择其他业务（例如NAT、QoS）实施的阶段。例如，如果用户希望对IPSec封装前的报文应用QoS，则可以在IPSec虚拟隧道接口上应用QoS策略；如果希望对IPSec封装后的报文应用QoS，则可以在进入对端内部网络的物理接口上应用QoS策略。

IPSEC隧道接口对报文的封装和加密的过程：

1. 网络设备将从入接口接收到明文IP报文后送到转发模块进行处理；
2. 转发模块依据路由查询结果，发现如果是要保护的数据流，则将其发送到IPSec虚拟隧道接口进行AH或ESP封装
3. IPSec虚拟隧道接口完成对明文IP报文的封装处理后，根据建立的IPSec SA安全策略再将封装后的报文进行加密，然后再将加密后的密文转发模块进行处理；
4. 转发模块再通过第二次路由查询后，将已封装和加密的IP报文通过隧道接口对应的实际物理接口转发出去，直到对端的IPSec设备Tunnel接口。

接口模式/路由模式的特点就是，全程只有一套加密算法和密钥，这个加密策略（ipsec sa）绑定到虚拟接口上, 凡是经过虚拟接口，就使用接口上对应的加密策略进行加密。所以，如果想保护某一个数据流，只需要使用路由引到的方式，将下一跳引到对应的虚拟隧道接口上。因为是路由模式，所以只要VPN两端的虚拟隧道能够匹配，不关心报文特征，只需要依据虚拟隧道接口上的加解密策略进行处理。