基于虛擬網卡的ＳＳＬ ＶＰＮ體系結構的研究

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

關鍵詞：安全套接字層/傳輸層安全性協議；虛擬專用網絡；虛擬網卡

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

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

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

1報文截獲技術的分析

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

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

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

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

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

2虛擬網卡驅動工作原理

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

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

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

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

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

3基于虛擬網卡技術的SSL VPN

3．1體系結構

VNICB－SSL VPN的體系結構^[4]如圖2所示。其主要包括主控模塊、規則庫模塊、SSL處理模塊、字符設備驅動和虛擬網卡等模塊。

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

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

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

（b）調用SSL處理模塊的接口對需要進行處理的數據報文進行加密或解密，保證數據傳輸的安全。

（c）負責與字符設備驅動、協議棧進行數據交互。

（d）查找規則庫模塊，根據規則來決定數據報文是丟棄還是發送。

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

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

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

e)字符驅動模塊。該模塊是以字符設備的方式連接用戶態和核心態，將數據報文在虛擬網卡與主控模塊之間傳送，模擬物理鏈路的數據接收和發送。

3．2系統的通信過程

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

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

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

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

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

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

4系統分析

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

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

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

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

5結束語

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

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

參考文獻：

[1]包麗紅，李立亞.基于SSL的VPN技術研究[J].網絡安全技術與應用，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]韓衛，薛健，白靈. 一種基于安全隧道技術的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.

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