摘要:SOCKS協議是可用的功能最強大、應用最靈活、安全性較高的代理協議,基於SOCKS的IPv4向IPv6過渡技術已經成為一種不錯的選擇。

首先討論了直接在雙棧主機上實現IPv4和IPv6的地址轉換的BIA技術,然後討論了通過一個雙棧閘道器來進行IPv4和IPv6的地址轉換的SOCKS64技術,最後對這兩種技術進行了比較分析。

關鍵詞:IPv4,IPv6,SOCKS,BIA,SOCKS64

一、概述

由於IPv6與IPv4相比具有諸多的優越性,IPv6代替IPv4已經成為網路發展的必然趨勢。然而現有IPv4網路是如此的龐大,以至於短時間之內不可能將它全部廢除。因此,需要尋找一種合適的過渡技術來解決這一難題。由於無狀態IP/網際網路控制訊息協議翻譯演算法(SIIT)、網路地址翻譯-協議轉換器(NAT-PT)和棧內凸塊(BIS)等過渡技術都存在著這樣那樣的缺點,隧道技術又不能解決IPv6節點與IPv4節點之間相互通訊的問題,而在網路中應用代理服務既可以充分利用IP地址資源,又能夠保證網路安全,尤其是全能代理協議SOCKS,它可以完成網頁瀏覽、檔案傳輸和遠端登陸等所有工作的代理,是可用的功能最強大、應用最靈活、安全性較高的代理,因而基於具有強大功能的SOCKS代理的IPv4向IPv6過渡技術已經成為一種不錯的選擇。基於SOCKS的過渡技術分為兩種。一種是API內凸塊(BIA)技術,這種技術直接在雙棧主機上實現IPv4和IPv6的地址轉換;另一種是SOCKS64技術,這種技術是通過一個雙棧閘道器來進行IPv4和IPv6的地址轉換。

二、BIA技術

BIA技術在雙棧主機的SocketAPI模組與TCP/IP模組之間加入一個API翻譯器(如圖1所示)。API翻譯器包含三個模組:域名解析器,地址對映器和函式對映器。其中,域名解析器負責對IPv4應用程式的請求域名返回一個正確的應答,地址對映器在主機內部維護一張IPv4與IPv6地址對的表格(分配的IPv4地址來自IPv4地址池中,採用未使用的IPv4地址,如0.0.0.1~ 0.0.0.255),函式對映器負責在IPv4的Socket API函式與IPv6的Socket API函式間相互翻譯。


圖1 採用BIA機制的雙棧主機的結構模型

RFC3338中描述了採用BIA機制的雙棧主機與IPv6主機之間相互通訊的過程。其中雙棧主機DualStack向IPv6主機Host6發起通訊的過程如下:

·當雙棧主機DualStack上的IPv4應用向它的域名伺服器(DNS)傳送查詢目的主機的地址請求時,域名解析器攔截了這個請求,併產生一個新的查詢請求轉發給DNS來解析A和AAAA兩種記錄。

·DNS解析出Host6的AAAA記錄後,將它返回給域名解析器。

·域名解析器要求地址對映器為IPv6地址分配一個IPv4地址。

·地址對映器在IPv4地址池中選擇一個未用的保留地址,在對映表中註冊後返回給域名解析器。

·域名解析器為分配的IPv4地址產生一條A記錄,返回給IPv4應用程式。

·IPv4應用程式呼叫IPv4的SocketAPI函式,函式對映器對呼叫命令進行攔截,判斷其是否來自於IPv6的應用。若不是,跳過翻譯程式;否則,函式對映器向地址對映器請求該IPv4地址對應的IPv6地址,地址對映器從對映表中查詢後將結果返回。函式對映器使用收到的這個AAAA型地址呼叫Host6上相應的IPv6socketAPI函式。

·當函式對映器接收到Host6上IPv6socketAPI函式的應答後,向地址對映器請求與Host6對應的IPv4地址。然後,函式對映器利用此IPv4地址繼續完成socketAPI函式的呼叫。
由IPv6主機Host6發起到雙棧主機DualStack的通訊過程相對簡單一些。Host6通過它的DNS解析DualStack的AAAA記錄,然後向DualStack傳送一個IPv6的資料包。為了通過呼叫IPv4的API函式和IPv4應用通訊,函式對映器檢測到IPv6資料包到達Dual Stack後,向地址對映器傳送一個IPv4地址請求,並用返回的IPv4地址發起一個IPv4的Socket API呼叫。然後,函式對映器再向地址對映器請求與該IPv4地址對應的原來的IPv6地址,按照這個地址對Host6答覆。 三、SOCKS64技術

