本文档介绍建立虚拟专用网络(VPN)的互联网密钥交换(IKEv1)协议过程。

Cisco建议您了解基本的安全概念：

本文档不限于特定的软件和硬件版本。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

用于建立虚拟专用网络(VPN)的互联网密钥交换(IKEv1)协议流程对于了解数据包交换非常重要，有助于简化任何类型的IKEv1互联网协议安全(IPsec)问题的故障排除。

IPsec是在IP层为Internet通信提供安全保护的一组协议。目前IPsec最常见的用途是在两个位置之间（网关到网关）或在远程用户与企业网络（主机到网关）之间提供虚拟专用网络(VPN)。

IPsec使用IKE协议协商并建立安全的站点到站点或远程访问虚拟专用网络(VPN)隧道。IKE协议也称为互联网安全关联和密钥管理协议(ISAKMP)（仅在思科提供）。

IKE有两个版本：

ISAKMP将协商分为两个阶段：

为了实现所有抽象概念，第1阶段隧道是父隧道，第2阶段是子隧道。下图以隧道形式说明两个阶段：

注意：第1阶段(ISAKMP)隧道保护两个网关之间的控制平面VPN流量。控制平面流量可以是协商数据包、信息包、DPD、keepalive、重新生成密钥等。ISAKMP协商使用UDP 500和4500端口建立安全信道。

注意：第2阶段(IPsec)隧道可保护在两个网关之间通过VPN的数据平面流量。用于保护数据的算法在第2阶段配置，并且独立于第1阶段中指定的算法。用于封装和加密这些数据包的协议是封装安全负载(ESP)。

发起方向响应方发送建议或建议时，IKE会话开始。节点间的第一次交换建立基本的安全策略；发起方提出加密和认证算法供使用。响应方选择适当的建议书（假设已选择建议书）并将其发送给发起方。下一个交换传递Diffie-Hellman公钥和其他数据。所有进一步协商在IKE SA内加密。第三个交换机会验证ISAKMP会话。一旦建立IKE SA，IPSec协商（快速模式）就会开始。

主动模式将IKE SA协商压缩成三个数据包，SA所需的所有数据都由发起方通过。响应方发送建议、密钥材料和ID，并在下一个数据包中验证会话。发起方回复并验证会话。协商速度更快，且发起方和响应方ID传递清晰。

IPSec协商（或快速模式）类似于主动模式 IKE协商，但协商必须在IKE SA中保护。快速模式协商用于数据加密的SA，并管理该IPSec SA的密钥交换。

每个ISAKMP数据包都包含用于建立隧道的负载信息。IKE词汇表将IKE缩写说明为主模式的数据包交换的负载内容的一部分，如下图所示。

要设置ISAKMP协商的条款，您需要创建ISAKMP策略，包括：

第一个数据包由IKE协商的发起方发送，如图所示：

注意：主模式1是IKE协商的第一个数据包。因此，当响应方SPI设置为0时，发起方SPI设置为随机值。在第二个数据包(MM2)中，响应方SPI必须使用新值进行响应，并且整个协商保持相同的SPI值。

如果捕获MM1并使用Wireshark网络协议分析器，则SPI值在Internet安全连接和密钥管理协议内容中，如图所示：

注意：如果路径中MM1数据包丢失或没有MM2应答，则IKE协商会保留MM1重新传输，直到达到最大重新传输次数为止。此时，发起方保持相同的SPI，直到再次触发下一次协商。

提示：识别发起方和响应方SPI对于识别同一VPN的多个协商以及缩小某些协商问题的范围非常有用。

在Cisco IOS® XE平台上，可以使用配置的远程IP地址的条件按隧道过滤调试。但是，同步协商会显示在日志中，并且无法对其进行过滤。需要手动执行。如前所述，整个协商为发起方和响应方保留相同的SPI值。如果从同一对等体IP地址收到数据包，但SPI与协商达到最大重新传输次数之前跟踪的上一个值不匹配，则这是同一对等体的另一个协商，如图所示：

