利用科来网络分析技术解决VPN异常中断故障

2018-06-11    来源:

容器云强势上线!快速搭建集群,上万Linux镜像随意使用

 

故障描述

   某保险公司北京总公司与各地分公司均通过双线与当地电信和联通两大互联网运营商相连,各地分公司通过IPsec VPN接入总公司内部网络。

   由于业务量增加,对广域网的带宽需求加大,用户对总公司的联通接入线路进行了扩容。升级后总公司联通线路的承载能力得到了提高,但各地分公司通过联通网络建立的VPN隧道经常会出现短时间的中断,用户怀疑是新升级的联通互联网线路存在问题,或运营商对其VPN通讯进行了限制或干扰,需要通过网络协议分析查找造成中断的具体原因。

环境描述

   本次分析使用科来回溯分析系统1002T,在总公司的VPN服务器(一台Juniper防火墙)外侧部署,7×24小时捕获并分析其VPN隧道ESP流量以及ISAKMP流量,部署拓扑示意图1:

分析过程

1、流量趋势分析

   首先通过回溯分析系统的IP流量精细分析功能查看发生中断的VPN对端IP地址175.44.133.172的11月13日下午14:30~18:30的流量趋势。从趋势图上,并没有发现明显的长时间流量中断,在发生问题的15:05和18:05左右也没有出现流量为0的情况。于是进一步使用4分钟窗口(1秒钟精度)查看15:05和18:05左右的流量趋势,发现在发生中断的2min内,总公司防火墙前端能够收到福建VPN对端的数据包,但是总公司的防火墙向对端发送的数据包却很少。通过与正常时段的流量进行比对分析,正常时段VPN两端发送的数据包量基本相当。

福建VPN 13日凌晨中断,通过用户提供的其他VPN隧道中断时刻我们也看到了两端数据包发送量差距巨大的现象。由此我们基本可以判断发生中断时刻,总公司和分公司之间的互联网链路(联通运营商网络)没有问题,很可能是由于总公司防火墙某段时间没有发送数据导致VPN中断。

2、数据包解码分析

   下载福建分公司VPN 175.44.133.172的11月13日下午的全部数据包进行解码分析。

   从数据包来看,当天下午双方每小时会进行一次二阶段协商来更换ESP密钥,可推断双方的ESP SA生存时间为1小时,但15:03的二阶段协商出现了意外情况。

   在福建分公司175.44.133.172与总公司123.127.198.81之间通信的数据包中我们看到在发生中断的15:03:58两端防火墙使用UDP 500端口交互了3个报文。通过分析3个UDP 500端口的报文,发现偏移量为3C的字段值(Exchange type类型字段)均为”0x20”,表示这三个报文是ISAKMP二阶段协商的报文,主要作用是协商新的ESP SA。这三个报文之后175.44.133.172发送的ESP报文使用了新的SPI(安全参数索引),但总公司的防火墙并没有使用新的SA发送数据,也没有继续使用以前的SA发送数据,可推断是总公司防火墙自身的程序出现问题导致这一现象。1分51秒后,我们看到175.44.133.172再次向123.127.198.81发送了一个Exchange type字段为“0x05”(ISAKMP Information)的通知报文,然后双方又交换了3个二阶段协商报文,此次协商之后VPN两端都使用了新的SPI进行ESP数据交互,后续通讯正常。

   从上面这些情况来看,15:03第一次协商之后,福建分公司的防火墙IPSec处理正常,后续发送的ESP数据包序列号连续,可以确定两地之间的互联网链路也没有问题。造成此次中断的直接原因是15:03的第一次协商之后,总公司防火墙处理出现异常,没有正确使用新的ESP SA通讯。

   在18:05左右时段,我们又看到了相同的现象:第一次二阶段协商后总公司防火墙不发送新的ESP数据,1分53秒后进行第二次二阶段协商,48秒后总公司防火墙使用新的SA发送数据,这就是造成 2分41秒单向通讯的原因。

    通过对比多次不同分公司VPN中断时刻的数据,我们发现每次中断的现象均一致,并且有些正常时段在双方更新SA后,总公司的防火墙也会出现短时间不发送数据的情况,如果这一现象持续时间超过1分50秒,双方就会重新开启二阶段协商,在这段时间内VPN处在中断的状态。

结论及建议

1、结论:

监控链路的流量趋势稳定,没有发现明显的持续丢包或链路质量异常的现象,总公司与分公司之间使用联通线路的VPN隧道短时间中断现象与运营商的网络链路无关;

造成异常中断的直接原因是在周期性二阶段协商之后,总公司的防火墙可能存在Bug或异常情况导致不能使用新的SA进行后续ESP通讯;

由于这一现象是在联通线路扩容之后才出现的,可推断是由于扩容后联通线路流量增大,总公司防火墙上有上百个IPSec隧道,频繁的密钥更新增大了防火墙的负荷,导致其在刷新SA后相关进程出现延时或锁死。

2、建议:

将捕获数据包与我们分析的结论提交给防火墙厂商,请厂商协助处理;

在厂商没有彻底解决相关问题期间,可以通过配置增大各隧道IPsec SA的生存时间,这样可以降低密钥更新的频率减少对防火墙性能的压力。

 

标签: 安全 防火墙 服务器 互联网 互联网运营 通信 网络 问题 用户

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点!
本站所提供的图片等素材,版权归原作者所有,如需使用,请与原作者联系。

上一篇:金山紧急推出XP防护盾企业版守护企业级用户

下一篇:瑞星发布企业移动管理系统