移动无线VPN客户端隧道建立故障分析说明

　　1.2 说明

　　1、移动无线上网用户由移动分配所得的IP为：10.143.235.141；

　　2、移动无线上网用户经过移动的NAT设备（使用NAT POOL做的地址转换）访问互联网；

　　3、无线移动用户使用天融信的IPSEC VPN远程客户端，经过：移动NAT设备->互联网->F5负载均衡设备（目的地址转化为天融信VPN外部接口地址）->天融信IPS->天融信VPN网关（IP地址为：172.31.1.76，通过F5对外映射为公网地址211.X.X.76）建立VPN隧道；

　　2故障现象

　　1、 移动无线上网用户使用VPN客户端经常无法与VPN网关正常建立VPN隧道，VPN网关上显示隧道正在协商，但是偶尔可以与VPN网关正常建立隧道（几率较小）；

　　2、 其他VPN客户端用户均可以与VPN网关正常建立VPN隧道；

　　3故障分析

　　3.1常规分析

　　1、首先，我们通过移动无线上网用户VPN客户端与VPN网关建立隧道的过程，可以发现故障点主要有以下五个：移动无线上网机器、移动NAT设备、F5设备、IPS、VPN网关；

　　2、通过故障现象，我们可以发现，其他VPN客户端用户均可以与VPN网关正常建立VPN隧道，那么基本上可以将F5设备、IPS、VPN网关等故障点排除；

　　3、隧道无法建立时，显示为正在协商，说明IPSEC VPN隧道建立异常，问题是出在协商过程；

　　4、到底是什么原因造成的协商问题，一时无法定位，我们只能通过抓取异常时的数据包来分析了。

　　3.2 数据包分析

　　在进行数据包分析之前，我们需要对IPSEC VPN隧道建立的基本理论以及天融信IPSEC VPN客户端与天融信VPN网关建立隧道的过程有一个较清晰的认识；

　　3.2.1 IPSEC VPN隧道基本原理

　　1、IPSEC VPN隧道建立基本过程

　　2、 协商过程

　　IKE协议是用于IPSEC隧道协商SA的协议，IKE的协商过程分为协商ISAKMP SA和协商IPSEC SA两个阶段；第一阶段可以采用：主模式或野蛮模式两种协商方法；第二阶段统称为快速模式。

　　第一阶段主模式协商（协商ISAKMP SA）过程图：

　　第一阶段野蛮模式协商（协商ISAKMP SA）过程图：

　　第二阶段快速模式协商（协商IPSEC SA）过程图：

　　从上面三张图示，我们可以看到隧道协商时，主模式需要双向传输6个数据包，野蛮模式双向3个数据包，快速模式双向3个数据包；

　　3.2.2 天融信VPN客户端隧道建立过程

　　天融信VPN客户端与天融信VPN网关建立IPSEC VPN隧道的主要流程如下：

　　1、 VPN客户端通过VPN网关的TCP 2012端口，在网关上进行注册；这个过程网关上会判断（可以通过用户名、口令的形式，也可以通过证书的形式）该VPN客户端用户是否为网关上预先定义的合法用户，如果是，将给客户端分配一个虚拟地址用于加密隧道内的通讯；

　　2、 VPN客户端注册成功后，客户端会向网关的UDP 2012端口发送通告，网关则向VPN客户端发送反向通告；

　　3、 VPN客户端通过野蛮模式进行第一阶段协商；

　　4、 第一阶段协商成功的话，则通过快速模式进行第二阶段协商；

　　5、 如果第二阶段协商成功，则IPSEC VPN隧道建立成功；

　　6、 隧道建立成功，则可以实现VPN隧道内的安全访问；

　　3.2.3抓包分析

　　当VPN客户端隧道建立异常时，我们抓取客户端的数据包如下（双击以wireshark打开）：

　　通讯过程图示：

　　我们首先通过该数据包，将此此通讯过程以图示的方式呈现如下（为便于分析协商过程，此图示未将VRC通告通讯画出）：

　　分析过程：

　　1、1－10数据包很清晰的显示了VPN客户端向VPN网关注册（使用的是TCP2012端口）的通讯过程，三次握手建立通讯，双向传输数据包，四次握手拆除连接；

　　2、12、14，22、23等为VPN客户端与防火墙间互相通告的通讯数据包，使用的是UDP 2012端口；

