☰

使用 tcpdump 提取 NFS RPC 内容

tag-icon • tag-icon rhel nfs tcp tcpdump
使用 tcpdump 提取 NFS RPC 内容

相当简单的问题...我正在运行 tcpdump 并尝试分析服务器/客户端之间的 TCP 数据包的内容。我看到收到了“GETATTR”RPC，这太棒了！但是，我想知道正在为其创建 RPC 的文件。我假设这是在数据包内容中。当我将 tcpdump 打印为 ASCII 时。

From server:
tcpdump -vvv -s 200 port 2049 
14:45:38.408949 IP (tos 0x0, ttl 64, id 58408, offset 0, flags [DF], proto TCP (6), length 296)
myserver.nfs > myclient.2469839164: reply ok 240 getattr NON 3 ids 0/3 sz 0

这里和其他站点表明可以映射到文件名。也许它依赖于平台？我只是想确保我缺少 tcpdump 的明显选项。

我正在运行 RH5 - 内核 2.6.32-279.el6.x86_64

答案1

你可以看一下nfstrace工具在 github 上：（https://github.com/epam/nfstrace）。它跟踪所有捕获的 NFSv3/NFSv4 过程。

答案2

好吧，所以我想我设法找到了“解决方法”。您将无法使用 NFSv3 获取文件名，但可以获取 inode。

使用 Wireshark，

转到编辑 -> 首选项 -> 协议 -> NFS -> 选中所有框并设置“将 nfs 句柄解码为：KNFSD_LE。

保存。现在通过 NFS 协议进行捕获和过滤。

搜索数据包GETATTR Reply (Call in #) Regular file mode: ???.

打开这个压缩包并展开以下内容：

Network File System -> obj_attributes

检查值文件编号，这将是文件的索引节点号。

在服务器上转到 nfs 共享并

find . -inum inode

使用 NFSv4，您可以直接看到带有文件名的调用。

答案3

RedHat 的（和任何）NFS v3 实现确实会在大多数操作中使用文件句柄，而不是名称。如果您没有看到wireshark的句柄，请继续展开数据包的各个部分，直到找到它。有些数据包将包含目标对象及其父目录的句柄，因此请仔细查看。在 NFS 调用上，wireshark 的摘要“信息”行通常会显示一个哈希值，它是句柄的缩小版本。问题是，如果没有“其他信息”或访问相关机器（例如，如果您正在分析其他人的数据包），文件句柄就不是一个非常有用的信息。

您可以搜索之前出现的数据包以获取句柄或其哈希值，并希望您可以找到存在相同文件句柄的某个位置，并将其与文件名关联起来。例如，查找将产生包含文件句柄的回复。或者创建操作的回复将显示刚刚创建的对象的句柄。或者，如果存在“readdirplus”序列并且数据包未被截断，您可能可以从那里获取信息。

或者当然，在许多情况下，nfs 挂载已经使用了一段时间，导致客户端“学习”与名称相关的句柄的原始调用可能早已不复存在。因此，如果您能够控制和计划问题重现和数据包收集的步骤，那么在不存在 nfs 挂载的情况下开始可能会很有帮助。然后启动tcpdump。然后进行挂载。然后重现nfs问题。这样，您就一定会捕获将所有文件句柄与文件名连接起来的数据包。

相关内容