linux nfs configuration and access

要配置linux nfs iptables ,必須知道nfs的工作原理，下面是nfs相關知識：

1.1.1  NFS簡介

　　NFS由SUN公司開發，目前已經成為檔案服務的一種標準（RFC1904，RFC1813）。其最大功能是可以通過網路讓不同作業系統的電腦可以共用資料，所以也可以將其看做是一台檔案伺服器，1-1所示。NFS提供了除Samba之外，Windows與Linux及UNIX與Linux之間通訊的方法。

    

    
    　圖1-1  NFS可作為檔案伺服器

　　用戶端PC可以掛載NFS伺服器所提供的目錄並且掛載之後這個目錄看起來如同本地的磁碟分割一樣，可以使用cp、cd、mv、rm及df等與磁碟相關的命令。NFS有屬於自己的協議與使用的連接埠號碼，但是在傳送資料或者其他相關資訊時候，NFS伺服器使用一個稱為"遠端程序呼叫"（Remote Procedure Call，RPC）的協議來協助NFS伺服器本身的運行。

　　1.1.2  為何使用NFS

　　NFS的目標是使電腦共用資源，在其發展過程中（即20世紀80年代），電腦工業飛速發展，廉價CPU及用戶端/伺服器技術促進了分散式運算環境的發展。然而當處理器價格下降時，大容量的儲存系統相對而言價格仍居高不下。因此必須採用某種機制在充分發揮單個處理器效能的同時使電腦可共用儲存資源和資料，於是NFS應運而生。

　　1.1.3  NFS協議

　　使用NFS，用戶端可以透明地訪問伺服器中的檔案系統，這不同於提供檔案傳輸的FTP協議。FTP會產生檔案一個完整的副本；NFS只訪問一個進程引用檔案部分，並且一個目的就是使得這種訪問透明。這就意味著任何能夠訪問一個本地檔案的用戶端程式不需要做任何修改，就應該能夠訪問一個NFS檔案。

　　NFS是一個使用SunRPC構造的用戶端/伺服器應用程式，其用戶端通過向一台NFS伺服器發送RPC請求來訪問其中的檔案。儘管這一工作可以使用一般的使用者進程來實現，即NFS用戶端可以是一個使用者進程，對伺服器進行顯式調用，而伺服器也可以是一個使用者進程。因為兩個理由，NFS一般不這樣實現。首先訪問一個NFS檔案必須對用戶端透明，因此NFS的用戶端調用是由用戶端作業系統代表使用者進程來完成的；其次，出於效率的考慮，NFS伺服器在伺服器作業系統中實現。如果NFS伺服器是一個使用者進程，每個用戶端請求和伺服器應答（包括讀和寫的資料）將不得不在核心和使用者進程之間進行切換，這個代價太大。第3版的NFS協議在1993年發布，圖1-2所示為一個NFS用戶端和一台NFS伺服器的典型結構。

  

    
    圖1-2  NFS用戶端和NFS伺服器的典型結構

　　（1）訪問一個本地檔案還是一個NFS檔案對於用戶端來說是透明的，當檔案被開啟時，由核心決定這一點。檔案被開啟之後，核心將本地檔案的所有引用傳遞給名為"本地檔案訪問"的框中，而將一個NFS檔案的所有引用傳遞給名為"NFS用戶端"的框中。

　　（2）NFS用戶端通過其TCP/IP模組向NFS伺服器發送RPC請求，NFS主要使用UDP，最新的實現也可以使用TCP。

　　（3）NFS伺服器在連接埠2049接收作為UDP資料包的用戶端請求，儘管NFS可以被實現為使用連接埠映射器，允許伺服器使用一個臨時連接埠，但是大多數實現都是直接指定UDP連接埠2049。

　　（4）當NFS伺服器收到一個用戶端請求時，它將這個請求傳遞給本地檔案訪問常式，然後訪問伺服器主機上的一個本地的磁碟檔案。

