1 IP隧道及安全VPN类故障处理

1.1  IPsec故障处理手册

1.1.1  未触发IKE协商（IPsec安全框架方式）

1. 故障描述

如图1-1所示，需要在Device A和Device B之间建立IKE协商方式的IPsec隧道，用于保护Host A和Host B之间的用户私网流量，IPsec隧道的封装模式为隧道模式。在Device A和Device B上完成配置后，Host A和Host B之间的流量不通。

在Device A上执行display ike sa命令，查看显示信息为空，表示IKE一阶段未协商成功。若执行display ike sa命令显示信息中Flag字段值为RD，且执行display ipsec sa命令，无显示信息，表示IKE二阶段未协商成功，如下所示：

<DeviceA> display ike sa

Flags:

RD--READY RL--REPLACED FD-FADING RK-REKEY

 ID       Profile   Remote             Flag      Remote-Type    Remote-ID

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

<DeviceA> display ipsec sa

<DeviceA>

在Device A上执行display ike statistics命令查看IKE统计数据，发现无明显错误发生，显示信息如下所示：

<DeviceA> display ike statistics

IKE statistics:

  No matching proposal: 0

  Invalid ID information: 0

  Unavailable certificate: 0

  Unsupported DOI: 0

  Unsupported situation: 0

  Invalid proposal syntax: 0

  Invalid SPI: 0

  Invalid protocol ID: 0

  Invalid certificate: 0

  Authentication failure: 0

…

在Device A上执行display ipsec statistics命令查看IPsec统计数据，发现无明显错误发生，显示信息如下所示：

<DeviceA> display ipsec statistics

  IPsec packet statistics:

    Received/sent packets: 0/0

    Received/sent bytes: 0/0

    Received/sent packet rate: 0/0 packets/sec

    Received/sent byte rate: 0/0 bytes/sec

    Dropped packets (received/sent): 0/0

 

    Dropped packets statistics

      No available SA: 0

      Wrong SA: 0

      Invalid length: 0

      Authentication failure: 0

      Encapsulation failure: 0

      Decapsulation failure: 0

      Replayed packets: 0

      ACL check failure: 0

      MTU check failure: 0

      Loopback limit exceeded: 0

      Crypto speed limit exceeded: 0

图1-1 未触发IKE协商（IPsec安全框架方式）组网图

‌

2. 常见原因

本类故障的常见原因主要包括：

·     IPsec网关之间路由不可达。

·     IPsec安全框架配置不正确。

·     IKE profile和IKE proposal配置不正确。

3. 故障分析

本类故障的诊断流程如图1-2所示。

图1-2 未触发IKE协商（IPsec安全框架方式）的故障处理流程图

 

4. 处理步骤

(1)     检查IPsec网关之间是否可以Ping通。

使用ping命令检查网络连接情况。

a.     如果Ping不通，请参见“三层技术-IP业务类故障处理”手册中的“Ping不通的定位思路”继续定位，确保IPsec网关之间可以Ping通。

b.     如果故障仍不能排除，请执行步骤(2)。

(2)     检查IPsec安全框架配置是否正确。

通过display ipsec profile命令查看本端IPsec网关Device A和对端IPsec网关Device B上的配置是否完整，即都配置了安全提议（Transform set），和IKE profile，需保证两端安全提议下配置的加密算法、认证算法以及PFS一致。Device A的显示信息如下所示：

[DeviceA] display ipsec profile

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

IPsec profile: myprofile

Mode: isakmp

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

  Transform set:  tran1

  IKE profile: profile

  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

[DeviceA] display ipsec transform-set

IPsec transform set: tran1

  State: complete

  Encapsulation mode: tunnel

  ESN: Enabled

  PFS：

  Transform: AH-ESP

  AH protocol:

    Integrity: SHA1

  ESP protocol:

    Integrity: SHA1

    Encryption: AES-CBC-128

Device B的显示信息如下所示：

[DeviceB] display ipsec profile

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

IPsec profile: myprofile

Mode: isakmp

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

  Transform set:  tran1

  IKE profile: profile

  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

