目  录

1 IPsec

1.1 IPsec简介

1.1.1 安全协议及封装模式

1.1.2 安全联盟

1.1.3 认证与加密

1.1.4 IPsec实现方式

1.1.5 协议规范

1.2 基于ACL建立IPsec隧道

1.2.1 基于ACL建立IPsec隧道配置任务简介

1.2.2 配置ACL

1.2.3 配置IPsec安全提议

1.2.4 配置手工方式的IPsec安全策略

1.2.5 配置IKE协商方式的IPsec安全策略

1.2.6 在接口上应用IPsec安全策略

1.2.7 配置IPsec报文日志信息记录功能

1.3 配置IPsec告警功能

1.4 配置本端允许建立IPsec隧道的最大数

1.5 IPsec显示和维护

2 IKE

2.1 IKE简介

2.1.2 IKE的协商过程

2.1.3 IKE的安全机制

2.1.4 协议规范

2.2 IKE配置任务简介

2.3 配置IKE profile

2.4 配置IKE提议

2.5 配置IKE keychain

2.6 配置本端身份信息

2.7 配置IKE Keepalive功能

2.8 配置IKE NAT Keepalive功能

2.9 配置IKE DPD功能

2.10 配置对IKE SA数目的限制

2.11 配置IKE告警功能

2.12 IKE显示和维护

2.13 常见错误配置举例

2.13.1 提议不匹配导致IKE SA协商失败

2.13.2 未正确引用IKE提议或IKE keychain导致IKE SA协商失败

2.13.3 提议不匹配导致IPsec SA协商失败

2.13.4 身份信息无效导致IPsec SA协商失败

1 IPsec

1.1  IPsec简介

IPsec（IP Security，IP安全）是IETF制定的三层隧道加密协议，它为互联网上传输的数据提供了高质量的、基于密码学的安全保证，是一种传统的实现三层VPN（Virtual Private Network，虚拟专用网络）的安全技术。IPsec通过在特定通信方之间（例如两个安全网关之间）建立“通道”，来保护通信方之间传输的用户数据，该通道通常称为IPsec隧道。

IPsec协议不是一个单独的协议，它为IP层上的网络数据安全提供了一整套安全体系结构，包括安全协议AH（Authentication Header，认证头）和ESP（Encapsulating Security Payload，封装安全载荷）、IKE（Internet Key Exchange，互联网密钥交换）以及用于网络认证及加密的一些算法等。其中，AH协议和ESP协议用于提供安全服务，IKE协议用于密钥交换。关于IKE的详细介绍请参见“安全配置指导”中的“IKE”，本节不做介绍。

IPsec提供了两大安全机制：认证和加密。认证机制使IP通信的数据接收方能够确认数据发送方的真实身份以及数据在传输过程中是否遭篡改。加密机制通过对数据进行加密运算来保证数据的机密性，以防数据在传输过程中被窃听。

IPsec为IP层的数据报文提供的安全服务具体包括以下几种：

·     数据机密性（Confidentiality）：发送方通过网络传输用户报文前，IPsec对报文进行加密。

·     数据完整性（Data Integrity）：接收方对发送方发送来的IPsec报文进行认证，以确保数据在传输过程中没有被篡改。

·     数据来源认证（Data Authentication）：接收方认证发送IPsec报文的发送端是否合法。

·     抗重放（Anti-Replay）：接收方可检测并拒绝接收过时或重复的IPsec报文。

IPsec具有以下优点：

·     支持IKE（Internet Key Exchange，互联网密钥交换），可实现密钥的自动协商功能，减少了密钥协商的开销。可以通过IKE建立和维护SA（Security Association，安全联盟），简化了IPsec的使用和管理。

·     所有使用IP协议进行数据传输的应用系统和服务都可以使用IPsec，而不必对这些应用系统和服务本身做任何修改。

·     对数据的加密是以数据包为单位的，而不是以整个数据流为单位，这不仅灵活而且有助于进一步提高IP数据包的安全性，可以有效防范网络攻击。

1.1.1  安全协议及封装模式

1. 安全协议

IPsec包括AH和ESP两种安全协议，它们定义了对IP报文的封装格式以及可提供的安全服务。

·     AH协议（IP协议号为51）定义了AH头在IP报文中的封装格式，如图1-3所示。AH可提供数据来源认证、数据完整性校验和抗重放功能，它能保护报文免受篡改，但不能防止报文被窃听，适合用于传输非机密数据。AH使用的认证算法有HMAC-MD5和HMAC-SHA1。

·     ESP协议（IP协议号为50）定义了ESP头和ESP尾在IP报文中的封装格式，如图1-3所示。ESP可提供数据加密、数据来源认证、数据完整性校验和抗重放功能。与AH不同的是，ESP将需要保护的用户数据进行加密后再封装到IP包中，以保证数据的机密性。ESP使用的加密算法有DES、3DES、AES等。同时，作为可选项，ESP还可以提供认证服务，使用的认证算法有HMAC-MD5和HMAC-SHA1。虽然AH和ESP都可以提供认证服务，但是AH提供的认证服务要强于ESP。

在实际使用过程中，可以根据具体的安全需求同时使用这两种协议或仅使用其中的一种。设备支持的AH和ESP联合使用的方式为：先对报文进行ESP封装，再对报文进行AH封装。

2. 封装模式

IPsec支持两种封装模式：

