一个DNS解析引发的“血案”

简介: 在复杂网络环境中,面对问题时,我们需要借助数据包分析技术来定位和解决。虽然没有固定的分析流程,但通常会通过排除法,从网络层、设备层和应用层指标入手。

面对越来越复杂的网络环境,每天发生着数以万亿的数据交互,一旦出现问题我们就需要快速去定位解决,那么我们就必须储备丰富的知识,利用手头各种工具帮助我们来分析问题。

有时应用日志、网管平台等看起来一切都没有异常,分析变得一筹莫展,这是就需要使用数据包分析技术,来深入探索每一个TCP连接及上层应用,最终来定位问题。

数据包分析的切入点很大程度上取决于具体的问题现象,也就是说并没有一个绝对固定不变的流程。

但总体上我们可以用排除法判断在哪些层次没有发生问题,快速把分析的重点找到:

• 网络层指标是相对通用化的;

• 多点对比分析常常用于网络设备层设备故障排查;

• 应用层指标则是专用的,应对于各种业务应用;

• 通常我们利用通用的TCP模型,分析其通信过程和具体行为;

• 正常/异常时的对比是分析行为的有效方法;


下面我们就用一个真实的案例,来体验下数据包分析的乐趣。


问题描述

1、某年7月28日X行新ETC网关上线, ETC地址10.*.*16在经过防火墙后访问三方系统时,三次握手建立正常,但发送数据时对方无法收到,且ETC网关这边收到报错信息为Empty replay for Server。

2、当ETC网关可以正常访问三方系统时,但是整个ETC业务访问过程特别慢大概有10-15s延迟,严重影响使用。

有了明确的问题,我们在分析时候首先要了解整个访问的逻辑过程及物理拓扑,切记这是做数据包分析的先决条件,这会涉及到你取数据包的位置,至关重要

环境描述

整个业务在行内访问流程,ESB10.*.*.83先访问ETC网关10.*.*.16:7550,ETC网关再访问三方系统172.*.*.248:2000。路由器上将172.*.*.248映射为172.*.*.155。

如下图所示,在采集点1、2、3、4分别部署了数据包捕获点,由数据包采集系统统一管理。

分析问题1

1)首先因为10.*.*.16是F5的虚拟地址,为了排除F5的影响,在ETC服务器(10.*.*.14)上将出去的路由手动指向防火墙FW2,然后在ETC服务器上发送一个Post请求172.*.*.248:2000,其中172.*.*.248 做NAT后的地址是172. ..155。使用tcpdump在10.*.*.14上抓包如下图:

可以看到10.*.*.14与172.*.*.248 三次握手正常建立,10.*.*.14发送了一个Post请求,172.*.*.248也对这个包,进行了确认,但没有发送响应,等到了60s超时后,248主动断开了连接。


2)从ETC服务器上可以看到Post请求发了出去,但对方没有收到,所以怀疑可能中间环节把请求丢了,即需要FW2前后的数据包进行比对,故在抓取采集3和采集点4关于ETC网关和三方系统交互的数据包,如下图所示:

从生存时间和MAC地址上可以看到,在同一个TCP流中,11号包是FW2前面的SYN包,12号是FW2后面的SYN包,三次握手之后,17号报是FW2前面的请求,18号是FW2回复的ACK包,60s之后因为连接超时而关闭。


从而可以判断出请求在过防火墙FW2时被丢弃了,需要检查下防火墙的配置


3)现象是防火墙可以正常放行三次握手,但http层的数据被丢弃。

通过排查和咨询之后确定是由于ETC访问外部的地址用的2000端口,而防火墙ASA会把访问外部 tcp 2000端口的流量当成了skinny协议的流量,而实际是http流量,两种协议流量的数据结构肯定不相同,而当TCP三次握手完成后,后面的http应用的包被当作skinny协议的流量被丢弃。


Skinny协议,即sccp,是思科专有的VOIP协议,用于连接Cisco VoIP电话到Cisco 呼叫管理服务器。此外通过Wireshark也可以看到2000端口被识别成Cisco-SCCP。

