摘 要：本文依托cnfug開發的Floppy Firewall為平台，以嗅探器抓包分析結合相應的路由轉發規分析IPFilter對數據報進行轉發和NAT的機理，最終針對實際案例的需求提出解決方案。關鍵詞：NAT FreeBSD 嗅探器 TCP/IP 一、前言 如今很多企事業單位擁有自己的LAN，介入互聯網的方案比較流行的方案是選用如圖1-1的拓撲結構來構建網絡。防火牆服務器充當過濾和轉發數據報的中間代理，專用服務器安置在防火牆後面避免受到攻擊。這類防火牆有硬件和軟件之分，對於一個普通小型局域網來說，軟件防火牆已經可以滿足需求，而軟件防火牆領域幾乎是IPfw和IP Filter的天下，它們的功能非常強大，安裝也非常容易，考驗防火牆管理員的主要是如何配置防火牆的rules，現在在網上可以很容易地找到如何配置 rules的文獻，但是很少有介紹其工作機理的資料，本文將以一個基於IP Filter防火牆的實際案例來分析這些rules的工作機理，並將其運用到實際案例中解決特殊的需求問題。圖1-1 常用的拓撲結構二、案例需求 本文所舉案例為一實驗室的局域網的防火牆配置。該實驗室局域網擁有30台客戶機，它們通過3個HUB連接在一起，通過一台安裝有FreeBSD的服務器用IPFW共享一個固定IP連接Internet，該服務器除了充當局域網的防火牆之外，在其上面還運行了幾乎所有FreeBSD能夠提供的大眾化服務，如WEB、TOMCAT、Java、FTP、SMABA、MAIL、DNS、TELNET等（詳情請參考cnfug期刊第八期的《用FreeBSD構建家庭網絡世界》和第九期的《基於FreeBSD操作系統的安全電子郵件系統架設》），隨著使用人數的增多，該服務器慢慢有些不堪重負，經常可以看到在後台運行的NATD服務占用了約50％的CPU時間，尤其是TOMCAT服務啟動並調用JDK之後占用的內存高達106M之巨，在高峰期客戶端的上網速度有明顯變慢。為了緩解服務器的壓力，我采用了前面介紹的現今比較流行的方案，把防火牆和專用服務器的功能分開，防火牆采用了由cnfug開發的基於 FreeBSD的Floppy Firewall系統。如此，一來可以節約硬件成本，因為所有配件下來不到150元；二來可以方便日後的維護，因為一旦配置好防火牆之後，再也不怕斷電等會導致硬盤版操作系統數據丟失的意外事故，也方便系統的備份（僅僅備份一張軟盤鏡像而已）；三來可以對在防火牆後的專用服務器提供一道安全屏障，這點是顯而易見的，雖然對於我們來說網絡安全並不是太重要。 這套由cnfug開發的軟盤版的FreeBSD防火牆使用的是4.9版本的FreeBSD，防火牆使用的是IP FilterV3.4.20，改造後的網絡的整體拓撲結構如圖2-1所示。圖2-1 網絡物理拓撲圖本案例的需求主要有四點： 1、 子網192.168.0.0/24中的所有電腦可以借助網關(防火牆)192.168.0.1透明地訪問互聯網。（注： 192.168.0.0/24這種格式在IP Filter 的rules中大量使用，其中/24＝3×8表示三個字節的子網掩碼255.255.255.0，掩蓋一個C類網段，在這裡表示IP地址前三段等於 192.168.0的所有電腦。同理，/16表示一個B類網，/32唯一標識一台主機。） 2、 外網的客戶機可以透明地可以訪問IP地址為192.168.0.251的多功能服務器（Web、Email、Ftp服務）和IP地址為192.168.0.2的文件兼打印服務器。 3、 內網客戶機可以和外網客戶機一樣通過訪問外網IP202.115.65.225來訪問內網的web、email等服務器。 4、內網的客戶機可以訪問遠程的Ftp服務器同時外網的客戶端也可訪問內網的Ftp服務器。（由於Ftp協議的特殊性在此專門提出）從圖2-1看到，防火牆的兩塊8139網卡rl1和rl0分別連接Internet和局域網的交換機，外網卡IP地址為202.115.65.225內網卡IP地址為 192.168.0.1。由於內核中IPf的缺省設置為block all，即過濾所有的包，在該情況下，防火牆的兩塊網卡不能和外界有任何數據交換，ping任何地址都提示“ping:sendto: no route to host”，所以必須人工配置IPf規則，如下命令可完成讓所有數據報自由進出防火牆的兩塊網卡：#cat ipf.conf //紅色的字表示是系統提示符>pass in all //允許任何包從任何網卡進>pass out all //允許任何包從任何網卡出>end //保存#ipf –f ipf.conf //執行ipf.conf文件中的過濾規則#sysctl –w net.inet.ip.forwarding =1 //打開內核的ip轉發 現在防火牆沒有任何過濾規則，可以允許所有的數據報自由進出自己的兩塊網卡，但是它還不知道如何把到達其上的數據報轉發，下面我將詳細介紹怎麼讓它按照我們的需求轉發數據報，這也是本文的重點所在。（注：本文主要目的是介紹IP filter防火牆軟件對數據報轉發機理，也就是路由功能，對於如何對數據報進行過濾不是本文的內容，請參考IPf的相關文獻。）三、IP Filter NAT機理分析 IP Filter的功能主要包括過濾和路由兩部分，所以該防火牆軟件包有兩個主要工具－IPf和IPnat。IPf可以實現數據報過濾，上一節就用到了IPf 命令來使pass in/our all過濾規則生效， 路由功能則由IPnat來實現，IPnat命令用來讀取並執行用戶設定的路由規則。3.1 用map指令來共享IP地址 為了讓192.168.0.0/24（24=3×8即三個字節的子網）的電腦可以共享一個外網IP來訪問互聯網，用一條最基本的兩條rules就可以實現，如下所示：map rl1 192.168.0.0/24 -> 202.115.65.225/32 portmap tcp/udp 10000:39999map rl1 192.168.0.0/24 -> 202.115.65.225/32 這兩條rules從字面上很好解釋，即在網卡rl1上把192.168.0.*(/24表示3字節的子網掩碼，標識一個C類網段的所有IP地址)網段的所有IP地址和IP地址202.115.65.225（/32表示4字節的子網掩碼，唯一標識一個IP地址）進行單向映射，portmap的用處是告訴防火牆把內網客戶機的端口進行臨時存儲時的映射范圍為10000-39999，具體原理在下面將詳述。圖3-1 內網用戶訪問外網WEB服務器的映射過程 從圖3-1中，內網中IP地址為192.168.0.3的PC客戶機欲訪問外網的IP地址為202.108.249.134的web服務器，連接過程如下： ①建立連接階段（SYN第一次握手）：客戶機先建立一個隨機的TCP端口1413准備和web服務器的80端口連接，但由於它們不在同一個網段，所以請求連接的SYN數據報被發送到了和客戶機在同一個網段的網關服務器，在這裡網關服務器就是我們的防火牆兼路由器，所以數據報在數據鏈路層會先發送至我們的防火牆的內網卡，從下面捕獲的數據報中可以看到，數據報的以太幀的目的地址是網關的MAC地址。網關即防火牆收到該數據報之後解開IP報取出目的IP地址，發現目的地址是外網IP所以在內部就轉發到外網卡rl1，rl1會按照IPnat設置的轉發規則，把在192.168.0.*發來的數據報接受下來，然後改變IP頭中的源地址為它的IP地址（202.115.65.225），map指令會把內部客戶端的IP和端口號暫時保存在一個臨時路由表中以便接受到返回的數據報時可以正確地交付給客戶端，客戶機的端口號並不是直接保存起來，而是防火牆先在portmap的范圍內找到一個端口和其一一對應起來保存，前面的設置portmap的范圍為10000:39999的原因主要是因為這個范圍的端口一般不會被防火牆上本身自己的監聽端口相同，如果端口沖突的話會導致嚴重問題，這種暫存功能在防火牆過濾中也經常被使用，Ipf規則中的keep state就是用來在屏蔽外網數據進入的狀態下把內網的請求端口號臨時保存到一張路由表中以便返回數據報可以順利被接收。 圖3-2 嗅探器捕獲的內網訪問外網web服務器的數據報 ②對方確認階段（SNY ACK第二次握手）：外網WEB服務器接收到了以202.115.65.225為源地址的連接請求，所以它會自動發會一個SYN連接請求並捎帶一個ACK 確認數據報，這個數據報將被防火牆外網卡rl1接收，防火牆收到後分析IP包的端口號並從臨時路由表中計算出該數據報應該轉發到哪一個客戶機，當然在我們的例子中它會把該數據報發還給192.168.0.3的客戶機，正如圖3-2②所示。 ③連接的最後確認（ACK 第三次握手）：內網客戶機收到WEB服務器的ACK＋SYN數據報後認為連接已經成功了，然後發送最後一個確認數據報給對方，防火牆對該數據報的處理步驟同①。 ④發送HTTP連接請求：客戶機發送的第一個攜帶HTTP數據的包從這裡開始，第一個數據報是HTTP連接請求。 ⑤WEB服務器回復數據報：WEB服務器順利接收到HTTP請求馬上給予回復的數據報，數據報如果標號是200則表示HTTP連接正常，接下來就可以把對方請求的WEB頁傳給客戶機。完成了上面的5個過程，一個對用戶透明的HTTP連接就建立了起來，對於客戶端的用戶來說，好像是直接連接到WEB服務器上去的，這都有賴於IPnat的功勞。3.2用rdr指令實現NAT轉換 為了讓外網的客戶機可以通過IP 202.115.65.225訪問到位於內網中的web、mail、Ftp服務器，IPnat的rule相應的設置為：rdr rl1 202.115.65.225/32 port 80 -> 192.168.0.221 port 80rdr rl1 202.115.65.225/32 port 21 -> 192.168.0.251 port 21rdr rl1 202.115.65.225/32 port 25 -> 192.168.0.251 port 25rdr rl1 202.115.65.225/32 port 110 -> 192.168.0.251 port 110 這條規則從字面上也很好解釋，rdr是rewrites destination addresses的意思，其功能是把防火牆上接收到的數據報改變目的地址（轉發）到另外的一台或多台主機上，上面的指令可以解釋為，把rl1（外網卡）上接收到的數據報按照指定的端口轉發到指定的位於內網的服務器上，80、21、25、110分別代表web、Ftp、smtp和pop3服務，所以這四條指令會把外網對防火牆的web、Ftp和mail請求轉發到IP為192.168.0.251內網服務器上，下面以web服務為例來分析其工作流程。如圖3-3所示，IP地址為202.115.65.38的客戶端欲用IP地址202.115.65.225訪問位於局域網內部的IP地址為192.168.0.221的WEB服務器，連接過程如下：圖3-3 外網客戶訪問內網WEB服務器的過程圖3-4 從外網客戶機上捕獲的數據報 ①發起連接階段（SYN）：客戶機202.115.65.38建立臨時端口1123發起對202.115.65.225的 80（http）端口的連接請求。該連接請求被傳送到了防火牆的外網卡rl1上，按照前面設置的IPnat的規則，防火牆會把在rl1上對80端口的請求數據報要改變其目的地址為192.168.0.221後轉發給目的主機。 ②服務器確認階段（SYN ACK第二次握手）：對於位於內網的web服務器來說，雖然它收到的HTTP連接請求是防火牆轉發給它的，但是轉發過程沒有改動IP數據包的頭信息，僅僅改動了數據鏈路層的地址信息，所以它以為請求是直接從202.115.65.38上發出的，因此它會立刻給202.115.65.38發確認數據報，這個過程其實等於202.115.65.38是外網服務器，192.168.0.221是內網客戶端，數據報的轉發過程和我們上一節討論的map機制完全一樣，數據報會透明地被轉發到202.115.65.38，只不過數據報的源IP地址被防火牆改為了202.115.65.225，如果沒有設置前面的 map規則，數據包將無法回送，連接會失敗告終。從圖3-4的第2步我們可以清晰看到外網客戶端接收到了返回的確認數據報。 ③連接的最後確認（ACK 第三次握手）：外網客戶端回送確認數據報給內網web服務器，這個過程和第一步類似不再詳述。 ④－⑤是HTTP連接建立，和上一節類似。3.3用bimap指令實現NAT轉換 bimap指令可以說是map指令的增強版，map實現的是單向映向，而bimap能夠實現雙向的同時映向，它其實實現了rdr＋map的功能，其主要應用到你想把所有的外部請求都轉換到內網的一台服務器上或幾台運行相同服務的負載均衡服務器群上。比如上面提到的案例中的192.168.0.251是一個身兼多職的綜合服務器，設置如下bimap規則後對外部來說202.115.65.225就等同於192.168.0.251，對 202.115.65.225的web、mail、DNS、telnet等等訪問會一股腦地發給192.168.0.251，用rdr來實現同樣的效果則必須每個服務作一個轉換。bimap rl1 192.168.0.251/32 -> 202.115.65.225/32bimap rl1 202.115.65.225/32 -> 192.168.0.251/32 在我的試驗中，上面兩個規則都能達到同樣的效果，這也充分的說明了該指令執行的是雙向的映射。雖然bimap使用起來如此簡單，但是bimap並沒有被廣泛使用，原因非常簡單，因為它只能把外部數據報轉到內網的一台主機上（負載均衡服務器群組其實相當於一台服務器），如果想把web、Ftp、 email服務器分別讓兩台以上的主機充當用bimap將無法做到，所以rdr被廣泛推崇和采納。由於前面已經比較詳盡的分別分析了rdr和map的工作機理，對於bimap來說就是rdr和map的組合，所以本文將不做詳細介紹。四、案例需求的實現4.1需求一的實現 案例的需求一是讓子網192.168.0.0/24中的所有電腦可以借助網關192.168.0.1透明地訪問互聯網。這其實是IPnat的最基本的功能，上面的已經做了詳盡的分析，rules設置如下：map rl1 192.168.0.0/24 -> 202.115.65.225/32 portmap tcp/udp 10000:39999map rl1 192.168.0.0/24 -> 202.115.65.225/324.2需求二的實現 案例需求二是要實現外網的客戶機可以透明地可以訪問IP地址為192.168.0.251的多功能服務器（Web、Email、Ftp服務）和IP地址為192.168.0.2的文件兼打印服務器。這其實也是IPnat的基本功能，rules設置如下：rdr rl1 202.115.65.225/32 port 80 192.168.0.251 port 80 \\webrdr rl1 202.115.65.225/32 port 21 192.168.0.251 port 21 \\Ftprdr rl1 202.115.65.225/32 port 25 192.168.0.251 port 25 \\smtprdr rl1 202.115.65.225/32 port 110 192.168.0.251 port 110 \\pop3rdr rl1 202.115.65.225/32 port 139 192.168.0.2 port 139 \\文件共享 4.3需求三的實現 案例需求三是要實現內網的用戶可以以外網的地址訪問內網的web、email等服務器，該需求不是非常的普遍，所以很難在現有的資料上找到rules的配置方法。該需求從表面上來看和需求二很相似，但是它們有一個本質的區別，那就是需求二的請求數據報的傳給的是外部網卡rl1，而本需求的請求是內網發起的所以請求數據報會被內網卡rl0接收，所以用需求二設置的rules是不能夠實現本需求的。 首先我們以web服務為例來一步一步地探索rules的配置方法。第一步可以仿照需求二的rules把rl1改為rl0，讓防火牆會自動轉發內網的請求數據報，這將得到下面的rule：rdr rl0 202.115.65.225/32 port 80 -> 192.168.0.251 port 80 \\web 在設置並執行上面的rule後用客戶端192.168.0.221試圖訪問202.115.65.225後失敗，表現為延遲一段時間後彈出打不開網頁提示。為了找到問題根源所在，分別在客戶端和服務器端用捕獲數據報進行分析，在客戶端和服務器端捕獲的數據報如圖4-1所示：圖4-1 在配置錯誤時同時捕獲到的客戶端和服務器端數據報 圖中的1-7是數據報收發的順序，1處表明連接請求是從192.168.0.221發至202.115.65.225的，防火牆將會在內網卡rl0接收到了數據報，按照IPnat的rule，防火牆會給客戶機發一個ICMP報文告訴客戶機有一條更好的路徑可以到達目的主機，如圖4-2所示：圖4-2 防火牆發給客戶端redirect指令的ICMP報文 ICMP報文的code是“5”，說明其目的是一個轉發控制，gateway address是192.168.0.251就是告訴客戶機把對目的主機的請求數據報去選擇一條更好的路由192.168.0.251（原本是 192.168.0.1），在ICMP數據報的後面還攜帶了原IP報的報頭信息。2處表明客戶機已經知道數據可以直接發送到192.168.0.251， 3處可以看到服務器收到了連接請求，4處表明服務器直接回送確認給客戶機，5處表明客戶機收到了了服務器的確認信息，6處是該次試驗失敗的直接原因，因為客戶機沒有發ACK作應答而是發了一個RST同服務器斷開連接，7表示服務器收到客戶機RST復位指令斷開連接。根據TCP/IP協議，RST指令一般在一個TCP連接結束的時候和數據包發生了某些錯誤時被發出，現在的情況很明顯不應該是TCP連接結束的原因那一定是TCP的三次握手沒有成功導致的，仔細觀察1、5、6這三次握手的報文記錄發現原因在於第一個請求是的服務器是202.115.65.225，之後的兩次握手的服務器地址是 192.168.0.251，對於客戶機來說，它會認為在5處的回復信息不是對應於它請求的回復，是非法的所以給予RST消息斷開連接。所以問題的關鍵在於要把第二次握手的服務器IP地址轉換為202.115.65.225，從5處可以知道第二次握手是服務器發給直接發給客戶機的，所以源地址只能是 192.168.0.251，所以不能讓它直接回復客戶機，為了讓其不直接回復客戶機又要讓客戶機可以收到它的回復那只有找防火牆作為中介。如果讓防火牆能夠記住客戶端的地址和端口號然後代替客戶端向服務器發送請求，之後再把服務器的回復按照客戶端的地址和端口返回給客戶端那就可以實現一次完整的TCP連接了，而這個功能恰好是IPnat中的map指令可以完成的，所以解決問題的方法就非常明顯了，加入下面rule執行就解決了問題，捕獲的包如：map rl0 192.168.0.0/24 -> 202.115.65.225/32 圖4-3所示。其工作流程和前面分析的讓內網訪問外網的原理相同，不同之出就在於這個rule只對內網卡rl0有效。圖4-3 配置正確的rules之後的客戶機與服務器的交互過程 從圖4-3可以清晰地看到，202.115.65.225成為了客戶機和服務器的中間代理，忠實地轉發著所有的數據報文。4.4需求四的實現4.4.1內網Client訪問外網Ftp Server 需求四首先要求內網的客戶機可以訪問遠程的Ftp服務器。之所以把訪問Ftp服務單獨拿出來作為一個需求是由Ftp協議的特殊性決定的，以web服務為例，web服務器始終都是在一個端口上為客戶機提供HTTP連接和傳輸服務，缺省的HTTP端口為80端口（但不限定）。所以對於這種服務，客戶機僅僅需要隨機地打開一個TCP端口和對應的服務器建立連接，而這個端口會被防火牆map指令映射到防火牆portmap范圍內的端口後暫存起來，等數據返回時可以正確地遞交給客戶機。而Ftp服務僅僅使用缺省的21端口來建立連接和傳遞控制數據，它還需要開辟另外一條TCP連接通道來專門傳輸文件數據，其實不光 Ftp服務，netmeeting,pptp等服務器工作模式也是類似，這裡以僅僅是以最常見的Ftp為例而已。 Ftp服務器建立第二條 TCP連接通道的方法有兩種，分別是PORT模式和PASV模式，通常被稱為主動模式和被動模式。主動模式就是客戶端在確認已經和Ftp服務器建立了連接之後在客戶端主動打開一個隨機的端口來和服務器進行數據傳送，同時向服務器發出PORT指令告訴服務器自己開設的端口；被動模式和主動模式相反，客戶端在和服務器端建立連接後發送PASV要求以被動模式建立數據傳輸通道，服務器端就會先開放一個端口來偵聽客戶機的連接以便建立數據傳輸通道。在該案例中，直接用FlashFXP訪問外部Ftp服務器只有用PASV模式才能成功，執行情況如圖4-4所示：圖4-4 客戶端用FlashFXP用PASV和PORT模式訪問外部Ftp服務器 之所以PASV模式可以成功是因為這種模式下兩個TCP連接過程占據主動始終是服務器，客戶機被動地連接服務器，僅僅相當於簡單增加了一個線程。 PORT模式之所以失敗是因為在建立第二個TCP數據通道的時候是由客戶端先創建端口來讓服務器連接，這樣內網客戶端和外網服務器都同時充當Client 和Server的角色。如圖4-4客戶端發出PORT指令要求外網的服務器端連接自己的143端口，在經過防火牆後攜帶PORT指令的IP包的源地址會更改為防火牆的對外地址202.115.65.225，所以外網的服務器收到了請求後會去試圖連接202.115.65.225的143端口，這等同於外網的服務器是一台欲訪問內網Server的Client，如果要實現該數據報的正確轉發，須在防火牆上應該加一條rule：“rdr rl1 202.115.65.225 port 143 -> 192.168.0.221 port 143”來實現，但是由於位於內網客戶機的端口和IP地址都是隨時變化的，無法事先為其設置rules。好在rule中有一種PROXY參數是專門為解決該類問題設計的。在這個案例中rule設置如下：map rl1 192.168.0.0/24 -> 202.115.65.225/32 proxy port Ftp Ftp/tcp圖4-5 設置好proxy rule後捕獲的內網客戶端和外網服務器的連接數據報 圖4-5是設置成功後內網客戶端以PORT模式和外網Ftp建立連接時捕獲的數據報，從中可以看出內網的客戶機首先打開了2224（一般大於1024）的端口等待外網的服務器的接入，外網的服務器之所以知道客戶端的新開的端口號是因為客戶端在此之前發送了一個PORT幀，格式為“PORT 192,168,0,221,8,176”，這個幀會先被防火牆一直監聽客戶機發往外部21端口數據的外網卡捕獲並且PORT幀中的客戶端地址以及端口會被修改為防火牆地址和映射端口，之後防火牆把修改後的數據轉發給Ftp服務器，所以Ftp服務器才會創建一個新端口來和客戶機建立連接，完成一次完整的 PORT過程。 4.4.2外網Client訪問內網Ftp Server 從上一小節介紹了如何讓內網的客戶端訪問外網的Ftp服務器在使用PORT模式可以順利通過，而這一小節要解決的問題和上一小節的剛好相反，外網的客戶端使用PORT模式可以在現有的rules基礎上不做任何更改就能和內網Ftp服務器建立連接並傳輸數據，但用PASV模式反而不行，如圖4-6所示。這種現象在上一小節已經分析得比較清楚了，因為PASV模式下，在內網的服務器端會建立一個隨機監聽端口並在此之前給外網客戶機送一個帶有其IP地址（192.168.0.*的內網地址）和新建端口號信息的 PASV幀，外網的客戶端能正確的接收到該幀然後以“192.168.0.*:服務器新端口號”為目的地址回復確認報文，當然這種數據報是不可能發送到目的地的，如圖4-7所示。圖4-6 外網客戶端FlashFXP用PASV模式時收到到的錯誤信息 圖4-7 從外網客戶端捕獲的連接失敗過程的數據報 通過分析發現問題的主要症結就在於服務器端告訴客戶端的IP地址是一個內網地址，這個信息和普通的TCP連接的源地址不一樣，後者的地址信息放置在IP 報頭裡，防火牆有能力分析並映射為自己的IP，而前者的地址信息放置在上層的應用層報文內部，防火牆不會對每個報文的應用層數據幀進行分析處理，所以內網 IP地址不能被轉換成防火牆的真實IP。既然防火牆沒有辦法實現那只有找發送PASV的服務器尋找解決問題的方法。好在大部分的Ftp服務器都支持手動調節PASV信息幀的內容，拿Windows平台最流行的Server-U服務器為例，設置如圖4-8所示：圖4-8 Server－U設定PASV的IP和隨機端口范圍 在這種情況下,內網服務器給外網客戶會發一個PASV告訴客戶端確認報文發送到202.115.65.225，端口為40000到60000隨機產生的一個確定數值，外網客戶端按照要求回復的數據報會被防火牆接收，但它還不知道怎麼轉發到內網服務器，還需加入下面rule才能正確轉發到內網Ftp服務器。rdr rl1 202.115.65.225/32 port 40000-60000 -> 192.168.0.221 port 40000 tcp 這條rule會把請求40000-60000的端口范圍的數據報轉發到192.168.0.221 Ftp服務器。圖4-9 連接成功後的客戶端和服務器端捕獲的數據報五、總結 把所有的rules匯總生成最後的rules 如下：map rl1 192.168.0.0/24 -> 202.115.65.225/32 portmap tcp/udp 10000:39999map rl1 192.168.0.0/24 -> 202.115.65.225/32map rl0 192.168.0.0/24 -> 202.115.65.225/32rdr rl1 202.115.65.225/32 port 40000-60000 -> 192.168.0.251 port 40000 tcpmap rl1 192.168.0.0/24 -> 202.115.65.225/32 proxy port Ftp Ftp/tcprdr rl1 202.115.65.225/32 port 80 -> 192.168.0.251 port 80rdr rl1 202.115.65.225/32 port 21 -> 192.168.0.251 port 21rdr rl1 202.115.65.225/32 port 25 -> 192.168.0.251 port 25rdr rl1 202.115.65.225/32 port 110 -> 192.168.0.251 port 110rdr rl1 202.115.65.225/32 port 139 -> 192.168.0.2 port 139rdr rl0 202.115.65.225/32 port 139 -> 192.168.0.2 port 139rdr rl0 202.115.65.225/32 port 80 -> 192.168.0.251 port 80rdr rl0 202.115.65.225/32 port 21 -> 192.168.0.251 port 21rdr rl0 202.115.65.225/32 port 25 -> 192.168.0.251 port 25rdr rl0 202.115.65.225/32 port 110 -> 192.168.0.251 port 110rdr rl0 202.115.65.225/32 port 139 -> 192.168.0.251 port 139 把上面的rules保存到nat.conf文件中後運行下面的命令，防火牆就能完成案例的所有需求了。#ipnat –CF#ipnat –f nat.conf 本文經過分析簡單的rule來推測著名防火牆軟件IP Filter的NAT工作機理，並在此基礎上探討了復雜路由的設計思路，結合實際案例分析路由數據報的收發流程並提出了完美的解決方案。
作者：曾慧鵬 cnfug