这是一个我无法诊断的问题：
我们的用户主目录通过 NFS 从运行 Mac OS X 10.5.7 的 Apple XServe 提供。通常它们被导出到我们的默认办公室子网“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)
在lan 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 服务很长时间了，并且会继续这样做。
只是想更新一下，以防有人遇到同样的问题。
从本质上讲，它归结为 Pf 中的州规则。默认情况下，Pf 保持状态，并使用 S/SA 作为掩码。然而，似乎 OS X 上的 NFS 服务器实现尝试使用一组非标准标志开始与客户端的对话。这导致它失败，因为 Pf 只是丢弃了数据包。我通过 tcpdumping lan 和 farm 接口收集了这些信息。在调整子网之间规则的状态标志后，连接已正确建立。
但是，由于某种其他形式的内部规范化，Pf 似乎继续过滤掉一些数据包，并且我尝试过的任何调整选项都无法使其正常工作。
最后，我最终在文件服务器上创建了另一个接口，并将其直接放在农场 vlan 上，完全绕过路由器。
我没用过
pf；但我认为这是最早的全状态过滤器之一。也许它正在考虑“连接”并丢弃它们？我会寻找任何与状态相关的过滤规则。在 Linux
iptables中，过滤器通常以因为这样它就不必在第一个数据包之后重新检查每个数据包的所有相关规则。但是由于 NFS 是基于 UDP 的，并且不关心长时间（甚至数小时）的静默期，因此路由器可能正在丢失
ESTABLISHED状态，并且新数据包在开始时无效。检查是否有任何“keepalive”参数使客户端在一分钟左右的沉默后发送心跳数据包。如果没有，请尝试基于 TCP 的 NFS。（确实有心跳包）。
首先要做的是确保防火墙实际上是罪魁祸首。
为此，请将您的默认阻止规则设置为记录。在我的防火墙上，这是过滤规则顶部的两行：
等待 NFS 挂载再次挂起并检查您的日志界面：
如果您看到这些数据包在防火墙处被阻止，请发布您的 pf.conf。如果没有，我们需要开始超越防火墙。