具体故障表现为：移动无线上网用户使用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个数据包）。青春期孩子的教育
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论