摘 要：針對ipv4協(xié)議地址的緊張，互聯(lián)網(wǎng)中NAT設備得到廣泛使用。但是NAT的設備引入導致計算機互相連接出現(xiàn)困難，很多客戶端/服務器協(xié)議的服務不能向NAT外的計算機提供直接訪問，其中包含SOCKS4/5協(xié)議。本文提供一種客戶端-服務器連接器模式使得SOCKS4/5服務即使在NAT內部也能對外提供所有服務。試驗結果表明，本方案對于SOCKS4/5協(xié)議穿透NAT的試驗非常成功。

關鍵詞：SOCKS；NAT；P2P；STUN；穿透

中圖分類號：TP393.03

IP網(wǎng)絡地址是整個互聯(lián)網(wǎng)的基礎，目前大多數(shù)網(wǎng)絡設備使用的都是IPv4地址。IPv4地址提出的時候沒有想到互聯(lián)網(wǎng)發(fā)展如此之快：根據(jù)2012年的思科報告，全球有23億互聯(lián)網(wǎng)用戶，到2017年，全球將會有約36億互聯(lián)網(wǎng)用戶。到2017年，將會有超過190億全球網(wǎng)絡聯(lián)接（固定/移動個人設備、M2M聯(lián)接等）?，F(xiàn)在IPv4的地址已經(jīng)不夠這些設備使用了，為了解決這個問題，IETF提供了NAT[1][2]方案，這個方案使用NAT將網(wǎng)絡分為外網(wǎng)和私網(wǎng)，每個私網(wǎng)都可以重用，這個方案大大緩解了IPv4地址匱乏的問題。但是這個方案導致了一個問題，對于想對外提供服務的NAT私網(wǎng)內的用戶而言，這個功能會受到限制，最主要的原因是NAT外的用戶不能直接訪問到NAT內私網(wǎng)中的計算機數(shù)據(jù)。這種情況導致了互聯(lián)網(wǎng)上P2P互相訪問的困難。不過目前還有很多應用需要這種服務器式的被動訪問，比如SOCKS4/5[3][4]協(xié)議，這個是最為知名的一種代理協(xié)議，通過這個代理協(xié)議服務，能夠透明地中轉服務器和客戶端之間的數(shù)據(jù)。然而NAT的引入導致在NAT后面的用戶無法對外提供SOCKS4/5服務。本文試圖使用穿透NAT的P2P技術，使在NAT內的SOCKS4/5服務也能提供給外部機器使用，真正實現(xiàn)對于互聯(lián)網(wǎng)的任何一個用戶都能夠直接訪問。

1 穿透NAT的協(xié)議

為了解決引入NAT設備后網(wǎng)絡互聯(lián)出現(xiàn)的問題，有大量協(xié)議被發(fā)明和使用，比如MIDCOM[5]、TURN[6]等，但是這些協(xié)議大都需要第三方介入，這會導致一些問題。如：中轉第三方的帶寬、處理能力以及實時性。這隨著NAT后面節(jié)點的增多，數(shù)據(jù)量的增長以及對于實時性的嚴格要求等，這些協(xié)議處理都存在問題。我們希望兩個機器能夠實現(xiàn)真正溝通，而不是通過中繼的方式。UPNP和STUN這兩個協(xié)議能夠實現(xiàn)這種真正直接的溝通。

1.1 UPNP[7]

UPNP（Universal Plug and Play）是由UPnP Forum推廣的一套網(wǎng)絡協(xié)議。該協(xié)議的目標是使家庭網(wǎng)絡和公司網(wǎng)絡中的各種設備能夠相互無縫連接，并簡化相關網(wǎng)絡的實現(xiàn)。UPnP通過定義和發(fā)布基于開放、遵循因特網(wǎng)通訊網(wǎng)協(xié)議標準的UPnP設備控制協(xié)議來實現(xiàn)這一目標。任何設備都能自動加入一個網(wǎng)絡，獲取自己的IP地址，宣布自己的名字，根據(jù)請求檢查自身功能并且檢測出其它設備和它們的功能。支持UPnP的設備允許UPnP數(shù)據(jù)包通過IGD協(xié)議在沒有用戶交互的情況下，無障礙的通過NAT。但是UPnP的缺點是：它要求所有網(wǎng)絡中的設備都支持UPnP，即使單臺設備不符合UPnP標準的，我們就無法實現(xiàn)一種P2P網(wǎng)絡。

1.2 STUN [8][9]

STUN協(xié)議是一種輕量級的客戶端-服務器模式的協(xié)議，它不需要任何管理員進行網(wǎng)絡配置，就能發(fā)現(xiàn)它們和公網(wǎng)之間是否存在NAT，并確定NAT的類型。STUN協(xié)議目前僅僅支持使用UDP報文穿透Cone NAT[10]。此協(xié)議利用Cone NAT傳輸 UDP的原理進行穿透[11][12][13]：私網(wǎng)內某個機器通過Cone NAT發(fā)送UDP數(shù)據(jù)到外網(wǎng)某個機器，內部IP地址和端口的UDP數(shù)據(jù)經(jīng)過Cone NAT被映射到一個外部地址，在某個時間段內這個內部IP地址和端口將被轉換為固定外部IP地址和端口（這個過程將被Cone NAT記錄，并且存儲為一個Session）。此后，如果外部Session對應的機器發(fā)送UDP數(shù)據(jù)到這個Cone NAT，Cone NAT會把這個數(shù)據(jù)包轉發(fā)到內部映射的這個地址上。目前IETF定義的STUN協(xié)議目前能夠穿透Cone NAT，但是不能穿透Symmetric NAT。不過我們可以通過修改STUN協(xié)議來實現(xiàn)穿透Symmetric NAT的目的。[14][15][16]