解决方法有两种

1、更换目的地址使用的端口号。

2、只需防火墙将默认的TCP 2000的skinny协议审查取消即可。

      policy-map global_policy

      class inspection_default

      no inspect skinny


分析问题2

1)首先根据ETC整个业务访问的流程先分成两段来看,业务一段是ESB<——>ETC网关,业务二段是ETC网关<——>三方系统

先抓取业务二段(采集点3和采集点4)的数据包过滤相关地址,如图所示可以看到从三次握手到服务器应用处理时间间隔都很小,在15s后ETC网关发送FIN主动请求断开连接。

2)同理抓取业务一段(采集点1和采集点2)的数据包过滤相关地址,如图所示可以看到从三次握手和ESB发送请求间隔时间都很短,但从ETC网关发送给ESB的响应间隔了15S左右,怀疑ETC网关在处理响应时比较慢或者发送有延迟。

3)由于在ESB和ETC网关之间有防火墙FW1,为了排除是否由防火墙造成的延迟,在采集点1和采集点2中抓取同一会话进行对比,发现防火墙前后ETC网关响应的间隔时间差值2-3ms,故排除防火墙问题。

4)在数据包采集系统抓取采集点2和采集点3同一时间段的流量,因为从ESB到ETC网关发送的是XML数据,而从ETC网关到三方系统发送的是http数据,只能根据发送字段的相关信息来把采集点2和采集点3的同一笔交易进行关联,发现ETC网关在同三方系统开始建立三次握手的时间与ESB发送完请求的时间之间刚好差了15s左右。

5)同时测试在ETC网关上telnet 自己的业务端口7550,发现也比较慢。至此,可以判断大概原因是ETC网关建立连接有延迟,后经查证行内系统都需要经过域名反解析,而ETC网关上配置的主域名服务器解析出了问题,每次先使用主DNS查询IP地址对应的PTR记录,当超时时间(可能是5s)内还没有收到回复,就会再查询一次,如果第二次超时还没有回复,就会查询备用的DNS服务器。


通过抓取ETC网关的数据包也可以验证,每次会先查询主DNS服务器10.*.*.10 ,超时时间为5s,连续超时之后再查询备DNS192.*.*.42,返回的信息是No such name。接着才开始和对端建立连接。

解决方案:在ETC网关服务器上将故障的主DNS服务器摘除,业务访问回复正常。


案例总结

1、分析数据包问题时最好多用几个分析软件,抓住每一个细节,比如wireshark、dali、sniffer可以配合使用,本案例中wireshark中可以把2000端口解析为cisco-sccp协议,可以帮助排查问题。

2、在抓取数据包时,宜多不宜少,多了可以通过过滤条件来导出特定分组,但少了就会忽略掉一些关键信息。


回顾和思考是快速增长经验的法宝

  • 在现场做故障诊断,往往受到很多外界因素影响;
  • 每个案例分析过后再回顾,一定可以发现并归纳出一些技术、技巧以及思路上的优化方法;
  • 行业化的应用模式具有通用性,特别是金融行业,应用通信模式有很多相似性;
  • 只有类似的Case,没有一模一样的Case,在回顾和思考中深入理解知识点和其应用模式;
  • 经验可贵,但不是全部,走投无路的时候要放弃经验。