[DeviceB] display ipsec transform-set

IPsec transform set: tran1

  State: complete

  Encapsulation mode: tunnel

  ESN: Enabled

  PFS：

  Transform: AH-ESP

  AH protocol:

    Integrity: SHA1

  ESP protocol:

    Integrity: SHA1

    Encryption: AES-CBC-128

如果故障仍不能排除，请执行步骤(3)。

(3)     检查IPsec安全框架是否在接口上正确配置。

a.     在本端IPsec网关Device A上执行命令interface tunnel进入隧道接口，执行display this命令查看隧道接口中的本端地址和对端地址，以及IPsec安全框架是否配置正确，显示信息如下所示：

[DeviceA] interface tunnel 1

[DeviceA-Tunnel1] display this

#

interface Tunnel1 mode ipsec

 ip address 3.3.3.1 255.255.255.0

 source 2.2.2.1

 destination 2.2.3.1

 tunnel protection ipsec profile myprofile

[DeviceA-Tunnel1] quit

若有配置错误，请按如下方法修改配置：

[DeviceA] interface tunnel 1 mode ipsec

[DeviceA-Tunnel1] ip address 3.3.3.1 255.255.255.0

[DeviceA-Tunnel1] source 2.2.2.1

[DeviceA-Tunnel1] destination 2.2.3.1

[DeviceA-Tunnel1] tunnel protection ipsec profile myprofile

[DeviceA-Tunnel1] quit

b.     在本端IPsec网关Device B上执行命令interface tunnel进入隧道接口，执行display this命令查看隧道接口中的本端地址和对端地址，以及IPsec安全框架是否配置正确，显示信息如下所示：

[DeviceB] interface tunnel 1

[DeviceB-Tunnel1] display this

#

interface Tunnel1 mode ipsec

 ip address 3.3.3.2 255.255.255.0

 source 2.2.3.1

 destination 2.2.2.1

 tunnel protection ipsec profile myprofile

[DeviceB-Tunnel1] quit

若有配置错误，请按如下方法修改配置：

[DeviceB] interface tunnel 1 mode ipsec

[DeviceB-Tunnel1] ip address 3.3.3.2 255.255.255.0

[DeviceB-Tunnel1] source 2.2.3.1

[DeviceB-Tunnel1] destination 2.2.2.1

[DeviceB-Tunnel1] tunnel protection ipsec profile myprofile

[DeviceB-Tunnel1] quit

如果故障仍不能排除，请执行步骤(4)。

(4)     检查IKE profile和IKE proposal配置是否正确。

a.     检查IKE profile的配置，确认两端IPsec网关的本端地址和对端地址配置是否正确。若采用预共享密钥认证，本端和对端的预共享密钥必须相同（通过pre-shared-key命令配置），若采用RSA签名或数字信封认证，需要确保数字证书在有效期内（通过display pki certificate domain命令查看证书有效期，即在Validity字段显示的有效期内使用），Device A上IKE profile的具体配置举例如下所示：

[DeviceA] ike keychain keychain1

[DeviceA-ike-keychain-keychain1] pre-shared-key address 2.2.3.1 255.255.255.0 key simple 123456TESTplat&!

[DeviceA-ike-keychain-keychain1] quit

[DeviceA] ike profile profile

[DeviceA-ike-profile-profile] keychain keychain1

[DeviceA-ike-profile-profile] local-identity address 2.2.2.1

[DeviceA-ike-profile-profile] match remote identity address 2.2.3.1 255.255.255.0

[DeviceA-ike-profile-profile] quit

Device B上IKE profile的具体配置举例如下所示：

[DeviceB] ike keychain keychain1

[DeviceB-ike-keychain-keychain1] pre-shared-key address 2.2.2.1 255.255.255.0 key simple 123456TESTplat&!

[DeviceB-ike-keychain-keychain1] quit

[DeviceB] ike profile profile

[DeviceB-ike-profile-profile] keychain keychain1

[DeviceB-ike-profile-profile] local-identity address 2.2.3.1

