CCIE安全性:使用加密映射对站点到站点IPSec 虚拟专用网 进行故障排除

在这篇文章中,我们将使用调试命令来解决VPN的故障排除。这对于那些只能访问VPN一侧或只能访问第三方VPN的人们特别有用。我希望这与我的ASA和IOS站点间VPN配置帖子分开,因为对它进行故障排除几乎完全是在路由器或ASA上的身份,因此我想将故障排除与一个帖子结合在一起。 

 

成功完成IPSec 虚拟专用网 创建

我将从 调试crypto isakmp 命令并完成成功的ISAKMP SA创建过程。这是我发出 清除加密会话 命令并从一侧ping主机到另一侧。

从一开始,我们就看到发起方开始准备建立与另一对等方(2.2.2.1)的SA。输出表明源/目标端口将为500(众所周知的UDP),并且由于未配置为主动模式而无法启动主动模式,因此它将使用主模式。接下来,它声明已找到在本地为对等方配置的预共享密钥(crypto isakmp密钥cisco123对等2.2.2.1)。此时,主模式尚未启动,

之后,我们将看到主模式开始。这是参数协商将开始的地方:

然后,MM#3和#4作为Diffie-Hellman交换的一部分进行处理,如果您从突出显示的部分中注意到,则NAT-T的作用是检测对等体之间没有NAT。 

主模式将使用MM#5和#6进行包装,其中使用预共享密钥进行相互身份验证,共享发送ID等。

第一阶段现已完成,第二阶段将开始。输出将使您知道快速模式正在启动。 您可以看到发起方发送的带有IPSec建议的第一条快速模式消息(加密ipsec转换集tset esp-aes 256 esp-sha512-hmac). 

对等方将发回包含所选提议和代理ID的答复。

然后,发起方将发送最终的快速模式消息作为最终确认。此时,调试输出将指示阶段2已完成。 

有道理吧?由于该帖子的名称中包含“疑难解答”,因此让我们分几部分来看一下它的外观。 

注意:  对站点到站点VPN进行故障排除时,总是有一方发送第一个数据包。此过程由需要将流量发送到另一端的第一端开始。该对等方称为发起方。对于IKE过程中出现的问题,响应者总是会得到更多的细节。如果您需要解决为什么VPN无法启动的问题,一个好的练习可能是清除加密会话,然后在发现发起方的情况下让另一方发起流量。 出于教育目的,我将引导您了解当VPN双方均出现故障时的状态。

故障排除阶段1

在本节中,我将对远程对等方的ISAKMP策略进行一些更改,并通过发出 清除加密会话 命令。清除会话后进行调试时,应反映出我所做的更改。 

ISAKMP策略故障排除

从发起人,  初始ISAKMP策略参数协商失败时,它是这样的:

从上面的输出可以看出,它永远不会超过MM#1和#2交换,并且ISAKMP策略被拒绝。此时,可能由于以下原因之一而使失败:

  • 加密不匹配
  • 哈希不匹配
  • Diffie-Hellman组不匹配
  • 验证类型不匹配

如果这是您能看到的全部,并且您无法让另一端与您一起进行故障排除或让他们启动流量,以便您可以将输出作为响应者查看,那么我将让另一端验证以上内容。如果您的一方是响应者,那么让我们在可能出现的情况下深入了解它的外观。

在响应方,调试输出将实际指定确切的错误。以下是我打破的各种配置的以下输出:

 

  • ISAKMP策略中的不匹配加密

  • ISAKMP策略中的不匹配哈希算法

 

  • ISAKMP政策中的Diffie-Hellman组不匹配

 

  • ISAKMP策略中的不匹配身份验证类型

 

  • ISAKMP策略中的不匹配身份验证类型

 

现在让我们看一下当ISAKMP策略匹配并且ISAKMP对等体已定义但预共享密钥错误时发生的情况。

从启动器的角度来看,一切都会看起来正确 直到 您将进入MM#5,对等方正在进行身份验证,它将失败。从发起方方面,您将看到发起方准备发送MM#5,它将向对等方进行身份验证,并且显然将失败并开始重新传输,直到超时为止。

如果此时失败, 极有可能是关键的不匹配 加密isakmp密钥 <key>  地址 <peer-address>组态。该命令必须存在于配置中才能通过初始MM#1和MM#2消息,但是由于MM#5和MM#6是两个对等方都使用该密钥进行彼此身份验证的位置,因此这是不匹配的地方密钥将失败。

在响应方,调试更清晰,表明由于MM_KEY_EXCH,MM#4完成并且MM#5应该开始后,密钥交换失败

 

故障排除阶段2

现在we're going to jump into Phase 2 troubleshooting. 

我将更改IPSec转换集,以使其在阶段2失败。通过更改转换集,我应该看到Main Mode交换已完成,并且阶段2开始了。从启动器,您应该看到QM#2上的快速模式失败,其中没有选择任何建议:

在响应方,我们可以看到更多细节。在这个 例如,我将响应者变换集更改为esp-3des而不是esp-aes,就像将对等体配置为使用并且我正在使用 调试加密ipsec 生成以下输出。

 

是很直观的吗?让我们尝试一些不同的东西。让我们关闭ISAKMP调试并使用 调试加密ipsec 并再次尝试这样做:

好多了吧?此数据从响应程序中闪闪发光,不幸的是不会在启动程序的调试中显示,但是如上所述,在对站点到站点IPSec 虚拟专用网 进行故障排除时,您可以轻松地翻转脚本以了解启动程序是谁。

如果我将加密恢复到以前的状态,并将哈希值更改为响应程序上的esp-md5-hmac,则可以再次看到初始化程序正在提供hmac-sha512并已将其拒绝:

当我为响应者配置模式传输,而另一个对等方是IPSec的模式隧道时,也是如此。如您所见,发起方提供了隧道,而响应方在此调试中拒绝了响应方的隧道:

现在 我要在加密映射中用粗略的手指指出对等IP地址,看看会发生什么: 

如您所见,对等地址在响应器的加密映射中找不到,并且被拒绝。 

现在让我们说我搞砸了,并在加密映射中放入了错误的ACL,或者不要将匹配流量的一个ACL用于从一侧到另一侧的流量。在响应者上,它将明确指出不支持的代理ID:

 

这样,我将继续整理这篇博客文章!