SOCKS64技術是原有SOCKS協議(IETFRFC1928)的擴充套件,相當於IP層的代理,其原理如圖2所示。它增加了兩個新的功能部件*SocksLib*和*Gateway*。*SocksLib*是在客戶機一端引入的,它位於應用層和Socket層之間,可以替代應用程式的Socket API和DNS域名解析API。在*Socks Lib*中有一個DNS域名解析代表,它在源節點(客戶機C)全權代表到中繼伺服器(閘道器G)的域名解析行為。*Gateway*是安裝在IPv6和IPv4雙棧閘道器上的一個增強型的SOCKS伺服器,可以完成客戶機C(IPvX)和目的端D之間的任何協議組合型別的中繼。當*Socks Lib*呼叫中繼時,由父*Gateway*來產生出一個*Gateway*程式(執行緒)來負責中繼連線。






圖2 採用SOCKS64技術的網路通訊原理

在SOCKS5中規定,IPv4地址、IPv6地址和域名的全限定域名(FQDN)資訊可以用在SOCKS協議格式的地址型別(ATYP)域。SOCKS64技術就是利用這一點,通過DNS域名解析代表將FQDN資訊用在ATYP域中從客戶機C傳到閘道器G來指出目的地D的位置。

為此,SOCKS64技術也和BIA技術一樣使用了IPv4中未使用的保留地址(稱之為偽IP地址),並在*SocksLib*(客戶機C處)中引入一個對映表來管理偽IP地址和FQDN之間的對映。

客戶機C[IPvX]使用SOCKS64技術通過雙棧閘道器G[IPvX|IPvY]與目的主機D[IPvY]通訊的過程如下:

·源節點(客戶機C)上的應用盡力通過呼叫DNS域名解析函式來獲得目的節點(目的地D)的IP地址資訊。這時,目的地D的邏輯主機名(即FQDN)資訊被作為被呼叫的API的一個引數傳遞給應用的*SocksLib*。

·FQDN資訊被註冊到*SocksLib*中的一個對映表內。*SocksLib*選擇一個偽IP地址回覆給應用。

·應用利用收到的偽IP地址資訊組織一個socket,並將socket用作API的一個引數來呼叫socketAPI啟動通訊。

·由於*SocksLib*已經取代了這些socketAPI,真正的socket函式將不再呼叫,而是先檢查socket的IP地址資訊。如果該地址是偽IP地址,則從對映表中獲取與該偽IP地址相匹配的登記過的FQDN資訊。通過使用與呼叫的socketAPI相匹配的SOCKS命令(例如與conNECt()對應的CONNECT命令),FQDN資訊被傳送到中繼伺服器(閘道器G)上的*Gateway*。

·*Gateway*通過接收到的FQDN資訊呼叫真正的DNS域名解析API從一個DNS伺服器處獲得一個真IP地址,並利用真IP地址資訊建立一個socket。*Gateway*再將socket用作API的一個引數來呼叫socketAPI與目的地D通訊。

四、技術比較分析

雖然BIA與SOCKS64都是為了使IPv4能夠順利過渡到IPv6的技術,都是基於SOCKS的技術,都是採用雙棧主機思想,都需要使用偽IP地址,但是它們的出發點卻各有側重,也各有優缺點。

1.適用性

BIA與SOCKS64都可以使IPv4應用在不作任何修改的情況下與IPv6主機通訊。BIA技術提供的是具有IPv4和IPv6協議的雙棧主機直接與IPv6主機通訊的解決方案,SOCKS64技術是提供了IPv4主機通過雙棧閘道器與IPv6主機通訊的解決方案。

2.預留IP地址的使用

BIA與SOCKS64都使用預留IP地址。雖然BIA技術中的地址池可以在節點中以不同的粒度來實現,然而如果大量的IPv4應用和IPv6的主機通訊時,可能耗盡可用地址,導致IPv4應用不能和IPv6的主機通訊,所以需要對地址池內的地址進行有效管理。SOCKS64技術由於主要使用FQDN資訊、通過DNS域名解析代表在*SocksLib*處負責域名管理工作,偽地址必須被作為臨時值來處理,所以不需要為地址對映預留很大的地址空間,也不需要複雜的地址申請和垃圾收集機制。