·     传输模式（Transport Mode）

该模式下的安全协议主要用于保护上层协议报文，仅传输层数据被用来计算安全协议头，生成的安全协议头以及加密的用户数据（仅针对ESP封装）被放置在原IP头后面。若要求端到端的安全保障，即数据包进行安全传输的起点和终点为数据包的实际起点和终点时，才能使用传输模式。如图1-1所示，通常传输模式用于保护两台主机之间的数据。

图1-1 传输模式下的IPsec保护

·     隧道模式（Tunnel Mode）

该模式下的安全协议用于保护整个IP数据包，用户的整个IP数据包都被用来计算安全协议头，生成的安全协议头以及加密的用户数据（仅针对ESP封装）被封装在一个新的IP数据包中。这种模式下，封装后的IP数据包有内外两个IP头，其中的内部IP头为原有的IP头，外部IP头由提供安全服务的设备添加。在安全保护由设备提供的情况下，数据包进行安全传输的起点或终点不为数据包的实际起点和终点时（例如安全网关后的主机），则必须使用隧道模式。如图1-2所示，通常隧道模式用于保护两个安全网关之间的数据。

图1-2 隧道模式下的IPsec保护

不同的安全协议及组合在隧道和传输模式下的数据封装形式如图1-3所示。

图1-3 安全协议数据封装格式

1.1.2  安全联盟

SA（Security Association，安全联盟）是IPsec的基础，也是IPsec的本质。IPsec在两个端点之间提供安全通信，这类端点被称为IPsec对等体。SA是IPsec对等体间对某些要素的约定，例如，使用的安全协议（AH、ESP或两者结合使用）、协议报文的封装模式（传输模式或隧道模式）、认证算法（HMAC-MD5或HMAC-SHA1）、加密算法（DES、3DES或AES）、特定流中保护数据的共享密钥以及密钥的生存时间等。

SA是单向的，在两个对等体之间的双向通信，最少需要两个SA来分别对两个方向的数据流进行安全保护。同时，如果两个对等体希望同时使用AH和ESP来进行安全通信，则每个对等体都会针对每一种协议来构建一个独立的SA。

SA由一个三元组来唯一标识，这个三元组包括SPI（Security Parameter Index，安全参数索引）、目的IP地址和安全协议号。其中，SPI是用于标识SA的一个32比特的数值，它在AH和ESP头中传输。

SA有手工配置和IKE自动协商两种生成方式：

·     手工方式：通过命令行配置SA的所有信息。该方式的配置比较复杂，而且不支持一些高级特性（例如定时更新密钥），优点是可以不依赖IKE而单独实现IPsec功能。该方式主要用于需要安全通信的对等体数量较少，或小型静态的组网环境中。

·     IKE自动协商方式：对等体之间通过IKE协议自动协商生成SA，并由IKE协议维护该SA。该方式的配置相对比较简单，扩展能力强。在中、大型的动态网络环境中，推荐使用IKE自动协商建立SA。

手工方式建立的SA永不老化。通过IKE协商建立的SA具有生存时间，该类型的SA有两种形式的生存时间：

·     基于时间的生存时间，定义了一个SA从建立到失效的时间；

·     基于流量的生存时间，定义了一个SA允许处理的最大流量。

可同时存在基于时间和基于流量两种方式的SA生存时间，只要SA的生存时间到达指定的时间或流量时，该SA就会失效。SA失效前，IKE将为IPsec对等体协商建立新的SA，这样，在旧的SA失效前新的SA就已经准备好。在新的SA开始协商而没有协商好之前，使用当前旧的SA保护通信。一旦协商出新的SA，立即采用新的SA保护通信。

1.1.3  认证与加密

1. 认证算法

IPsec使用的认证算法主要是通过杂凑函数实现的。杂凑函数是一种能够接受任意长度的消息输入，并产生固定长度输出的算法，该算法的输出称为消息摘要。IPsec对等体双方都会计算一个摘要，接收方将发送方的摘要与本地的摘要进行比较，如果二者相同，则表示收到的IPsec报文是完整未经篡改的，以及发送方身份合法。目前，IPsec强制使用基于HMAC（Hash-based Message Authentication Code，基于散列的消息鉴别码）的认证算法，包括HMAC-MD5和HMAC-SHA1。其中，HMAC-MD5算法的计算速度快，而HMAC-SHA1算法的安全强度高。

2. 加密算法

IPsec使用的加密算法属于对称密钥系统，这类算法使用相同的密钥对数据进行加密和解密。目前设备的IPsec使用三种加密算法：

·     DES：使用56比特的密钥对一个64比特的明文块进行加密。

·     3DES：使用三个56比特（共168比特）的密钥对明文块进行加密。

·     AES：使用128比特、192比特或256比特的密钥对明文块进行加密。

这三个加密算法的安全性由高到低依次是：AES、3DES、DES，安全性高的加密算法实现机制复杂，运算速度慢。

1.1.4  IPsec实现方式

要实现建立IPsec隧道为两个IPsec对等体之间的数据提供安全保护，首先要配置相应的安全策略，通过安全策略定义哪些报文属于要保护的范围，并定义用于保护这些报文的安全参数。之后，将安全策略应用于设备的某接口上或某应用中。当IPsec对等体根据安全策略识别出要保护的报文时，就建立一个相应的IPsec隧道并将其通过该隧道发送给对端。此处的IPsec隧道可以是提前手工配置或者由报文触发IKE协商建立。这些IPsec隧道实际上就是两个IPsec对等体之间建立的IPsec SA。由于IPsec SA是单向的，因此出方向的报文由出方向的SA保护，入方向的报文由入方向的SA来保护。对端接收到报文后，首先对报文进行分析、识别，然后根据预先设定的安全策略对报文进行不同的处理（丢弃，解封装，或直接转发）。

