由于iNode在L2tpoverIPSec下第一次启动时发送相同的icookie导致概率出现ike协商不过问题的解决方法

由于iNode在L2tpoverIPSec下第一次启动时发送相同的iCOOKIE导致概率出现ike协商不过问题的解决方法

一、       组网：

iNode与设备配置做L2tpoverIPSec认证，IPSEC采用野蛮（aggressive）模式。

二、       问题描述：

在网络正常，各项参数配置正确的情况下，iNode 3.60-C6206及之前版本在做认证时第一次认证会概率的出现ike协商不过导致认证失败，如下图所示。此时再认证一次可以成功通过ike协商。

三、       过程分析：

在某些异常的情况下（比如用户认证后直接拔了网线，此时ike的下线报文到不了设备）这样关于这个终端用户的ike sa 会在ike的生存周期life-time（默认是86400秒）内存在。这样在这个用户再次使用iNode认证前，设备上已经有了关于这个终端用户的ike sa。

iNode启动后第一次认证，在建立ike sa时发出的第一个isakmp aggressive报文中的ICOOKIE总是同一个值。后续的ICOOKIE会随机。

综上，这时iNode做L2tpoverIPSec认证，由于设备上已经存在了关于此终端的ike sa,如下图所示（终端用户的IP为10.153.49.160）

[U200M]dis ike sa

    total phase-1 SAs:  3

    connection-id  peer            flag        phase   doi

  ----------------------------------------------------------

     35            10.153.49.230   RD            1     IPSEC

     7             10.153.49.160   RD            1     IPSEC

     39            10.153.49.160   RD            1     IPSEC

 

设备上的ike sa session会记住此session的每个ICOOKIE。由于iNode建立ike sa时发出的第一个isakmp aggressive报文中的ICOOKIE总是同一个值，如果终端用户重启了iNode的进程或操作系统，再次认证进行ike协商时会由于IOOKIE重复导致第一个isakmp aggressive报文被设备丢弃。

问题发生时设备上的debug ike all如下所示

*Oct 12 04:34:36:664 2009 U200M IKE/7/DEBUG: message recv:

*Oct 12 04:34:36:664 2009 U200M IKE/7/DEBUG:   ICOOKIE: 0x4337680755510447

*Oct 12 04:34:36:664 2009 U200M IKE/7/DEBUG:   RCOOKIE: 0x0000000000000000

*Oct 12 04:34:36:665 2009 U200M IKE/7/DEBUG:   NEXT_PAYLOAD: SA

*Oct 12 04:34:36:665 2009 U200M IKE/7/DEBUG:   VERSION: 16

*Oct 12 04:34:36:665 2009 U200M IKE/7/DEBUG:   EXCH_TYPE: AGGRESSIVE

*Oct 12 04:34:36:666 2009 U200M IKE/7/DEBUG:   FLAGS: [ ]

*Oct 12 04:34:36:666 2009 U200M IKE/7/DEBUG:   MESSAGE_ID: 0x00000000

*Oct 12 04:34:36:666 2009 U200M IKE/7/DEBUG:   LENGTH: 219

*Oct 12 04:34:36:667 2009 U200M IKE/7/DEBUG: exchange lookup all list from COOKIE: iCOOKIE 4337680755510447

*Oct 12 04:34:36:667 2009 U200M IKE/7/DEBUG: message recv: dropping setup for existing SA

iNode重发此isakmp报文后下线，iNode抓包如下图所示

 

四、       解决方法：

以下这几个规避解决方案为并列关系，根据实际情况采用其中的一种即可。

1.由于iNode下一次认证会使用随机的ICOOKIE，此时再认证一次即可规避解决此问题。

2.可以在设备上将ike sa的生存周期life-time配置短一些，这样可以加速设备上ike sa 的老化速度，以减少此问题发生的概率。

3.可以在设备上配置ike sa keep-alive(注意不是dpd),同时在iNode“VPN连接属性”－“基本配置”－“高级”－“ike设置”tab页上配置“定时发送KeepAlive报文”来缩小设备上ike sa的老化时间（如下图所示）。该方法解决思路与方法2相同，均是通过缩小设备上ike sa的老化时间来降低概率。与2相比，这个方法可以将设备上ike sa的老化时间缩的更短，但这个方法会增加整个方案的复杂性，同时也加重了设备的开销（当多个用户同时连接时设备要不停的发送keepalive）.另外请注意iNode上的时间隔离请与设备上的配置保持一致。

n