支持NAT穿透的SOCKS4/5協(xié)議

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

關(guān)鍵詞：SOCKS；NAT；P2P；STUN；穿透

中圖分類號：TP393.03

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

1 穿透NAT的協(xié)議

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

1.1 UPNP[7]

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

1.2 STUN [8][9]

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

2 SOCKS4/5協(xié)議

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

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

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

3.1 協(xié)議方案

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

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

3.2 建立直接通信

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

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

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

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

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

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

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

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

如圖3所示：

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

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

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

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

4 實(shí)驗測試

4.1 實(shí)驗設(shè)備

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

NAT設(shè)備：兩臺NetGear WPN824路由器。

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

4.2 實(shí)驗效果

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

5 結(jié)論

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

參考文獻(xiàn)：

[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].計算機(jī)應(yīng)用，2006，4（26）.

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

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

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