首先需要通过定义ACL来指定两个对等体之间需要被保护的数据流的范围，并需要将引用了该ACL的IPsec安全策略应用到相应的接口上。只要接口发送的报文与该接口上应用的IPsec安全策略中的ACL的permit规则匹配，就会受到出方向IPsec SA的保护并进行封装处理。接口接收到目的地址是本机的IPsec报文时，首先根据报文头里携带的SPI查找本地的入方向IPsec SA，由对应的入方向IPsec SA进行解封装处理。解封装后的IP报文若能与ACL的permit规则匹配上则采取后续处理，否则被丢弃。

目前，设备支持的数据流的保护方式包括以下三种：

·     标准方式：一条IPsec隧道保护一条数据流。ACL中的每一个规则对应的数据流分别由一条单独创建的IPsec隧道来保护。缺省采用该方式。

·     聚合方式：一条IPsec隧道保护ACL中定义的所有数据流。ACL中的所有规则对应的数据流只会由一条创建的IPsec隧道来保护。该方式仅用于和老版本的设备互通。

·     主机方式：一条IPsec隧道保护一条主机到主机的数据流。ACL中的每一个规则对应的不同主机之间的数据流分别由一条单独创建的IPsec隧道来保护。这种方式下，受保护的网段之间存在多条数据流的情况下，将会消耗更多的系统资源。

1.1.5  协议规范

与IPsec相关的协议规范有：

·     RFC 2401：Security Architecture for the Internet Protocol

·     RFC 2402：IP Authentication Header

·     RFC 2406：IP Encapsulating Security Payload

·     RFC 4552：Authentication/Confidentiality for OSPFv3

1.2  基于ACL建立IPsec隧道

1.2.1  基于ACL建立IPsec隧道配置任务简介

基于ACL建立IPsec隧道的基本配置思路如下：

(1)     配置ACL：指定要保护的数据流。IPsec不需要通过在ACL规则中指定VPN参数来保护VPN间的数据流。

(2)     配置IPsec安全提议：指定安全协议、认证算法、加密算法、封装模式等。

(3)     配置IPsec安全策略：一个IPsec安全策略是若干具有相同名字、不同顺序号的IPsec安全策略表项的集合。在同一个IPsec安全策略中，顺序号越小的IPsec安全策略表项优先级越高。IPsec安全策略将要保护的数据流和IPsec安全提议进行了关联（即定义对何种数据流实施何种保护），并指定了IPsec SA的生成方式（手工方式、IKE协商方式）、对等体IP地址（即保护路径的起点或终点）、所需要的密钥和IPsec SA的生存时间等。

(4)     在接口上应用IPsec安全策略。

表1-1 基于ACL建立IPsec隧道配置任务简介

1.2.2  配置ACL

1. ACL规则中关键字的使用

IPsec通过配置ACL来定义需要保护的数据流。在IPsec应用中，ACL规则中的permit关键字表示与之匹配的流量需要被IPsec保护，而deny关键字则表示与之匹配的流量不需要保护。一个ACL中可以配置多条规则，首个与数据流匹配上的规则决定了对该数据流的处理方式。

在IPsec安全策略中定义的ACL既可用于过滤接口入方向数据流，也可用于过滤接口出方向数据流。

·     设备出入方向的数据流都使用IPsec安全策略中定义的ACL规则来做匹配依据。具体是，出方向的数据流正向匹配ACL规则，入方向的数据流反向匹配ACL规则。例如，对于应用于IPsec安全策略中的某ACL规则：rule 0 permit ip source 1.1.1.0 0.0.0.255 destination 2.2.2.0 0.0.0.255，设备使用其正向过滤出方向上从1.1.1.0/24网段发往2.2.2.0/24网段的数据流，反向过滤入方向上从2.2.2.0/24网段发往1.1.1.0/24网段的数据流。

·     在出方向上，与ACL的permit规则匹配的报文将被IPsec保护，未匹配上任何规则或与deny规则匹配上的报文将不被IPsec保护。

·     在入方向上，与ACL的permit规则匹配上的未被IPsec保护的报文将被丢弃；目的地址为本机的被IPsec保护的报文将被进行解封装处理。缺省情况下解封装后的IP报文若能与ACL的permit规则匹配上则采取后续处理，否则被丢弃。若解封装后IPsec报文的ACL检查功能处于关闭状态，则解封装后的IP报文不与ACL匹配，直接进行后续处理。

需要注意的是：

·     仅对确实需要IPsec保护的数据流配置permit规则，避免盲目地使用关键字any。这是因为，在一个permit规则中使用any关键字就代表所有指定范围上出方向的流量都需要被IPsec保护，所有对应入方向上被IPsec保护的报文将被接收并处理，入方向上未被IPsec保护的报文都将被丢弃。这种情况下，一旦入方向收到的某流量是未被IPsec保护的，那么该流量就会被丢弃，这会造成一些本不需要IPsec处理的流量丢失，影响正常的业务传输。