2 SOCKS4/5協(xié)議

SOCKS協(xié)議是一種應用層次的代理協(xié)議，它提供一種通用方案，能為應用程序提供基于TCP和UDP數(shù)據(jù)報文的代理服務，但是它不能代理ICMP之類的底層通訊協(xié)議，SOCKS協(xié)議從概念上來講是介于應用層和傳輸層之間的“中介層（shim-layer）”，SOCKS V4協(xié)議為HTTP、FTP、TELNET、WAI和GOPHER等基于TCP協(xié)議的客戶/服務器程序提供了代理方案。新的SOCKS V5協(xié)議在SOCKS V4協(xié)議基礎上作了進一步擴展，從而可以支持UDP協(xié)議，并對其框架規(guī)定作了擴展，以支持安全認證方案。同時它還采用地址解析方案以支持域名和IPV6地址。

SOCKS協(xié)議利用握手（negotiation），請求（Requests），應答（Replies）等過程完成對于上述協(xié)議的代理轉發(fā)。一般而言SOCKS4/5服務器通常綁定在1080端口上。

3 NAT穿透SOCKS4/5協(xié)議實現(xiàn)

3.1 協(xié)議方案

如圖1，為了實現(xiàn)雙方都在NAT后的機器的SOCKS4/5之間的直接通信，我們需要一個雙方都能訪問的中間服務先把兩邊的機器關聯(lián)起來。在公網(wǎng)上我們需要架設一個雙方都能夠聯(lián)系的服務器，然后通過STUN協(xié)議幫助雙方完成直接通信。一旦直接聯(lián)系完成，我們就不再需要公網(wǎng)中間服務了，此后我們采用可靠的UDP傳輸協(xié)議完成SOCKS4/5客戶端和服務器的直接數(shù)據(jù)傳輸。

此協(xié)議分為兩個部分，首先是通過STUN協(xié)議完成NAT后兩個機器的SOCKS4/5客戶端關聯(lián)器和SOCKS4/5服務器關聯(lián)器的直接通信，然后使用可靠的UDP協(xié)議完成SOCKS4/5客戶端服務器的數(shù)據(jù)通信。

3.2 建立直接通信

我們可以使用STUN協(xié)議來幫助雙方都在NAT后的機器建立直接的通信。STUN協(xié)議通過一種叫做UDP hole punching的機制來實現(xiàn)這一目的。一旦完成這個操作，兩個NAT設備后的機器就能夠實現(xiàn)直接的網(wǎng)絡通信而不再需要STUN服務器的介入了。

如圖2顯示SOCKS4/5客戶端關聯(lián)器和SOCKS4/5服務端關聯(lián)器通過STUN協(xié)議幫助建立直接通信的過程。

（1）客戶端關聯(lián)器通過NAT A連接到服務器，服務端關聯(lián)器通過NAT B連接到服務器，服務器記錄客戶端關聯(lián)器和服務端關聯(lián)器的外網(wǎng)地址和端口。

（2）服務器向客戶端關聯(lián)器發(fā)送服務端管理器的外網(wǎng)地址和端口消息，服務器向服務端關聯(lián)器發(fā)送客戶端關聯(lián)器的外網(wǎng)地址和端口消息。

（3）客戶端關聯(lián)器向服務端關聯(lián)器的外網(wǎng)地址和端口發(fā)送hole punching消息。雖然這個數(shù)據(jù)包在NAT B的時候會被阻止（非Full Cone NAT禁止沒經(jīng)過關聯(lián)的外網(wǎng)IP直接訪問內網(wǎng)），但是這個UDP數(shù)據(jù)包在經(jīng)過NAT A的時候，會在NAT A上建立一個Session，這個Session記錄了本地客戶端關聯(lián)器與服務端關聯(lián)器外網(wǎng)地址的關聯(lián)信息。

（4）服務端關聯(lián)器發(fā)送回應消息到客戶端關聯(lián)器，NAT A由于有步驟3由hole punching消息建立的Session，NAT A將會把這個消息轉發(fā)到客戶端關聯(lián)器，完成后雙方建立直接的消息通信。

3.3 SOCKS4/5數(shù)據(jù)傳輸

由于STUN協(xié)議僅僅支持UDP的穿透，但是SOCKS4協(xié)議只支持TCP的連接，為了兼容SOCKS4/5協(xié)議，我們使用代理轉發(fā)的機制來保證我們的程序能夠完美匹配SOCKS4/5這兩種協(xié)議。