[DeviceB-ike-profile-profile] match remote identity address 2.2.2.1 255.255.255.0

[DeviceB-ike-profile-profile] quit

b.     检查IPsec网关之间的IKE proposal配置是否一致。在Device A和Device B上通过display ike proposal命令查看IKE proposal配置信息，保证配置参数一致，如下所示：

[DeviceA] display ike proposal

 Priority Authentication Authentication Encryption  Diffie-Hellman Duration

              method       algorithm    algorithm       group      (seconds)

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

 default  PRE-SHARED-KEY     SHA1           DES-CBC        Group 1        86400

[DeviceB] display ike proposal

 Priority Authentication Authentication Encryption  Diffie-Hellman Duration

              method       algorithm    algorithm       group      (seconds)

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

 default  PRE-SHARED-KEY     SHA1           DES-CBC        Group 1        86400

如果故障仍不能排除，请执行步骤(5)。

(5)     如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

¡     执行debugging命令收集IPsec隧道建立过程中的相关信息，配置方法如下所示。

<DeviceA> terminal debugging

The current terminal is enabled to display debugging logs.

<DeviceA> terminal monitor

The current terminal is enabled to display logs.

<DeviceA> debugging ike all

<DeviceA> debugging ipsec all

1.1.2  配置IKE野蛮模式的IPsec，IPsec SA无法协商成功

1. 故障描述

在MSR G1设备与MSR G2设备之间建立IPsec 隧道，IKE第一阶段的协商模式为野蛮模式，其中MSR G1作为发起端，MSR G2作为接收端。通过display ike sa命令查看当前的IKE SA信息，发现IKE SA协商成功，其状态（Flags字段）为RD。但是通过display ipsec sa命令查看当前的IPsec SA时却发现没有协商出相应的IPsec SA。

<Router> display ike sa

    Connection-ID  Remote          Flag        DOI

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

      2               10.1.1.1/500  RD           IPsec

Flags:

RD--READY RL--REPLACED FD-FADING RK-REKEY

<Router>display ipsec sa

<Router>

2. 故障处理步骤

野蛮模式的交互过程如下：

 

(1)     检查发起端MSR G1的所有IKE调试信息。

执行debugging ike all命令打开发起端MSR G1的所有IKE调试信息开关，确认协商过程中报文交互是否正常。

MSR G1上打印的关键debug信息如下：

*Nov  7 09:23:08:808 2014 ROUTER IKE/7/DEBUG: send message: （发起端发送第一个协商报文）

*Nov  7 09:23:08:808 2014 ROUTER IKE/7/DEBUG:   ICOOKIE: 0xb8a20d7c014806fa

*Nov  7 09:23:08:808 2014 ROUTER IKE/7/DEBUG:   RCOOKIE: 0x0000000000000000

…………………

*Nov  7 09:23:09:365 2014 ROUTER IKE/7/DEBUG: exchange state machine(I): finished step 0, advancing...

*Nov  7 09:23:09:415 2014 ROUTER IKE/7/DEBUG: received message: （收到对端回复的第二个报文）

*Nov  7 09:23:09:516 2014 ROUTER IKE/7/DEBUG:   ICOOKIE: 0xb8a20d7c014806fa

*Nov  7 09:23:09:566 2014 ROUTER IKE/7/DEBUG:   RCOOKIE: 0x67a9145eb46c41d9

…………………

*Nov  7 09:23:13:510 2014 ROUTER IKE/7/DEBUG: exchange state machine(I): finished step 1, advancing...

…………………

*Nov  7 09:23:14:820 2014 ROUTER IKE/7/DEBUG: send message: （发送第三个协商报文）

*Nov  7 09:23:14:920 2014 ROUTER IKE/7/DEBUG:   ICOOKIE: 0xb8a20d7c014806fa

*Nov  7 09:23:14:971 2014 ROUTER IKE/7/DEBUG:   RCOOKIE: 0x67a9145eb46c41d9

…………………