·     当一个安全策略下有多条优先级不同的安全策略表项时，合理使用deny规则。避免本应该与优先级较低的安全策略表项的ACL permit规则匹配而被IPsec保护的出方向报文，因为先与优先级较高的安全策略表项的ACL deny规则匹配上，而没有被IPsec保护，继而在接收端被丢弃。

下面是一个deny规则的错误配置示例。Router A和Router B上分别配置如下所示的IPsec安全策略，当Router A连接的1.1.2.0/24网段用户访问Router B连接的3.3.3.0/24网段时，报文在Router A的应用了IPsec安全策略testa的出接口上优先与顺序号为1的安全策略表项匹配，并匹配上了IPv4 ACL 3000的rule 1，因此Router A认为它不需要IPsec保护，而未进行IPsec封装。该报文到达Router B后，在应用了IPsec安全策略testb的入接口上与IPv4 ACL 3001的rule 0匹配，并被判断为应该受IPsec保护但未被保护的报文而丢弃。

Router A上的关键配置如下：

acl advanced 3000

 rule 0 permit ip source 1.1.1.0 0.0.0.255 destination 2.2.2.0 0.0.0.255

 rule 1 deny ip

acl advanced 3001

 rule 0 permit ip source 1.1.2.0 0.0.0.255 destination 3.3.3.0 0.0.0.255

 rule 1 deny ip

#

ipsec policy testa 1 isakmp <---优先级高的安全策略表项

 security acl 3000

 ike-profile aa

 transform-set 1

#

ipsec policy testa 2 isakmp <---优先级低的安全策略表项

 security acl 3001

 ike-profile bb

 transform-set 1

Router B上的关键配置如下：

acl advanced 3001

 rule 0 permit ip source 3.3.3.0 0.0.0.255 destination 1.1.2.0 0.0.0.255

 rule 1 deny ip

#

ipsec policy testb 1 isakmp

 security acl 3001

 ike-profile aa

 transform-set 1

为保证Router A连接的1.1.2.0/24网段用户访问Router B连接的3.3.3.0/24网段的报文可被正确处理，建议将Router A上的IPv4 ACL 3000中的deny规则删除。

2. ACL规则的镜像配置

为保证IPsec对等体上能够成功建立SA，建议两端设备上用于IPsec的ACL配置为镜像对称，即保证两端定义的要保护的数据流范围的源和目的尽量对称。例如，图1-4中Router A和Router B上的ACL配置都是完全镜像对称的，因此用于保护主机Host A与主机Host C之间、子网Network 1与子网Network 2之间流量的SA均可成功建立。

图1-4 镜像ACL配置

若IPsec对等体上的ACL配置非镜像，那么只有在一端的ACL规则定义的范围是另外一端的子集时，SA协商可以成功。如图1-5所示，Router A上的ACL规则允许的范围（Host A->Host C）是Router B上ACL规则允许的范围（Network 2->Network 1）的子集。

图1-5 非镜像ACL配置

需要注意的是，在这种ACL配置下，并不是任何一端发起的SA协商都可以成功，仅当保护范围小（细粒度）的一端向保护范围大（粗粒度）的一端发起的协商才能成功，反之则SA协商失败。这是因为，协商响应方要求协商发起方发送过来的数据必须在响应方可以接受的范围之内。其结果就是，从细粒度一端向粗粒度一端发送报文时，细粒度侧设备发起的SA协商可以成功，例如Host A->Host C；从粗粒度一方向细粒度一方发送报文时，粗粒度侧设备发起的SA协商不能成功，例如Host C->Host A、Host C->Host B、Host D->Host A等。

1.2.3  配置IPsec安全提议

IPsec安全提议是IPsec安全策略的一个组成部分，它用于定义IPsec需要使用的安全协议、加密/认证算法以及封装模式，为IPsec协商SA提供各种安全参数。

可对IPsec安全提议进行修改，但对已协商成功的IPsec SA，新修改的安全提议并不起作用，即仍然使用原来的安全提议，只有新协商的SA使用新的安全提议。若要使修改对已协商成功的IPsec SA生效，则需要执行reset ipsec sa命令。

表1-2 配置IPsec安全提议

1.2.4  配置手工方式的IPsec安全策略

1. 配置限制和指导

为保证SA能够成功生成，IPsec隧道两端的配置必须符合以下要求：

·     IPsec安全策略引用的IPsec安全提议应采用相同的安全协议、加密/认证算法和报文封装模式。

·     当前端点的IPv4对端地址应与对端应用IPsec安全策略的接口的主IPv4地址保持一致；当前端点的IPv6对端地址应与对端应用IPsec安全策略的接口的第一个IPv6地址保持一致。

·     应分别设置inbound和outbound两个方向的IPsec SA参数，且保证每一个方向上的IPsec SA的唯一性：对于出方向IPsec SA，必须保证三元组（对端IP地址、安全协议、SPI）唯一；对于入方向IPsec SA，必须保证SPI唯一。

·     本端和对端IPsec SA的SPI及密钥必须是完全匹配的。即，本端的入方向IPsec SA的SPI及密钥必须和对端的出方向IPsec SA的SPI及密钥相同；本端的出方向IPsec SA的SPI及密钥必须和对端的入方向IPsec SA的SPI及密钥相同。

·     两端IPsec SA使用的密钥应当以相同的方式输入，即如果一端以字符串方式输入密钥，另一端必须也以字符串方式输入密钥。

