通過第一篇的介紹，大家瞭解到SSL VPN與IPSec相較的巧妙之處在於可以將遠程用戶的訪問粒度細化到指定的資源對象，例如一個文件或者一個URL。爲了讓遠程用戶對自己的訪問權限一目瞭然，虛擬網關提供了一個特別友好、特別人性化的平臺：將若干文件和URL組合成“私人定製”資源清單呈現給遠程用戶。這就好比虛擬網關是新潮的時尚餐廳，不僅賣美食還賣定製化服務，可以爲不同口味的顧客定製不同的菜單。不僅如此，由於大多數企業出於安全考慮都不想對外公開內網服務器資源地址（URL或文件路徑），爲此SSL VPN還提供了“資源地址加密”服務--對資源路徑進行了巧妙改寫，讓遠程用戶既能順暢訪問內網資源，又很難找到內網資源地址。這就好比給白菜豆腐起名爲翡翠白玉，紅椒綠椒冠以絕代雙驕，乍一看挺玄乎費點腦筋才能搞懂其中奧妙。
華爲防火牆SSL VPN爲大家準備了豐盛的菜餚，提供了定製化菜單服務，還附贈了腦筋急轉彎似的小節目，希望顧客在品嚐美味的同時能收穫美麗的心情！
口味：對文件的訪問----菜系：文件共享功能
菜系簡介：SSL VPN的文件共享功能，簡單說就是能夠讓遠程接入用戶能夠直接通過瀏覽器安全的訪問企業內部的文件服務器，而且支持新建、修改、上傳、下載等常見的文件操作。目前，在企業中較爲流行的文件共享協議包括SMB（Server Message Block）和NFS（Network File System），前者主要應用於Windows操作系統，後者主要應用在Linux操作系統。華爲防火牆的SSL VPN對這兩種協議已經兼顧到了，小夥伴們不必擔心。接下來的內容以SMB協議爲例，並藉助域控制器這種常用的鑑權方式，介紹文件共享的交互過程。
如下圖所示，可以看出防火牆作爲代理設備，與客戶端之間的通信始終是通過安全HTTPS（HTTP+SSL）協議加密傳輸，當加密報文抵達防火牆後，防火牆對其解密後並進行協議轉換，最終作爲SMB客戶端，向相應的SMB文件共享服務器發起請求，其中還包含了文件服務器認證的過程。從通信所使用協議的角度，以上過程可以概況爲兩個階段：
1）遠程接入用戶作爲Web Client與防火牆作爲Web Server之間的HTTPS交互。
2）防火牆作爲SMB Client與文件服務器SMB Server之間的SMB交互。
準備文件共享資源菜單（配置文件共享資源）
在正式介紹交互之前，我們首先假設在SMB文件服務器（以Windows Server 2008爲例）中已配置好文件共享資源，並在域控制器中配置好權限分配：
|
資源訪問地址：\\4.0.2.11\huawei 使用者權限分配：admin具有讀取/寫入權限；usera僅具有讀取權限 |
虛擬網關作爲SSL VPN的所有資源入口，任何需要訪問的資源都必須在SSL VPN的配置中體現，這也體現了SSL VPN可以細化訪問控制粒度的設計理念。對於文件共享，首先需要開啓文件共享功能，並新建文件共享資源，目的是爲遠程用戶提供可視化的文件共享資源“菜單”。
遠程用戶輕鬆點菜（遠程用戶與防火牆的HTTPS交互）
登錄成功後，虛擬網關對用戶開放的資源都會在此界面上體現。將鼠標置於資源上，在瀏覽器的狀態欄中可以看到此資源對應的Web鏈接，包含了需要向防火牆請求的頁面和需要傳遞的參數，可不要小瞧這個URL，它代表了遠程用戶請求的文件資源信息以及相應的操作指令，不同的目錄和操作，均會對應不同的URL。
Q：上文的提到的文件共享資源\\4.0.2.11\huawei 這裏爲什麼看不到？
A：因爲防火牆已經將其隱藏，使用ResourceID唯一確定資源地址，ResourceID與資源地址的對應關係保存在防火牆的大腦（內存）中，這樣便可以隱藏了內網服務器的真實地址，保護服務器安全。
對這個Web鏈接進行深入剖析，除去很明顯的4.1.64.12是虛擬網關地址外，強叔將剩下的鏈接結構分解爲3個部分：
1. protocoltran， 文件共享的專屬目錄。從字面猜測是protocol+transform，表示將HTTPS協議和SMB/NFS協議相互轉換。
2. Login.html，請求的頁面，通常情況下不同的操作會對應不同的請求頁面，強叔整理了所有可能用到的請求頁面和請求結果頁面。
|
頁面名稱 |
含義 |
|
login.html loginresult.html |
SMB文件服務器鑑權頁面。 |
|
dirlist.html |
顯示文件共享資源的詳細列表，文件夾結構。 |
|
downloadresult.html downloadfailed.html |
下載文件。 |
|
create.html result.html |
創建文件夾。 |
|
deleteresult.html result.html |
刪除文件、文件夾。 |
|
rename.html result.html |
重命名文件、文件夾。 |
|
upload.html uploadresult.html |
上傳文件。 |
3. ?VTID=0&UserID=4&SessionID=2141622535&ResourceType=1&ResourceID=4&PageSize=20&%22,1，向請求頁面傳遞的參數。強叔這裏先給出一張參數明細表，除了已經給出這條URL涵蓋的參數外，還包括了之後其他操作的請求參數，供大家對照理解。
|
參數 |
含義 |
|
VTID |
虛擬網關ID，用以區分同一臺防火牆上的多個虛擬網關。 |
|
UserID |
用戶ID，標識當前登錄用戶。爲了安全起見，同一用戶每次登錄的ID不同，防止中間攻擊人僞造假的數據包。 |
|
SessionID/RandomID |
會話ID，同一次登錄虛擬網關的所有會話ID均相同。 |
|
ResourceID |
資源ID，標識每個文件共享資源。 |
|
CurrentPath |
當前操作所在的文件路徑。 |
|
MethodType |
操作類型： l 1：刪除文件夾 l 2：刪除文件 l 3：顯示目錄 l 4：重命名目錄 l 5：重命名文件 l 6：新建目錄 l 7：上傳文件 l 8：下載文件 |
|
ItemNumber |
操作對象數量。 |
|
ItemName1 |
操作對象名稱，可以包含多個操作對象，例如刪除多個文件。 |
|
ItemType1 |
操作對象類型： l 0：文件 l 1：文件夾 |
|
NewName |
新名稱。 |
|
ResourceType |
資源類型： l 1：SMB資源 l 2：NFS資源 |
|
PageSize |
每頁顯示資源條目數量。 |
爲了讓大家對文件共享功能的全景有所瞭解，強叔將結合文件共享的具體功能對以上各種操作指令進行逐一驗證。
1）首次訪問文件共享資源，要先通過文件服務器的認證。這裏所說的認證一定要和SSL VPN登錄時的認證區分開，在登錄階段，接入用戶首先要通過的是防火牆認證。而此時要訪問文件共享資源，當然要看文件服務器是否答應。在點擊資源列表中的“Public_share”時會彈出認證頁面：
鑑權通過後顯示文件資源頁面：
上面的訪問，強叔理解可以分解爲認證和顯示文件夾兩個過程，那麼真正的交互過程是否是這樣呢？
沒錯，看來強叔的理解是正確的，Login.html/LoginResult.html均是鑑權認證的頁面，而且將加密報文解密後，LoginResult.html還包括了待文件服務器認證的用戶名和密碼。另外的Dirlist.html正是顯示文件夾結構的頁面。
2）下載文件的驗證。
可以對照強叔給出的表格，描述出如下語句：下載（MethodType=8）根目錄（CurrentPath=2F）下的文件（ItemType1=0），名稱爲readme_11（ItemName1=%r%e%a%d%m%e_%1%1）。但是要注意，這裏有一點URL解碼的內容，例如CurrentPath的取值2F解碼之後是/，表示當前資源的根目錄。
3）重命名文件夾的驗證。
這裏因爲用戶usera只有可讀的權限，所以提示失敗了，但不妨礙我們繼續驗證：重命名（MethodType=4）根目錄（CurrentPath=2F）下的文件（ItemType1=1）userb（ItemNmae1=%u%s%e%r%b）爲usera（NewName=%u%s%e%r%a）。
通過以上介紹相信大家已經明白，防火牆構建這些鏈接，首先是爲了隱藏真實的內網文件資源路徑（\\4.0.2.11\huawei\），再者就是作爲SSL VPN網關爲遠程用戶訪問牽線搭橋：作爲SMB Client向SMB Server發起文件訪問（明確訪問的文件對象和操作）。
虛擬網關爲遠程用戶文件訪問牽線搭橋（防火牆與文件服務器的SMB交互）
1、防火牆（4.1.64.12）作爲客戶端向文件服務器（4.0.2.11）發起協商請求， 首先協商使用的SMB版本（Dialect），防火牆目前僅支持使用SMB1.0（NT LM 0.12）作爲客戶端與服務器進行交互。
2、服務器響應信息中包含接下來使用的認證方式以及16位挑戰隨機數。這裏使用了一種安全的認證機制：NT挑戰/響應機制，即NTLM。
過程大致如下：
1）服務器產生一個16位隨機數字發送給防火牆，作爲一個挑戰隨機數。
2）防火牆使用散列算法生成用戶密碼的哈希值，並對收到的挑戰隨機數進行加密。同時將自己的用戶名，使用明文傳輸，一併返回給服務器。
3）服務器將用戶名、挑戰隨機數和防火牆返回的加密後的挑戰隨機數，發送給域控制器。
4）域控制器按用戶名在密碼管理庫中找到用戶密碼的哈希值，也用來加密挑戰隨機數。域控制器比對兩個加密的挑戰隨機數，如果相同，那麼認證成功。
認證通過後就是訪問指定的文件或文件夾，暫不贅述。
綜上，我們可以看出防火牆在文件共享功能中的作用其實就是代理，作爲遠程用戶和SMB server的中介：在HTTPS階段，作爲Web Server接收遠程用戶的文件訪問請求，並翻譯爲SMB請求；在SMB階段，作爲SMB Client發起請求、接收應答，並翻譯給遠程用戶。有了文件共享功能，遠程用戶訪問內網文件服務器就像訪問普通Web網頁一樣方便，不用安裝文件共享客戶端、不用記服務器的IP地址，也不會在衆多服務器中迷航。
看似簡單的文件共享菜系，沒想到包含了這麼多道工序：接收請求 -> 翻譯並轉發請求 ->接收響應 -> 翻譯並轉發響應，防火牆如同技藝精湛的廚師，精心料理每一個環節，現在文件訪問這道大餐已經火熱出爐，那麼對於另外一種常用服務：Web訪問服務，防火牆又是如何發揮作用的呢？
口味：對URL的訪問----菜系：Web代理功能
菜系簡介：儘管都是對象級別的資源訪問，但URL與文件共享不同，訪問URL本身使用的就是HTTP協議，而SSL協議生來就和HTTP是天生一對，因此在Web代理功能中，已經不再涉及協議轉換的內容。但是我們還是要圍繞兩個最核心的內容進行闡述：URL級別的訪問控制和隱藏真實的URL地址。
Web代理，菜如其名，也就是通過防火牆做代理訪問內網的Web服務器資源，也就是URL。說到這有的朋友可能會問了，這不就是普通的代理功能嗎：使用一臺服務器做跳板訪問目的URL地址，這臺服務器就是起的代理作用，防火牆跟這個實現一樣嗎？答案是不完全一樣，防火牆在整個過程中不僅做了代理，而且對真實的URL進行了改寫處理，從而達到隱藏真實的內網URL的目的，進一步保護了內網Web服務器的安全。
準備Web代理資源菜單（配置Web代理資源）
假設企業已架設好Web服務器，並對企業內網提供了Portal門戶地址：http://portal.test.com:8081/ ，希望通過Web代理功能爲遠程用戶提供訪問。
與文件共享資源一樣，爲了細化訪問控制粒度到URL級別，需要在虛擬網關中配置相應的Web代理資源。
在以上配置中，最重要的參數要屬資源類型，它定義了Web代理方式。代理方式包括Web改寫和Web-Link，二者的差異請參見下表：
|
對比項 |
Web改寫 |
Web-Link |
|
安全性 |
對真實的URL進行改寫，隱藏內網服務器地址，安全性較高。 |
對URL不會進行改寫，直接轉發Web請求和響應，會暴露內網服務器的真實地址 |
|
易用性 |
不依賴IE控件，在非IE環境的瀏覽器中可以正常使用。 |
依賴IE控件，在非IE環境中無法正常使用。 |
|
兼容性 |
由於Web技術發展非常迅速，防火牆對於各類URL資源的改寫無法做到面面俱到，可能會出現圖片錯位，字體顯示不正常等問題。 |
無需對資源進行改寫，由防火牆直接對請求和響應進行轉發，所以沒有頁面兼容性的問題。 |
|
使用建議 |
優先推薦使用Web改寫，因爲這是最安全、最方便的一種訪問方式。如果出現頁面顯示異常，再考慮Web-Link方式。 |
Web-Link作爲Web改寫的最佳替補，但由於依賴IE控件，必然在使用上存在侷限性。而且沒有對內網URL進行改寫，存在安全風險。 |
看到這裏大家知道什麼時候用Web-Link了麼？
在下表中強叔還列出了其他一些參數的含義：
|
參數 |
說明 |
|
URL |
內網可以直接訪問的Web應用地址。如果是域名形式的話，那麼需要在虛擬網關中配置相應的DNS服務器地址。 |
|
資源組 |
相當於Web應用地址的自定義分類，遠程用戶登錄後可以通過資源組篩選需要的資源，好比菜單中的主食、酒水分類一樣。
|
|
門戶鏈接 |
選擇Web代理資源是否顯示在登錄後的虛擬網關首頁上。如果不選中，相當於爲老顧客準備了菜單之外的私房菜。這時老用戶可以在登錄後的右上角地址欄中手動輸入URL地址，訪問一些比較機密的URL資源。
|
Web改寫究竟是如何工作的，強叔會帶着大家一起繼續學習。對於Web-Link這裏先埋個小伏筆，強叔會在後續的帖子會重點提到它。
遠程用戶輕鬆點菜（對URL地址的改寫）
對於前面已經配置的Web代理資源URL http://portal.test.com:8081/，給用戶實際呈現的URL地址我們可以看到已經被改寫成：
對改寫結果進行逆向分析，其中4.1.64.12爲虛擬網關地址，剩餘部分大致可以分爲：
1）webproxy：Web代理的專屬目錄。
2）1/1412585677/4：UserID/SessionID/ResourceID，這幾個參數在介紹文件共享的時候已經提到過。
3）http/portal.test.com:8081/0-2+：原始URL地址的變形。
當用戶訪問改寫後的地址時，發生瞭如下交互。
1、遠程用戶向防火牆請求改寫後的URL地址。
請求報文到達防火牆之前均爲加密狀態，上圖是經過解密處理後的，所以也可以理解爲防火牆收到的真實請求。
2、防火牆對收到的報文進行解密後，向內網服務器發送請求之前，繼續對原始報文作如下處理：
1）需要刪除原始報文頭中的Accept-Encoding字段，否則Web服務器可能會將響應報文加密發給虛防火牆，而防火牆對其無法解密處理，無法進行進一步的轉發。在下圖中，可見防火牆已經將原始報文中的Accept-Encoding字段刪除了。
2）將host字段替換爲真實的內網Web資源地址。
3）修改與此Web資源相關的一些URL的Referer字段爲真實的內網Web資源地址。
3、防火牆作爲Web Client將改寫後的數據發送給真實的Web Server。
接下來就是正常的HTTP交互了，此處不再贅述。
對URL中資源路徑的改寫
防火牆接收到的應答報文，也就是需要呈現給用戶的頁面（以首頁http://portal.test.com:8081/爲例），對於頁面中的一些資源路徑也需要進行改寫，如果不對資源路徑進行改寫，客戶端就會使用錯誤/不存在的地址獲取資源，最終導致相應的內容無法正常顯示。目前防火牆支持對如下頁面資源進行改寫：
l HTML屬性
l HTML事件
l JavaScript
l VBScript
l ActiveX
l CSS
l XML
防火牆可以對這些資源的內部路徑進行改寫，目的是爲了頁面的正常顯示和功能的正常使用。
對URL包含的文件改寫
其實在上一小節已經對文件的改寫已經作了一部分介紹，但均是基於所請求頁面的資源改寫，也就是說所改寫的內容是用戶無需感知的，用戶所關心的是頁面是否能正常顯示，Web的功能是否正常。而接下來要說的，正是用戶切實關心的文件，包括PDF、Java Applet和Flash。
以PDF爲例，我們將a.pdf內嵌到http://portal.test.com:8081/ 中，以鏈接的形式供用戶下載使用。PDF中的內容中如下，包括只有在內網可以訪問的鏈接（http://support.test.com/enterprise ），如果防火牆不對其進行改寫，接入用戶打開下載後的PDF文件並訪問其中的鏈接，會無法訪問。
而通過虛擬網關下載Web代理資源中的PDF文件，本地打開後顯示如下，可見文件中原來的內網URL已經被改寫，改寫後的URL爲虛擬網關地址開頭，這樣外網用戶就可以訪問內嵌在PDF文件中的內網資源。
定製化菜單服務-角色授權
企業管理員可以爲不同的用戶定製不同的“菜單”，實現細粒度的資源訪問控制。在華爲防火牆中，對多個資源的訪問控制是通過角色授權完成的，一個角色中的所有用戶擁有相同的權限。角色是連接用戶/組與業務資源的橋樑，管理員可以將權限相同的用戶或組加入到某個角色，然後在角色中關聯業務資源。
如下圖所示，角色中可以包含多個用戶/組，同時還可以關聯多個業務資源項。
普通員工usera登錄後的資源界面： 管理者master登錄後的資源界面：
說明：由於管理者master加入了兩個角色中，所以看到的菜單是兩個角色的合集。
角色授權的配置界面如下所示，其中角色具體可以關聯的控制項如下：
l 業務授權：指定角色內用戶可以使用的業務，包括Web代理、文件共享，以及後面將要介紹的端口轉發和網絡擴展。
l 資源授權：在啓用某個業務的前提下，指定具體可以訪問的資源。如果不指定具體資源，角色內用戶無法訪問任何資源。
普通員工角色配置： 管理者角色配置：
本篇中，強叔介紹了SSL VPN時尚餐廳中兩個熱銷的菜系：文件共享和Web代理，其中詳細介紹了兩種菜系各自不同的料理工序—隱藏或改寫URL。另外針對不同口味的顧客，還推出了定製化菜單服務--角色授權。文件共享和Web代理各自對應了文件和URL這兩類最細粒度的資源訪問方式，而且均是基於Web進行訪問。但是在有些遠程辦公場景中，使用的是Non-Web的應用方式，例如Telnet，所以在下一篇中，強叔將對此類訪問需求進行詳細介紹。