扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条
作者:论坛管理 来源:zdnet安全频道 2008年12月27日
关键字: VPN
故障:移动无线VPN无法连接
具体故障表现为:移动无线上网用户使用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均未找到好的相关资料。
睿博工作室介绍:
本文章系睿博工作室提供,睿博工作室是一群在网络性能,网络安全及网络故障方面有着多年从业经验的咨深专业人士、致力于为政府、教育、能源以及广大企事业单位提供优质的技术咨询及服务的技术团队。其宗旨是:以专业技术,资深经验、热情服务,全力为客户打造高性能的安全网络!
如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。
现场直击|2021世界人工智能大会
直击5G创新地带,就在2021MWC上海
5G已至 转型当时——服务提供商如何把握转型的绝佳时机
寻找自己的Flag
华为开发者大会2020(Cloud)- 科技行者