　　（5）NFS伺服器需要花一定的時間來處理一個用戶端的請求，訪問本地檔案系統一般也需要一部分時間。在這段時間間隔內，伺服器不應該阻止其他用戶端請求。為了實現這一功能，大多數的NFS伺服器都是多線程的--伺服器的核心中實際上有多個NFS伺服器在NFS本身的加鎖管理程式中運行，具體實現依賴於不同的作業系統。既然大多數UNIX核心不是多線程的，一個共同的技術就是啟動一個使用者進程（常被稱為"nfsd"）的多個執行個體。這個執行個體執行一個系統調用，使其作為一個核心進程保留在作業系統的核心中。

　　（6）在用戶端主機上，NFS用戶端需要花一定的時間來處理一個使用者進程的請求。NFS用戶端向伺服器主機發出一個RPC調用，然後等待伺服器的應答。為了給使用NFS的用戶端主機上的使用者進程提供更多的並發性，在用戶端核心中一般運行著多個NFS用戶端，同樣具體實現也依賴於作業系統。

    1.1.4  RPC

　　因為NFS支援的功能相當多，而不同的功能都會使用不同的程式來啟動。每啟動一個功能就會啟用一些連接埠來傳輸資料，因此NFS的功能所對應的連接埠才沒有固定，而是採用隨機取用一些未被使用的小於724的連接埠來作為傳輸之用。但如此一來又造成用戶端要串連伺服器時的困擾，因為用戶端要知道伺服器端的相關連接埠才能夠聯機，此時我們需要遠端程序呼叫（RPC）的服務。RPC最主要的功能就是指定每個NFS功能所對應的連接埠號碼，並且回報給用戶端，讓用戶端可以串連到正確的連接埠上。當伺服器在啟動NFS時會隨機選用數個連接埠，並主動地向RPC註冊。因此RPC可以知道每個連接埠對應的NFS功能。然後RPC固定使用連接埠111來監聽用戶端的請求並回報用戶端正確的連接埠，所以可以讓NFS的啟動更為容易。注意，啟動NFS之前，要先啟動RPC；否則NFS會無法向RPC註冊。另外，重新啟動RPC時原本註冊的資料會不見，因此RPC重新啟動後它管理的所有程式都需要重新啟動以重新向RPC註冊。

　　當用戶端有NFS檔案要存取請求時，它如何向伺服器端要求資料？

　　（1）用戶端會向伺服器端的RPC（port 111）發出NFS檔案存取功能的詢問請求。

　　（2）伺服器端找到對應的登入的NFS daemon連接埠後會回報給用戶端。

　　（3）用戶端瞭解正確的連接埠後，就可以直接與NFS守護進程來聯機。

　　由於NFS的各項功能都必須要向RPC註冊，因此RPC才能瞭解NFS服務的各項功能的port number、PID和NFS在主機所監聽的IP等，而用戶端才能夠通過RPC的詢問找到正確對應的連接埠。即NFS必須要有RPC存在時才能成功地提供服務，因此我們稱NFS為RPC Server的一種。事實上，有很多這樣的伺服器都向RPC註冊。例如，NIS（Network Information Service）也是RPC Server的一種。所以1-3所示，不論是用戶端還是伺服器端，要使用NFS都需要啟動RPC。

    
      

    
    圖1-3  NFS與RPC服務及作業系統的相關性

　　NFS協議從誕生到現在為止，已經有多個版本，如NFS V2（rfc794）及NFS V3（rfc1813）（最新的版本是V4（rfc307））。最早，SUN公司曾將NFS V2設計為只使用UDP，主要原因是當時機器的記憶體、網路速度和CPU的影響，不得不選擇對機器負擔較輕的方式。而到了NFS V3，SUN公司選擇了TCP作為預設的傳輸方式。V3相對V2的主要區別如下。

　　（1）檔案尺寸。

　　V2最大隻支援32位的檔案大小（4 GB），而V3新增加了支援64位檔案大小的技術。

　　（2）檔案傳輸尺寸。

　　V3沒有限定傳輸尺寸，V2最多隻能設定為8 KB，可以使用-rsize and -wsize來設定。

　　（3）返回完整的資訊。

　　V3增加和完善了返回錯誤和成功資訊，對於伺服器的設定和管理能帶來很大好處。

