VPN故障排除手册.doc-道客多多_道客多多docduoduo.com

资源描述

1、IPsec VPN 故障排除手册Version1.0迈普技术服务中心2008-05-01三、IPsec VPN 常见问题处理本章重点介绍VPN的故障排除的基本思路，以及分析故障原因和解决问题的常用方的基本思路，以及分析故障原因和解决问题的常用方法。本章内容： IPsec VPN故障排除基本思路 IPsec VPN常见故障处理 IPsec VPN SA状态信息说明调试命令参数解释3.1 IPsec VPN 故障排除基本思路当 IPsec VPN 出现问题时，最直接的表现就是无法通过 IPsec VPN 访问远端内部网络。按照具体的情况又分为：IPsec 隧道无法建立、IPsec 隧道建立但无法

2、访问远端内部网络和IPsec 隧道时断时连。通过 IPsec 的 debug 信息检测问题是比较快的，但需要使用者对debug 信息比较熟悉。所以这里介绍针对上面三种情况的一般检测方法。1 IPsec VPN 隧道无法建立检测方法：使用 show cry ike proposal 和 sh cry ipsec proposal 命令查看 ike 和 ipsec 的策略两端是否相同。使用 sh cry policy 查看两端数据流是否匹配。2 IPsec 隧道建立但无法访问远端内部网络检测方法：sh ip esp 查看是否有 in 和 out 的数据；查看访问列表是否 deny 了受保护的数据流

3、。3 IPsec 隧道时断时连检测方法：查看物理线路是否时通时断；查看是否有网点冲突。3.2 IPsec VPN 常见故障处理故障一：IPsec VPN 隧道无法建立可能的原因判断方法和解决方案1两端 VPN 设备无法互通1 从一端 VPN 设备 ping 另外一端，看是否能否 ping 通。如果不通，首先检查网络连接情况。2两端 VPN 可以 ping通，但是相互收不到 IKE协商报文1 检查 VPN 是否配置 ACL 或者前端是否有防火墙，禁止了 IKE 协商报文，需要在 ACL 或者防火墙上开放UDP500/4500 端口；2 检查发起方 VPN 的内网口是否 UP，特别是 3005C

4、-104以 SW 接口作为内网口，LAN 口上没有接 PC，SW 口无法 UP，将导致扩展 ping 不通对端。3两端 VPN 采用证书认证方式，但是没有证书或者证书无效；采用预共享密钥方式认证没有配置密码1 通过 show cry ike sa 查看 IKE 隧道状态没有任何信息；2 打开 debug cry ike normal，提示%IKE-ERR: cant initiate, no available authentication material (cert/psk) ；3 sh crypto ca certificates，查看证书是否有效。4两端 IKE 和 IPsec 策略不

5、一致1. 如果采用主模式，查看 IKE 状态停止在STATE_MAIN_I1，采用积极模式，IKE 状态停止在STATE_AGGR_I1，说明可能是两端策略不一致，通过show cry ike proposal 和 show cry ipsec proposal 查看两端策略是否相同；2. 打开 debug cry ike normal，提示 ignoring notification payload, type NO_PROPOSAL_CHOSEN 。5两端 VPN 设备配置了ID 不是 IP 地址作为身份标识，而是域名或者其1 查看 IKE KEY 配置了 identity，但是 tunn

6、el 配置中配置了 set mode main；2 查看 IKE 状态停止在 STATE_MAIN_I1 状态。他，但是采用 IKE 协商采用主模式6对端 VPN 设备配置错误 ID 或者没有配置 ID1 查看 IKE KEY 配置了 identity，但是 tunnel 配置中没有配置 ID；2 查看 IKE 状态停止在 STATE_AGGR_I1 状态；3 有%IKE-ERR: Aggressive Mode packet from 20.0.0.2:500 has invalid ID 报错。7两端 VPN 设备不支持NAT 穿越1 如果采用主模式，查看 IKE 状态停止在STATE_M

7、AIN_I2 状态，说明有可能 VPN 不支持 NAT 穿越，我们 VPN 默认支持，一般可能其他厂家 VPN 不支持。8两端 VPN 设备预共享密钥不一致1. 如果采用主模式，查看 IKE 状态停止在STATE_MAIN_I3 状态，说明有可能两端 VPN 预共享密钥配置不一致；2. 通过 show run cry key 查看两端的 KEY 是否相同。9两端保护数据流不匹配1. 查看 IKE 状态停止在 STATE_QUICK_I1 状态，说明有可能两端 VPN 预共享密钥配置不一致；2. 通过 show cry ipsec sa 查看没有 ipsec 隧道；3. 日志中有报错：%IKE-

