虚妄

防火墙、VPN与MTU

    笔记     网络

  1. 1. 问题
  2. 2. 原因
  3. 3. 解决方案
  4. 4. 总结

问题

因为行业原因,之前理解中的软件都是跑在局域网内,数据的传输至少不会遇上网络方面的原因,除去一些硬件等物理因素。这是常规的用法,测试团队也是基于这样的网络环境进行测试,也包括防火墙。

编程方面有一句名言:

永远不要假设编程。

我所理解的是,除去我们能够想到的(也就是我们假设的)正常case外,应该尽量地考虑其他case,包括边界case和环境因素。恰恰大部分人(有些时候包括我自己)平常所进行的都是假设编程。

工程团队的一个现场:一个调控中心(称为C),多个采集站(称为S)。C和S是异地,中间有防火墙,数据通过VPN走公网。
当时是10个采集站。报告说有几个站数据一直时好时坏。

远程登录后,用procexp看了下,有几个站在进行疯狂的重连(用的是TCP协议)。一个链路建立没多久就被关闭,然后又新建一个链路。第一反应是感觉很蹊跷,想到的是会不会超时时间过短?在前面一个链路未完全建立的情况下超时了,导致主动断开又重连。

但是反过来又说不通,因为其他几个站的数据完好,且用的是同样的超时时间。(正因为上述的假设,没考虑到网络延时因素)后来用wireshark抓包看了下,有些情况下是采集站主动关闭链路,有些时候又不是。其中有个规律是,采集站主动关闭的前一刻,有个超大的数据包从C发往S。而这种情况在数据好的采集站中未发现过。

原因

经过后续的询问与调查,发现C与S数据未通的几个站的网络延时相对来说非常高,基本在150ms以上。可以确定是C这端的数据粘连成一个很大的数据包,这个很大的数据通过防火墙后,被防火墙丢弃了,因为数据包大小超过了MTU值。导致S端认为链路出现了状况,进行了主动关闭。
关于走VPN导致数据不稳定的情况,网上有很多帖子。情况基本一致。

解决方案

方法就是调整MTU的值。防火墙的设置基本是固定的,1500。所以能想到的是改变主机的MTU。
以下是在Windows平台的操作。
首先是找到发包相应的网络适配器名称:
netsh interface ipv4 show subinterface

找到名称后,进行修改:

1
netsh interface ipv4 set subinterface “网络A” mtu = 1400 store=persistent

总结

基于很多现实原因,测试环境无法和真实的生产环境一致,以及大部分时候开发人员的假设编程等情况。综合各种情况,在特定的场景中会一些我们无法预料的到情况。反过来看,从各种意外状况,需要反省,不管是测试用例,测试场景还是开发时的思维模式。因为这些都是正反馈,有反馈才能有目的的改善。

页阅读量:  ・  站访问量:  ・  站访客数: