基于虛擬網(wǎng)卡的ＳＳＬ ＶＰＮ體系結(jié)構(gòu)的研究

摘要：為了打破傳統(tǒng)的SSL VPN(secure socket layer virtual private network)局限于支持Web的應用，不能滿足諸如OA、ERP、FTP等非Web應用需求的局限，提出了一種基于虛擬網(wǎng)卡的SSL VPN（VNICB－SSL VPN）體系結(jié)構(gòu)。基于虛擬網(wǎng)卡的技術成功地解決了NDIS（network driver interface specification，網(wǎng)絡驅(qū)動接口規(guī)范）框架中的軟件沖突問題，也避免了WinSock2動態(tài)鏈接庫重載、傳輸層過濾驅(qū)動截獲網(wǎng)絡報文不夠徹底的問題。

關鍵詞：安全套接字層/傳輸層安全性協(xié)議；虛擬專用網(wǎng)絡；虛擬網(wǎng)卡

中圖分類號：TP393文獻標志碼：A

文章編號：1001-3695(2007)12-0327-03

隨著市場的逐步成熟，有越來越多的理由期待SSL VPN 成為企業(yè)的首選VPN 設備。然而SSL VPN^[1] 相對IPSec VPN的種種優(yōu)點，對于應用VPN的大、中型企業(yè)來說，卻顯得微不足道。一個企業(yè)往往運行了很多并不基于Web的應用，如OA（office automation，辦公自動化）、財務、銷售管理、ERP（enterprise resource planning，企業(yè)資源計劃）等，單純只有Web應用的企業(yè)極少。這為SSL VPN大規(guī)模的推廣和應用帶來了很大的障礙。為了使SSL VPN支持更多的應用，首先要解決的問題就是截獲這些應用程序的數(shù)據(jù)報文，并對這些數(shù)據(jù)報文進行SSL處理。本文針對目前流行的報文截獲技術進行分析，提出了一種基于虛擬網(wǎng)卡的SSL VPN的體系結(jié)構(gòu)。基于虛擬網(wǎng)卡技術的截包方案解決了其他截包技術中存在的問題，并為SSL VPN帶來了新的應用特性，取得了很好的實際效果。

1報文截獲技術的分析

為了使SSL VPN^[2]能夠支持更多的應用，必須截獲應用程序發(fā)給服務器的數(shù)據(jù)報文，并進行相應的處理。目前比較流行的截包模式有以下三種：

a)WinSock2動態(tài)鏈接庫重載模式。系統(tǒng)的WinSock2動態(tài)鏈接庫Winsock.dll隨系統(tǒng)啟動而載入內(nèi)存，提供29個用于網(wǎng)絡傳輸?shù)墓δ芎瘮?shù)。IE等普通上層應用程序，調(diào)用WinSock2動態(tài)鏈接庫中的函數(shù)實現(xiàn)網(wǎng)絡收、發(fā)功能。修改注冊表項，建立新的自定義入口函數(shù)，可以重載Winsock.dll。通過重載Winsock.dll中的有關網(wǎng)絡收、發(fā)函數(shù)，增加網(wǎng)絡封包收、發(fā)前、后的自定義處理功能，實現(xiàn)網(wǎng)絡封包截獲。但其最致命的缺點是不用socket的網(wǎng)絡通信無法攔截，如使用NetBIOS的網(wǎng)上鄰居和使用ICMP協(xié)議的ping。

