互聯(lián)網(wǎng)是基于32位IP地址的，這意味著互聯(lián)網(wǎng)理論上最大電腦數(shù)目約為四萬億。由于IP地址使用方式的無效性，實際的數(shù)量會少得多。實際上，互聯(lián)網(wǎng)過不了多久就會將IP地址用完。

因為可用的IP地址越來越少，一種被稱為網(wǎng)絡(luò)地址解析或箭稱NAT的技術(shù)被開發(fā)出來，它允許以一個IP地址來代表整個網(wǎng)絡(luò)的電腦。

一個NAT處在公用互聯(lián)網(wǎng)與它所服務(wù)的網(wǎng)絡(luò)之間，重寫數(shù)據(jù)中IP頭部的IP地址和端口號以使所有的包看上去都象從一個NAT設(shè)備的公用IP地址發(fā)來（或到它去）的，而不是發(fā)自（往）實際的源或者目標(biāo)。

NAT如今已經(jīng)在小型家庭－辦公室路由被普遍租用,也在很多軟件中被用戶使用以連接幾臺PC到一個唯一的電纜MODEM。它甚至被一些ISP使用。

（NAT不是唯一可能的解決辦法，代理服務(wù)器也被普遍使用，但需要更多的配置，有時還需要要定制的客戶端軟件。而最終，我們都將轉(zhuǎn)換到IPｖ6，它將使用128位地址，可以解決已有的及所有的問題，但那將在很久后才會普及。

某些協(xié)議是非NAT友好的

一些應(yīng)用程序?qū)P和端口號隱藏在它們的數(shù)據(jù)包中發(fā)送，NAT不能正確重寫它們，所以當(dāng)你想在NAT網(wǎng)絡(luò)內(nèi)使用那些程序的話，它們將不會正確運行。

一些NAT，由于安全原因，只允許從已經(jīng)發(fā)送過數(shù)據(jù)去的外部地址接收數(shù)據(jù)。這意味著處于不同NAT后的兩個人不能以通常的方式建立連接。

解決辦法

希望NAT友好的Peer-to-peer（點對點）協(xié)議必須明確：其所嵌入數(shù)據(jù)包的任何地址在通過NAT時都可能變夢扌В虼誦枰咕取Ｒ桓隹尚械姆椒ㄈ縵攏?/p>

兩點之間所有的數(shù)據(jù)流都通過一個單一的UDP端口。存在著一個不處于任何NAT之后的地址服務(wù)器，用戶首先與地址服務(wù)器連接，并發(fā)送他們認(rèn)為擁有的IP地址；服務(wù)器標(biāo)記該地址和它在UDP頭部所看到的地址。然后服務(wù)器將兩個地址都送往其它點。這樣，所有人都知道其它人的地址。

為打開點對點的連接，所有的舊（結(jié)）點發(fā)送一個UDP包到新的（結(jié)）點，且新（結(jié)）點發(fā)送一個UDP包到每一個老（結(jié)）點。因為無人知道開始它們是否處于同一個NAT之后，第一個包往往被同時送往公有和私有地址。

這導(dǎo)致每個人的NAT為UDP數(shù)據(jù)流的通過打開一個雙向的洞。一旦第一個響應(yīng)從每個（結(jié)）點返回，發(fā)送者就知道使用哪個返回地址，并能停止向兩個地址發(fā)送數(shù)據(jù)。

兼容性需求

基于和超越基本的NAT　RFC，一個想支持這個技術(shù)的NAT設(shè)備必須有以下要求的屬性：

＞＞NAT不允許改變被數(shù)據(jù)流使用的UDP端口號。
如果一個處于NAT之后的主機(jī)從一個單一的UDP口發(fā)送了一系列的包，被NAT接棒后的包也必須表現(xiàn)為來自同一主機(jī)和UDP口。

RFC藍(lán)圖

我正在擬訂這項技術(shù)RFC藍(lán)圖更為詳細(xì)的細(xì)節(jié)。如果你感興趣，請與我聯(lián)系。

兼容性測試結(jié)果

我正在測試實現(xiàn)幾個NAT通訊的兼容性。這里是部分結(jié)果：

已知的NAT實現(xiàn)的兼容性

