防火墙环境中的IPsec
NAT环境中的IPsec
IPsec和服务质量
IPsec和碎片
IPsec和递归路由
IPsec诊断工具在思科IOS
思科IOS中最常用的诊断工具类别是显示和调试命令。在本章的整个过程中，我们将使用这两个命令集的变体来诊断思科IOS中常见的问题。正如我们所讨论的，在形成Internet安全协会和密钥管理协议(ISAKMP)以及两个IPsec VPN端点之间的IPsec协商过程中，有一些详细的步骤。我们将通过在IOS中执行以下调试命令来检查这些步骤中常见的错误:
调试加密isakmp
调试加密IPsec
此外，我们将探讨几个显示用于发现与IPsec VPN隧道协商相关的常见错误和性能问题的命令，包括分段/最大传输单元(MTU)问题、服务质量(QoS)问题、网络地址转换(NAT)问题以及与递归路由相关的问题。我们将讨论解决这些问题的命令的一个子集包括:
显示crypto isakmp sa
显示加密isakmp sa nat
显示加密IPsec sa
显示加密引擎连接活动
显示加密引擎连接丢失的数据包
显示加密引擎连接流
显示加密引擎的qos
IPsec vpn的常见配置问题
在部署IPsec vpn时，需要了解许多参数和特性。在本节中，我们将讨论当一个或多个IPsec VPN网关配置错误时出现的配置问题。在讨论了上述每个常见的IPsec VPN配置问题的性质之后，我们将讨论用于有效诊断和解决这些问题的方法。
艾克SA提议不匹配
除非IPsec会话密钥是手动定义的，否则两个加密端点必须就在协商安全Internet密钥交换(IKE)通道或ISAKMP安全协会(SA)时使用的ISAKMP策略达成一致。因此，当两个VPN端点不能就可用的ISAKMP策略达成一致时，IPsec SA协商将无法启动，流量将继续未加密流动。
图2-24和图2-25分别简要描述了主模式和主动模式下的ISAKMP策略协商过程以及在两个VPN端点上的配置。还记得我们在第2章中讨论过的ISAKMP策略是按优先级排序的(较低的优先级为最高优先级)。发起者将提供最高优先级的建议，响应者将搜索其本地配置的ISAKMP策略以寻找匹配项。如果没有，启动程序将提出下一个最高的ISAKMP策略，并定义其本地配置。这个过程将继续，直到发起者没有剩余的建议提供给响应者。在这种情况下，结果将是ISAKMP SA提案不匹配。使用示例4-1和示例4-2中提供的配置，Router_A和Router_B将尝试使用中所示的拓扑在彼此之间形成一个IKE SA图4 - 1。
ISAKMP SA谈判导致ISAKMP提案不匹配
示例4-1提供了为Router_A配置的ISAKMP策略图4 - 1。注意，在这个配置中，没有配置与示例4-2中在Router_B上配置的ISAKMP建议相匹配的ISAKMP建议。
例4-1中Router_A的加密ISAKMP策略定义图4 - 1(与Router_B不匹配，示例4-2)
Router_A #显示加密isakmp策略全球艾克政策保护的优先级10加密算法:三个关键三重DES散列算法:消息摘要5认证方法:Pre-Shared关键diffie - hellman组:# 2(1024位)寿命:86400秒,没有数量限制保护20套优先级加密算法:DES(数据加密标准(56位密钥)。哈希算法:安全哈希标准认证方法:预共享密钥Diffie-Hellman组:#2(1024位)生命期:86400秒，无容量限制优先级30的保护套加密算法:AES -高级加密标准(128位密钥)。哈希算法:安全哈希标准认证方法:Rivest-Shamir-Adleman签名Diffie-Hellman组:#1(768位)寿命:86400秒，无容量限制默认保护套件加密算法:DES -数据加密标准(56位密钥)。哈希算法:安全哈希标准认证方法:Rivest-Shamir-Adleman签名Diffie-Hellman组:#1(768位)生存期:86400秒，没有容量限制
示例4-2提供了Router_B上的ISAKMP策略配置图4 - 1。在为Router_A构建ISAKMP SA时，Router_B将使用此策略，其ISAKMP策略在示例4-1中提供。因为Router_B的ISAKMP配置不包含与示例4-1中提供的Router_A配置匹配的建议，所以ISAKMP协商将失败。
例4-2中Router_B的加密ISAKMP策略定义图4 - 1(与Router_B不匹配，示例4-1)
Router_B #显示加密isakmp策略优先级10加密算法的全局IKE策略保护套件:AES高级加密标准(128位密钥)。散列算法:消息摘要5验证方法:Pre-Shared关键diffie - hellman组:# 5(1536位)寿命:86400秒,没有数量限制保护20套优先级加密算法:三个关键三重DES散列算法:消息摘要5认证方法:Rivest-Shamir-Adleman签名diffie - hellman组:# 1(768位)寿命:86400秒,没有数量限制保护30套优先级加密算法:DES(数据加密标准(56位密钥)。哈希算法:安全哈希标准认证方法:预共享密钥Diffie-Hellman组:#2(1024位)寿命:86400秒，无容量限制默认保护套件加密算法:DES -数据加密标准(56位密钥)。哈希算法:安全哈希标准认证方法:Rivest-Shamir-Adleman签名Diffie-Hellman组:#1(768位)生存期:86400秒，没有容量限制
以下编号的事件序列描述了示例4-1中为Router_A提供的配置之间的ISAKMP建议不匹配图4 - 1例4-2中Router_B图4 - 1。
路由器A将其配置好的ISAKMP策略10、20和30发送给路由器B。
路由器B根据自己配置的策略检查步骤1中获得的策略10，从编号最低的策略开始，到编号最高的策略结束。
如果路由器B在步骤2中没有找到匹配，它将检查步骤1中获得的策略20与自己配置的策略，从编号最低的开始，以编号最高的结束。
如果路由器B在步骤3中没有找到匹配，它将检查步骤1中获得的策略30与自己配置的策略，从编号最低的开始，以编号最高的结束。
如果路由器B在步骤4中没有找到匹配，那么提议不匹配就发生了，并且阶段1协商超时。
为了确认艾克提议不匹配发生在一个IPsec VPN隧道谈判,我们将检查的输出ISAKMP SA路由器A和B之间的谈判路由器A和B是在站点中使用预共享艾克认证VPN,但尚未配置匹配ISAKMP政策。我们将执行该命令调试加密isakmp在路由器A和B上强调IKE提议不匹配确实是导致ISAKMP SA协商失败的原因。示例4-3显示了调试输出，因为Router_A提出的ISAKMP策略将根据Router_B上本地配置的策略进行检查。
在示例4-3所示的诊断输出中，Router_B检查从Router_A发送的建议是否存在潜在匹配。Router_B首先根据自己配置的ISAKMP建议检查从Router_A发送的ISAKMP建议。它通过检查收到的所有建议(从最低编号开始，以最高编号结束)和所支持的策略(最低编号)来实现这一点。如果没有匹配项，它将按照同样的顺序检查接收到的策略是否符合它的下一个最低编号策略。此过程将继续，直到找到匹配项或检查了所有策略，但未找到匹配项为止。在这个特定的建议中，为加密IKE信道而提出的加密方法不匹配(关于Router_A和Router_B的ISAKMP建议信息，请参阅示例4-2和4-3)，路由器B继续根据其本地配置的ISAKMP策略检查其他提供的建议。示例4-3，第12行，确认出现了建议不匹配。Router_B发现从Router_A发送的ISAKMP建议没有与其自己配置的ISAKMP策略匹配，因此删除Router_A上的Phase1 SA和Phase1协商超时，如示例4-3第18行所确认的。
示例4-3在初始VPN端点(路由器A)上隔离IKE建议不匹配
2 .密码isakmp调试是在3上!4 !5 * 2月16 12:11:02.379:ISAKMP:(0时:N / A: 0):检查ISAKMP变换1对优先级10政策6 * 2月16 12:11:02.379:ISAKMP:加密3 des - cbc 7 * 2月16 12:11:02.379:ISAKMP:哈希MD5 8 * 2月16 12:11:02.379:ISAKMP:默认组2 9 * 2月16 12:11:02.379:ISAKMP: auth pre-share 10 * 2月16 12:11:02.379:ISAKMP:生活在秒11 * 2月16 12:11:02.379类型:ISAKMP:生活持续时间(新品)0 x0 0 x1 0 x51 0 x80 12 * 2月16 12:11:02.379:ISAKMP:(0:0:N/A:0):提供的加密算法与策略不匹配!13 !14 !2月16日12:11:02.379:ISAKMP:(0:0:N/A:0):不接受报价!16 * 2月16日12:11:02.379:ISAKMP:(0:0:N/A:0):阶段1 SA政策不可接受!ISAKMP:(0:0:N/A:0):peer不做偏执保持活动。18 * 2月16日12:11:02.379:ISAKMP:(0:0:N/A:0):删除SA原因“Phase1 SA策略建议不接受”状态(R) MM_NO_STATE (peer 200.0.0.1)
在两个端点就保护IKE信道时使用的ISAKMP策略达成一致，并协商加密IKE交换和IPsec转换时使用的Diffie-Hellman密钥之前，IPsec VPN隧道协商将不能继续。要继续进行IPsec VPN隧道协商，必须成功执行的另一个任务是IKE身份验证。
IKE身份验证失败和错误
回顾我们之前的讨论，在Cisco IOS中，提供了三种方法来认证想要协商ISAKMP SA的对等方:预共享密钥(PSKs)、RSA签名或RSA加密。正如我们在第2章中所讨论的，在对IKE对等点进行身份验证时，所有三种身份验证方法都使用不同的元素。我们将在这三种身份验证方法的上下文中讨论常见的IKE身份验证失败问题。
IKE身份验证错误和PSKs
两个IPsec VPN端点要使用IKE PSKs相互验证，必须满足两个条件。首先，必须在两个端点上配置匹配的密钥。其次，端点必须配置为与正确的对等方共享这些密钥。现在，Router_A和Router_B为第1阶段协商配置了匹配的ISAKMP策略，但是仍然存在阻止它们对彼此进行身份验证的问题。我们将检查在路由器上调试输出图4 - 2突出显示直接归因于密钥不匹配和对等点不匹配的身份验证失败。
故障诊断IKE PSK身份验证
示例4-4提供了Router_A in的配置图4 - 2。注意，与Router_A的配置不同图4 - 1， Router_A现在配置了一个ISAKMP策略，该策略包含一个匹配的建议(示例4-4，优先级为30)和Router_B(示例4-5，优先级为10)。然而，在本例中，IKE仍然会由于Router_A(例4-4，第32行)和Router_B(例4-5，第32行)上的PSK不匹配而无法进行协商。