b)傳輸層過濾驅(qū)動模式。使用NDIS技術，又稱為TDI(transport driver interface，傳輸層驅(qū)動接口）編程。Windows 2000和Windows XP操作系統(tǒng)中，TCP/IP作為系統(tǒng)驅(qū)動程序TcpIp.sys，在系統(tǒng)啟動時加載入系統(tǒng)內(nèi)存，以TCP/IP設備對象的形式供應用程序或其他系統(tǒng)程序調(diào)用。傳輸層過濾驅(qū)動程序創(chuàng)建一個或多個設備對象，直接掛接到TCP/IP設備對象之上成功后，當其他程序使用網(wǎng)絡傳輸功能，調(diào)用TCP/IP設備對象時，操作系統(tǒng)首先將該調(diào)用映射到TCP/IP設備對象之上所掛接的傳輸層過濾驅(qū)動程序；通過傳輸層過濾驅(qū)動程序，再調(diào)用下層的TCP/IP設備對象，從而完成網(wǎng)絡訪問功能。同樣，從TCP/IP層上傳至應用程序的網(wǎng)絡封包，也要經(jīng)傳輸層過濾驅(qū)動程序后，再轉(zhuǎn)發(fā)至目標應用程序端口。基于此工作原理，可以在傳輸層過濾驅(qū)動程序中實現(xiàn)網(wǎng)絡封包截獲，完成網(wǎng)絡封包的過濾及加/解密處理。但是，傳輸層過濾驅(qū)動屬于上層驅(qū)動，位于 TcpIp.sys之上。這就意味著由 TcpIp.sys接收并直接處理的數(shù)據(jù)包不會傳送到上面，從而無法過濾某些接收的數(shù)據(jù)包。典型的就是ICMP、ICMP的應答包直接由TcpIp.sys生成并回應，上面的過濾驅(qū)動程序全然不知。

NDIS中間層驅(qū)動程序模式^[3]。與傳輸層過濾驅(qū)動實現(xiàn)基本原理一致，也是使用NDIS技術。主要差別在于，中間層驅(qū)動程序掛接在協(xié)議設備對象（包括TCP/IP設備對象）與網(wǎng)卡設備對象之間。任何進出網(wǎng)卡的網(wǎng)絡封包，均必須首先經(jīng)過中間層驅(qū)動程序的處理。從結(jié)構(gòu)上分析，中間層驅(qū)動程序更像一個虛擬網(wǎng)卡。該虛擬卡封裝了物理網(wǎng)卡，對物理網(wǎng)卡的一切網(wǎng)絡訪問操作，均必須先經(jīng)虛擬卡處理。但是NDIS需要在主入口函數(shù)DriverEntry中，根據(jù)驅(qū)動程序類型使用不同的注冊函數(shù)，向NDIS框架注冊自己的輸出函數(shù)集入口。隨著人們對網(wǎng)絡安全需求的不斷增加，各種網(wǎng)絡安全系統(tǒng)應運而生。例如安全代理軟件、個人防火墻、實時網(wǎng)絡病毒防護、網(wǎng)絡地址轉(zhuǎn)換等流行的網(wǎng)絡安全系統(tǒng)往往也需要對網(wǎng)絡報文進行透明的安全處理。但是普通實現(xiàn)者無法在Windows操作系統(tǒng)中將這些處理無縫地融入到協(xié)議棧中，因此它們越來越多地選擇使用中間層驅(qū)動技術。當眾多的處理模塊同時向NDIS注冊自己的處理函數(shù)，而這些函數(shù)又對流經(jīng)協(xié)議棧的網(wǎng)絡報文進行類似的操作時（如修改網(wǎng)絡報文首部參數(shù)、過濾報文數(shù)據(jù)等），就很容易引起沖突。輕者導致安全系統(tǒng)不可用，重者將導致系統(tǒng)崩潰且很難恢復。

針對以上的截包技術中存在的問題，本文提出了基于虛擬網(wǎng)卡的SSL VPN的體系結(jié)構(gòu)，解決了其他數(shù)據(jù)包截取技術中存在的被繞開和軟件沖突的問題，并且可以使其支持更多的應用，取得了較好的實際應用效果。

2虛擬網(wǎng)卡驅(qū)動工作原理

用tun/tap驅(qū)動程序來實現(xiàn)虛擬網(wǎng)卡的功能。Tun表示虛擬對象是點對點設備；tap則表示虛擬對象是以太網(wǎng)設備。這兩種設備針對網(wǎng)絡數(shù)據(jù)包實施不同的封裝。利用tun/tap驅(qū)動，可以將TCP/IP協(xié)議棧處理好的網(wǎng)絡分包傳給任何一個使用tun/tap驅(qū)動的進程，由進程重新處理后再發(fā)送到物理鏈路中。

Tun/tap虛擬網(wǎng)卡驅(qū)動程序的工作原理如圖1所示。作為虛擬網(wǎng)卡驅(qū)動，tun/tap驅(qū)動程序的數(shù)據(jù)接收和發(fā)送并不直接與真實網(wǎng)卡打交道，而是通過用戶態(tài)來轉(zhuǎn)交。在Linux下，要實現(xiàn)核心態(tài)與用戶態(tài)數(shù)據(jù)的交互，有多種方式。例如可以通過socket創(chuàng)建特殊套接字，利用套接字實現(xiàn)數(shù)據(jù)交互；通過proc文件系統(tǒng)創(chuàng)建文件來進行數(shù)據(jù)交互；還可以使用設備文件的方式。訪問設備文件會調(diào)用設備驅(qū)動相應的例程。設備驅(qū)動本身就是核心態(tài)與用戶態(tài)的一個接口。Tun/tap驅(qū)動就是利用設備文件實現(xiàn)用戶態(tài)與核心態(tài)的數(shù)據(jù)交互。

由圖1可知，tun/tap驅(qū)動并不單純是實現(xiàn)網(wǎng)卡驅(qū)動，它包括字符設備驅(qū)動和虛擬網(wǎng)卡驅(qū)動兩個部分。虛擬網(wǎng)卡驅(qū)動部分接收來自TCP/IP協(xié)議棧的網(wǎng)絡分包并發(fā)送或者反過來將接收到的網(wǎng)絡分包傳給協(xié)議棧處理。字符驅(qū)動部分則以字符設備的方式連接用戶態(tài)和核心態(tài)，將網(wǎng)絡分包在內(nèi)核與用戶態(tài)之間傳送，模擬物理鏈路的數(shù)據(jù)接收和發(fā)送。

Tun/tap設備提供的虛擬網(wǎng)卡驅(qū)動，從TCP/IP協(xié)議棧的角度而言，它與真實的網(wǎng)卡驅(qū)動并沒有區(qū)別；從驅(qū)動程序的角度來說，它與真實網(wǎng)卡的不同表現(xiàn)在tun/tap設備獲取的數(shù)據(jù)不是來自物理鏈路，而是來自用戶區(qū)。Tun/tap設備驅(qū)動通過字符設備文件來實現(xiàn)數(shù)據(jù)從用戶區(qū)的獲取。發(fā)送數(shù)據(jù)時tun/tap設備也不是發(fā)送到物理鏈路，而是通過字符設備發(fā)送至用戶區(qū)，再由用戶區(qū)程序通過其他渠道發(fā)送。

根據(jù)對虛擬網(wǎng)卡技術的分析可知，虛擬網(wǎng)卡是在驅(qū)動程序中攔截，因此它可以避免WinSock2動態(tài)鏈接庫重載和TDI編程中數(shù)據(jù)報文無法攔截的情況。另外，當網(wǎng)絡報文經(jīng)過協(xié)議棧到達虛擬網(wǎng)卡時，虛擬網(wǎng)卡獨占對該報文的處理權(quán)限，從而避免使用中間層驅(qū)動技術時多個模塊同時對網(wǎng)絡報文進行相互修改而導致的沖突。

3基于虛擬網(wǎng)卡技術的SSL VPN

3．1體系結(jié)構(gòu)

VNICB－SSL VPN的體系結(jié)構(gòu)^[4]如圖2所示。其主要包括主控模塊、規(guī)則庫模塊、SSL處理模塊、字符設備驅(qū)動和虛擬網(wǎng)卡等模塊。

各個模塊的主要功能及模塊間的交互如下：

a)主控模塊。該模塊是整個系統(tǒng)的中心樞紐，負責整個系統(tǒng)業(yè)務流程的調(diào)度；通過調(diào)用其他模塊提供的接口實現(xiàn)對數(shù)據(jù)報文的安全處理，包括以下主要功能：