　　（4）增加了對TCP傳輸協議的支援。

　　V2隻提供了對UDP的支援，在一些高要求的網路環境中有很大限制；V3增加了對TCP的支援。UDP有著傳輸速度快且非串連傳輸的便捷特性，但是在傳輸上沒有TCP穩定。當網路不穩定或者駭客入侵時很容易使NFS的效能大幅度降低，甚至使網路癱瘓。所以對於不同情況，網路要有針對性地選擇傳輸協議。NFS的預設傳輸協議是UDP，然而RHEL 4.0核心提供了對通過TCP的NFS的支援。要通過TCP來使用NFS，在用戶端系統上掛載NFS匯出的檔案系統時包括一個"-o tcp"選項。使用TCP的優點和缺點如下。

　　- 被提高了的串連持久性，因此獲得的NFS stale file handles訊息就會較少。

　　- 載量較大的網路的效能會有所提高，因為TCP確認每個分組，而UDP只在完成時才確認。

　　- TCP具有擁塞控制技術（UDP根本沒有），在一個擁塞情況嚴重的網路上，UDP分組是被首先撤銷的類型。使用UDP意味著，如果NFS正在寫入資料（單元為8 KB的塊），所有這8 KB資料都需要被重新傳輸。由於TCP的可靠性，8 KB資料中只有一部分需要重新傳輸。

　　- 錯誤偵測。當TCP串連中斷（由於伺服器停止），用戶端就會停止發送資料而開始重新串連。UDP是不需連線的，使用它的用戶端就會繼續給網路發送資料直到伺服器重新上線為止。

　　- TCP的費用在效能方面的提高並不顯著。

　　（5）非同步寫入特性。

　　（6）改進了伺服器的mount效能。

　　（7）有更好的I/O寫效能。

　　（8）更強的網路運行效能，使得網路運行更為有效。

　　（9）更強的災難恢複功能。

　　在Linux上，UDP是預設使用的協議。作為伺服器別無選擇。但作為用戶端，可以使用TCP和其他使用TCP的UNIX NFS伺服器互聯。在區域網路中使用UDP較好，因為區域網路有比較穩定的網路保證。使用UDP可以帶來更好的效能，Linux預設使用V2，但是也可以通過mount option的nfsvers=n選擇。NFS使用TCP/IP提供的協議和服務運行於OSI層次模型的應用程式層，如下表所示。

    

    
    表  OSI層次模型上的NFS

　　更多的NFS相關協議資訊可以參考如下網頁。

　　（1）http://www.faqs.org/rfcs/rfc794.html。

　　（2）http://www.tldp.org/HOWTO/NFS-HOWTO/index.html。

中文的寫的不好， 我們來看看RedHat 官方的文檔：
How It Works
Currently, there are three versions of NFS. NFS version 2 (NFSv2) is older and is widely supported. NFS version 3 (NFSv3) has more features, including 64bit file handles, Safe Async writes and more robust error handling. NFS version 4 (NFSv4) works through firewalls and on the Internet, no longer requires portmapper, supports ACLs, and utilizes stateful operations. Red Hat Enterprise Linux supports NFSv2, NFSv3, and NFSv4 clients, and when mounting a file system via NFS, Red Hat Enterprise Linux uses NFSv3 by default, if the server supports it.

All versions of NFS can use Transmission Control Protocol (TCP) running over an IP network, with NFSv4 requiring it. NFSv2 and NFSv3 can use the User Datagram Protocol (UDP) running over an IP network to provide a stateless network connection between the client and server.

When using NFSv2 or NFSv3 with UDP, the stateless UDP connection under normal conditions has less Protocol overhead than TCP which can translate into better performance on very clean, non-congested networks. The NFS server sends the client a file handle after the client is authorized to access the shared volume. This file handle is an opaque object stored on the server's side and is passed along with RPC requests from the client. The NFS server can be restarted without affecting the clients and the cookie remains intact. However, because UDP is stateless, if the server goes down unexpectedly, UDP clients continue to saturate the network with requests for the server. For this reason, TCP is the preferred protocol when connecting to an NFS server.