2. 配置手工方式的IPsec安全策略

表1-3 配置手工方式的IPsec安全策略

1.2.5  配置IKE协商方式的IPsec安全策略

IKE协商方式的IPsec安全策略有以下两种配置方式：

·     直接配置IPsec安全策略：在安全策略视图中定义需要协商的各参数；

·     引用IPsec安全策略模板配置IPsec安全策略：首先在IPsec安全策略模板中定义需要协商的各参数，然后通过引用IPsec安全策略模板创建一条IPsec安全策略。应用了该类IPsec安全策略的接口不能发起协商，仅可以响应远端设备的协商请求。由于IPsec安全策略模板中未定义的可选参数由发起方来决定，而响应方会接受发起方的建议，因此这种方式适用于通信对端（例如对端的IP地址）未知的情况下，允许这些对端设备向本端设备主动发起协商。

1. 配置限制和指导

IPsec隧道两端的配置必须符合以下要求：

·     IPsec安全策略引用的IPsec安全提议中应包含相同的安全协议、认证/加密算法和报文封装模式。

·     IPsec安全策略引用的IKE profile参数相匹配。

·     一条IKE协商方式的IPsec安全策略中最多可以引用六个IPsec安全提议。IKE协商过程中，IKE将会在隧道两端配置的IPsec安全策略中查找能够完全匹配的IPsec安全提议。如果IKE在两端找不到完全匹配的IPsec安全提议，则SA不能协商成功，需要被保护的报文将被丢弃。

·     IKE协商的发起方必须配置IPsec隧道的对端地址，响应方可选配，且当前端点的对端地址与对端的本端地址应保持一致。

对于IKE协商建立的IPsec SA，遵循以下原则：

·     采用隧道两端设置的IPsec SA生存时间中较小者。

·     可同时存在基于时间和基于流量两种方式的IPsec SA生存时间，只要到达指定的时间或指定的流量，IPsec SA就会老化。

2. 直接配置IKE协商方式的IPsec安全策略

表1-4 直接配置IKE协商方式的IPsec安全策略

3. 引用IPsec安全策略模板配置IKE协商方式的IPsec安全策略

IPsec安全策略模板与直接配置的IKE协商方式的IPsec安全策略中可配置的参数类似，但是配置较为简单，除了IPsec安全提议和IKE profile之外的其它参数均为可选。应用了引用IPsec安全策略模板配置的IPsec安全策略的接口不能发起协商，仅可以响应远端设备的协商请求。IPsec安全策略模板中未定义的可选参数由发起方来决定，而响应方会接受发起方的建议，例如IPsec安全策略模板下的用于定义保护对象范围的ACL是可选的，该参数在未配置的情况下，相当于支持最大范围的保护，即完全接受协商发起端的ACL设置。这种方式配置的IPsec安全策略适用于通信对端（例如对端的IP地址）未知的情况下，允许这些对端设备向本端设备主动发起协商。

表1-5 引用IPsec安全策略模板配置IKE协商方式的IPsec安全策略

1.2.6  在接口上应用IPsec安全策略

为使定义的IPsec SA生效，应在每个要加密的数据流和要解密的数据流所在接口上应用一个IPsec安全策略，以对数据进行保护。当取消IPsec安全策略在接口上的应用后，此接口便不再具有IPsec的安全保护功能。IPsec安全策略除了可以应用到串口、以太网接口等实际物理接口上之外，还能够应用到Tunnel、Virtual Template等虚接口上，对GRE、L2TP等流量进行保护。

当从一个接口发送数据时，接口将按照顺序号从小到大的顺序逐一匹配引用的IPsec安全策略中的每一条安全策略表项。如果数据匹配上了某一条安全策略表项引用的ACL，则停止匹配，并对其使用当前这条安全策略表项进行处理，即根据已经建立的IPsec SA或者触发IKE协商生成的IPsec SA对报文进行封装处理；如果数据与所有安全策略表项引用的ACL都不匹配，则直接被正常转发，IPsec不对数据加以保护。

应用了IPsec安全策略的接口收到数据报文时，对于目的地址是本机的IPsec报文，根据报文头里携带的SPI查找本地的IPsec SA，并根据匹配的IPsec SA对报文进行解封装处理；对于那些本应该被IPsec保护但未被保护的报文进行丢弃。

表1-6 在接口上应用IPsec安全策略

1.2.7  配置IPsec报文日志信息记录功能

开启IPsec报文日志记录功能后，设备会在丢弃IPsec报文的情况下，例如入方向找不到对应的IPsec SA、AH/ESP认证失败、ESP加密失败等时，输出相应的日志信息，该日志信息内容主要包括报文的源和目的IP地址、报文的SPI值、报文的序列号信息，以及设备丢包的原因。

表1-7 配置IPsec日志信息记录功能

1.3  配置IPsec告警功能

开启IPsec的Trap功能后，IPsec会生成告警信息，用于向网管软件报告该模块的重要事件。生成的告警信息将被发送到设备的SNMP模块，通过设置SNMP中告警信息的发送参数，来决定告警信息输出的相关属性。有关告警信息的详细介绍，请参见“网络管理和监控配置指导”中的“SNMP”。

如果希望生成并输出某种类型的IPsec告警信息，则需要保证IPsec的全局告警功能以及相应类型的告警功能均处于开启状态。

