您发布了 IKEv1 主模式协商的捕获。在这个协商中有 6 个消息，或 3 对来回交换。

第一次交换是 ISAKMP 策略套件的协商。第二次交流是Diffie-Hellman的谈判。第三个交换是验证每个对等方是否具有正确的身份验证数据（通常是预共享密钥，但也可以是证书）。

这一切都由 RFC 2409 管理，它解释了具有预共享密钥身份验证的IKEv1 主模式交换如下所示：

Initiator                  Responder
----------                 -----------
HDR, SA             -->
                    <--    HDR, SA

HDR, KE, Ni         -->
                    <--    HDR, KE, Nr

HDR*, IDii, HASH_I  -->
                    <--    HDR*, IDir, HASH_R

交换 1

在第一次交换中，SA 负载是对等方用来建议 ISAKMP 策略（作为发起者）和确认所选策略（作为响应者）的内容。

交流2

在第二个交换中，有两个有效载荷：KEand Nior or Nr(i=initiator, r=responder)。

KE您在图片中突出显示的值是 Diffie-Hellman 公钥。每一方都有自己的，这是共享的地方。在这个 DH 插图中，这将是 Alice 和 Bob 分享他们的2和值9。

此值将与每一方生成（且从未共享）的 Private 值组合在一起。最终结果将是共享秘密，这是 Diffie-Hellman 交换的最终目标。然后，共享密钥将用于派生会话密钥——特别是对称加密密钥和HMAC 密钥。

任何窃听者都无法将最终价值放在一起，因为他们无法访问双方产生的任何私人价值。

该Ni或Nr值是所谓的一个随机数。这只是一个由 Initiator 和 Responder 生成的随机数，用于生成密钥材料。术语“Nonce”排序代表使用一次的数量（N+Once = nonce）。

交流3

在最后的交换中，IDi和HASH_值与Identity Method和Identity Hash 相关联。这些有效载荷中任何一个末尾的r和i表示响应者 ( r) 发送的或发起者 ( i)发送的有效载荷。

这些值用于验证每个 Peer 的身份。我在另一个答案中解释了使用预共享密钥完成此操作的方式，但其关键在于：

有两个项目用于向每个 Peer 验证它们都具有相同的 PSK：Identity Method和Identity Hash。

VPN Peer 可以选择通过多种方式来识别自己；最常见的是，对等点将简单地使用其源 IP 地址。但他们可以选择使用 FQDN 或主机名。这些中的每一个，连同所选方法的相关值，构成了身份方法。例如，如果我有 IP 5.5.5.5，并且我想使用我的 IP 地址来识别我自己，那么我的ID 方法实际上是[IP Address, 5.5.5.5]。 （注意：BOTH 值构成了整个 ID 方法）

然后将 ID 方法与我们之前讨论的种子值 (SKEYID) 以及一些其他值组合（使用 PRF）以创建身份哈希。回想一下，首先创建 SKEYID 的是预共享密钥。

然后通过线路发送 ID 方法和 ID 哈希，另一方尝试使用相同的公式重新创建 ID 哈希。如果接收方能够重新创建相同的 ID 哈希，则它向接收方证明发送方必须拥有正确的预共享密钥。

TLDR - 您突出显示的值是 DH 公钥，这是任何一方将与私有值（从不共享）结合以创建 DH 共享密钥（从不共享）的公共值。

主模式中的交换 1 是发起者建议 (M 1) 策略和响应者确认所选策略 (M 2) 的地方。

所以消息 3 和 4 是（这是我感到困惑的地方）DH 公钥的交换（我捕获的突出显示部分）。这些公钥是使用从未在对等方之间共享的私有值（指数）在两端独立导出的。将此私有值与在每一端收到的公钥相结合，从数学上讲，两个对等方都可以得出相同的共享密钥。然后使用共享密钥进一步导出会话密钥，即加密和 HMAC 密钥。

感谢您花时间解释这个 Eddie。

我认为您不需要数据包捕获来查看协商。

来自Cisco 支持论坛：

要将调试范围缩小到一个对等方，应使用条件调试。

在 IOS 上，这是通过执行以下操作来完成的：

debug crypto condition peer ipv4 .... 可调试两大组件

debug crypto isakmp- 特定于 ISAKMP 交换的信息。这将包含有关主模式和快速模式协商的信息。

debug crypto ipsec - 可以在此处找到一些第 2 阶段的特定信息。