NFSv4 has no interaction with portmapper, rpc.mountd, rpc.lockd, and rpc.statd, since protocol support has been incorporated into the v4 protocol. NFSv4 listens on the well known TCP port (2049) which eliminates the need for the portmapper interaction. The mounting and locking protocols have been incorpated into the V4 protocol which eliminates the need for interaction with rpc.mountd and rpc.lockd.

Note
TCP is the default transport protocol for NFS under Red Hat Enterprise Linux. Refer to the chapter titled Network File System (NFS) in the System Administrators Guide for more information about connecting to NFS servers using TCP. UDP can be used for compatibility purposes as needed, but is not recommended for wide usage.
The only time NFS performs authentication is when a client system attempts to mount the shared NFS resource. To limit access to the NFS service, TCP wrappers are used. TCP wrappers read the /etc/hosts.allow and /etc/hosts.deny files to determine if a particular client or network is permitted or denied access to the NFS service. For more information on configuring access controls with TCP wrappers, refer to Chapter 17, TCP Wrappers and xinetd.

After the client is granted access by TCP wrappers, the NFS server refers to its configuration file, /etc/exports, to determine whether the client is allowed to access any of the exported file systems. Once access is granted, all file and directory operations are available to the user.

Important
In order for NFS to work with a default installation of Red Hat Enterprise Linux with a firewall enabled, IPTables with the default TCP port 2049 must be configured. Without an IPTables configuration, NFS does not function properly.

The NFS initialization script and rpc.nfsd process now allow binding to any specified port during system start up. However, this can be error prone if the port is unavailable or conflicts with another daemon.

其它的就不寫了，看看https://news.wideopen.com/docs/manuals/enterprise/RHEL-4-Manual/en-US/Reference_Guide/ch-nfs.html

下面這個防火牆配置寫得比較好：

However, NFS and portmap are pretty complex protocols. Firewalling should be done at each host and at the border firewalls to protect the NFS daemons from remote
access, since NFS servers should never be accessible from outside the organization. However, by default, the portmapper assigns each NFS service to a port dynamically at service startup time. Dynamic ports cannot be protected by port filtering firewalls such as iptables. First, you need to configure NFS services to use fixed ports. Open /etc/sysconfig/nfs, enter:
# vi /etc/sysconfig/nfs

Modify config directive as follows to set TCP/UDP unused ports:

# TCP port rpc.lockd should listen on.
LOCKD_TCPPORT=lockd-port-number
# UDP port rpc.lockd should listen on.
LOCKD_UDPPORT=lockd-port-number
# Port rpc.mountd should listen on.
MOUNTD_PORT=mountd-port-number
# Port rquotad should listen on.
RQUOTAD_PORT=rquotad-port-number
# Port rpc.statd should listen on.
STATD_PORT=statd-port-number
# Outgoing port statd should used. The default is port is random
STATD_OUTGOING_PORT=statd-outgoing-port-numbe

Here is sample listing from one of my production NFS server:

LOCKD_TCPPORT=32803
LOCKD_UDPPORT=32769
MOUNTD_PORT=892
RQUOTAD_PORT=875
STATD_PORT=662
STATD_OUTGOING_PORT=2020

Save and close the files. Restart NFS and portmap services:

# service portmap restart
# service nfs restart
# service rpcsvcgssd restart
Update /etc/sysconfig/iptables files
Open /etc/sysconfig/iptables, enter:
# vi /etc/sysconfig/iptables
Add the following lines, ensuring that they appear before the final LOG and DROP lines for the RH-Firewall-1-INPUT chain:

-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state NEW -p udp --dport 111 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 111 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 2049 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 32769 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state NEW -p udp --dport 32769 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 892 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state NEW -p udp --dport 892 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 875 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state NEW -p udp --dport 875 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 662 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state NEW -p udp --dport 662 -j ACCEPT

Save and close the file. Replace 192.168.1.0/24 with your actual LAN subnet /mask combo. You need to use static port values defined by /etc/sysconfig/nfs config file.
Restart iptables service:
# service iptables restart