注意：该示例显示协商中的第一个数据包(MM1)的同时协商。但是，这可以在任何协商点发生。所有后续数据包必须在响应方SPI上包含与0不同的值。

在主模式2数据包中，响应方为匹配的提议发送所选策略，并且响应方SPI设置为随机值。整个协商保持相同的SPI值。MM2回复MM1，SPI响应器设置为与0不同的值，如图所示：

如果捕获MM2并使用Wireshark网络协议分析器，则发起方SPI和响应方SPI值在Internet安全连接和密钥管理协议内容中，如图所示：

MM3和MM4数据包仍未加密且未经身份验证，并且会进行密钥交换。MM3和MM4如图所示：

MM5和MM6数据包已加密，但仍未经身份验证。在这些数据包上，身份验证按图中所示进行：

在主节点和IKE在第1阶段建立安全隧道后出现快速模式。快速模式协商共享IPSec策略，用于IPSec安全算法，并管理IPSec SA建立的密钥交换。随机数用于生成新的共享密钥材料，并防止来自生成的伪造SA的重播攻击。

如图所示，在此阶段交换三个数据包：

 主动模式将IKE SA协商压缩为三个数据包，SA所需的所有数据都由发起方通过。

下图显示在主动模式下交换的三个数据包的负载内容：

与主模式相比，主动模式可分为三个包：

在IKEv2协商中，为建立隧道而交换的消息更少。IKEv2使用四个消息；IKEv1使用六个消息（在主模式下）或三个消息（在主动模式下）。

IKEv2消息类型定义为请求和响应对。下图显示了IKEv2与IKEv1的数据包比较和负载内容：

注意：本文档不深入探讨IKEv2数据包交换。有关更多参考，请导航到IKEv2数据包交换和协议级别调试。

如名称所述，基于策略的VPN是IPsec VPN隧道，对符合策略匹配条件的传输流量执行策略操作。对于Cisco设备，会配置访问列表(ACL)并将其附加到加密映射，以指定要重定向到VPN并加密的流量。

流量选择器是在策略中指定的子网或主机，如图所示：

不需要策略。流量被重定向到具有路由的隧道，并支持通过隧道接口进行动态路由。默认情况下，流量选择器（通过VPN加密的流量）为0.0.0.0到0.0.0.0，如图所示：

注意：由于流量选择器为0.0.0.0，因此中包含任何主机或子网。因此，仅创建一个SA。动态隧道例外。本文档不介绍动态隧道。

基于策略和路由的VPN可以具体化，如图所示：

注意：与仅创建一个SA的基于路由的VPN不同，基于策略的VPN可以创建多个SA。配置ACL后，ACL上的每条语句（如果它们不同）都会创建子隧道。

互联网服务提供商(ISP)阻止UDP 500/4500端口是一个非常常见的问题。对于IPsec隧道的建立，可以采用两个不同的ISP。其中一个可以阻塞端口，另一个允许阻塞。

下图显示了ISP只能在一个方向上阻止UDP 500/4500端口的两个场景：

注意：互联网密钥交换(IKE)使用端口UDP 500建立安全VPN隧道。当NAT存在于一个VPN终端中时，使用UDP 4500。

注意：当ISP阻止UDP 500/4500时，IPsec隧道建立会受到影响，它不会启动。

IPsec隧道的另一个非常常见的问题是ISP阻止ESP流量；但它允许UDP 500/4500端口。例如，允许UDP 500/4500端口双向传输。因此，隧道已成功建立，但ISP或ISP在两个方向上都阻止了ESP数据包。这会导致通过VPN的加密流量失败，如图所示：

注意：当ISP阻止ESP数据包时，IPsec隧道建立是成功的，但已加密的流量将受到影响。VPN启动时可以反映这一点，但流量无法通过该接口工作。 

提示：ESP流量仅在一个方向被阻止的场景也可能出现。症状相同，但使用隧道统计信息、封装、解封计数器或RX和TX计数器可以轻松找到它。