＞＞NAT1000：完全兼容。感謝Nevod技術(shù)人員早期所幫助做的兼容性測試。無任何東西需要改變；這項技術(shù)與他們的NAT一起運行很穩(wěn)定。Nevod已經(jīng)不再存在了，它已被微軟兼并。
＞＞W(wǎng)in98 SE包含的網(wǎng)絡(luò)聯(lián)接共享軟件，起源贜AT1000，所以一定運行良好。
＞＞SYGATE：完全兼容。
＞＞NAT32：1999年1月5號公布的BETA測試版完全兼容。現(xiàn)在公布的版本也應(yīng)該完全兼容。
＞＞LINUX　IP　Masquerading（LINUX　IP偽裝）：2.2.1版本內(nèi)核和后續(xù)版本可以正常運行。請到http://juanjox.linuxhq.com/?尋找早期2.1版本的補丁。2.0版本的補丁見Glenn Lamb的頁面：http://home.indyramp.com/lists/masq/msg03024.html：
ftp://ftp.netcom.com/pub/mu/mumford/loose-udp-2.0.36.patch.gz；
Glenn的端口使之擁有一個配置時選項CONFIG_IP_MASQ_LOOSE_UDP，這是一個很好的舉措。
＞＞W(wǎng)inNAT：當(dāng)前版本工作正常。

NAT實現(xiàn)即將可兼容的

＞＞Arescom Apex 1100 ISDN路由：Arescom在1999年1月針對此問題發(fā)布了一個固件補丁；也許現(xiàn)在已經(jīng)并入其標(biāo)準(zhǔn)固件里了,但我還沒有證實。
＞＞Vicomsoft Softrouter Plus：Vicom曾公布過一個版本以解決這個問題，但我還沒有機(jī)會來測試一下。注意：為使這個實現(xiàn)正常運行，你必須把網(wǎng)關(guān)設(shè)備上除指向內(nèi)部以太適配器外的所有本地TCP綁定禁止。在使用Vicom的安裝助手之前請閱讀其文檔。

未知是否兼容的

＞＞Cisco IOS有一內(nèi)置的NAT兼容特性，也許有用也許不然。
＞＞我們已經(jīng)測試了我們手上所有能得到的WIN32軟件。但還沒有測試嵌入到許多小型家庭辦公路由中的NAT，也沒有測試外置的NAT如SonicWall等。

不兼容的

＞＞所有的純代理服務(wù)器解決辦法，如WINGATE2或者PPPShar，都不能正常運行。

使用這項技術(shù)的軟件

以下軟件包是已知的支持在NAT后操作的：
＞＞Civilization: Call To Power
＞＞Heavy Gear 2

討論區(qū)

我想聽到其它開發(fā)者對于這項技術(shù)的想法，以及Masq如何被重寫以正確復(fù)用UDP端口。加入NAT-peer-games（http://onelist.com/viewarchive.cgi?listname=nat-peer-games）郵件列表讓我們一起討論。

實施問題

在測試SYGATE和近期NAT1000版本時，我遇到一些實施方面的問題。當(dāng)運行網(wǎng)關(guān)的機(jī)器是通過MODEM與INTERNET聯(lián)接的話所有一切均正常。但如果網(wǎng)關(guān)機(jī)器是通過以太網(wǎng)與INTERNET聯(lián)接的話，客戶端不能訪問那個外部以太網(wǎng)上的其它主機(jī)。看上去就象那臺網(wǎng)關(guān)送出來的包完全被外部以太網(wǎng)上的其它主機(jī)丟棄了。然而路由器不會丟棄數(shù)據(jù)，所以與遠(yuǎn)程主機(jī)聯(lián)接沒有問題。想了解更多信息，請到my Usenet post（http://www.dejanews.com/getdoc.xp?AN=427631763）獲取。

我傾向于相信這是硬件原因，但誰知道呢...

鏈接

＞＞IETF Working Group on NAT：
http://www.ietf.org/html.charters/nat-charter.html
新的RFC草圖和郵件列表。其中一個文檔
http://www.ietf.org/internet-drafts/draft-ietf-nat-protocol-issues-01.txt
提到這項技術(shù)；搜索關(guān)鍵詞“Activision”

＞＞NAT頁面：
http://www.uq.edu.au/~gadmacka/the-nat-page/
列出了一些可行的NAT實現(xiàn)

＞＞LINUX　IP偽裝：
http://www.indyramp.com/masq/
都是關(guān)于NAT實現(xiàn)的LINUX之Masq。

＞＞MASQ郵件列表的可查詢索引：
http://www.mail-archive.com/masq@tori.indyramp.com/

＞＞LINUX　IP　NAT論壇：
http://serf.csn.tu-chemnitz.de/HyperNews/get/linux-ip-nat.html
NAT論文，老式的不支持的LINUX　NAT實現(xiàn)和一個討論區(qū)。多半為了歷史興趣。

歷史

相對于我的知識來講這是一項新技術(shù)。我在1997年開始研究它，并在1998年用它完成了我的第一個作品。這項技術(shù)在制作Activision多玩家游戲中被開發(fā)。

1999　DAN　KEGEL　版權(quán)所有
dank@alumni.caltech.edu
最近更新：1999年7月17日
KEGEL的主頁：http://www.kegel.com/