记录一次网络连通性排查
  

新手172766 1393

本帖最后由 静态路由 于 2019-9-21 12:48 编辑


看到论坛有活动,那就贴上上周的网络连通性排查吧

99075d75e7f8a01ed.png
      精简的网络拓扑图,总体差不多这个架构。现在有个需求,服务器A172.X.X.X通过互联网访问某个目标公网IP103.X.X.X,HTTPS协议,443端口。出口有三条链路,配置策略路由选择电信某线路。配置完毕后,发现服务器A到目标端口不通,记录下排查的过程。

      第一步:检查防火墙策略匹配
      外网用的深信服的防火墙,发现策略有27条匹配记录,说明数据包已经达到防火墙,网络设备配置应该没问题。
269055d75e935b01f6.png

      第二步:外网防火墙抓包
      在PC3位置,抓取目标地址外网数据包,分析故障,抓包情况如下图。
      建立握手的时候,SYN发出去了,目标IP也恢复了SYN,ACK。这个时候还差服务器A再回复一个ACK就能建立连接了。偏偏缺没有这个ACK,自然网络现象是不通的。后面又大量的SYN重传,这说明服务器A没收到目标IP的SYN,ACK,于是一直在重传。
     在服务器A之前还有个核心交换机,我们在核心交换机上上,利用PC2抓包发现同样的情况。
这说明什么了?说明服务器A的SYN已经通过中间的网络设备,达到目标IP了。目标IP回复的SYN,ACK也已经到最后的一个网络设备,即将传递给服务器A了,但是莫名的原因服务器A并给syn,ack回应ACK。
      这个时候问题的最后一步也就自然的在服务器A上,负责网络的我可以甩锅咯。
    628475d75e9be7e006.png
     第三步:抓包服务器A
      联系系统管理员,让他在服务器A的对应网卡tcpdump一下,解析tcpdump。发现是一样的情况。
一样的,SYN从网卡发出去了,SYN,ACK也从网卡收到了,就是没有在回应了。为什么了,肯定是某种原因丢弃了。
88455d75e9eaf1399.png

      第四步:确定问题
     根据上述分析, 猜想是服务器上的iptables,规则导致进来的数据包丢弃了,系统管理员检查iptables后,发现确实没有配置有状态的规则,配置正确后,网络访问正常。 这里我就不贴iptables的规则了。


      总结:判断网络故障我个人认为比较重要的是要熟悉数据流的走向,进而在关键节点逐一抓包定位,确定问题出现的节点。分析出到底是策略,还是路由或者其他的原因导致,对症下药即可。
      第二篇关于抓包定位的类似文章《AF安全模块引发的思考》https://bbs.sangfor.com.cn/forum.php?mod=viewthread&tid=83719   ~

喜欢这篇文章吗?喜欢就给楼主打赏吧!

打赏
8人已打赏

sailyang 发表于 2019-9-10 09:49
  

非常详细的分享,楼主技术了得,按照数据流抓包定位问题,排错思路清晰
Sangfor_95899 发表于 2019-9-12 18:17
  
感谢楼主分享,从数据包分析看,这真的是一次非常典型的数据包tcp协议分享,可以作为教材出现。
网络运维工程师的日常就是不管遇到什么样的问题,只要和网络有关系,一定是第一时间救火的人。
通过确凿的证据定位到是业务系统问题,非常强大。
分享数据包可以说是基本功了,希望我们社区的每一个工程师都能沉下心,好好学习下。
楼主可以抽空分享下数据包的分享经验
droprains 发表于 2019-9-9 17:29
  
好东西,谢谢分享,学习了
Sangfor_闪电回_朱丽 发表于 2019-9-10 09:24
  
非常棒的分享,楼主对数据流程处理很熟悉,遇到问题先不慌,按照数据流抓包定位问题,排错思路清晰!点赞
ITapple 发表于 2019-9-10 09:25
  
非常详细的分享,楼主技术了得,排错四维清晰
誓言落寞了年华 发表于 2019-9-10 10:14
  
排错思路清晰
糊糊 发表于 2019-9-10 11:45
  
学习了 学习了
一条咸鱼。 发表于 2019-9-10 18:38
  

学习了 学习了
hell—123456 发表于 2019-9-11 10:04
  
很好奇  上面那个抓包工具不是WIRESHARK,是什么软件呢
好心情能长寿 发表于 2019-9-11 20:59
  
很有用的排查案例,思路很清晰。