相关文章
|
13天前
|
缓存 网络协议 安全
【计算巢】DNS 解析过程详解:域名如何转换为 IP 地址
【5月更文挑战第31天】DNS(域名系统)将人类可读的域名转换为IP地址,涉及本地DNS缓存、层次化DNS服务器系统,包括根DNS、顶级域名DNS和权威DNS。当查询域名时,通过DNS服务器间的交互找到对应IP并返回给浏览器。Python示例展示了DNS查询过程。尽管DNS面临安全挑战,如欺骗和缓存中毒,采取安全措施可确保其稳定性和安全性。它是互联网的重要基础,连接域名与IP,支持便捷的网络访问。
|
15天前
|
域名解析 缓存 网络协议
【域名解析DNS专栏】IPv6与DNS:兼容性挑战与解决方案
【5月更文挑战第29天】随着IPv6逐渐成为互联网主流,DNS面临兼容性挑战,包括解析机制差异、资源记录类型扩展和查询流程优化。为解决这些问题,可采取升级DNS系统以支持IPv6、部署双栈DNS服务和优化DNS缓存策略。通过这些措施,可确保IPv6环境下的域名解析顺利进行。
|
13天前
|
域名解析 缓存 网络协议
|
13天前
|
JSON 监控 网络协议
局域网管理软件的DNS解析代码实践
本文介绍了如何使用Python实现DNS解析,通过示例代码展示了构建和解析DNS请求的过程。此外,还讨论了网络流量监控,利用psutil库获取网络接口的流量数据。最后,探讨了自动将监控数据提交到网站的方法,使用requests库将网络数据以JSON格式发送到指定网站。这些自动化工具提升了局域网管理效率和安全性。
398 1
|
14天前
|
域名解析 网络协议 安全
【域名解析DNS专栏】未来趋势:DNS解析技术的新发展与挑战
【5月更文挑战第30天】随着AI和物联网的发展,DNS解析正向智能化和安全增强迈进,利用大数据和DNSSEC保障速度与安全。同时,匿名解析技术将提升用户隐私保护。然而,面对复杂网络环境、性能与延迟挑战及国际标准兼容性问题,DNS技术需不断创新以应对未来挑战。Python示例展示了DNSSEC验证查询。DNS解析的持续进化对互联网的稳定和隐私至关重要。
|
14天前
|
域名解析 负载均衡 网络协议
【域名解析DNS专栏】从DNS解析看全球互联网基础设施布局
【5月更文挑战第30天】本文探讨了DNS解析在全球互联网基础设施布局中的关键作用。DNS负责将域名转换为IP地址,其高效、可靠的运行依赖于全球分布式、负载均衡且具有冗余备份的服务器网络。通过Python代码示例展示了DNS查询过程,强调DNS服务对用户体验的影响,指出合理布局互联网基础设施的重要性。
|
14天前
|
域名解析 缓存 负载均衡
【域名解析DNS专栏】域名解析在CDN服务中的应用与优化
【5月更文挑战第30天】本文探讨了域名解析在CDN服务中的重要性,强调其对访问速度和稳定性的影响。文中提出了三种优化方法:使用智能解析以动态选择最佳节点,配置负载均衡保证服务稳定,以及利用DNS缓存提升访问速度。通过Python代码示例展示了基本的DNS解析过程,结论指出优化域名解析对于提升网站性能至关重要。
|
15天前
|
存储 域名解析 缓存
【域名解析DNS专栏】DNS解析中的分布式哈希表(DHT)应用
【5月更文挑战第29天】为解决DNS性能瓶颈和单点故障问题,分布式哈希表(DHT)技术被引入DNS解析,以实现分布式存储和检索,提高可扩展性和鲁棒性。DHT应用于DNS解析,包括负载均衡与数据分发、缓存优化和安全性增强。示例代码展示了DHT基本概念,但实际应用更复杂,需考虑更多因素。
|
15天前
|
域名解析 Kubernetes 网络协议
【域名解析DNS专栏】云原生环境下的DNS服务:Kubernetes中的DNS解析
【5月更文挑战第29天】本文探讨了Kubernetes中的DNS解析机制,解释了DNS如何将服务名转换为网络地址,促进集群内服务通信。Kubernetes使用kube-dns或CoreDNS作为内置DNS服务器,每个Service自动分配Cluster IP和DNS条目。通过示例展示了创建Service和使用DNS访问的流程,并提出了优化DNS解析的策略,包括使用高性能DNS解析器、启用DNS缓存及监控日志,以实现更高效、可靠的DNS服务。
|
16天前
|
负载均衡 网络协议 容灾
【飞天技术沙龙】云解析DNS上海站《多云+IDC融合场景下的DNS最佳实践》圆满落幕
【飞天技术沙龙】云解析DNS上海站《多云+IDC融合场景下的DNS最佳实践》圆满落幕

推荐镜像

更多