vpn无法连接诊断.doc

具体故障表现为：移动无线上网用户使用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、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隧道协商异常？
　　肯定是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个数据包）。
　　以上的假设，完全可以解释我们遇到的所有的故障现象，但是为彻底定位问题根源，我们还需要在防火墙抓包验证。
　　验证：
　　当移动无线用户使用VPN客户端进行隧道协商时，在防火墙上使用tcpdump抓包，经过过滤的数据包如下所示：
　　07:28:38.596205 R@eth0 IP 211.141.161.52.13708 > 172.30.1.76.500: [|isakmp]
　　07:28:38.631396 X@eth0 IP 172.30.1.76.500 > 211.141.161.52.13708: [|isakmp]
　　07:28:39.416526 R@eth0 IP 211.141.161.50.16385 > 172.30.1.76.4500: NONESP-encap: [|isakmp]
　　07:28:39.557025 R@eth0 IP 211.141.161.50.16385 > 172.30.1.76.4500: NONESP-encap: [|isakmp]
　　07:28:41.676182 R@eth0 IP 211.141.161.52.13787 > 172.30.1.76.4500: UDP-encap: ESP(spi=0x45000038,seq=0x3e820000), length 56
　　07:28:42.297607 R@eth0 IP 211.141.161.52.13708 > 172.30.1.76.500: [|isakmp]
　　07:28:42.337361 X@eth0 IP 172.30.1.76.500 > 211.141.161.52.13708: [|isakmp]
　　07:28:42.636140 R@eth0 IP 211.141.161.52.13787 > 172.30.1.76.4500: UDP-encap: ESP(spi=0x4500003f,seq=0x3ef30000), length 63
　　07:28:44.437691 R@eth0 IP 211.141.161.52.13787 > 172.30.1.76.4500: UDP-encap: ESP(spi=0x45000040,seq=0x3f234000), length 64
　　07:28:48.340234 X@eth0 IP 172.30.1.76.500 > 211.141.161.52.13708: [|isakmp]
　　07:28:52.115557 R@eth0 IP 211.141.161.52.13708 > 172.30.1.76.500: [|isakmp]
　　07:28:52.117275 X@eth0 IP 172.30.1.76.500 > 211.141.161.52.13708: [|isakmp]
　　07:28:52.149250 X@eth0 IP 172.30.1.76.500 > 211.141.161.52.13708: [|isakmp]
　　通过上面的数据包，我们可以清楚的发现：移动无线用户在跟VPN网关建立隧道时，的确如我们上面假设的一样，经过移动NAT设备后，VPN客户端数据包是以两个不同的IP地址来跟VPN网关通讯的，因此VPN网关会将来自211.141.161.50的数据包丢弃，并且给211.141.161.52重传数据包，导致隧道协商异常；
　　故障解决：采用固定地址NAT访问互联网
　　找到了故障根源，故障解决就比较好办了，可以使用两种方式：
　　要求移动修改其NAT设备上的NAT POOL转换算法；
　　要求移动给淮北矿无线上网用户采用固定地址NAT访问互联网；
　　以上两种方式均需要移动配合。
　　总结：产生此次故障的原因有两个：
　　一：VPN客户端通过NAT访问互联网，VPN客户端在做IKE协商时使用了NAT-T协议，因此在第一阶段ISAKMP SA协商时，VPN客户端会更改其与VPN网关通讯的目的端口（原来为UDP500，更改为UDP4500），从而使得移动的NAT设备认为这个目的端口为UDP4500的数据包隶属于一个新的UDP连接；
　　二：NAT设备在为无线用户通过NAT POOL做动态地址转换时，NAT设备会按照一种均衡算法对NAT POOL中的可用地址进行调用，这种算法可能是基于连接的、IP、数据包、流量等等，通过对VPN网关上的抓取的数据包的分析，我们可以推论出移动NAT设备采用的是基于连接的均衡算法，但该推论未得到移动方面的确切答复；
　　很多设备（包括专业的数据分析软件）定位一个连接或数据流基本都是基于源IP、目的IP、源端口、目的端口、协议类型等五元组的，所以，当存在象IKE NAT 穿越等应用时，往往无法正确判断；
　　UDP协议是无连接的，没有收发序列号，所以，在做这种应用层分析时，很不方便，好在IKE协商数据包可以根据应用层的一些信息来定位是否属于同一数据流；
　　引申问题
　　NAT POOL的均衡算法问题，google、baidu均未找到好的相关资料。