在忙碌的几周后，我已经浮出水面了 - 我最终可以继续描述IPsec VPN故障排除（抱歉延迟）。这次我将仔细看看IKE阶段1（主模式）故障排除。
在分析IKE阶段1的特定问题之前，使用Debug Crypto Isakmp命令是一个好主意，以检查成功的IKE阶段1协商的示例。在两个名为Tokyo和Osaka的IPSec VPN网关之间进行此协商：
Crypto Isakmp调试已开启
东京＃
旧状态= IKE_READY NEW State = IKE_I_MM1（第1行）
3月7日：14：29.027 GMT：isakmp（0：1）：开始主模式交换
3月7日：14：29.027 GMT：isakmp（0：1）：发送数据包到172.16.6.2（i）（第2行）mm_no_state.
第1行显示旧状态= IKE_READY NEW State = IKE_I_MM1，这表示IKE协商已开始，并且主要发送主模式交换中的第一个ISAKMP消息即将发送。
在第2行中，主要模式始于东京向大阪发送IKE SA建议（172.16.6.2，响应者）。使用Crypto Isakmp Policy命令在Tokyo上配置这些提案。
接下来，从大阪收到提案接受：
3月7日：14：29.067 GMT：isakmp（0：1）：收到的数据包从172.16.6.2（i）（第1行）
mm_no_state.
3月7日：14：29.067 GMT：isakmp（0：1）：输入= IKE_MESG_FROM_PEER，IKE_MM_EXCH
旧状态= IKE_I_MM1新状态= IKE_I_MM2（第2行）
3月7日：14：29.067 GMT：isakmp（0：1）：加工SA有效载荷。消息ID = 0（第3行）
MAR 7 16：14：29.067 GMT：isakmp（0：1）：发现对等体预共享键匹配172.16.6.2
MAR 7 16：14：29.067 GMT：isakmp（0：1）：检查ISAKMP变换1对优先级10
政策
MAR 7 16：14：29.067 GMT：ISAKMP：加密DES-CBC（第4行）
3月7日：14：29.067 GMT：isakmp：哈希MD5（第5行）
3月7日：14：29.067 GMT：isakmp：默认组1（第6行）
3月7：14：29.067 GMT：isakmp：auth份额（第7行）
3月7日：14：29.067 GMT：isakmp：寿命型以秒为单位（第8行）
3月7日：14：29.067 GMT：isakmp：0x0 0x1 0x51 0x80的寿命持续时间（VPI）（第9行）
3月7日：14：29.067 GMT：isakmp（0：1）：Atts是可以接受的。下一个有效载荷为0（第10行）
MAR 7 16：14：29.103 GMT：isakmp（0：1）：SA正在使用ID类型ID_IPv4_ADDR进行预共享的密钥身份验证
3月7日：14：29.103 GMT：isakmp（0：1）：Input = IKE_MESG_INTERNAL，IKE_Process_Main_Mode
旧状态= IKE_I_MM2新状态= IKE_I_MM2
第1行显示了从大阪收到的消息。这包含了已接受的提案（其中一个在东京初始信息中发送的提案）。
在第2行中，您可以看到状态已从IKE_I_MM1移动到IKE_I_MM2，这表示这是IKE Exchange中的第二条消息。
东京开始处理SA有效载荷，其中包含已接受的提案，在第3行。第4行至9，您可以看到已接受的提案本身。该提案包括DES加密，MD5哈希算法，预先认证和SA寿命。
东京报告这些提案属性是可接受的（突出显示的第10行）。
东京和大阪现已准备好交换Diffie-Hellman公共值和诺斯：
3月7日：14：29.103 GMT：isakmp（0：1）：发送数据包到172.16.6.2（i）（第1行）mm_sa_setup.
3月7日：14：29.107 GMT：isakmp（0：1）：输入= ike_mesg_internal，ike_process_complete
旧状态= IKE_I_MM2新状态= IKE_I_MM3（第2行）
3月7日：14：29.147 GMT：isakmp（0：1）：收到的数据包从172.16.6.2（i）（第3行）
mm_sa_setup.
3月7日：14：29.147 GMT：isakmp（0：1）：输入= IKE_MESG_FROM_PEER，IKE_MM_EXCH
旧状态= IKE_I_MM3新状态= IKE_I_MM4（第4行）
3月7日：14：29.147 GMT：isakmp（0：1）：处理ke有效载荷。消息ID = 0（第5行）
3月7日：14：29.183 GMT：isakmp（0：1）：处理随机载荷。消息ID = 0（第6行）
3月7日：14：29.183 GMT：isakmp（0：1）：找到对等体预共享密钥匹配172.16.6.2
3月7日：14：29.183 GMT：isakmp（0：1）：生成的SkeyID状态（第7行）
3月7日：14：29.183 GMT：isakmp（0：1）：处理供应商ID有效载荷
3月7日：14：29.183 GMT：isakmp（0：1）：与另一个iOS盒子说话！
3月7日：14：29.187 GMT：isakmp（0：1）：输入= ike_mesg_internal，ike_process_main_mode
旧状态= IKE_I_MM4新状态= IKE_I_MM4
在第1行，东京将其Diffie-Hellman公共值和随机价值发送给大阪。在第2行中，状态更改为IKE_I_MM3，表示已发送IKE交换机中的第三个消息。
然后从大阪收到响应，如第3行所示。第4行显示该状态现在已更改为IKE_I_MM4，这表明此响应是主模式交换中的第四条消息。
东京处理从大阪接收的数据包，从第5行和6中所示的ke（key交换机）和nonce有效载荷开始。这些有效载荷包含大阪的diffie-hellman公共值和随机值。
在第7行中，您可以看到消息“生成的SkeyID状态”。这表示东京已生成用于导出IPSec键的键控材料（会话键SKEYID_D，SKEYID_E和SKEY_A），以及加密和验证剩余的主模式和快速模式ISAKMP消息。
主模式谈判的最后一部分开始。这包括IKE对等体认证（主模式消息5和6）：
3月7日：14：29.187 GMT：isakmp（0：1）：发送数据包到172.16.6.2（i）（第1行）mm_key_exch.
3月7：14：29.187 GMT：isakmp（0：1）：Input = IKE_MESG_INTERNAL，IKE_Process_Complete
旧状态= IKE_I_MM4新状态= IKE_I_MM5（第2行）
3月7日：14：29191 GMT：isakmp（0：1）：收到的数据包从172.16.6.2（i）（第3行）
mm_key_exch.
3月7日：14：29.191 GMT：isakmp（0：1）：输入= IKE_MESG_FROM_PEER，IKE_MM_EXCH
旧状态= IKE_I_MM5新状态=未知
3月7日：14：29.191 GMT：isakmp（0：1）：处理ID有效载荷。消息ID = 0（第4行）
3月7日：14：29.191 GMT：isakmp（0：1）：处理哈希有效载荷。消息ID = 0（第5行）
MAR 7 16：14：29191 GMT：ISAKMP（0：1）：SA已通过172.16.6.2（第6行）
3月7日：14：29.191 GMT：isakmp（0：1）：输入= ike_mesg_internal，
ike_process_main_mode.
旧状态=未知新状态=未知
3月7：14：29.191 GMT：isakmp（0：1）：输入= ike_mesg_internal，ike_process_complete（第7行）
旧状态=未知新状态= ike_p1_complete
东京发送包含ID和哈希有效载荷的ISAKMP消息（突出显示第1行）。ID有效负载用于标识，哈希有效载荷用于身份验证。
接下来，在突出显示的第2行中，状态更改为IKE_I_MM5，这表示已发送IKE主模式交换机中的第五条消息。
在突出显示的第3行中从大阪收到响应。此响应包含ID和HASH有效载荷，并且这些有效载荷在突出显示的线路4和5中处理。
东京在突出显示的第6行验证大阪。
最后，在突出显示的第7行中，状态更改为IKE_P1_COMPLETE，指示主模式协商已完成。
现在您已经看到了成功的主模式谈判，您处于一个很大的位置，可以分析我下次讨论的主要模式故障。
标记