表1-8 配置IPsec告警功能

1.4  配置本端允许建立IPsec隧道的最大数

本端允许建立IPsec隧道的最大数与内存资源有关。内存充足时可以设置较大的数值，提高IPsec的并发性能；内存不足时可以设置较小的数值，降低IPsec占用内存的资源。

表1-9 配置本端允许建立IPsec隧道的最大数

1.5  IPsec显示和维护

在完成上述配置后，在任意视图下执行display命令可以显示配置后IPsec的运行情况，通过查看显示信息认证配置的效果。

在用户视图下执行reset命令可以清除IPsec统计信息。

表1-10 IPsec显示和维护

2 IKE

2.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。

如图2-1所示，IKE为IPsec协商建立SA，并把建立的参数交给IPsec，IPsec使用IKE建立的SA对IP报文加密或认证处理。

图2-1 IPsec与IKE的关系图

2.1.2  IKE的协商过程

IKE使用了两个阶段为IPsec进行密钥协商以及建立SA：

(1)     第一阶段，通信双方彼此间建立了一个已通过双方身份认证和对通信数据安全保护的通道，即建立一个IKE SA（本文中提到的IKE SA都是指第一阶段SA）。

(2)     第二阶段，用在第一阶段建立的IKE SA为IPsec协商安全服务，即为IPsec协商IPsec SA，建立用于最终的IP数据安全传输的IPsec SA。

第一阶段有主模式（Main Mode）和野蛮模式（Aggressive Mode）两种IKE协商模式。

·     主模式

图2-2 主模式协商过程

如图2-2所示，第一阶段主模式的IKE协商过程中包含三对消息，具体内容如下：

(1)     第一对消息完成了SA交换，它是一个协商确认双方IKE安全策略的过程；

(2)     第二对消息完成了密钥交换，通过交换Diffie-Hellman公共值和辅助数据（如：随机数），最终双方计算生成一系列共享密钥（例如，认证密钥、加密密钥以及用于生成IPsec密钥参数的密钥材料），并使其中的加密密钥和认证密钥对后续的IKE消息提供安全保障；

(3)     第三对消息完成了ID信息和验证数据的交换，并进行双方身份的认证。

·     野蛮模式

图2-3 野蛮模式协商过程

如图2-3所示，第一阶段野蛮模式的IKE协商过程中包含三条消息，具体内容如下：

(1)     发起方通过第一条消息发送本地IKE信息，包括建立IKE SA所使用的参数、与密钥生成相关的信息和身份验证信息。

(2)     接收方通过第二条消息对收到的第一个消息进行确认，查找并返回匹配的参数、密钥生成信息和身份验证信息。

(3)     发起方通过第三条消息回应验证结果，并成功建立IKE SA。

与主模式相比，野蛮模式的优点是建立IKE SA的速度较快。但是由于野蛮模式的密钥交换与身份认证一起进行，因此无法提供身份保护。在对身份保护要求不高的场合，使用交换报文较少的野蛮模式可以提高协商的速度；在对身份保护要求较高的场合，则应该使用主模式。

2.1.3  IKE的安全机制

IKE可以在不安全的网络上安全地认证通信双方的身份、分发密钥以及建立IPsec SA，具有以下几种安全机制。

1. 身份认证

IKE的身份认证机制用于确认通信双方的身份。设备支持三种认证方法：预共享密钥认证、RSA数字签名认证和DSA数字签名认证。

·     预共享密钥认证：通信双方通过共享的密钥认证对端身份。

·     数字签名认证：通信双方使用由CA颁发的数字证书向对端证明自己的身份。

2. DH算法

DH算法是一种公共密钥算法，它允许通信双方在不传输密钥的情况下通过交换一些数据，计算出共享的密钥。即使第三方（如黑客）截获了双方用于计算密钥的所有交换数据，由于其复杂度很高，也不足以计算出双方的密钥。

3. PFS特性

PFS（Perfect Forward Secrecy，完善的前向安全性）是一种安全特性，它解决了密钥之间相互无关性的需求。由于IKE第二阶段协商需要从第一阶段协商出的密钥材料中衍生出用于IPsec SA的密钥，若攻击者能够破解IKE SA的一个密钥，则会非常容易得掌握其衍生出的任何IPsec SA的密钥。使用PFS特性后，IKE第二阶段协商过程中会增加一次DH交换，使得IKE SA的密钥和IPsec SA的密钥之间没有派生关系，即使IKE SA的其中一个密钥被破解，也不会影响它协商出的其它密钥的安全性。

2.1.4  协议规范

与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

2.2  IKE配置任务简介

进行IKE配置之前，用户需要确定以下几个因素，以便配置过程的顺利进行。

(1)     确定IKE交换过程中安全保护的强度，包括认证方法、加密算法、认证算法、DH group。

·     认证方法分为预共享密钥认证和数字签名认证。预共享密钥认证机制简单、不需要证书，常在小型组网环境中使用；数字签名认证安全性更高，常在“中心—分支”模式的组网环境中使用。例如，在“中心—分支”组网中使用预共享密钥认证进行IKE协商时，中心侧可能需要为每个分支配置一个预共享密钥，当分支很多时，配置会很复杂，而使用数字签名认证时只需配置一个PKI域。

·     不同认证/加密算法的强度不同，算法强度越高，受保护数据越难被破解，但消耗的计算资源越多。

