从不同子网上的服务器访问时，NFS 挂载“挂起”

Question

这是一个我无法诊断的问题：

我们的用户主目录由运行 Mac OS X 10.5.7 的 Apple XServe 通过 NFS 提供服务。通常，它们会导出到我们的默认办公室子网“lan”。最近我一直在构建一个新的子网，“农场”。“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)

在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 服务，并将继续这样做。

Answer 1

只是想更新一下，以防有人遇到同样的问题。

从本质上讲，它归结为 Pf 中的州规则。默认情况下，Pf 保持状态，并使用 S/SA 作为掩码。但是，似乎 OS X 上的 NFS 服务器实现尝试使用一组非标准标志开始与客户端的对话。这导致它失败，因为 Pf 只是丢弃了数据包。我通过 tcpdumping lan 和 farm 接口收集到了这个。调整子网之间规则的状态标志后，连接已正确建立。

然而，由于某种其他形式的内部规范化，似乎 Pf 继续过滤掉一些数据包，并且我尝试过的任何调整选项都无法使其工作。

最后，我最终在文件服务器上创建了另一个接口并将其直接放置在场 vlan 上，完全绕过了路由器。