- 产品与解决方案
- 行业解决方案
- 服务
- 支持
- 合作伙伴
- 新华三人才研学中心
- 关于我们
09-IKE配置
本章节下载： 09-IKE配置 (403.49 KB)
若无特殊说明，本文中的IKE均指第1版本的IKE协议。
IKE（Internet Key Exchange，互联网密钥交换）协议利用ISAKMP（Internet Security Association and Key Management Protocol，互联网安全联盟和密钥管理协议）语言定义密钥交换的过程，是一种对安全服务进行协商的手段。
用IPsec保护一个IP数据包之前，必须先建立一个安全联盟（IPsec SA），IPsec SA可以手工创建或动态建立。IKE为IPsec提供了自动建立IPsec SA的服务，具体有以下优点。
· IKE首先会在通信双方之间协商建立一个安全通道（IKE SA），并在此安全通道的保护下协商建立IPsec SA，这降低了手工配置的复杂度，简化IPsec的配置和维护工作。
· IKE的精髓在于DH（Diffie-Hellman）交换技术，它通过一系列的交换，使得通信双方最终计算出共享密钥。在IKE的DH交换过程中，每次计算和产生的结果都是不相关的。由于每次IKE SA的建立都运行了DH交换过程，因此就保证了每个通过IKE协商建立的IPsec SA所使用的密钥互不相关。
· IPsec使用AH或ESP报文头中的顺序号实现防重放。此顺序号是一个32比特的值，此数溢出之前，为实现防重放，IPsec SA需要重新建立，IKE可以自动重协商IPsec SA。
如图1-1所示，IKE为IPsec协商建立SA，并把建立的参数交给IPsec，IPsec使用IKE建立的SA对IP报文加密或认证处理。
图1-1 IPsec与IKE的关系图
IKE使用了两个阶段为IPsec进行密钥协商以及建立SA：
(1) 第一阶段，通信双方彼此间建立了一个已通过双方身份认证和对通信数据安全保护的通道，即建立一个IKE SA（本文中提到的IKE SA都是指第一阶段SA）。
(2) 第二阶段，用在第一阶段建立的IKE SA为IPsec协商安全服务，即为IPsec协商IPsec SA，建立用于最终的IP数据安全传输的IPsec SA。
(3) 第一阶段的IKE协商模式有：主模式（Main Mode）、野蛮模式（Aggressive Mode）。
如图1-2所示，第一阶段主模式的IKE协商过程中包含三对消息，具体内容如下：
(1) 第一对消息完成了SA交换，它是一个协商确认双方IKE安全策略的过程；
(2) 第二对消息完成了密钥交换，通过交换Diffie-Hellman公共值和辅助数据（如：随机数），最终双方计算生成一系列共享密钥（例如，认证密钥、加密密钥以及用于生成IPsec密钥参数的密钥材料），并使其中的加密密钥和认证密钥对后续的IKE消息提供安全保障；
(3) 第三对消息完成了ID信息和验证数据的交换，并进行双方身份的认证。
如图1-3所示，第一阶段野蛮模式的IKE协商过程中包含三条消息，具体内容如下：
(2) 发起方通过第一条消息发送本地IKE信息，包括建立IKE SA所使用的参数、与密钥生成相关的信息和身份验证信息。
(3) 接收方通过第二条消息对收到的第一个消息进行确认，查找并返回匹配的参数、密钥生成信息和身份验证信息。
(4) 发起方通过第三条消息回应验证结果，并成功建立IKE SA。
与主模式相比，野蛮模式的优点是建立IKE SA的速度较快。但是由于野蛮模式的密钥交换与身份认证一起进行，因此无法提供身份保护。在对身份保护要求不高的场合，使用交换报文较少的野蛮模式可以提高协商的速度；在对身份保护要求较高的场合，则应该使用主模式。
本端的协商模式配置为国密主模式，必须使用RSA-DE或者SM2-DE数字信封方式认证。
IKE可以在不安全的网络上安全地认证通信双方的身份、分发密钥以及建立IPsec SA，具有以下几种安全机制。
IKE的身份认证机制用于确认通信双方的身份。设备支持三种认证方法：预共享密钥认证、RSA数字签名认证和DSA数字签名认证。
· 预共享密钥认证：通信双方通过共享的密钥认证对端身份。
· 数字签名认证：通信双方使用由CA颁发的数字证书向对端证明自己的身份。
DH算法是一种公共密钥算法，它允许通信双方在不传输密钥的情况下通过交换一些数据，计算出共享的密钥。即使第三方（如黑客）截获了双方用于计算密钥的所有交换数据，由于其复杂度很高，也不足以计算出双方的密钥。
PFS（Perfect Forward Secrecy，完善的前向安全性）是一种安全特性，它解决了密钥之间相互无关性的需求。由于IKE第二阶段协商需要从第一阶段协商出的密钥材料中衍生出用于IPsec SA的密钥，若攻击者能够破解IKE SA的一个密钥，则会非常容易得掌握其衍生出的任何IPsec SA的密钥。使用PFS特性后，IKE第二阶段协商过程中会增加一次DH交换，使得IKE SA的密钥和IPsec SA的密钥之间没有派生关系，即使IKE SA的其中一个密钥被破解，也不会影响它协商出的其它密钥的安全性。
与IKE相关的协议规范有：
· RFC2408：Internet Security Association and Key Management Protocol (ISAKMP)
· RFC2409：The Internet Key Exchange (IKE)
· RFC2412：The OAKLEY Key Determination Protocol
· Internet-Draft：draft-ietf-ipsec-isakmp-xauth-06.txt
· Internet-Draft：draft-dukes-ike-mode-cfg-02.txt
IKE配置任务如下：
(1) （可选）配置IKE profile
b. 配置匹配对端身份的规则
f. 配置本端身份信息
(2) 配置IKE提议
(3) 配置IKE keychain
(4) （可选）配置本端身份信息
(5) （可选）配置IKE Keepalive功能
(6) （可选）配置IKE NAT Keepalive功能
(7) （可选）配置全局IKE DPD功能
(8) （可选）配置针对无效IPsec SPI的IKE SA恢复功能
(9) （可选）配置对IKE SA数目的限制
(10) （可选）配置为客户端分配IP地址的IKE本地地址池
(11) （可选）配置IKE协商的兼容性
(12) （可选）配置IKE告警和日志功能
进行IKE配置之前，用户需要确定以下几个因素，以便配置过程的顺利进行。
· 确定IKE交换过程中安全保护的强度，包括认证方法、加密算法、认证算法、DH group。
¡ 认证方法分为预共享密钥认证和数字签名认证。预共享密钥认证机制简单、不需要证书，常在小型组网环境中使用；数字签名认证安全性更高，常在“中心—分支”模式的组网环境中使用。例如，在“中心—分支”组网中使用预共享密钥认证进行IKE协商时，中心侧可能需要为每个分支配置一个预共享密钥，当分支很多时，配置会很复杂，而使用数字签名认证时只需配置一个PKI域。
¡ 不同认证/加密算法的强度不同，算法强度越高，受保护数据越难被破解，但消耗的计算资源越多。
¡ DH group位数越大安全性越高，但是处理速度会相应减慢。应该根据实际组网环境中对安全性和性能的要求选择合适的DH group。
· 确定通信双方预先约定的预共享密钥或所属的PKI域。关于PKI的配置，请参见“安全配置指导”中的“PKI”。
· 确定通信双方都采用IKE协商模式的IPsec安全策略。IPsec安全策略中若不引用IKE profile，则使用系统视图下配置的IKE profile进行协商，若系统视图下没有任何IKE profile，则使用全局的IKE参数进行协商。关于IPsec安全策略的配置，请参见“安全配置指导”中的“IPsec”。
创建一个IKE profile，并进入IKE Profile视图。
(1) 进入系统视图。
system-view
(2) 创建一个IKE profile，并进入IKE Profile视图。
ike profile profile-name
响应方首先需要根据发起方的身份信息查找一个本端的IKE profile，然后使用此IKE profile中的信息验证对端身份，发起方同样需要根据响应方的身份信息查找到一个IKE profile用于验证对端身份。对端身份信息若能满足本地某个IKE profile中指定的匹配规则，则该IKE profile为查找的结果。
协商双方都必须配置至少一个match remote规则，当对端的身份与IKE profile中配置的match remote规则匹配时，则使用此IKE profile中的信息与对端完成认证。
(1) 进入系统视图。
system-view
(2) 进入IKE Profile视图。
ike profile profile-name
(3) 配置匹配对端身份的规则。
match remote { certificate policy-name | identity { address { { ipv4-address [ mask | mask-length ] | range low-ipv4-address high-ipv4-address } | ipv6 { ipv6-address [ prefix-length ] | range low-ipv6-address high-ipv6-address } } | fqdn fqdn-name | user-fqdn user-fqdn-name } }
根据IKE提议中配置的认证方法，配置IKE keychain或PKI域。
· 如果认证方法为数字签名（dsa-signature或者rsa-signature），则需要配置PKI域。
· 如果指定的认证方式为预共享密钥（pre-share），则需要配置IKE keychain。
(1) 进入系统视图。
system-view
(2) 进入IKE Profile视图。
ike profile profile-name
(3) 配置keychain或者PKI域。
¡ 配置采用预共享密钥认证时所使用的keychain。
keychain keychain-name
¡ 配置采用数字签名认证时证书所属的PKI域。
certificate domain domain-name
缺省情况下，未指定keychain和PKI域。
配置本端作为发起方时所使用的协商模式（主模式、野蛮模式）。本端作为响应方时，将自动适配发起方的协商模式。
(1) 进入系统视图。
system-view
(2) 进入IKE Profile视图。
ike profile profile-name
(3) 配置IKE第一阶段的协商模式。
exchange-mode { aggressive | gm-main | main }
缺省情况下，IKE第一阶段发起方的协商模式使用主模式。
本端作为发起方时可以使用的IKE提议（可指定多个），先指定的优先级高。响应方会将发起方的IKE提议与本端所有的IKE提议进行匹配，如果找到匹配项则直接使用，否则继续查找。若未查找到匹配的IKE提议，则协商失败。
(1) 进入系统视图。
system-view
(2) 进入IKE Profile视图。
ike profile profile-name
(3) 配置IKE profile引用的IKE提议。
proposal proposal-number&<1-6>
缺省情况下，IKE profile未引用IKE提议，使用系统视图下已配置的IKE提议进行IKE协商。
· 如果本端的认证方式为数字签名，则可以配置任何类型的身份信息。若配置的本端身份为IP地址，但这个IP地址与本地证书中的IP地址不同时，设备将使用FQDN（Fully Qualified Domain Name，完全合格域名）类型的本端身份，该身份的内容为设备的名称（可通过sysname命令配置）。
· 如果本端的认证方式为预共享密钥，则只能配置除DN之外的其它类型的身份信息。
(1) 进入系统视图。
system-view
(2) 进入IKE Profile视图。
ike profile profile-name
(3) 配置本端身份信息。
local-identity { address { ipv4-address | ipv6 ipv6-address } | dn | fqdn [ fqdn-name ] | user-fqdn [ user-fqdn-name ] }
缺省情况下，未配置本端身份信息。此时使用系统视图下通过ike identity命令配置的身份信息作为本端身份信息。若两者都没有配置，则使用IP地址标识本端的身份，该IP地址为IPsec安全策略或IPsec安全策略模板应用的接口的IP地址。
(1) 进入系统视图。
system-view
(2) 进入IKE Profile视图。
ike profile profile-name
(3) 配置IKE profile的可选功能。
¡ 配置IKE DPD功能。
dpd interval interval [ retry seconds ] { on-demand | periodic }
缺省情况下，IKE profile视图下没有配置DPD功能，采用系统视图下的DPD配置。若两者没有配置，则不进行DPD探测。
如果IKE profile视图下和系统视图下都配置了DPD功能，则IKE profile视图下的DPD配置生效，如果IKE profile视图下没有配置DPD功能，则采用系统视图下的DPD配置。
¡ 配置IKE profile的使用范围。
match local address { interface-type interface-number | { ipv4-address | ipv6 ipv6-address } }
缺省情况下，未限制IKE profile的使用范围。
限制IKE profile只能在指定的地址或指定接口的地址下使用。配置了match local address的IKE profile的优先级高于所有未配置match local address的IKE profile。
¡ 配置IKE profile的优先级。
priority priority
缺省情况下，IKE profile的优先级为100。
IKE profile的匹配优先级首先取决于其中是否配置了match local address，其次决定于配置的优先级值，最后决定于配置IKE profile的先后顺序。
¡ 开启对客户端的认证。
client-authentication xauth
缺省情况下，对客户端的认证处于关闭状态。
该命令配置在中心侧网关设备上。在IKE一阶段协商后IPsec协商前，对远程客户端使用AAA机制进行认证。另外，对客户端的认证还需要在网关设备上配置相应的AAA认证方法。
¡ 配置客户端认证的用户名和密码。
client-authentication xauth user
缺省情况下，未配置客户端认证的用户名和密码。
该命令配置在客户端设备上。当远程客户端收到中心侧认证请求报文后，可以使用本命令配置的用户名和密码给中心侧用于AAA认证。
¡ 配置AAA授权功能。
aaa authorization domain domain-name username user-name
缺省情况下，AAA授权功能处于关闭状态。
通过本功能可以获得授权的IKE本地地址池的名称，地址池中配置了可分配给对端的IP地址。关于AAA授权IKE本地地址池的具体配置请参见“用户接入与认证配置指导”中的“AAA”。
¡ 配置IKE SA软超时缓冲时间。
sa soft-duration buffer seconds
缺省情况下，未配置IKE SA的软超时缓冲时间。
通过配置软超时缓冲时间来控制SA重协商的时机，即软超时时间。软超时时间=IKE SA的生存时间－IKE SA软超时缓冲时间。
¡ 配置IKE国密主模式协商时使用的SM4算法版本。
ike gm-main sm4-version { draft | standard }
缺省情况下，IKE国密主模式协商时使用的SM4算法版本为standard。
设备作为发起方与其他厂家设备进行IKE协商时，需要通过本命令指定SM4算法版本，保证两端设备使用相同版本的SM4算法进行协商。
IKE定义了一套属性数据来描述IKE第一阶段使用怎样的参数来与对端进行协商。用户可以创建多条不同优先级的IKE提议。协商双方必须至少有一条匹配的IKE提议才能协商成功。
在进行IKE协商时，协商发起方会将自己的IKE提议发送给对端，由对端进行匹配。
· 若发起方使用的IPsec安全策略中没有引用IKE profile，则会将当前系统中所有的IKE提议发送给对端，这些IKE提议的优先级顺序由IKE提议的序号决定，序号越小优先级越高；
· 若发起方的IPsec策略中引用了IKE profile，则会将该IKE profile中引用的所有IKE提议发送给对端，这些IKE提议的优先级由引用的先后顺序决定，先引用的优先级高。
协商响应方则以对端发送的IKE提议优先级从高到低的顺序与本端所有的IKE提议进行匹配，直到找到一个匹配的提议来使用。匹配的IKE提议将被用来建立IKE SA。
以上IKE提议的匹配原则是：协商双方具有相同的加密算法、认证方法、认证算法和DH group标识。匹配的IKE提议的IKE SA存活时间则取两端的最小值。
(1) 进入系统视图。
system-view
(2) 创建IKE提议，并进入IKE提议视图。
ike proposal proposal-number
缺省情况下，存在一个缺省的IKE提议。
(3) 配置IKE提议的描述信息。
description
不存在IKE提议的描述信息。
(4) 指定一个供IKE提议使用的加密算法。
encryption-algorithm { 3des-cbc | aes-cbc-128 | aes-cbc-192 | aes-cbc-256 | des-cbc | sm1-cbc-128 | sm4-cbc }
缺省情况下，IKE提议使用CBC模式的56-bit DES加密算法。
(5) 指定一个供IKE提议使用的认证方法。
authentication-method { dsa-signature | pre-share | rsa-de | rsa-signature | sm2-de }
缺省情况下，IKE提议使用预共享密钥的认证方法。
(6) 指定一个供IKE提议使用的认证算法。
authentication-algorithm { md5 | sha | sha256 | sha384 | sha512 | sm3 }
缺省情况下，IKE提议使用HMAC-SHA1认证算法。
(7) 配置IKE第一阶段密钥协商时所使用的DH密钥交换参数。
dh { group1 | group14 | group2 | group24 | group5 }
缺省情况下，IKE第一阶段密钥协商时所使用的DH密钥交换参数为group1，即768-bit的Diffie-Hellman group。
(8) （可选）指定一个IKE提议的IKE SA存活时间。
sa duration seconds
缺省情况下，IKE提议的IKE SA存活时间为86400秒。
若配置中同时存在IPsec SA存活时间，则建议IKE SA存活时间大于IPsec SA存活时间。
在IKE需要通过预共享密钥方式进行身份认证时，协商双方需要创建并指定IKE keychain。IKE keychain用于配置协商双方的密钥信息，具体包括以下内容：
· 预共享密钥。IKE协商双方配置的预共享密钥必须相同，否则身份认证会失败。以明文或密文方式设置的预共享密钥，均以密文的方式保存在配置文件中。
· IKE keychain的使用范围。限制keychain的使用范围，即IKE keychain只能在指定的地址或指定接口对应的地址下使用（这里的地址指的是IPsec安全策略/IPsec安全策略模板下配置的本端地址，若本端地址没有配置，则为引用IPsec安全策略的接口的IP地址）。
· IKE keychain的优先级。配置了match local address的IKE keychain的优先级高于所有未配置match local address的IKE keychain。即IKE keychain的优先级首先决定于是否配置了match local address，其次取决于配置的优先级，最后决定于配置IKE keychain的先后顺序。
(1) 进入系统视图。
system-view
(2) 创建IKE keychain，并进入IKE keychain视图。
ike keychain keychain-name
(3) 配置预共享密钥。
pre-shared-key { address { ipv4-address [ mask | mask-length ] | ipv6 ipv6-address [ prefix-length ] } | hostname host-name } key { cipher | simple } string
缺省情况下，未配置预共享密钥。
(4) （可选）配置IKE keychain的使用范围。
match local address { interface-type interface-number | { ipv4-address | ipv6 ipv6-address } }
缺省情况下，未限制IKE keychain的使用范围。
(5) （可选）配置IKE keychain的优先级。
priority priority
缺省情况下，IKE keychain的优先级为100。
本端身份信息适用于所有IKE SA的协商，而IKE profile下的local-identity仅适用于本IKE profile。如果IKE profile下没有配置本端身份，则默认使用此处配置的全局本端身份。
· 如果本端采用的认证方式为数字签名，则本端配置的任何类型的身份信息都有效；
· 如果本端采用认证方式为预共享密钥，则本端除DN之外的其它类型的身份信息均有效。
(1) 进入系统视图。
system-view
(2) 配置本端身份信息。
ike identity { address { ipv4-address | ipv6 ipv6-address }| dn | fqdn [ fqdn-name ] | user-fqdn [ user-fqdn-name ] }
缺省情况下，使用IP地址标识本端的身份，该IP地址为IPsec安全策略或IPsec安全策略模板应用的接口地址。
(3) （可选）配置当使用数字签名认证方式时，本端的身份总从证书的主题字段中获得。
ike signature-identity from-certificate
缺省情况下，本端身份信息由local-identity或ike identity命令指定。
在采用IPsec野蛮协商模式且使用数字签名认证方式的情况下，与仅支持使用DN类型的身份进行数字签名认证的ComwareV5设备互通时需要配置本命令。
IKE Keepalive功能用于检测对端是否存活。在对端配置了等待IKE Keepalive报文的超时时间后，必须在本端配置发送IKE Keepalive报文的时间间隔。当对端IKE SA在配置的超时时间内未收到IKE Keepalive报文时，则删除该IKE SA以及由其协商的IPsec SA。
· 当有检测对方是否存活的需求时，通常建议配置IKE DPD，不建议配置IKE Keepalive。仅当对方不支持IKE DPD功能且支持IKE Keepalive功能时，才考虑配置IKE Keepalive功能。配置IKE Keepalive功能后，会定时检测对方是否存活，因此会额外消耗网络带宽和计算资源。
· 本端配置的IKE Keepalive报文的等待超时时间要大于对端发送的时间间隔。由于网络中一般不会出现超过连续三次的报文丢失，所以，本端的超时时间可以配置为对端配置的发送IKE Keepalive报文的时间间隔的三倍。
(1) 进入系统视图。
system-view
(2) 配置通过IKE SA向对端发送IKE Keepalive报文的时间间隔。
ike keepalive interval interval
缺省情况下，不向对端发送IKE Keepalive报文。
(3) 配置本端等待对端发送IKE Keepalive报文的超时时间。
ike keepalive timeout seconds
缺省情况下，永不超时，一直等待对端发送IKE Keepalive报文。
在采用IKE协商建立的IPsec隧道中，可能存在NAT设备，由于在NAT设备上的NAT会话有一定存活时间，一旦IPsec隧道建立后如果长时间没有流量，对应的NAT会话表项会被删除，这样将导致IPsec隧道无法继续传输数据。为防止NAT表项老化，NAT内侧的IKE网关设备需要定时向NAT外侧的IKE网关设备发送NAT Keepalive报文，以便维持NAT设备上对应的IPsec流量的会话存活，从而让NAT外侧的设备可以访问NAT内侧的设备。
(1) 进入系统视图。
system-view
(2) 配置向对端发送NAT Keepalive报文的时间间隔。
ike nat-keepalive seconds
缺省情况下，向对端发送NAT Keepalive报文的时间间隔为20秒。
DPD（Dead Peer Detection，对等体存活检测）用于检测对端是否存活。本端主动向对端发送DPD请求报文，对对端是否存活进行检测。如果本端在DPD报文的重传时间间隔（retry seconds）内未收到对端发送的DPD回应报文，则重传DPD请求报文，若重传两次之后仍然没有收到对端的DPD回应报文，则删除该IKE SA和对应的IPsec SA。
· IKE DPD有两种模式：按需探测模式（on-demand）和定时探测模式（periodic）。一般若无特别要求，建议使用按需探测模式，在此模式下，仅在本端需要发送报文时，才会触发探测；如果需要尽快地检测出对端的状态，则可以使用定时探测模式。在定时探测模式下工作，会消耗更多的带宽和计算资源，因此当设备与大量的IKE对端通信时，应优先考虑使用按需探测模式。
· 如果IKE profile视图下和系统视图下都配置了DPD探测功能，则IKE profile视图下的DPD配置生效，如果IKE profile视图下没有配置DPD探测功能，则采用系统视图下的DPD配置。
· 建议配置的触发IKE DPD探测的时间间隔大于DPD报文的重传时间间隔，使得直到当前DPD探测结束才可以触发下一次DPD探测，DPD在重传过程中不触发新的DPD探测。
· 以定时探测模式为例，若本端的IKE DPD配置如下：ike dpd interval 10 retry 6 periodic，则具体的探测过程为：IKE SA协商成功之后10秒，本端会发送DPD探测报文，并等待接收DPD回应报文。若本端在6秒内没有收到DPD回应报文，则会第二次发送DPD探测报文。在此过程中总共会发送五次DPD探测报文，若第五次DPD探测报文发出后6秒仍没收到DPD回应报文，则会删除发送DPD探测报文的IKE SA及其对应的所有IPsec SA。若在此过程中收到了DPD回应报文，则会等待10秒再次发送DPD探测报文。
(1) 进入系统视图。
system-view
(2) 配置IKE DPD功能。
ike dpd interval interval [ retry seconds ] { on-demand | periodic }
缺省情况下，IKE DPD功能处于关闭状态。
当IPsec隧道一端的安全网关出现问题（例如安全网关重启）导致其IPsec SA丢失时，会造成IPsec流量黑洞现象：一端（接收端）的IPsec SA已经丢失，而另一端（发送端）还持有对应的IPsec SA且不断地向对端发送报文，当接收端收到发送端使用此IPsec SA封装的IPsec报文时，就会因为找不到对应的SA而持续丢弃报文，形成流量黑洞。该现象造成IPsec通信链路长时间得不到恢复（只有等到发送端旧的IPsec SA生存时间超时，并重建IPsec SA后，两端的IPsec流量才能得以恢复），因此需要采取有效的IPsec SA恢复手段来快速恢复中断的IPsec通信链路。
IPsec SA由SPI唯一标识，接收方根据IPsec报文中的SPI在SA数据库中查找对应的IPsec SA，若接收方找不到处理该报文的IPsec SA，则认为此报文的SPI无效。如果接收端当前存在IKE SA，则会向对端发送删除对应IPsec SA的通知消息，发送端IKE接收到此通知消息后，就会立即删除此无效SPI对应的IPsec SA。之后，当发送端需要继续向接收端发送报文时，就会触发两端重建IPsec SA，使得中断的IPsec通信链路得以恢复；如果接收端当前不存在IKE SA，就不会触发本端向对端发送删除IPsec SA的通知消息，接收端将默认丢弃无效SPI的IPsec报文，使得链路无法恢复。后一种情况下，如果开启了IPsec无效SPI恢复IKE SA功能，就会触发本端与对端协商新的IKE SA并发送删除消息给对端，从而使链路恢复正常。
由于开启此功能后，若攻击者伪造大量源IP地址不同但目的IP地址相同的无效SPI报文发给设备，会导致设备因忙于与无效对端协商建立IKE SA而面临受到DoS（Denial of Sevice）攻击的风险。因此，建议通常不要打开ike invalid-spi-recovery enable功能。
(1) 进入系统视图。
system-view
(2) 开启针对无效IPsec SPI的IKE SA恢复功能。
ike invalid-spi-recovery enable
缺省情况下，针对无效IPsec SPI的IKE SA恢复功能处于关闭状态。
由于不同设备的能力不同，为充分利用设备的处理能力，可以配置允许同时处于协商状态的IKE SA的最大数，也可以配置允许建立的IKE SA的最大数。
若设置允许同时协商更多的IKE SA，则可以充分利用设备处理能力，以便在设备有较强处理能力的情况下得到更高的新建性能；若设置允许同时协商较少的IKE SA，则可以避免产生大量不能完成协商的IKE SA，以便在设备处理能力较弱时保证一定的新建性能。
若设置允许建立更多的IKE SA，则可以使得设备在有充足内存的情况下得到更高的并发性能；若设置允许建立较少的IKE SA，则可以在设备没有充足内存的情况下，使得IKE不过多占用系统内存。
(1) 进入系统视图。
system-view
(2) 配置对本端IKE SA数目的限制。
ike limit { max-negotiating-sa negotiation-limit | max-sa sa-limit }
缺省情况下，不限制允许同时处于协商状态的IKE SA数目，也不限制允许建立的IKE SA的最大数目。
IKE本地地址池与AAA授权配合使用，可以向对端客户端应答地址请求，从而使得企业分支客户端使用由企业中心网关统一分配的IP地址作为私网地址来进行通信，达到由企业中心统一管理的目的。关于AAA如何授权IKE本地地址池的具体配置请参见“用户接入与认证”中的“AAA”。
(1) 进入系统视图。
system-view
(2) 配置为对端分配IPv4地址的IKE本地地址池。
ike address-group group-name start-ipv4-address end-ipv4-address [ mask | mask-length ]
由于历史原因，IKE协商使用sm4-cbc算法和国密主模式存在兼容性问题。通过配置本功能，设备可以兼容老版本设备，保证新老版本设备IKE协商成功。仅当新老版本设备进行IKE协商时，需要在新版本设备上配置本功能。老版本设备是指不支持本功能的设备，新版本设备是指支持本功能的设备。
(1) 进入系统视图。
system-view
(2) 配置IKE协商使用sm4-cbc算法的兼容性。
ike compatible-sm4 enable
缺省情况下，IKE协商过程中使用的sm4-cbc算法的密钥长度不兼容老版本。
(3) 配置IKE协商国密主模式的兼容性。
ike compatible-gm-main enable
缺省情况下，IKE协商国密主模式与现有版本设备及第三方设备兼容。
开启IKE的告警功能后，IKE会生成告警信息，用于向网管软件报告该模块的重要事件。生成的告警信息将被发送到设备的SNMP模块，通过设置SNMP中告警信息的发送参数，来决定告警信息输出的相关属性。有关告警信息的详细介绍，请参见“网络管理和监控配置指导”中的“SNMP”。
如果希望生成并输出某种类型的IKE告警信息，则需要保证IKE的全局告警功能以及相应类型的告警功能均处于开启状态。
(1) 进入系统视图。
system-view
(2) 开启IKE的全局告警功能。
snmp-agent trap enable ike global
缺省情况下，IKE的告警Trap功能处于关闭状态。
(3) 开启IKE的指定告警功能。
snmp-agent trap enable ike [ attr-not-support | auth-failure | cert-type-unsupport | cert-unavailable | decrypt-failure | encrypt-failure | invalid-cert-auth | invalid-cookie | invalid-id | invalid-proposal | invalid-protocol | invalid-sign | no-sa-failure | proposal-add | proposal–delete | tunnel-start | tunnel-stop | unsupport-exch-type ] *
缺省情况下，IKE的所有告警功能均处于关闭状态。
开启IKE协商事件日志记录功能后，设备会输出IKE协商过程中的相关日志。
(1) 进入系统视图。
system-view
(2) 开启IKE协商事件日志功能。
ike logging negotiation enable
缺省情况下，IKE协商事件日志功能处于关闭状态。
可在任意视图下执行以下命令：
· 显示所有IKE提议的配置信息。
display ike proposal
· 显示当前IKE SA的信息。
display ike sa [ verbose [ connection-id connection-id | remote-address [ ipv6 ] remote-address ] ]
· 显示IKE的统计信息。
display ike statistics
请在用户视图下执行以下命令：
· 清除IKE SA。
reset ike sa [ connection-id connection-id ]
· 清除IKE的MIB统计信息。
reset ike statistics
(1) 通过如下命令查看当前的IKE SA信息，发现IKE SA的状态（Flags字段）为Unknown。
<Sysname> display ike sa
Connection-ID Remote Flag DOI
------------------------------------------------------------------
1 192.168.222.5/500 Unknown IPsec
Flags:
RD--READY RL--REPLACED FD-FADING RK-REKEY
(2) 打开IKE事件和报文调试信息开关后分别可以看到如下调试信息。
IKE事件调试信息：
The attributes are unacceptable.
IKE报文调试信息：
Construct notification packet: NO_PROPOSAL_CHOSEN.
IKE提议配置错误。
(1) 排查IKE提议相关配置。具体包括：检查两端的IKE提议是否匹配，即IKE提议中的认证方法、认证算法、加密算法是否匹配。
(2) 修改IKE提议的配置，使本端IKE提议的配置和对端匹配。
(1) 通过如下命令查看当前的IKE SA信息，发现IKE SA的状态（Flags字段）为Unknown。
<Sysname> display ike sa
Connection-ID Remote Flag DOI
------------------------------------------------------------------
1 192.168.222.5/500 Unknown IPsec
Flags:
RD--READY RL--REPLACED FD-FADING RK-REKEY
(2) 打开IKE事件和报文调试信息开关后分别可以看到如下调试信息。
IKE事件调试信息：
Notification PAYLOAD_MALFORMED is received.
IKE报文调试信息：
Construct notification packet: PAYLOAD_MALFORMED.
故障原因可能为以下两点：
(1) 匹配到的IKE profile中没有引用协商过程中匹配到的IKE提议。
通过调试信息看到：
Failed to find proposal 1 in profile profile1.
(2) 匹配到的IKE profile中没有引用协商过程中匹配到的IKE keychain。
通过调试信息看到：
Failed to find keychain keychain1 in profile profile1.
(1) 检查匹配到的IKE提议是否在IKE profile下引用。以故障分析中的调试信息为例，IKE profile profile1中需要引用IKE proposal 1。
(2) 检查匹配到的IKE keychain是否在IKE profile下引用。以故障分析中的调试信息为例，IKE profile profile1中需要引用IKE keychain keychain1。
(1) 通过display ike sa命令查看当前的IKE SA信息，发现IKE SA协商成功，其状态（Flags字段）为RD。但通过display ipsec sa命令查看当前的IPsec SA时，发现没有协商出相应的IPsec SA。
(2) 打开IKE调试信息开关可以看到以下调试信息：
The attributes are unacceptable.
或者：
Construct notification packet: NO_PROPOSAL_CHOSEN.
IPsec安全策略参数配置错误。
(1) 排查IPsec相关配置。具体包括：检查双方接口上应用的IPsec安全策略的参数是否匹配，即引用的IPsec安全提议的协议、加密算法和认证算法是否匹配。
(2) 修改IPsec安全策略配置，使本端IPsec安全策略的配置和对端匹配。
(1) 通过display ike sa命令查看当前的IKE SA信息，发现IKE SA协商成功，其状态（Flags字段）为RD。但通过display ipsec sa命令查看当前的IPsec SA时，发现没有协商出相应的IPsec SA。
(2) 打开IKE调试信息开关可以看到以下调试信息：
Notification INVALID_ID_INFORMATION is received.
或者：
Failed to get IPsec policy when renegotiating IPsec SA. Delete IPsec SA.
Construct notification packet: INVALID_ID_INFORMATION.
响应方IPsec安全策略配置错误，导致在IKE第二阶段协商时找不到IPsec安全策略，原因可能为如下几点：
(1) 通过display ike sa verbose命令查看IKE一阶段协商中是否找到匹配的IKE profile。若没有找到IKE profile，则会查找全局的IKE参数，因此就要求这种情况下IPsec安全策略中不能引用任何IKE profile，否则协商失败。
通过如下显示信息可以看到，IKE SA在协商过程中没有找到匹配的IKE profile：
<Sysname> display ike sa verbose
-----------------------------------------------
Connection ID: 3
Outside VPN:
Inside VPN:
Profile:
Transmitting entity: Responder
Initiator cookie: 1bcf453f0a217259
Responder cookie: 5e32a74dfa66a0a4
-----------------------------------------------
Local IP/port: 192.168.222.5/500
Local ID type: IPV4_ADDR
Local ID: 192.168.222.5
Remote IP/port: 192.168.222.71/500
Remote ID type: IPV4_ADDR
Remote ID: 192.168.222.71
Authentication-method: PRE-SHARED-KEY
Authentication-algorithm: MD5
Encryption-algorithm: 3DES-CBC
Life duration(sec): 86400
Remaining key duration(sec): 85847
Exchange-mode: Main
Diffie-Hellman group: Group 1
NAT traversal: Not detected
Vendor ID index: 0xa1d
Vendor ID sequence number: 0x0
但在IPsec策略中引用了IKE profile profile1：
[Sysname] display ipsec policy
-------------------------------------------
IPsec Policy: policy1
Interface: GigabitEthernet1/0/1
-------------------------------------------
-----------------------------
Sequence number: 1
Mode: ISAKMP
-----------------------------
Description:
Security data flow: 3000
Selector mode: aggregation
Local address: 192.168.222.5
Remote address: 192.168.222.71
Transform set: transform1
IKE profile: profile1
SA trigger mode: Auto
SA duration(time based): 3600 seconds
SA duration(traffic based): 1843200 kilobytes
SA soft-duration buffer(time based): 1000 seconds
SA soft-duration buffer(traffic based): 43200 kilobytes
SA idle time: 100 seconds
Responder only: Disabled
(2) 查看IPsec安全策略中引用的ACL配置是否正确。
例如，如发起方ACL流范围为网段到网段：
[Sysname] display acl 3000
Advanced IPv4 ACL 3000, 1 rule,
ACL's step is 5
rule 0 permit ip source 192.168.222.0 0.0.0.255 destination 192.168.222.0 0.0.0.255
响应方ACL流范围为主机到主机：
[Sysname] display acl 3000
Advanced IPv4 ACL 3000, 1 rule,
ACL's step is 5
rule 0 permit ip source 192.168.222.71 0 destination 192.168.222.5 0
以上配置中，响应方ACL规则定义的流范围小于发起方ACL规则定义的流范围，这会导致IPsec SA协商失败。
(3) IPsec 安全策略配置不完整。具体包括：没有配置对端地址、没有配置IPsec提议、IPsec提议配置不完整。
例如，如下IPsec安全策略中没有配置隧道的对端IP地址，因此IPsec安全策略是不完整的：
[Sysname] display ipsec policy
-------------------------------------------
IPsec Policy: policy1
Interface: GigabitEthernet1/0/1
-------------------------------------------
-----------------------------
Sequence number: 1
Mode: ISAKMP
-----------------------------
Security data flow: 3000
Selector mode: aggregation
Local address: 192.168.222.5
Remote address:
Transform set: transform1
IKE profile: profile1
SA trigger mode: Auto
SA duration(time based): 3600 seconds
SA duration(traffic based): 1843200 kilobytes
SA soft-duration buffer(time based): 1000 seconds
SA soft-duration buffer(traffic based): 43200 kilobytes
SA idle time: 100 seconds
Responder only: Disabled
(1) 若在IKE第一阶段协商过程中没有找到IKE profile，建议在响应方IPsec安全策略中去掉对IKE profile的引用或者调整IKE profile的配置使之能够与发起端相匹配。
(2) 若响应方ACL规则定义的流范围小于发起方ACL规则定义的流范围，建议修改响应方ACL的流范围大于或等于发起方ACL的流范围。以故障分析（2）中的配置为例，可以将响应方ACL流范围修改为：
[Sysname] display acl 3000
Advanced IPv4 ACL 3000, 2 rules,
ACL's step is 5
rule 0 permit ip source 192.168.222.0 0.0.0.255 destination 192.168.222.0 0.0.0.255
(3) 将IPsec安全策略配置完整。以故障分析中的（3）中的配置为例，需要在IPsec安全策略中配置隧道的对端IP地址。
不同款型规格的资料略有差异, 详细信息请向具体销售和400咨询。H3C保留在没有任何通知或提示的情况下对资料内容进行修改的权利!
支持
售前咨询
售后咨询
人工在线咨询
