这是一个我无法诊断的问题：
我们的用户主目录通过运行 Mac OS X 10.5.7 的 Apple XServe 通过 NFS 提供服务。通常，它们会导出到我们默认的办公室子网“lan”。最近，我一直在构建一个新的子网“farm”。“farm”上的计算机运行与“lan”上的计算机相同的操作系统（openSUSE 11.1 和 Gentoo），软件版本也相同。
问题是，当我的用户使用“农场”中的机器一段时间（5 分钟，有时 30 分钟，有时整整一个小时）时，NFS 安装似乎就挂起了。尝试ls对目录或尝试访问用户主目录的其他任何操作（例如登录等）都会卡住。从“挂起”的机器安装到其他 NFS 服务器似乎可以按预期工作。
客户端或服务器的日志中没有任何内容表明存在任何问题。相同类型的客户端在默认“lan”子网中工作正常。
我尝试了 NFS 服务器和客户端的各种不同配置（禁用/启用 kerberos、不同的挂载选项）但似乎没有任何区别。
我强烈怀疑这两个子网之间存在一些网络级问题，可能是防火墙/路由器造成的（OpenBSD 使用 pf 作为数据包过滤器）。两组机器之间的连接相当简单：
x serve --> switch --> router --> switch --> clients
我几乎不知道下一步该尝试什么调试方法，也不知道可能的解决方案是什么。从这一点开始，有什么想法可以解决这个问题吗？
更新：
仍然无法解决这个问题。我以为当我禁用scrub内部接口时，我已经将其扼杀在萌芽状态，但问题再次出现。奇怪的是，pf 似乎仍在修改一些数据包。
以下是一个示例对话农场VLAN 侧：
09:17:39.165860 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472382:2887472382(0) win 5840 <mss 1460,sackOK,timestamp 236992843 0,nop,wscale 6> (DF)
09:17:39.166124 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 43 win 65535 <nop,nop,timestamp 316702204 236992843> (DF)
09:17:54.164490 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472385:2887472385(0) win 5840 <mss 1460,sackOK,timestamp 236996593 0,nop,wscale 6> (DF)
09:17:54.164760 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: R 1441270809:1441270809(0) ack 43 win 65535 (DF)
09:17:54.164776 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: R 4243886205:4243886205(0) ack 46 win 0 (DF)
09:17:54.164989 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236996593 0,nop,wscale 6> (DF)
09:17:57.164066 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236997343 0,nop,wscale 6> (DF)
09:17:57.164330 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 49 win 65535 <nop,nop,timestamp 316702384 236997343> (DF)
09:18:03.163468 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236998843 0,nop,wscale 6> (DF)
09:18:03.163732 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 49 win 65535 <nop,nop,timestamp 316702444 236998843> (DF)
同样局域网VLAN：
09:17:39.165876 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472382:2887472382(0) win 5840 <mss 1460,sackOK,timestamp 236992843 0,nop,wscale 6> (DF)
09:17:39.166110 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 1 win 65535 <nop,nop,timestamp 316702204 236992843> (DF)
09:17:54.164505 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472385:2887472385(0) win 5840 <mss 1460,sackOK,timestamp 236996593 0,nop,wscale 6> (DF)
09:17:54.164740 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: R 1:1(0) ack 1 win 65535 (DF)
09:17:54.164745 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: R 2802615397:2802615397(0) ack 4 win 0 (DF)
09:17:54.165003 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236996593 0,nop,wscale 6> (DF)
09:17:54.165239 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: S 449458819:449458819(0) ack 2887472389 win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 316702354 236996593,sackOK,eol> (DF)
09:17:55.123665 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: S 449458819:449458819(0) ack 2887472389 win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 316702363 236996593,sackOK,eol> (DF)
09:17:57.124839 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: S 449458819:449458819(0) ack 2887472389 win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 316702383 236996593,sackOK,eol> (DF)
09:17:57.164082 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236997343 0,nop,wscale 6> (DF)
09:17:57.164316 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 1 win 65535 <nop,nop,timestamp 316702384 236997343> (DF)
09:18:01.126690 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: S 449458819:449458819(0) ack 2887472389 win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 316702423 236997343,sackOK,eol> (DF)
09:18:03.163483 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236998843 0,nop,wscale 6> (DF)
09:18:03.163717 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 1 win 65535 <nop,nop,timestamp 316702444 236998843> (DF)
我还应该提到，我们还有其他 NFS 流量通过同一台机器，但来自不同的 NFS 服务器。我们已经使用多年了，没有遇到任何问题。同样，这些 XServes 也一直在自己的子网上为 Linux 客户端提供 NFS 服务，并且将继续这样做。
答案1
只是想更新一下，以防有人遇到同样的问题。
本质上，这归结于 Pf 中的状态规则。默认情况下，Pf 会保留状态，并使用 S/SA 作为掩码。但是，OS X 上的 NFS 服务器实现似乎尝试使用一组非标准标志来启动与客户端的对话。这导致它失败，因为 Pf 只是丢弃了数据包。我通过 tcpdump lan 和 farm 接口来收集这些信息。在调整子网之间规则的状态标志后，连接已正确建立。
然而，Pf 似乎由于某种其他形式的内部规范化而继续过滤掉一些数据包，而且我尝试对选项进行任何调整都无法使其正常工作。
最后，我最终在文件服务器上创建了另一个接口并将其直接放置在农场 vlan 上，完全绕过了路由器。
答案2
我没有用过pf；但我认为它是第一个有状态的过滤器之一。也许它记录了“连接”并删除它们？
我会寻找任何依赖于状态的过滤规则。在 Linux 中，iptables过滤器通常以
ACCEPT all state RELATED,ESTABLISHED
因为这样它就不必在第一个数据包之后重新检查每个数据包的所有相关规则。但由于 NFS 是基于 UDP 的，并且不关心长时间（甚至数小时）的静默期，因此路由器可能会丢失状态ESTABLISHED，而新数据包从一开始就无效。
检查是否有任何“keepalive”参数来使客户端在一分钟左右的静默后发送心跳包。如果没有，请尝试通过 TCP 的 NFS。（它确实有心跳包）。
答案3
首先要确保防火墙确实是罪魁祸首。
为此，请将默认阻止规则设置为日志。在我的防火墙上，过滤规则顶部有两行：
block in log
block out log
等待 NFS 挂载再次挂起并检查您的日志接口：
tcpdump -eeni pflog0 'host <client ip> and host <nfs server ip>'
如果您发现这些数据包在防火墙处被阻止，请发布您的 pf.conf。如果没有，我们需要开始查看防火墙之外的情况。