《某保险公司VPN异常中断故障分析》.pdf

某保险公司 VPN 异常中断故障分析报告 1. 故障描述 某保险公司北京总公司与各地分公司均通过双线与当地电信和联通两大互 联网运营商相连，各地分公司通过 IPsec VPN 接入总公司内部网络。 近期由于业务量增加对广域网的带宽需求加大，用户对总公司的联通接入线 路进行了扩容，升级后总公司联通线路的承载能力得到了提高，但各地分公司通 过联通网络建立的 VPN 隧道经常会出现短时间的中断。用户怀疑是新升级的联 通互联网线路存在问题 ，或者运营商对其 VPN 通讯进行了限制或干扰 ，需要通 过网络协议分析查找造成中断的具体原因。 2. 环境描述 本次分析使用科来回溯分析系统 1002T ，在总公司的VPN 服务器（一台 Juniper 防火墙）外侧部署，7×24 小时捕获并分析其 VPN 隧道 ESP 流量以及 ISAKMP 流量 ，部署拓扑示意图如下。 第1 页 3. 分析过程 3.1. 流量趋势分析 用户技术人员通过 VPN 两端的防火墙日志查看到福建分公司 VPN 隧道于 11 月 13 日凌晨 1 点、下午 15 点和下午 18 点左右发生过 3 次短暂中断，本次 分析重点针对这 3 次中断。 首先我们通过回溯分析系统的IP流量精细分析功能查看发生中断的VPN 对 端 IP 地址 72 的 11 月 13 日下午14:30~18:30 的流量趋势 ，如下 图所示。 从 4 小时窗口（1 分钟精度）的趋势图上我们并没有看到明显的长时间流量 中断，在发生问题的 15:05 和 18:05 左右也没有出现流量为 0 的情况。于是我们 进一步使用 4 分钟窗口（1 秒钟精度）查看 15:05 和 18:05 左右的流量趋势，如 下图。 第2 页 从上图中能够看出，发生中断时刻有 2 分钟左右的时间在总公司防火墙前端 能够收到福建 VPN 对端的数据包，但是总公司的防火墙向对端发送的数据包很 少；通过对正常时段的流量进行比对分析，我们发现在正常时段 VPN 两端发送 的数据包量基本相当。 福建 VPN 13 日凌晨中断时刻，以及用户提供的其他VPN 隧道中断的时刻 我们也看到了相同的现象。由此我们基本可以判断发生中断时刻，总公司和分公 司之间的互联网链路（联通运营商网络）应该没有问题，很可能是由于一段时间 内总公司防火墙没有发送数据导致VPN 中断。 3.2. 数据包解码分析 为了进一步分析造成VPN 中断的根源，我们下载了福建 VPN 72 的 11 月 13 日下午的全部数据包进行解码分析。 在福建分公司 72 与总公司 1之间通信的数据包 中我们看到在发生中断的15:03:58 我们看到两端防火墙使用 UDP 500 端口交互 了 3 个报文，在此之后 1 分 50 秒的时间只看到 72 使用新的 SPI 发送 ESP 数据包，1 没有发送任何 ESP 数据包，如下图。 第3 页 这 3 个 UDP 500 端口的报文偏移量为 3C 的字段值 （Exchange type 类型 字段）均为”0x20” ，表示这三个报文是ISAKMP 二阶段协商的报文，主要作用是 协商新的 ESP SA。从这三个报文之后 72 发送的 ESP 报文使用了 新的 SPI （安全参数索引）可以判断，此次二阶段协商并没有问题，福建分公司 的防火墙已经使用了新的 ESP SA 进行后续数据加密；但总公司的防火墙并没有 使用新的 SA 发送数据，也没有继续使用以前的 SA 发送数据，很可能是总公司 防火墙自身的程序出现问题导致这一现象。 从整个下午的数据包来看，在 13:04 和 14:04 也有过一次二阶段协商，但后 续双方都正常使用新的 SPI 交互数据。由此可以推断是双方的 ESP SA 生存时 间为 1 小时，双方每过一小时会进行一次二阶段协商更换 ESP 密钥，不过 15:03 的二阶段协商之后出现了意外情况。 在上图中的二阶段协商完成 1 分 51 秒后，我们看到 72 向 1发送了一个Exchange type字段为“0x05”（I