3.對應用的支援

BIA與SOCKS64的初衷都是不需要修改IPv4應用而與IPv6主機通訊。但是它們對應用的支援都不能達到盡善盡美。對於BIA來說,由於需要轉換嵌在應用層協議中的IP地址(例如FTP),所以這種機制可能不適用於那些其負載中包含地址的新應用。BIA僅支援單播通訊,如果要支援組播通訊,還需要在函式對映模組中增加新的功能。BIA只是從語義上將IPv4SocketAPI函式轉換成相應的IPv6Socket API函式,如果在API函式中轉換內嵌於應用層協議的IP地址,其實現有賴於作業系統。由於IPv6的API具有新的高階引數,轉換帶有這種引數的IPv6 API是很困難的,因此接收到的帶有高階引數的IPv6資料包會被丟棄。對於SOCKS64來說,雖然它是直接繼承SOCKS機制的技術,但是在使用時仍有一定的問題。SOCKSv5協議由三個命令(CONNECT、BIND和UDP ASSOCIATE)組成,所有這三個命令在SOCKS64中都能使用。其中,主要的命令也是使用最頻繁的命令CONNECT沒有明確的弱點,可以不加考慮地隨意使用它。而BIND命令基本上是為支援FTP型別應用的反向通道聚合而設計的,所以通常的BIND命令的使用可能會導致一些問題。UDP ASSOCIATE命令基本上是為簡單UDP應用(如archie)而設計的,所以在支援同時使用TCP和UDP的一大類應用時通用性還不夠。另外,如果有些應用使用了非常靈活的、特別的方式建立連線,SOCKS64技術就無能為力了。

4.DNS查詢結果與另一端應用程式版本不匹配問題

對於BIA,若正在使用的伺服器端應用不支援IPv6,但是它又執行在一臺支援其他IPv6服務的主機上,而且這臺主機還在DNS中以AAAA型記錄出現,在DNS的查詢結果和伺服器應用的版本之間就出現了不匹配的情況。這時,使用BIA的IPv4客戶端應用可能連線不到這個伺服器端應用上。解決方法是嘗試所有在DNS中列出的地址,而不應只嘗試一次即宣告失敗。但是對於UDPsocket,即便可能,BIA也很難發現可工作的IP地址,因此應用必須重複嘗試各種可能的地址,直到發現一個可用地址為止。另一種避免這種問題的方法是僅當通訊對端的A型記錄不存在時,BIA才發生作用。這樣,一臺採用BIA的雙棧主機上的應用到另一臺雙棧主機的資料流只使用IPv4協議。對於SOCKS64則不存在這個問題。

5.安全性

對於BIA,由於它採用了API翻譯器,很難實現端到端的安全性,而且傳輸層和應用層的安全也同樣無法實現。但是,由於翻譯機制發生在socketAPI層,採用BIA機制執行IPv4應用的主機和其他IPv6主機通訊時,可以利用網路層的安全策略(如IPsec)。另外,由於預留IP地址的使用,有地址耗盡的可能,這就使得使用這種機制的主機易於遭到拒絕服務***。對於SOCKS64,由於它是直接建立在SOCKSv5協議基礎上的,其安全方面的特點與SOCKSv5相一致。它同樣不提供從原始源節點到最終目的節點的整體端到端的安全保證。但是由於它建立了應用層兩個“分開的”連線的中繼,所以端到端的安全就由這兩個被中繼的連結來提供保證。

五、結語

基於SOCKS的IPv4向IPv6過渡技術主要有BIA與SOCKS64兩種,它們都採用雙棧主機和IPv4預留地址思想,使IPv4應用在不作任何修改的情況下與IPv6主機通訊。BIA技術提供的是具有IPv4和IPv6協議的雙棧主機直接與IPv6主機通訊的解決方案,SOCKS64技術是提供了IPv4主機通過雙棧閘道器與IPv6主機通訊的解決方案。也正由於它們是兩種不同的解決方案,才使得它們分別具有各自的優點和缺點。在實際應用時,可以根據具體情況確定採用哪種技術,並根據需要對它們加以改進。