·     DH group位数越大安全性越高，但是处理速度会相应减慢。应该根据实际组网环境中对安全性和性能的要求选择合适的DH group。

(2)     确定通信双方预先约定的预共享密钥或所属的PKI域。关于PKI的配置，请参见“安全配置指导”中的“PKI”。

(3)     确定通信双方都采用IKE协商模式的IPsec安全策略。IPsec安全策略中若不引用IKE profile，则使用系统视图下配置的IKE profile进行协商，若系统视图下没有任何IKE profile，则使用全局的IKE参数进行协商。关于IPsec安全策略的配置，请参见“安全配置指导”中的“IPsec”。

表2-1 IKE配置任务简介

2.3  配置IKE profile

IKE profile中包括以下配置：

(1)     匹配对端身份的规则。响应方首先需要根据发起方的身份信息查找一个本端的IKE profile，然后使用此IKE profile中的信息验证对端身份，发起方同样需要根据响应方的身份信息查找到一个IKE profile用于验证对端身份。对端身份信息若能满足本地某个IKE profile中指定的匹配规则，则该IKE profile为查找的结果。

(2)     根据IKE提议中配置的认证方法，配置IKE keychain或PKI域。

·     如果认证方法为数字签名（dsa-signature或者rsa-signature），则需要配置PKI域。

·     如果指定的认证方式为预共享密钥（pre-share），则需要配置IKE keychain。

(3)     本端作为发起方时所使用的协商模式（主模式、野蛮模式）。本端作为响应方时，将自动适配发起方的协商模式。

(4)     本端作为发起方时可以使用的IKE提议（可指定多个），先指定的优先级高。响应方会将发起方的IKE提议与本端所有的IKE提议进行匹配，如果找到匹配项则直接使用，否则继续查找。若未查找到匹配的IKE提议，则协商失败。

(5)     本端身份信息。

·     如果本端的认证方式为数字签名，则可以配置任何类型的身份信息。若配置的本端身份为IP地址，但这个IP地址与本地证书中的IP地址不同时，设备将使用FQDN（Fully Qualified Domain Name，完全合格域名）类型的本端身份，该身份的内容为设备的名称（可通过sysname命令配置）。

·     如果本端的认证方式为预共享密钥，则只能配置除DN之外的其它类型的身份信息。

(6)     IKE DPD（Dead Peer Detection，对等体存活检测）功能，IKE DPD功能用于检测协商对端是否存活。如果IKE profile视图下和系统视图下都配置了DPD功能，则IKE profile视图下的DPD配置生效，如果IKE profile视图下没有配置DPD功能，则采用系统视图下的DPD配置。

(7)     IKE profile的使用范围。限制IKE profile只能在指定的地址或指定接口的地址下使用（这里的地址指的是IPsec策略下配置的本端地址，若本端地址没有配置，则为引用IPsec策略的接口IP地址）。配置了match local address的IKE profile的优先级高于所有未配置match local address的IKE profile。

(8)     IKE profile的优先级。IKE profile的匹配优先级首先取决于其中是否配置了match local address，其次决定于配置的优先级值，最后决定于配置IKE profile的先后顺序。

(9)     支持对客户端认证。远程客户端与中心侧网关设备协商建立IPsec隧道的过程中，若中心侧网关设备上开启了对客户端认证，则在IKE一阶段协商完成之后，中心侧网关设备将会使用AAA机制对客户端进行认证，要求每个客户端在接入时，都需要提供用户名和密码。只有通过AAA认证的客户端才能继续进行后续的IPsec协商。对客户端的认证还需要在网关设备上配置相应的AAA认证方法来配合，关于AAA认证方法的详细配置请参见“安全配置指导”中的“AAA”。

表2-2 配置IKE profile

2.4  配置IKE提议

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存活时间则取两端的最小值。

表2-3 配置IKE提议

2.5  配置IKE keychain

在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的先后顺序。

表2-4 配置IKE keychain

2.6  配置本端身份信息

本端身份信息适用于所有IKE SA的协商，而IKE profile下的local-identity仅适用于本IKE profile。如果IKE profile下没有配置本端身份，则默认使用此处配置的全局本端身份。

·     如果本端采用的认证方式为数字签名，则本端配置的任何类型的身份信息都有效；

·     如果本端采用认证方式为预共享密钥，则本端除DN之外的其它类型的身份信息均有效。

表2-5 配置本端身份信息

2.7  配置IKE Keepalive功能

IKE Keepalive功能用于检测对端是否存活。在对端配置了等待IKE Keepalive报文的超时时间后，必须在本端配置发送IKE Keepalive报文的时间间隔。当对端IKE SA在配置的超时时间内未收到IKE Keepalive报文时，则删除该IKE SA以及由其协商的IPsec SA。

配置IKE Keepalive功能时，请遵循以下配置限制和指导：

·     当有检测对方是否存活的需求时，通常建议配置IKE DPD，不建议配置IKE Keepalive。仅当对方不支持IKE DPD功能且支持IKE Keepalive功能时，才考虑配置IKE Keepalive功能。配置IKE Keepalive功能后，会定时检测对方是否存活，因此会额外消耗网络带宽和计算资源。

·     本端配置的IKE Keepalive报文的等待超时时间要大于对端发送的时间间隔。由于网络中一般不会出现超过连续三次的报文丢失，所以，本端的超时时间可以配置为对端配置的发送IKE Keepalive报文的时间间隔的三倍。