（a）進行隧道協(xié)商，交換密鑰信息和協(xié)商加密算法，通過PKI系統(tǒng)進行通信雙方的身份認證，并將加密算法和密鑰信息交付給SSL處理模塊。

（b）調(diào)用SSL處理模塊的接口對需要進行處理的數(shù)據(jù)報文進行加密或解密，保證數(shù)據(jù)傳輸?shù)陌踩?/p>

（c）負責與字符設備驅(qū)動、協(xié)議棧進行數(shù)據(jù)交互。

（d）查找規(guī)則庫模塊，根據(jù)規(guī)則來決定數(shù)據(jù)報文是丟棄還是發(fā)送。

b)規(guī)則庫模塊。在SSL隧道建立以后，主控模塊向服務器發(fā)送規(guī)則下發(fā)請求；服務器收到請求后下發(fā)規(guī)則，它與主控模塊進行交互；主控模塊通過查找規(guī)則庫來決定對網(wǎng)絡報文進行何種處理。規(guī)則庫是由路由規(guī)則和IP規(guī)則兩部分組成。在啟動虛擬網(wǎng)卡時，主控模塊根據(jù)規(guī)則庫生成路由表，交給協(xié)議棧。IP規(guī)則包含IP地址（可能是主機地址，也可能是個地址范圍）、端口列表、協(xié)議類型和規(guī)則匹配后的動作（放行或丟棄）。

