從不同子網上的伺服器訪問時 NFS 掛載“掛起”
這是一個我無法診斷的問題：
我們的使用者主目錄通過 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 上，完全繞過路由器。