Wireshark/tcpdump 抓到的数据包可信吗?


问题的表面现象

问题的背景是这样的:

一个应用程序监听某端口的 UDP 包,发送者发送的 UDP 包比较大,有 65535 个字节。显然,发送者的 UDP 包在经过 IP 层时,会被拆分层多个 1460 字节长度的 IP 分片,经过网络传输之后到达接收方,接收方的网卡收到包后,在内核协议栈的 IP 层又将分片重新组合,生成大的 UDP 包给应用程序。

正常情况下,应用程序能准确无误的收到大 UDP 包,偶尔系统网络流量十分巨大的时候,会丢个别 UDP 包 ——这都在允许范围内。

突然有一天,即便网络流量不是很大的时候,UDP 包的丢包十分严重,应用程序几乎收不到任何数据包。

开始 debug

遇到这样的问题,第一反应有两种可能:

  • 网络不通,数据包没送到网卡。
  • 个别 IP 分片在传输中丢失了,导致接收方无法重组成完整的 UDP 包。

于是用 tcpdump 在 interface eth0 上抓包,出乎意料的是,抓到的 pcap 有完整的 IP 分片。用 wireshark 打开 pcap,wireshark 会自动把 IP 分片重组成 UDP 数据包,检查这个 UDP 包,数据完整无误

那么现在能断定是应用程序自己出了问题吗?

因为一直以来一个根深蒂固的想法是:既然抓到的 pcap 准确无误,所以数据包已经送到了接收方了,linux 内核只要把分片重组一下交给应用层就可以了,这个过程一般不会出错,所以应用程序没收到只能怪它自己咯?

实际导致问题的原因

最终查明的原因是这台 linux 系统上有两个参数被修改了,当 IP 分片数量过大时,内核中分配给重组的缓冲区已满,导致之后的分片都被丢弃了。

因为 CVE-2018-5390 和 CVE-2018-5391,黑客可以用带有随机偏移量的 IP 分片引发 DoS 攻击(详细见参考资料 1)

RedHat 给无法立刻升级内核的用户的临时解决方案是,减小 net.ipv4.ipfrag_high_thresh 的值,从 4MB 减小到 256 KB;net.ipv4.ipfrag_low_thresh, 从 3MB 到 192 KB。

因为值改动的比较大,所以一些潜在的问题就暴露了出来。

可以用 netstat -s 命令输出一些统计信息,其中 IP Fragment 相关字段会有明显的增长。

本文的标题《tcpdump 抓到的包可信吗?》 似乎有一些标题党,其实在这里我想表达的意思是:能否根据 tcpdump 抓到的 pcap 文件判断一个数据包是否被接收方收到,或者是否被应用程序收到? 之前我想当然的会回答 “是”,现在看来答案是 “否”。

其实平时在使用 tcpdump 时,命令行的输出已经提示了我们有多少包被 kernel 丢弃了:

# tcpdump -ieth0 -s0 -wt.pcap
tcpdump: listening on wlp3s0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C2 packets captured
4 packets received by filter
0 packets dropped by kernel

重新认识 tcpdump

现在回过头来再思考 tcpdump 和内核协议栈的关系。很显然,之前我的理解是错误的,现在根据看到的现象猜测内部实现,那么 tcpdump 的抓包应该是从驱动直接拷贝的,与内核的 TCP/IP 协议栈是完全独立的。

在上网搜索了一些资料后,证实了我的想法。首先来看一张架构图:

aho.go

libpcap 使用的是一种称为设备层的包接口(packet interface on device level)的技术。 使用这种技术,应用程序可以直接读写内核驱动层面的数据,而不经过完整的 Linux 网络协议栈。所以抓包大致是这样工作的:

  1. 网卡加载初始化驱动;
  2. 报文通过网络到达网卡;
  3. DMA 将报文复制到内核内存(Ring Buffer)中;
  4. 复制完毕后,网卡产生硬中断通知系统;
  5. NAPI 处理内核报文;
  6. libpcap 将获取的原始报文复制一份;
  7. 使用设置的过滤器对报文进行过滤,并保存至缓存中;
  8. 应用程序(Tcpdump、Wireshark)读取缓存中的数据。

PF_PACKET 和 PF_RING

抓包会影响系统的网络性能吗? 当然会。

可以做一个非常简单的实验证明这一点:

  • 局域网内 wget 下载一个 500MB 大文件,记录下载速度。
  • 局域网内 wget 下载同一个文件,开启 tcpdump 抓包,记录下载速度。

在我的测试中,两者差别是很明显的。

所以,当你的系统下载速度已经达到 50MB/s,你觉得不够,应该至少 100MB/s,这个时候开启 tcpdump 企图抓包分析原因是错误的,因为 tcpdump 本身会影响你的网络性能。

再次回到上面的 tcpdump 架构图,可以看出在内核层使用的是 PF_PACKET,而现在 linux 已经自带了更加先进的 PF_RING 专门针对大流量的场景。有关 PF_RING 下次写一篇博客介绍一下。

tcpdump 与 iptables

首先,tcpdump 直接从网络驱动层面抓取输入的数据,不经过任何 Linux 网络协议栈,

iptables 依赖 netfilter 模块,后者工作在 Linux 网络协议栈中;

iptables 的入栈的策略不会影响到 tcpdump 抓取;而 iptables 的出栈策略会影响数据包发送到网络驱动层面,因此,出栈策略会影响到 tcpdump 的抓取。

总结下来就是:

  • tcpdump 可以抓取到被 iptables 在 INPUT 链上 DROP 掉的数据包;
  • tcpdump 不能抓取到被 iptables 在 OUTPUT 链上 DROP 掉的数据包

参考资料

前一篇        返回首页        后一篇

| Copyright 2009 - 2018 by Runz |