*Nov  7 09:23:15:524 2014 ROUTER IKE/7/DEBUG: exchange state machine(I): finished step 2, advancing...（第一阶段协商完毕）

…………………

*Nov  7 09:23:21:801 2014 ROUTER IKE/7/DEBUG: send message: （发送第二阶段第一个报文）

*Nov  7 09:23:21:902 2014 ROUTER IKE/7/DEBUG:   ICOOKIE: 0xb8a20d7c014806fa

*Nov  7 09:23:22:002 2014 ROUTER IKE/7/DEBUG:   RCOOKIE: 0x67a9145eb46c41d9

…………………

*Nov  7 09:23:22:506 2014 ROUTER IKE/7/DEBUG: exchange state machine(I): finished step 0, advancing...

*Nov  7 09:23:22:606 2014 ROUTER IKE/7/DEBUG: received message: （收到对端回复的报文）

*Nov  7 09:23:22:657 2014 ROUTER IKE/7/DEBUG:   ICOOKIE: 0xb8a20d7c014806fa

*Nov  7 09:23:22:757 2014 ROUTER IKE/7/DEBUG:   RCOOKIE: 0x67a9145eb46c41d9

…………………

*Nov  7 09:23:24:571 2014 ROUTER IKE/7/DEBUG: validate payload NOTIFY

*Nov  7 09:23:24:621 2014 ROUTER IKE/7/DEBUG:   DOI: IPSEC

*Nov  7 09:23:24:722 2014 ROUTER IKE/7/DEBUG:   PROTO: IPSEC_ESP

*Nov  7 09:23:24:822 2014 ROUTER IKE/7/DEBUG:   SPI_SZ: 4

*Nov  7 09:23:24:873 2014 ROUTER IKE/7/DEBUG:   MSG_TYPE: INVALID_ID_INFORMATION（回复的报文类型，协商失败）

*Nov  7 09:23:24:973 2014 ROUTER IKE/7/DEBUG: exchange setup(R): 9c16530

*Nov  7 09:23:25:024 2014 ROUTER IKE/7/DEBUG: exchange check: checking for required INFO

*Nov  7 09:23:25:124 2014 ROUTER IKE/7/DEBUG: got NOTIFY of type INVALID_ID_INFORMATION

从MSR G1打印的debug信息中可以看出，第一阶段的IKE协商交互的三个报文均正常，但是在发起端MSR G1发送完第二阶段协商的第一个报文后，收到了对端回复的一个INVALID_ID_INFORMATION的报文，导致IPsec协商无法继续进行。

(2)     检查接收端MSR G2的所有IKE调试信息。

执行debugging ike all命令打开接收端MSR G2的所有IKE调试信息开关，确认协商过程中报文交互是否正常。

MSR G2上打印的关键debug信息如下：

*Nov  6 17:03:05:527 2014 ROUTER IKE/7/Event: IKE thread 366519722672 processes a job.

*Nov  6 17:03:05:527 2014 ROUTER IKE/7/Packet: Begin a new phase 1 negotiation as responder.

*Nov  6 17:03:05:527 2014 ROUTER IKE/7/Event: Responder created an SA for peer 10.1.1.1, local port 500, remote port 500.

*Nov  6 17:03:05:527 2014 ROUTER IKE/7/Event: Set IKE SA state to IKE_P1_STATE_INIT.

*Nov  6 17:03:05:527 2014 ROUTER IKE/7/Packet: Received ISAKMP Security Association Payload.（收到对端发起的第一个协商报文）

………

*Nov  6 17:03:05:527 2014 ROUTER IKE/7/Packet: The profile 1 is matched.（匹配到了ike profile 1）

……….

*Nov  6 17:03:05:528 2014 ROUTER IKE/7/Event: Found pre-shared key in keychain 1 matching address 10.1.1.1.（匹配到了key chain）

……….

*Nov  6 17:03:05:535 2014 ROUTER IKE/7/Event: IKE SA state changed from IKE_P1_STATE_INIT to IKE_P1_STATE_SEND2.

