假设上图中icmp流量可以命中兴趣流并建立ipsec隧道，针对上述流量抓包，抓包结果如图所示：

可以看到总共21个报文；前6个为协商阶段一，建立IKE SA；第7-9个报文为协商阶段二，建立IPSEC SA；第10-19个报文为加密的ICMP报文，下面对报文挨个分析。

 

报文1如下图所示：

用户VPN侧发起协商，使用的是UDP协议，端口号是500，上层协议是ISAKMP；可以看到发起端提供了自己的cookie值，以及SA的加密套件，加密套件主要是加密算法，哈希算法，认证算法，生存时间等。

Initiator SPI: d8ec4745d242adaa //发起者的SPI值，告知响应端主机要使用IPSEC的哪一把密钥来加密这个包

Responder SPI: 0000000000000000 //响应者的SPI值，第一个包只有发起者没有响应者所以响应者的SPI为空

Version：1.0 //IKE版本号，表示使用ikev1建立连接

Exchange type:Identity Protection (Main Mode) (2) //IKE协商模式为主模式

IKE Attribute (t=12,l=4): Life-Duration: 100800 //密钥周期，密钥过期后会重新协商IKE

IKE Attribute (t=1,l=2): Encryption-Algorithm: AES-CBC //IKE加密数据用的加密算法

IKE Attribute (t=2,l=2): Hash-Algorithm: SHA //IKE校验数据完整性的算法

IKE Attribute (t=3,l=2): Authentication-Method: Pre-shared key //使用预共享密钥认证

IKE Attribute (t=4,l=2): Group-Description: 1536 bit MODP group //Diffie-Hellman (DH) 组在密钥交换进程中使用的1536 bit的密钥强度

 

报文2如下图所示：

网关VPN侧收到用户VPN侧发送的加密套件后，对比自己是否有相对应的加密套件，如果有就发送自己的cookie值和用户VPN侧相同的加密套件；如果没有相同加密套件则IKE建立失败。

Responder SPI: eb6b1b9fc6f1d8b8 //响应者的SPI值，告知发送端使用哪一把密钥加密数据包

 

报文3如下图所示：

用户VPN侧生成随机数和DH公共值，发送自己的DH公共值和Nonce随机数，用于生成加密时所需要的KEY值。

Key Exchange Data: 4e76de3365590153584e28e6f36bbb15d0dce69effdcb78726f55683aa97ef5e3cd02bab… //DH公共值，DH公共值通过Diffie-Hellman算法计算出来；在报文1和报文2中所协商的算法需要一个相同的KEY（即预共享密钥），但这个KEY不能在链路中传递。所以，该过程的目的是分别在两个对等体间独立地生成一个DH公共值，然后在报文中发送给对端，对端通过公式计算出相同的KEY值

 

报文4如下图所示：

类似于报文3，网关VPN侧也生成随机数和DH公共值，发送自己的DH公共值和Nonce随机数。

 

报文5如下图所示：

发送本端身份和验证信息，由于前面已经协商好了加密算法和KEY值，该报文被加密。

 

报文6如下图所示：

类似于报文5。

 

报文7如下图所示：

进行IPSEC SA的协商，主要协商封装方式、加密算法、生存时间和兴趣流等，该报文被加密。

Exchange type：Quick Mode（32） //交换类型使用快速模式，IPSec协商时只有快速模式

 

报文8如下图所示：

网关VPN侧确认收到的协商信息。

 

报文9如下图所示：

用户VPN侧二次确认，并表明本方处于主动状态。