c)SSL處理模塊。該模塊用于對服務器和客戶端之間的數(shù)據(jù)報文進行加/解密。通過這個安全編碼的過程形成一個客戶端與服務器之間的保密通信隧道。該模塊與主控模塊進行交互。主控模塊把要發(fā)送的數(shù)據(jù)報文交給SSL處理模塊進行加/解密處理；處理完后，SSL處理模塊把處理后的報文交給主控模塊進行轉(zhuǎn)發(fā)。

d)虛擬網(wǎng)卡模塊。該模塊負責與協(xié)議棧和字符驅(qū)動模塊進行交互。將協(xié)議棧交付的數(shù)據(jù)包通過字符驅(qū)動模塊提交給主控模塊進行SSL加密處理；將主控模塊SSL解密后的數(shù)據(jù)包通過協(xié)議棧提交給用戶應用程序。由于虛擬網(wǎng)卡并沒有對應的物理網(wǎng)卡，其不必實現(xiàn)與物理網(wǎng)卡進行交互的接口，僅僅完成與協(xié)議棧之間的交互接口就能夠完成功能。

e)字符驅(qū)動模塊。該模塊是以字符設備的方式連接用戶態(tài)和核心態(tài)，將數(shù)據(jù)報文在虛擬網(wǎng)卡與主控模塊之間傳送，模擬物理鏈路的數(shù)據(jù)接收和發(fā)送。

3．2系統(tǒng)的通信過程

在啟動虛擬網(wǎng)卡之前，必須為虛擬網(wǎng)卡配置相應的IP地址（虛擬IP地址）、子網(wǎng)掩碼等參數(shù)；還需要在系統(tǒng)中添加兩條虛擬路由信息：一條路由信息的目的網(wǎng)絡是該隧道保護的目的網(wǎng)絡，本地接口配置成虛擬IP地址；另一條路由信息為“源：虛擬IP地址，目的：保護子網(wǎng)”。

圖2中使用順序標志S標明了發(fā)送報文時VNICB－SSL VPN系統(tǒng)的處理流程。用戶應用程序訪問遠程保護子網(wǎng)內(nèi)的某一臺主機時，會向協(xié)議棧發(fā)送一個目的地址在遠程保護子網(wǎng)內(nèi)的IP數(shù)據(jù)包。協(xié)議棧匹配到虛擬路由，則將該報文的源地址字段填入虛擬IP地址；同時將其交付給虛擬網(wǎng)卡進行發(fā)送，虛擬網(wǎng)卡接收到報文后，通過字符驅(qū)動模塊將該報文提交給主控模塊。主控模塊接收到的報文如圖3所示。原始IP首部中的源IP地址為虛擬IP地址；目的IP地址為遠程保護子網(wǎng)內(nèi)的主機地址。