　　3、第11、13、15数据包均为VPN客户端发出的ISAKMP SA协商的第一个包（有Initiator cookie值，Responder cookie为0000000000000000，故可以判断为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数据包同属于一个应用层会话；

　　8、20、21数据包通过其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 payload来判断。UDP协议本身是不可靠的，不存在重传一说，那么这个重传应该是通过应用层的机制来实现的；

　　10、第25个数据包为第17个数据包的重传，此可以通过25包和17包的Initiator cookie值、Responder cookie值以及Next payload来判断；

　　11、第26、27个数据包为VPN客户端对第25个数据包的响应，这两个数据包与第18、19个数据包的内容是一模一样的；

　　12、第28、29、30个数据包与第20、21的数据包一样为协商错误通告数据包；

　　发现问题：

　　通过上面的数据包分析，我们已经可以发现问题了：为什么VPN网关没有响应第19个数据包，而是重传了第16、17个数据包？

　　引出疑问：

　　肯定是VPN网关没有收到第19个数据包，也就是说，第19个数据包在经过中间设备时丢弃了！那么中间什么设备会做这样的处理呢？移动无线上网用户的其他互联网的应用基本正常，由此可以判断中间设备不会对经过它的正常数据包做丢弃处理，那么问题到底出在什么地方呢？

　　大胆假设：

　　忽然想到，有些厂家的设备可以通过某种算法（可能是针对连接的、源地址的等）实现内部上网用户均衡使用NAT POOL中各个地址访问互联网（NETSCREEN好象有这种功能开关），移动无线那边的互联网接入设备是通过NAT POOL做动态转换访问互联网的，那么是否存在这种可能：移动那边的NAT设备就是采用基于连接的均衡算法，实现内部机器平均使用NAT POOL中各个地址访问互联网的，那么在VPN客户端与VPN网关进行野蛮模式协商时，由于客户端需要NAT，所以VPN客户端使用NAT-T协议，对协商的端口做了偏移（第18、19个数据包），而移动NAT设备在收到这两个数据包时，认为是一个新的连接，于是在做NAT时，重新给这两个数据包选择了一个地址（这个地址与前面的NAT地址一样的几率肯定很小，当两次NAT的地址一样时，可以正常建立VPN隧道），并传送给VPN网关，VPN网关收到这两个数据包后，将其丢弃（因为，VPN网关中没有连接与此IP对应），经过一段时间后，VPN网关重传第一阶段的协商响应包（第24、25个数据包）。

　　以上的假设，完全可以解释我们遇到的所有的故障现象，但是为彻底定位问题根源，我们还需要在防火墙抓包验证。

　　4故障解决

　　找到了故障根源，故障解决就比较好办了，可以使用两种方式：

　　1、 要求移动修改其NAT设备上的NAT POOL转换算法；

　　2、 要求移动给淮北矿无线上网用户采用固定地址NAT访问互联网；

　　以上两种方式均需要移动配合。

　　5总结

　　1、 产生此次故障的原因有两个：

　　一：VPN客户端通过NAT访问互联网，VPN客户端在做IKE协商时使用了NAT-T协议，因此在第一阶段ISAKMP SA协商时，VPN客户端会更改其与VPN网关通讯的目的端口（原来为UDP500，更改为UDP4500），从而使得移动的NAT设备认为这个目的端口为UDP4500的数据包隶属于一个新的UDP连接；

　　二：NAT设备在为无线用户通过NAT POOL做动态地址转换时，NAT设备会按照一种均衡算法对NAT POOL中的可用地址进行调用，这种算法可能是基于连接的、IP、数据包、流量等等，通过对VPN网关上的抓取的数据包的分析，我们可以推论出移动NAT设备采用的是基于连接的均衡算法，但该推论未得到移动方面的确切答复；

　　2、 很多设备（包括专业的数据分析软件）定位一个连接或数据流基本都是基于源IP、目的IP、源端口、目的端口、协议类型等五元组的，所以，当存在象IKE NAT 穿越等应用时，往往无法正确判断；

　　3、 UDP协议是无连接的，没有收发序列号，所以，在做这种应用层分析时，很不方便，好在IKE协商数据包可以根据应用层的一些信息来定位是否属于同一数据流；