表2-6 配置IKE Keepalive功能

2.8  配置IKE NAT Keepalive功能

在采用IKE协商建立的IPsec隧道中，可能存在NAT设备，由于在NAT设备上的NAT会话有一定存活时间，一旦IPsec隧道建立后如果长时间没有流量，对应的NAT会话表项会被删除，这样将导致IPsec隧道无法继续传输数据。为防止NAT表项老化，NAT内侧的IKE网关设备需要定时向NAT外侧的IKE网关设备发送NAT Keepalive报文，以便维持NAT设备上对应的IPsec流量的会话存活，从而让NAT外侧的设备可以访问NAT内侧的设备。

表2-7 配置IKE NAT Keepalive功能

2.9  配置IKE DPD功能

DPD（Dead Peer Detection，对等体存活检测）用于检测对端是否存活。本端主动向对端发送DPD请求报文，对对端是否存活进行检测。如果本端在DPD报文的重传时间间隔（retry seconds）内未收到对端发送的DPD回应报文，则重传DPD请求报文，若重传两次之后仍然没有收到对端的DPD回应报文，则删除该IKE SA和对应的IPsec SA。

配置IKE DPD功能时，请遵循以下配置限制和指导：

·     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探测报文。

表2-8 配置全局IKE DPD功能

2.10  配置对IKE SA数目的限制

由于不同设备的能力不同，为充分利用设备的处理能力，可以配置允许同时处于协商状态的IKE SA的最大数，也可以配置允许建立的IKE SA的最大数。

若设置允许同时协商更多的IKE SA，则可以充分利用设备处理能力，以便在设备有较强处理能力的情况下得到更高的新建性能；若设置允许同时协商较少的IKE SA，则可以避免产生大量不能完成协商的IKE SA，以便在设备处理能力较弱时保证一定的新建性能。

若设置允许建立更多的IKE SA，则可以使得设备在有充足内存的情况下得到更高的并发性能；若设置允许建立较少的IKE SA，则可以在设备没有充足内存的情况下，使得IKE不过多占用系统内存。

表2-9 配置对本端IKE SA数目的限制

2.11  配置IKE告警功能

开启IKE的告警功能后，IKE会生成告警信息，用于向网管软件报告该模块的重要事件。生成的告警信息将被发送到设备的SNMP模块，通过设置SNMP中告警信息的发送参数，来决定告警信息输出的相关属性。有关告警信息的详细介绍，请参见“网络管理和监控配置指导”中的“SNMP”。

如果希望生成并输出某种类型的IKE告警信息，则需要保证IKE的全局告警功能以及相应类型的告警功能均处于开启状态。

表2-10 配置IKE 告警功能

2.12  IKE显示和维护

在完成上述配置后，在任意视图下执行display命令可以显示配置后IKE的运行情况，通过查看显示信息验证配置的效果。

在用户视图下执行reset命令可以删除IKE SA。

表2-11 IKE显示和维护

2.13  常见错误配置举例

2.13.1  提议不匹配导致IKE SA协商失败

1. 故障现象

(1)     通过如下命令查看当前的IKE SA信息，发现IKE SA的状态（Flags字段）为Unknown。

<Sysname> display ike sa

    Connection-ID   Remote                Flag         DOI

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

    1               192.168.222.5         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.

2. 故障分析

IKE提议配置错误。

3. 处理过程

(1)     排查IKE提议相关配置。具体包括：检查两端的IKE提议是否匹配，即IKE提议中的认证方法、认证算法、加密算法是否匹配。

(2)     修改IKE提议的配置，使本端IKE提议的配置和对端匹配。

2.13.2  未正确引用IKE提议或IKE keychain导致IKE SA协商失败

1. 故障现象

(1)     通过如下命令查看当前的IKE SA信息，发现IKE SA的状态（Flags字段）为Unknown。

<Sysname> display ike sa

    Connection-ID   Remote                Flag         DOI

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

    1               192.168.222.5         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.

2. 故障分析

故障原因可能为以下两点：

(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.

3. 处理过程

(1)     检查匹配到的IKE提议是否在IKE profile下引用。以故障分析中的调试信息为例，IKE profile profile1中需要引用IKE proposal 1。

(2)     检查匹配到的IKE keychain是否在IKE profile下引用。以故障分析中的调试信息为例，IKE profile profile1中需要引用IKE keychain keychain1。

2.13.3  提议不匹配导致IPsec SA协商失败

1. 故障现象

(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.

2. 故障分析

IPsec安全策略参数配置错误。

3. 处理过程

(1)     排查IPsec相关配置。具体包括：检查双方接口上应用的IPsec安全策略的参数是否匹配，即引用的IPsec安全提议的协议、加密算法和认证算法是否匹配。

(2)     修改IPsec安全策略配置，使本端IPsec安全策略的配置和对端匹配。

2.13.4  身份信息无效导致IPsec SA协商失败

1. 故障现象

(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.

2. 故障分析

响应方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

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

   Local IP: 192.168.222.5

   Local ID type: IPV4_ADDR

   Local ID: 192.168.222.5

   Remote IP: 192.168.222.71

   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

但在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 duration(time based):

  SA duration(traffic based):

  SA idle time:

(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 duration(time based):

  SA duration(traffic based):

  SA idle time:

3. 处理过程

(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地址。