主控模塊通過查找規(guī)則庫對接收數(shù)據(jù)包進行檢測，查看數(shù)據(jù)包的IP地址是否在IP規(guī)則的IP地址范圍內(nèi)。如果匹配成功，則查看端口是否匹配，根據(jù)匹配結(jié)果查看規(guī)則匹配后的動作決定對數(shù)據(jù)包進行的操作。如果是放行就把數(shù)據(jù)交給SSL處理模塊進行加密處理，SSL處理后的模塊通過記錄的遠端socket套接字將報文發(fā)送到協(xié)議棧。由于套接字連接的目的地址是遠程SSL VPN網(wǎng)關的外口地址，協(xié)議棧匹配相應的路由后將報文的源地址字段填充為實際網(wǎng)卡的地址，把目的地址字段填充為遠程SSL VPN網(wǎng)關的外口地址，此時的報文格式如圖4所示，然后將該報文交給實際網(wǎng)卡發(fā)送到網(wǎng)絡中。

當SSL VPN網(wǎng)關設備收到數(shù)據(jù)包之后，上交給協(xié)議棧，協(xié)議棧根據(jù)目的地址和端口將其交給主控模塊；主控模塊報數(shù)據(jù)模塊交給SSL處理模塊進行解密。由于解密之后的IP報文的目的地址是VPN網(wǎng)關保護子網(wǎng)內(nèi)的地址，VPN網(wǎng)關將其交付給保護子網(wǎng)內(nèi)的主機。

VNICB－SSL VPN系統(tǒng)接收報文的流程與發(fā)送報文的流程相反。圖2中使用順序標志R標明了接收報文時VNICB－SSL VPN系統(tǒng)的處理流程。實際網(wǎng)卡接收到對端VNICB－SSL VPN系統(tǒng)發(fā)送的經(jīng)過SSL加密處理的報文。其報文結(jié)構(gòu)與圖4類似，只是新IP首部中源地址是對端VPN系統(tǒng)的外口地址，而目的地址是本地實際網(wǎng)卡地址。實際網(wǎng)卡通過協(xié)議棧將該報文交付給主控模塊。主控模塊通過與SSL處理模塊交互進行解密處理。解密的報文結(jié)構(gòu)與圖3類似，但原始IP首部中源地址是對端保護子網(wǎng)內(nèi)的地址，而目的地址是虛擬IP地址。主控模塊通過字符驅(qū)動模塊將解密后的報文交付給虛擬網(wǎng)卡；虛擬網(wǎng)卡再次將該報文交付給協(xié)議棧，協(xié)議棧會認為從虛擬網(wǎng)卡收到一個報文，并將其交付給用戶應用程序。

從用戶應用程序的角度看，報文的發(fā)送和接收似乎都是通過虛擬IP地址進行的，從而實現(xiàn)了數(shù)據(jù)包的SSL加/解密處理對用戶應用程序的透明。

4系統(tǒng)分析

由于虛擬網(wǎng)卡對于操作系統(tǒng)而言就像一塊真正的物理網(wǎng)卡，其IP地址就是配置的虛擬IP地址，操作系統(tǒng)可以對其進行所有真正物理網(wǎng)卡可以進行的控制，如收發(fā)數(shù)據(jù)包、禁用、啟用、掛起、查詢狀態(tài)和綁定TCP/IP、IPX協(xié)議等。將其應用到SSL VPN中，可以使SSL VPN支持HTTP、FTP、TELNET等更多的應用，并可以實現(xiàn)NAT等高級應用。

當數(shù)據(jù)包經(jīng)過協(xié)議棧到達虛擬網(wǎng)卡時，虛擬網(wǎng)卡獨占對該數(shù)據(jù)包的處理權(quán)限，從而避免了使用中間驅(qū)動程序技術時多個模塊對數(shù)據(jù)包的相互修改而導致的沖突。再者，即使存在對同一報文的多種處理，由于協(xié)議棧和虛擬網(wǎng)卡對數(shù)據(jù)報的處理順序總是固定的，發(fā)送的數(shù)據(jù)包報文總是先經(jīng)過協(xié)議棧處理；接收的數(shù)據(jù)包報文總是先經(jīng)過虛擬網(wǎng)卡再提交給協(xié)議棧，也可以對處理結(jié)果進行預測和控制。

