科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网网络频道无法移动办公!无线VPN故障分步排查记

无法移动办公!无线VPN故障分步排查记

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

某单位采用移动无线VPN来实现移动办公,从而进行ERP等应用销售项目等操作,然而,VPN始终无法连接,严重了企业的移动办公效率。

作者:论坛管理 来源:zdnet安全频道 2008年12月27日

关键字: VPN

  • 评论
  • 分享微博
  • 分享邮件
某单位采用移动无线VPN来实现移动办公,从而进行ERP等应用销售项目等操作,然而,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领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章