*Nov  6 17:03:05:535 2014 ROUTER IKE/7/Packet: Sending packet to 10.1.1.1 remote port 500, local port 500.（发送第二个协商报文）

………..

*Nov  6 17:03:05:739 2014 ROUTER IKE/7/Packet: Received packet from 10.1.1.1 source port 500 destination port 500.（接收到第三个协商报文）

…………….

*Nov  6 17:03:05:741 2014 ROUTER IKE/7/Event: IKE SA state changed from IKE_P1_STATE_SEND2 to IKE_P1_STATE_ESTABLISHED.（第一阶段协商完成）

*Nov  6 17:03:05:741 2014 ROUTER IKE/7/Event: Add tunnel, alloc new tunnel with ID [1].

*Nov  6 17:03:05:983 2014 ROUTER IKE/7/Packet: Received packet from 10.1.1.1 source port 500 destination port 500.（接收到第2阶段第1个报文）

………….

*Nov  6 17:03:05:984 2014 ROUTER IKE/7/Event: IPsec SA state changed from IKE_P2_STATE_INIT to IKE_P2_STATE_GETSP.

*Nov  6 17:03:05:985 2014 ROUTER IKE/7/Error: Failed to get IPsec policy for phase 2 responder. Delete IPsec SA.

*Nov  6 17:03:05:985 2014 ROUTER IKE/7/Error: Failed to negotiate IPsec SA. （没有找到ipsec policy，协商失败）

*Nov  6 17:03:05:985 2014 ROUTER IKE/7/Event: Delete IPsec SA.

*Nov  6 17:03:05:985 2014 ROUTER IKE/7/Packet: Encrypt the packet.

*Nov  6 17:03:05:985 2014 ROUTER IKE/7/Packet: Construct notification packet: INVALID_ID_INFORMATION.

*Nov  6 17:03:05:985 2014 ROUTER IKE/7/Packet: Sending packet to 10.1.1.1 remote port 500, local port 500.（知会对方协商失败。）

从MSR G2打印的debug信息可以看出，接收端MSR G2没有找到匹配的IPsec安全策略，这是IPsec SA没有协商成功的关键原因。

(3)     检查接收端MSR G2的IPsec安全策略配置。

此IPsec安全策略相关配置信息如下：

ipsec policy hzbank 7000 isakmp

transform-set 1

security acl 3000

ike-profile 1

reverse-route dynamic

reverse-route tag 10

从MSR G2打印的IPsec安全策略信息可以看出，接收端MSR G2没有在IPsec安全策略下配置对端的IP地址。

通过执行remote-address命令指定MSR G2的对端IP地址。

[Router]ipsec policy hzbank 7000 isakmp

[Router-ipsec-policy-isakmp-hzbank-7000]remote-address 10.1.1.1

 

(4)     检查IPsec安全提议的配置，核对发起端MSR G1和接收端MSR G2两端配置的加密算法、认证算法等是否一致。

(5)     检查发起端MSR G1和接收端MSR G2的IPsec安全策略保护的数据流是否一致。

发起端MSR G1的ACL配置信息如下：

acl number 3001

 rule 5 permit ip source 168.201.0.0 0.0.0.7 destination 168.68.2.200 0

 rule 25 permit ip source 168.201.0.0 0.0.0.7 destination 168.201.255.1 0

接收端MSR G2的ACL配置信息如下：

acl number 3000

 rule 7 permit ip source 168.68.2.200 0 destination 168.201.0.0 0.0.127.255

从发起端MSR G1和接收端MSR G2两端的ACL信息可以看出，发起端MSR G1有一条流168.201.0.0/29 -> 168.201.255.1在接收端MSR G2上没有对应，导致两端的ACL数据流不一致。

修改接收端的ACL配置如下：

acl number 3000

rule 7 permit ip source 168.68.2.200 0 destination 168.201.0.0 0.0.127.255

rule 10 permit ip source 168.201.255.1 0 destination 168.201.0.0 0.0.127.255

在接收端MSR G2上增加了168.201.255.1 -> 168.201.0.0/29数据流后，IPsec协商成功。