一个 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，在回顾和思考中深入理解知识点和其应用模式；

• 经验可贵，但不是全部，走投无路的时候要放弃经验。