具体故障表现为：移动无线上网用户使用 VPN 客户端经常无法与 VPN 网关正常建立 VPN 隧道，VPN 网关上显示隧道正在协商， 但是偶尔可以与 VPN 网关正常建立隧道 （几率较小）； 其他 VPN 客户端用户均可以与 VPN 网关正常建立 VPN 隧道。 故障环境说明： 1、移动无线上网用户经过移动的 NAT 设备（使用 NAT POOL 做的地址转换）访问互 联网； 2 、无线移动用户使用天融信的 IPSEC VPN 远程客户端，经过：移动 NAT 设备 - 互联 网-F5 负载均衡设备（目的地址转化为天融信 VPN 外部接口地址） - 天融信 IPS- 天融信 VPN 网关（ IP 地址为： 172.31.1.76 ，通过 F5 对外映射为公网地址 211.X.X.76 ）建立 VPN 隧道； 常规分析：问题是出在协商过程？ 1、首先，我们通过移动无线上网用户 VPN 客户端与 VPN 网关建立隧道的过程，可以 发现故障点主要有以下五个：移动无线上网机器、移动 NAT 设备、 F5 设备、 IPS 、VPN 网 关； 2 、通过故障现象，我们可以发现，其他 VPN 客户端用户均可以与 VPN 网关正常建立 VPN 隧道，那么基本上可以将 F5 设备、 IPS、VPN 网关等故障点排除； 3 、隧道无法建立时，显示为正在协商，说明 IPSEC VPN 隧道建立异常，问题是出在 协商过程； 4 、到底是什么原因造成的协商问题，一时无法定位，我们只能通过抓取异常时的数据 包来分析了。 数据包分析：采用 Wireshark 分析工具来做 在进行数据包分析之前，我们需要对 IPSEC VPN 隧道建立的基本理论以及天融信 IPSEC VPN 客户端与天融信 VPN 网关建立隧道的过程有一个较清晰的认识； 1 IPSEC VPN 隧道基本原理 1、 IPSEC VPN 隧道建立基本过程 协商过程 IKE 协议是用于 IPSEC 隧道协商 SA 的协议，IKE 的协商过程分为协商 ISAKMP SA 和 协商 IPSEC SA 两个阶段；第一阶段可以采用：主模式或野蛮模式两种协商方法；第二阶 段统称为快速模式。 第一阶段主模式协商（协商 ISAKMP SA ）过程图： 第一阶段野蛮模式协商（协商 ISAKMP SA ）过程图： 第二阶段快速模式协商（协商 IPSEC SA ）过程图： 从上面三张图示，我们可以看到隧道协商时，主模式需要双向传输 6 个数据包，野蛮 模式双向 3 个数据包，快速模式双向 3 个数据包； 2 天融信 VPN 客户端隧道建立过程 天融信 VPN 客户端与天融信 VPN 网关建立 IPSEC VPN 隧道的主要流程如下： VPN 客户端通过 VPN 网关的 TCP 2012 端口， 在网关上进行注册； 这个过程网关上会 判断（可以通过用户名、口令的形式，也可以通过证书的形式）该 VPN 客户端用户是否为 网关上预先定义的合法用户， 如果是，将给客户端分配一个虚拟地址用于加密隧道内的通讯； VPN 客户端注册成功后，客户端会向网关的 UDP 2012 端口发送通告，网关则向 VPN 客户端发送反向通告； VPN 客户端通过野蛮模式进行第一阶段协商； 第一阶段协商成功的话，则通过快速模式进行第二阶段协商； 如果第二阶段协商成功，则 IPSEC VPN 隧道建立成功； 隧道建立成功，则可以实现 VPN 隧道内的安全访问； 3 抓包分析 当 VPN 客户端隧道建立异常时，我们抓取客户端的数据包如下（双击以 wireshark 打 开）： 通讯过程图示： 我们首先通过该数据包， 将此此通讯过程以图示的方式呈现如下 （为便于分析协商过程， 此图示未将 VRC 通告通讯画出）： 发现问题：为何 VPN 网关没有响应第 19 个数据包？ 1、 1 －10 数据包很清晰的显示了 VPN 客户端向 VPN 网关注册（使用的是 TCP2012 端口）的通讯过程，三次握手建立通讯，双向传输数据包，四次握手拆除连接； 2 、 12 深信服VPN无法连接、 14 ，22 、23 等为 VPN 客户端与防火墙间互相通告的通讯数据包，使用的是 UDP 2012 端口； 3 、第 11 、13 、15 数据包均为 VPN 客户端发出的 ISAKMP SA 协商的第一个包 （有Initiator cookie 值， Responder cookie 为 0 ，故可以判断为 SA 协商的第一个数 据包），三数据包的 Initiator cookie 值不一样，因此，可以肯定这三个数据包是没有关联关 系的； 4 、第 16 个数据包为 VPN 网关给第 13 个数据包的响应，因为其 Initiator cookie 值与 第 13 个数据包的 Initiator cookie 值对应； 5 、第 17 个数据包为 VPN 网关给第 14 个数据包的响应，因为其 Initiator cookie 值与 第 14 个数据包的 Initiator cookie 值对应； 6 、第 18 个数据包通讯端口变成 UDP 4500 了（这是由于 VPN 客户端是经过 NAT 访 问互联网的，天融信的 IV VPN 客户端支持 NAT-T 协议，所以在野蛮模式下，第三个数据 包自动漂移到 UDP 4500 端口进行通讯了， 具体参见 RFC3947 ），通过此数据包的 Initiator cookie: 44A81E8F3CE968DC 和 Responder cookie: C067353F5DE37295 ，我们可以判断 该数据包是 VPN 客户端给第 17 个数据包的回应， 也就是说， 第 15 、17 、18 数据包为完整 完成野蛮模式协商的通讯数据包， VPN 客户端为什么没有响应第 16 个数据包？这可能是 VPN 客户端内部的实现机制决定的， VPN 客户端只响应最后到达的 VPN 网关数据包吧； 7 、第 19 个数据包为 VPN 客户端向 VPN 网关发出的第二阶段协商的第一个数据包， 其协商模式为快速模式，通过该数据包的 Initiator cookie 值、 Responder cookie 值，我们 可以确定其与第 15 、17 、 18 数据包同属于一个应用层会线 数据包通过其 Initiator cookie 值、 Responder cookie 值以及 Next payload: UNKNOWN-ISAKMP-VERSION (10) ，我们可以判断该数据包为一个告知 VPN 网关协商错 误的数据包； 为什么会协商错误？因为 VPN 客户端没有收到 VPN 网关对第 19 个数据包的 回应，这里有个时差问题，从 VPN 客户端发出快速模式的第一个包（第 19 个数据包）到 VPN 客户端发出错误通告数据包（第 20 个数据包），期间大概时差为 3 秒左右，也就意味 着 VPN 客户端内部存在着这样一个超时机制，超过 3 秒未收到 VPN 网关的响应包就会发 送错误通告； 9 、第 24 个数据包为第 16 个数据包的重传， 此可以通过 24 包和 16 包的 Initiator cookie 值、Responder cookie 值以及 Next p

　　2、成为VIP后，下载本文档将扣除1次下载权益。下载后，不支持退款、换文档。如有疑问请联系我们。

　　3、成为VIP后，您将拥有八大权益，权益包括：VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。

　　4、VIP文档为合作方或网友上传，每下载1次， 网站将根据用户上传文档的质量评分、类型等，对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档

　　VOA文章AClassWhereTeensLearnMothering(中英对照)借鉴.pdf

　　14BJ8-1-卫生间、浴卫隔断、厨卫排气道系统(原88J8图集停用)-全国各省建筑标准.pdf

　　原创力文档创建于2008年，本站为文档C2C交易模式，即用户上传的文档直接分享给其他用户（可下载、阅读），本站只是中间服务平台，本站所有文档下载所得的收益归上传人所有。原创力文档是网络服务平台方，若您的权利被侵害，请发链接和相关诉求至 电线) ，上传者