8、ERR: cannot respond to IPsec SA request for instance-65666: 30.0.0.0/8:0/0 = 20.0.0.2 (20.0.0.2). 20.0.0.1 (20.0.0.1)= 192.168.0.0/16:0/0 注：IKE 第一阶段采用积极模式，因为积极模式进行 IKE 协商同时传送与 SA、密钥交换和认证相关的载荷，所以一般 IKE 的错误都将导致 IKE SA 的状态为 STATE_AGGR_I1。因此上述对 IKE 第一阶段问题判断基本都是基于主模式。故障二：VPN 隧道通，无法处理业务可能的原因判断方法和解决方案1

9、业务数据走 NAT，没有走 VPN 隧道1. 设备配置了 NAT 转换，访问列表没有将 VPN 的业务数据 deny，可以查看访问列表来判断；2. 可以通过 show cry ipsec sa 或者 show ip esp 查看output 的数据一直没有增加；3. 修改访问列表，拒绝 VPN 数据走 NAT 转换。2要访问服务器没有路由指向对端 VPN 网关或者网关设置不对1. 在中心端 VPN 设备上 ping 服务器看能否 ping 通；2. 第一步可以 ping 通，则可以在客户端 VPN 设备上通过 show cry ipsec sa 或者 show ip esp 查看 output

10、的数据有增加，但是 input 的数据一直没有增加，在中心端 VPN 设备相反，有 input 的数据，但是没有output;3. 设置服务器对应的下端网段路由应该指向中心 IPsec VPN 设备的内网口。3线路 PMTU 导致大数据包丢弃1. 某些业务软件（例如一些财务软件或者登陆需要下载大量数据的应用程序）可以出现登陆界面，但是输入用户名密码后一直没有反应；2. 客户端采用默认 ping 包可以 ping 通服务器，ping 大包不通；3. 可以修改服务器网卡的 MTU线路 PMTU。故障三：VPN 时通时断可能的原因判断方法和解决方案1公网连接不稳定 1. 通过 ping 测试检测物

11、理线路问题；2. 直接用 PC 接在公网线路测试看看是否会断；3. 如果是动态拨号，可以更改 idletimeout 为 0。2某次线路故障造成两端的 IPsec SA 不能够同步1. 查看两端 VPN 设备是否关闭了 DPD；2. 通过 show cry ipsec sa 查看两端 SPI 是否不相同;3. 在两端手工清除隧道重新建立或者设置 DPD 解决不同步问题。3分支机构 VPN 配置重复1. 隧道时断时连表现为当只有一个下端的时候一切正常，但当第二个或某个特定下端连接上来的时候，出现只有一个能正确建立 IPsec 隧道或时断时连；2. 在中心 VPN 设备检查某个分支机构不能建立 V

12、PN 隧道时却有相关的 IPsec 数据流；3. 可以在分支机构 VPN 上更换网段测试或者配置使用积极模式，配置不通的标识 ID。3.3 IPsec VPN SA 状态信息说明在进行 VPN 故障排除过程中，经常要查看 IPsec VPN SA 状态，这里有必要对 SA 显示信息做以说明，以便排查问题。正常情况下，每个分支结构对应两条 IKE SA 条目，且一般分支机构都是 VPN 发起方。当我们在分支机构 VPN 的特权模式下，键入 show crypto ike sa 后，显示 IKE SA 信息如下：localaddr peeraddr peer-identity negotiatio

13、n-state sa-id20.0.0.1 20.0.0.2 20.0.0.2 STATE_QUICK_I2 34620.0.0.1 20.0.0.2 20.0.0.2 STATE_MAIN_I4 3451、localaddr：发起 IKE SA 的本端地址，这里为公网接口地址；2、peeraddr：IKE SA 的对端地址，为对端 VPN 的公网接口地址；3、peer-identity ：对端标识，如果采用证书方式，显示为 CN=xxxx；4、negotiation-state：隧道状态，IKE 第一阶段协商分主模式和积极模式，主模式为MAIN，积极模式为 AGGR，本例第一阶段采用主模式，

14、IKE 第二阶段协商都是 QUICK 模式。关键字“I”代表 IKE 发起方，相应方用 “R”表示；5、sa-id：SA 的 ID 号。注：IKE 的状态根据发起方和相应方状态有所区别，根据 IKE 第一阶段采用模式也有所区别，发起方正常情况状态，主模式时为 STATE_QUICK_I2 和 STATE_MAIN_I4，积极模式时为 STATE_QUICK_I2 和 STATE_AGGR_I2。相应正常情况状态，主模式时为STATE_QUICK_R2 和 STATE_MAIN_R3，积极模式时为 STATE_QUICK_R2 和STATE_AGGR_R2。当在 VPN 的特权模式下，键入

15、show crypto ipsec sa 后，显示 IPsec SA 信息如下：VPN#show crypto ipsec sa1 policy name : p2 f (src, dst, protocol, src port, dst port) : 192.168.0.0/22 30.0.0.0/8 ip any any3 local tunnel endpoint : 20.0.0.1 remote tunnel endpoint : 20.0.0.24 the pairs of ESP ipsec sa : id : 18933, algorithm : DES HMAC-SHA1-