通過對數(shù)據(jù)包的處理流程分析可知，如果發(fā)送的數(shù)據(jù)包需要用SSL VPN對其進行加密處理，則在進行加密之前，由于匹配了虛擬路由，可直接使用虛擬IP地址作為原始IP報文的源地址，且不會與實際網(wǎng)卡的IP地址發(fā)生任何關系。這樣VPN網(wǎng)關設備對發(fā)送給對端系統(tǒng)的回應報文進行封裝時，其原始IP報文的目的地址就是虛擬IP地址。如果網(wǎng)絡報文是不需要經(jīng)過SSL VPN加密的非隧道通信報文，則在第一次交付協(xié)議棧時不會匹配虛擬路由。協(xié)議棧會將其直接交給實際網(wǎng)卡進行發(fā)送。因此虛擬網(wǎng)卡的存在和其參數(shù)配置并不會影響到用戶非隧道通信的正常進行。

如圖5所示，移動用戶通過ADSL撥號獲得202.112.20.131的實際地址，與VPN網(wǎng)關設備建立隧道，網(wǎng)關保護子網(wǎng)為192.168.20.0/24。配置移動用戶的虛擬網(wǎng)卡IP地址為192.168.20.73/24。在移動用戶打開Outlook應用程序訪問192.168.20.0/24網(wǎng)段的notes服務器時，系統(tǒng)會發(fā)送目的地址為192.168.100.91的廣播報文。該報文經(jīng)過規(guī)則庫匹配，然后經(jīng)過SSL模塊加密處理后發(fā)送到VPN網(wǎng)關，VPN解密之后會將其交給保護子網(wǎng)192.168.20.91/24子網(wǎng)內(nèi)的所有主機，從而實現(xiàn)移動用戶與保護子網(wǎng)內(nèi)的服務器之間的透明通信。如果在網(wǎng)關上配置該用戶具有訪問遠端子網(wǎng)所有資源的權(quán)限，那么該用戶就好像置身于遠端子網(wǎng)中。這在傳統(tǒng)SSL VPN結(jié)構(gòu)中是無法簡單實現(xiàn)的。

5結(jié)束語

由VNICB－SSL VPN的系統(tǒng)結(jié)構(gòu)可知，基于虛擬網(wǎng)卡的SSL VPN是一種全功能的SSL VPN實現(xiàn)方法。VNICB－SSL VPN可以用來構(gòu)建外聯(lián)網(wǎng)、內(nèi)聯(lián)網(wǎng)和遠程接入訪問，使SSL VPN不再局限于支持Web瀏覽器的應用，可以支持更多的應用，更大地擴充了其應用范圍，能夠更好地滿足用戶的需求。另外，基于虛擬網(wǎng)卡的SSL VPN從根本上解決了NDIS框架中的軟件沖突問題，也避免了WinSock2動態(tài)鏈接庫重載、傳輸層過濾驅(qū)動截獲網(wǎng)絡報文不夠徹底及被繞開等問題。

顯然，從對數(shù)據(jù)包處理流程的分析中可以看出，需要進行SSL VPN加密的報文無論是發(fā)送還是接收都會兩次經(jīng)過協(xié)議棧處理， 這自然會在一定程度上導致數(shù)據(jù)交互性能下降^[5]。因此基于虛擬網(wǎng)卡技術的VPN系統(tǒng)目前比較適合于對傳輸性能要求不高的場合。該系統(tǒng)已經(jīng)成功地實現(xiàn)，并取得了很好的實際應用效果。

參考文獻：

[1]包麗紅，李立亞.基于SSL的VPN技術研究[J].網(wǎng)絡安全技術與應用，2004(5)：38-40.

[2]HARDING A. SSL virtual private networks[J].Computers and Security，2003，22(5)：416-420.

[3]DIERKS T， ALLEN C C. RFC 2246， Transport layer security version 1.0[S]. 1999.

[4]韓衛(wèi)，薛健，白靈. 一種基于安全隧道技術的SSL VPN及其性能分析[J].科學技術與工程，2005，5(12)：791-796.

[5]COHEN R.On the establishment of an access VPN in broadband access networks[J].IEEE Communications Magazine， 2003，41(2)：156－163.

“本文中所涉及到的圖表、注解、公式等內(nèi)容請以PDF格式閱讀原文”