ipsecvpn是VPN技术中一种点击率很高的技术。它还提供VPN和信息加密。本专栏将介绍IPSecVPN的原理。
IPSecVPN有三种应用场景：
1.站点到站点（站点到站点或网关到网关）：例如，这三个组织分布在互联网的三个不同位置，每个组织使用业务试点网关彼此建立VPN隧道，企业内部网（多台PC）之间的数据可以通过这些网关建立的IPSec隧道进行安全互连。
2.端到端（端到端或PC到PC）：两台PC之间的通信由两台PC之间的IPSec会话保护，而不是由网关保护。
3.端到站点（端到站点或PC到网关）：网关和远程PC之间的通信受IPSec保护。
VPN只是IPSec的一种应用模式。IPSec实际上是IP安全的缩写。其目的是為IP提供高安全性功能。VPN是通过实现此安全功能而生成的解决方案。IPSec是一种框架体系结构，由两种类型的协议组成：
1、Ah协议（认证头，较少使用）：可同时提供数据完整性确认、数据源确认、反重放等安全功能；ah通常使用摘要算法（单向散列函数）MD5和SHA1來实现此功能。
2、ESP协议（广泛使用）：可同时提供数据完整性确认、数据加密、防重放等安全功能；ESP通常使用DES、3DES、AES等加密算法实现数据加密，使用MD5或SHA1实现数据完整性。
為什么ah使用较少？因為ah不能提供数据加密，所以所有数据都以明文传输，而ESP提供数据加密；其次，ah不能跨越NAT，因為它提供了数据源确认（一旦源IP地址更改，ah验证就会失败）。当然，在极端情况下，IPSec可以使用ah和ESP实现最完整的安全功能，但这种方案非常罕見。
IPSec封装模式
在介绍了IPSecVPN的场景和IPSec协议的组成之后，我们來看看IPSec（传输模式和隧道模式）提供的两种封装模式。
上图显示了传输模式的封装结构，然后比较隧道模式：
传输模式和隧道模式之间的差异可以发现：
1.传输方式在ah和ESP处理前后保持IP报头不变，主要用于端到端应用场景。
2.隧道模式封装ah和ESP处理后的外部IP报头，主要用于点对点应用场景。
从上图中，我们还可以验证上一节介绍的ah和ESP之间的差异。下图描述了传输模式和隧道模式适用于哪些场景。
从这个数字的比较中可以看出：
1.隧道模式可应用于任何场景
2.传输模式仅适用于PC到PC的场景
尽管隧道模式可以应用于任何场景，但隧道模式需要额外的IP报头层（長度通常為20字节），因此建议在PC到PC场景中使用传输模式。
為了让妳有一个更直观的理解，让我们看看下面的图來分析為什么隧道模式只能在站点到站点场景中使用：
如上图所示，如果发起方内网PC发送到响应方内网PC的流量满足网关的兴趣流匹配条件，则发起方使用传输方式进行封装：
1.在发起方和响应方之间建立IPSec会话。
2.由于使用了传输模式，IP报头不会改变。IP源地址為192.1681.2，目标地址為10.11.2
3.当这个数据包被发送到互联网后，它的命运注定是一个杯子。為什么这么说，因為它的目标地址是10.1.2？这不是根本原因。根本原因是互联网没有维护企业网络的路由，因此很可能被丢弃。
4.即使数据包没有在互联网上被丢弃，并且幸运地到达了响应者网关，我们是否期望响应者网关对其进行解密？哎呀，真的没有好的证件。数据包的目标地址是intranetPC1.2的10.1，因此直接转发它。
5.最重要的是，响应者的内联网PC收到了数据包。由于未参与IPSec会话的协商会议，且没有相应的SA，该数据包无法解密并被丢弃。
我们使用这种反证法巧妙地解释了在站点到站点的案例中无法使用传输模式的原因。提出了采用传输方式的充要条件：感兴趣的流必须完全在发起方和响应方的IP地址范围内。例如，在图中，启动器的IP地址為6.241.2。响应者的IP地址為2.171.2，则兴趣流可以是源6.241.2/32。目的是2.171.2/32，协议可以是任意的。如果数据包的源IP地址和目标IP地址略有不同，对不起，请使用隧道模式。
IPSec协商
除了IPSec的一些协议原则外，我们更关注协议中与方案制定相关的内容：
1.兴趣流：IPSec是一种需要消耗资源的保护措施。并非所有流量都需要IPSec处理，但需要IPSec保护的流量称為兴趣流。最终协商的兴趣流是发起方和响应方指定的兴趣流的交集。例如，发起者指定的兴趣流是192.1681.0/24á10.0。0.0/8，而受访者的利息流為10.00.0/8á192.168。0.0/16，则其交点為192.1681.0/24乘以10.0。0.0/8，这是受IPSec保护的最后一个兴趣流。
2.启动器：启动器，IPSec会话协商的触发器。IPSec会话通常由指定的兴趣流触发。触发过程通常是将数据包中的源、目标地址、协议、源和目标端口号与预先指定的IPSec兴趣流匹配模板（如ACL）匹配。如果匹配成功，则它属于指定的兴趣流。指定的利息流仅用于触发协商。它是否受IPSec保护取决于它是否匹配协商兴趣流。然而，在一般实现过程中，通常设计為发起方指定兴趣流属于协商兴趣流。
3.响应者：响应者，IPSec会话协商的接收者。回应者是被动谈判。响应者可以指定兴趣流，也可以不指定（完全由发起人指定）。
4.发起方与响应方协商的内容主要包括：双方身份确认和密钥种子刷新周期、ah/ESP组合模式及其各自算法、兴趣流、封装模式等。
5.Sa：发起方和响应方协商的结果是高暴露的Sa。SA通常包括密钥和密钥生存期、算法、封装模式、发起方、响应方地址、兴趣流等。
我们以最常見的IPSec隧道模式為例來说明IPSec的协商过程：
上图描述了由兴趣流触发的IPSec协商过程。原始IPSec没有身份确认和其他协商过程。该方案存在许多缺陷，如当启动器地址发生动态变化时，无法支持身份确认和密钥动态更新。带IPSec的Ike（Internet密钥交换）协议专门用于弥补这些缺点：
1.发起方定义的兴趣流為source192.1681.0/24purpose10.00.0/8，因此从发起方的内联网PC发送到响应方的内联网PC的数据包可以在接口处进行匹配。
2.如果满足利息流条件，且转发界面上SA不存在、到期或不可用，则进行协商。否则，当前SA将用于处理数据包。
3.谈判过程通常分為两个阶段。第一阶段是服务于第二阶段，第二阶段是服务于利益流的真正SA。这两个阶段的重点是不同的。第一阶段主要是确认双方身份的正确性，第二阶段是為兴趣流创建指定的安全套件，最重要的结果是第二阶段的兴趣流是对话中的密文。