16、965 inbound esp ipsec sa : spi : 0X562f2161(1445929313)6 current input 0 packets, 0 kbytes7 encapsulation mode : Tunnel8 replay protection : ON9 remaining lifetime (seconds/kbytes) : 1244/460800010 uptime is 7 hour 39 minute 16 second11 outbound esp ipsec sa : spi : 0Xd2a40215(3533963797)12 current

17、output 0 packets, 0 kbytes13 encapsulation mode : Tunnel14 replay protection : ON15 remaining lifetime (seconds/kbytes) : 1244/460800016 uptime is 7 hour 39 minute 16 second显示信息内容1 IPsec 策略名称2 源网段、目的网段、协议、源端口和目的端口3 显示隧道的本地公网地址为和对端公网地址4 显示隧道为 ESP 模式，ID 号为 18933，使用算法为 DES HMAC-SHA1-965 显示 inbound 的 SP

18、I 号为 0X562f2161(1445929313)6 显示隧道入方向的接收到的数据包个数和字节数7、 13 显示封装模式为隧道模式8、 14 重放保护状态为开启9、15 显示隧道的 lifetime，以时间为单位和以字节数为单位表示10、16 显示隧道建立时间11 显示 inbound 的 SPI 号为 0Xd2a40215(3533963797)12 显示隧道出方向的发送的数据包个数和字节数3.4 调试命令参数解释 debug crypto ike 命令【命令说明】打开 IKE 调试开关【命令格式】vpn#debug crypto ike all | crypt | dns | down

20、息dns IKE 协商过程中与 DNS 相关的调试信息downloaded-script 配置下载过程的调试信息emitting IKE 协商过程中发出报文的详细内容event IKE 的时钟事件相关调试信息kernel IKE 与内核之间的调试信息lifecycle IKE 协商过程中与生存期相关的调试信息natt IKE 协商过程中与 NAT 穿越相关的调试信息normal IKE 协商过程中通常使用的调试信息parsing IKE 协商过程中接收到的报文内容调试信息raw IKE 协商报文的原始内容调试信息syslog IKE 发送给 SYSLOG 服务器的调试信息 debug cryp

22、报文地址信息，不指定则显示双向地址信息。packet tx|rx 打开 IP 报文内容调试信息，tx:显示外出报文内容信息，rx：显示内入报文内容信息，不指定则显示双向内容信息。fragment 打开 IP 报文为分片时调试处理信息【配置模式】特权用户模式3.5 IKE 错误信息（以下只是信息的关键语句）及原因信息原因信息 1：00:24:20: %IKE-DBG-received Vendor ID payload draft-ietf-由于对方提议的 SA 载荷中的变换算法（如加密算法）与本地策略不符，因而拒绝对方的协商请求，协商失败，删除产生的状态信息ipsec-nat-t-ike-0

23、300:24:20: %IKE-DBG-ignoring Vendor ID payload draft-ietf-ipsec-nat-t-ike-0200:24:20: %IKE-DBG-ignoring Vendor ID payload draft-ietf-ipsec-nat-t-ike-0000:24:20: %IKE-DBG-received Vendor ID payload Dead Peer Detection00:24:20: %IKE-ERR-no acceptable Oakley Transform信息 2：00:26:24: %IKE-ERR-next payloa

24、d type of ISAKMP Identification Payload has an unknown value: 20100:26:24: %IKE-ERR-probable authentication failure (mismatch of preshared secrets?): malformed payload in packet预共享密钥不匹配，就必然导致双方使用的加密密钥和验证密钥不相同，从而引起解密失败（出现的现象是发现接收到的 ISAKMP 消息格式不正确）信息 3：00:35:51: %IKE-DBG-sending encrypted notification

25、 NO_PROPOSAL_CHOSEN to 128.255.40.223:500双方关于进行 IPsec 封装所采用的算法或协议没有达成一致，就会导致快速模式协商失败信息 4：00:38:53: %IKE-ERR-requested flow is not matched by any flow of ours, not accepted00:38:53: %IKE-ERR-cannot respond to IPsec SA request for instance-65545: 1.1.1.0/24:0/0 = 128.255.40.222 双方就提议的受 IPsec 保护的数据流进行协商不一致就直接导致协商失败(128.255.40.222). 128.255.40.223 (128.255.40.222)= 2.2.2.0/24:0/0信息 5：2w3d:22:41:26: %IKE-ERR: we require peer to have ID 3005B, but peer declares 20.0.0.22w3d:22:41:26: %IKE-ERR: Aggressive Mode packet from 20.0.0.2:500 has invalid ID对端 ID 无效导致 IKE 协商失败

展开阅读全文