如圖3所示：

（1）SOCKS客戶端關聯(lián)器綁定本機端口1080。本地SOCKS客戶端程序（如IE等程序）設置本地SOCKS代理為本地127.0.0.1080。SOCKS客戶端按需要訪問某個公網(wǎng)服務器或者遠端對方的私網(wǎng)服務器。

（2）客戶端關聯(lián)器接收到SOCKS客戶端發(fā)送過來的數(shù)據(jù)，不做任何改變，通過可靠的UDP（如UDT協(xié)議，此協(xié)議可以提供類似TCP的可靠數(shù)據(jù)傳輸）數(shù)據(jù)傳輸發(fā)送到已經(jīng)建立的直接通信的服務端關聯(lián)器。

（3）服務端關聯(lián)器接收到可靠的UDP傳輸過來的數(shù)據(jù)，然后不做任何改變的將這個數(shù)據(jù)通過TCP轉發(fā)到SOCKS4/5的真正服務器程序（127.0.0.1：1080）。

（4）SOCKS服務器連接實際需要訪問的公網(wǎng)或者私網(wǎng)服務器（如需要訪問的HTTP服務）。

4 實驗測試

4.1 實驗設備

系統(tǒng)硬件：三臺PC，配置：CPU P6 3.40GHz 4GM 內存

NAT設備：兩臺NetGear WPN824路由器。

操作系統(tǒng)軟件：Windows7。

4.2 實驗效果

程序經(jīng)過實際測試證明，支持NAT穿透的SOCKS協(xié)議完全可行。測試顯示瀏覽器瀏覽網(wǎng)站與直接使用SOCKS協(xié)議連接的效率基本接近，但是由于中轉過程的花費，瀏覽大型網(wǎng)站可能相對于直接SOCKS連接慢了5%，不過這個基本不會影響用戶的感受。

5 結論

SOCKS協(xié)議是客戶端/服務器模式，這種模式由于NAT的引入導致如果服務在NAT后面將會出現(xiàn)問題。本論文使用一種新的客戶端-服務端關聯(lián)器方法使得SOCKS協(xié)議能夠支持NAT的穿透，這個使得SOCKS協(xié)議能夠被大多數(shù)工作在NAT后的計算機使用。并且這種關聯(lián)器方法與上層的協(xié)議沒有任何直接關系，我們可以擴展此種協(xié)議，使得很多原來不支持NAT穿透的協(xié)議也能夠被支持，比如：SMTP、POP3、IMAP、SNMP等。同樣，這個方法也能支持我們定義新的協(xié)議，比如類似QQ一樣即時P2P通訊協(xié)議。

參考文獻：

[1]P Srisuresh， M Holdrege. IP network address translator （NAT）terminology and considerations.RFC 2663.August 1999.

[2]G Tsirtsis and P Srisuresh. Network address translation-protocol translation （NAT-PT）.RFC 2766.February 2000.

[3]Ying-Da Lee， SOCKS： A protocol for TCP proxy across firewalls， http：//www.openssh.org/txt/socks4.protocol.

[4]M. Leech ， M. Ganis， Y. Lee， R. Kuris， D. Koblas， L. Jones. SOCKS Protocol Version 5. RFC 1928.

[5]P Srisuresh， J Kuthan， J Rosenberg， A Molitor，A Rayhan. Middlebox communication architecture and framework.RFC 3303.August 2002.

[6]J. Rosenberg， C. Huitema， and R. Mahy. Traversal using relay NAT （TURN）. Draft-rosenberg-midcom-turn-03， October 2003.

[7]UpnP Forum. Internet gateway device （IGD） standardized device control protocol. November 2001.

[8]J. Rosenberg， J. Weinberger， C. Huitema， R. Mahy.STUN–Simple traversal of user datagram protocol（UDP）through network address translators （NATs）.RFC 3489，2003.

[9]J Rosenberg， R Mahy， P Matthews， D Wing. Session traversal utilities for NAT （STUN）. RFC 5389. 2008.

[10]C Jennings. NAT classification results using STUN. RFC 5389. October 2008.

[11]T. Hain. Architectural implications of NAT. RFC 2993. November 2000.

[12]D Senie. Network address translator （NAT）-friendly application design guidelines. RFC 3235. January 2002.

[13]Saikat Guha， Paul Francis. Simple traversal of UDP through NATs and TCP too （STUNT）. http：//nutss.gforge.cis.cornell.edu/stunt.php.

[14]Yuan Wei，Daisuke，et al. A new method for symmetric NAT traversal in UDP and TCP，APAN Network Research Workshop.11-18，August 2008.

[15]王勇，崔修濤，呂釗，李子成.基于探測對Symmetric NAT與端口受限NAT的穿透方案[J].計算機應用，2006，4（26）.

[16]楊璐，沈悅，蔣蕾.一種TCP協(xié)議穿透Symmetric NAT方案[J].計算機工程與應用，2007，43（6）.

作者簡介：周暉（1979.08-），男，本科，工程師，軟件開發(fā)工程師，研究方向：網(wǎng)絡通信。

作者單位：漢王科技股份有限公司，北京 100094