我們第一篇中介紹過，SSL VPN的特色及優勢便是可以藉助Web覆蓋所有的遠程訪問需求，而現在這些非Web的應用使得原本基於Web的SSL VPN看似束手無策了。但事實並非如此，在本篇技術貼中，強叔就是要帶着大家跨過山和大海，共同見證SSL VPN展示出的神奇力量——端口轉發功能。
端口轉發，一言以蔽之，就是端口轉發客戶端程序在遠程用戶側獲取用戶的訪問請求，再通過虛擬網關轉發到內網相應的服務器。接下來以最常見的Telnet訪問爲例，介紹遠程客戶端通過SSL VPN訪問內網的Telnet應用。
端口轉發業務的配置如下，與前面介紹的SSL VPN其他功能一樣，無論訪問什麼樣的應用，首先都要在虛擬網關中添加相應的資源，對Telnet而言，只需要在虛擬網關中配置Telnet服務器的IP地址和端口即可。
遠程用戶在登錄後的虛擬網關界面中，可以選擇手動啓用端口轉發功能，也可以設置爲登錄後客戶端自動啓用，總之全憑虛擬網關一句話；除了可以自動啓動端口轉發功能，還可以選擇是否保持端口轉發長連接，這是由於有些應用的訪問持續時間較長（例如管理員正操作Telnet過程中突然要離開一段時間），選中後可以防止因SSL連接超時斷開而中斷端口轉發業務。
端口轉發的數據處理流程相對複雜，強叔這裏給出一張簡圖，後文將對各個階段逐一介紹。
說明：這裏的端口轉發客戶端包含了SSL VPN客戶端功能，只是爲了強調端口轉發業務才特地如此稱謂。
準備階段
1. 登錄SSL VPN
此過程在SSL VPN第一篇貼子《遠程接入IPSec現短板，SSL VPN登上歷史舞臺》中已經介紹，不再贅述。
另外需要大家知悉，在上一篇貼子中強叔是圍繞URL展開分析的，而端口轉發的分析將有所不同，儘管也登錄了虛擬網關，但因爲是非Web類的應用訪問，所以對應的資源訪問也不再使用Web，而是藉助其他應用程序，如Putty（Telnet/SSH工具）、Filezilla（FTP工具）、Foxmail（郵件程序）等。這時問題也隨之而來了，非web應用程序是如何利用已經登錄的SSL VPN連接的呢？
2. 順風耳收到指令，進入聆聽狀態
使用非web應用程序進行數據訪問時，看似與SSL VPN沒什麼關係，但實際上，端口轉發的關鍵的技術點已在此恭候多時：用戶使用Windows系統的IE瀏覽器登錄虛擬網關後，會在本地PC的IE瀏覽器上自動運行端口轉發客戶端（ActiveX控件）。這個客戶端的作用就是像順風耳一樣時刻“聆聽”其他程序的所有請求，並在千鈞一髮之際將遠程用戶發給內網服務器的請求“攔截”下來，然後再通過SSL連接發送給虛擬網關。對於“聆聽”到的請求，選擇哪些請求進行攔截，這位順風耳並不是一意孤行，是根據虛擬網關這位上級的指示來嚴格執行的。那麼指令是什麼呢？
前面配置的端口轉發資源，實際上就是虛擬網關給端口轉發客戶端下發的指令——“有用戶要訪問這些資源，你協助他們完成訪問任務”。在端口轉發功能中，下發的指令便是目的主機IP地址+目的端口，以上信息可以唯一確定遠程用戶要訪問的應用信息。
如下圖所示，遠程用戶手動啓用端口轉發功能後，端口轉發客戶端會自動向虛擬網關請求資源信息，客戶端請求到的資源信息會保存在遠程用戶PC的內存中，隨時待命，便於在接下來選擇“攔截”哪些請求。
爲了不暴露內網服務器的地址，具體資源信息無法在端口轉發客戶端上進行查看，菜單中的資源也無法直接點擊，只有簡單的提示作用。不過我們可以間接通過查看端口轉發客戶端日誌（存放路徑爲%appdata%\Roaming\svnclient\log），瞭解資源信息下發的過程。
Telnet連接建立階段
3. 順風耳精準攔截，施展代理絕活
在順風耳的腦海中，已經明確要“攔截”哪些請求了，當下要做的就是豎起耳朵，聆聽自己關心的內容。當用戶使用Telnet程序對10.1.1.1的23端口請求連接時（一個TCP SYN報文），順風耳發現與上級虛擬網關下發的資源信息（目的IP+目的端口）匹配，立即將此TCP SYN報文“攔截”。如果按照普通的人的做法這時就可以將請求報文發給虛擬網關交差了，但這裏順風耳考慮到如果不經過處理便發送給虛擬網關，即會導致每個Telnet請求（即每條TCP連接）都會對應建立一條新的SSL連接，這樣做會不但會佔用過多的系統資源，而且響應速度也會有延遲。爲了節省虛擬網關的會話和內存資源，提高用戶體驗，順風耳決定先喬裝打扮成接收方，模擬接收一次Telnet業務請求（TCP連接），弄清楚用戶需要訪問什麼樣的資源，採用“集中代理的方式，一條SSL 連接搞定”的戰術，減輕“上級”（虛擬網關）的壓力。如何模擬接收Telnet業務？如何集中代理呢？順風耳這個優秀的代理業務員自有妙計：
端口轉發收到Telnet請求後對報文進行改造，將原來要發送給10.1.1.1的請求改爲發送給自己（127.0.0.1），這樣就等於自己代替Telnet服務器接受了請求。不過，模擬歸模擬，模擬的同時必須記錄改造前後的對應關係（本地換回記錄表），便於後續可以代替Telnet服務器應答真正的用戶（4.1.64.179）。
本地環回記錄表
|
改造項目 |
改造前 |
改造後 |
|
源IP地址 |
4.1.64.179 |
127.0.0.1 |
|
源端口 |
隨機 |
隨機 |
|
目的IP地址 |
10.1.1.1 |
127.0.0.1 |
|
目的端口 |
23 |
1047（23+1024） |
端口轉發客戶端與自己建立了TCP連接1（也叫本地環回連接），使用netstat命令驗證如下。
4. 構造私有報文頭，提交“端口轉發業務單”
模擬接收Telnet業務請求後，端口轉發客戶端對用戶的請求已經瞭然於胸，按流程要求需要填寫“端口轉發業務單”提交上級領導。業務單中必須包括用戶要請求的目的地址（10.1.1.1）和端口（23），以及命令字（建立連接、傳輸數據報文或關閉連接等），這樣上級才能進一步處理。
此處需要注意：由於端口轉發客戶端自己模擬了接收方建立了TCP鏈接1，所以業務單中必須對該TCP鏈接做一個標記（TCP連接1的socket ID，稱爲客戶端socket ID），只有這樣當上級將業務受理結果返回時，端口轉發客戶端才能根據標記找到TCP連接1，將返回結果發給對應的Telnet客戶端。
“端口轉發業務單”在端口轉發業務中被稱爲私有報文頭（簡稱私有頭）。這裏僅以Telnet請求連接的報文爲例，對私有報文頭的主要字段進行說明。Telnet連接建立階段報文載荷爲空，所以傳輸時只有私有報文頭，在數據傳輸階段報文纔會有載荷。
|
字段名稱 |
字段說明 |
|
用戶標識 |
標識用戶身份，虛擬網關自動爲用戶分配。可以理解爲端口轉發業務單號。 |
|
命令字 |
1. Open-新建連接 2. Data-數據命令 3. Close-關閉連接 |
|
業務類型 |
1. 端口轉發 2. Web-Link Web-Link實際上就是HTTP/HTTPS的端口轉發業務，也就是說Web-Link資源，同樣也可以配置爲端口轉發資源。但是請注意，在Web-Link資源中知名端口可以不指定，例如http://www.huawei.com/，但是在端口轉發的配置中端口號是必選，例如HTTP的知名端口號80，HTTPS是443。 |
|
源IP 地址 |
原始請求中的源IP地址，本例中爲遠程用戶客戶端的地址：4.1.64.179 |
|
目的IP地址 |
原始請求中的目的IP地址，本例中爲內網Telnet地址：10.1.1.1 |
|
協議類型 |
目前僅支持TCP協議。 |
|
目的端口 |
原始請求中的目的端口，本例中爲內網Telnet端口：23 |
|
客戶端socket ID |
遠程用戶與自己建立連接使用的socket ID，用於標識此次會話，後續的報文會繼續使用這個socket ID。 |
|
服務器socket ID |
防火牆作爲Telnet Client與內網服務器建立連接使用的socket ID，作用與客戶端socket ID一樣，均用來標識會話。 |
“端口轉發業務單”整理完成後通過SSL連接加密發送給虛擬網關。
需要注意的是，此處建立的是一條專門用於端口轉發業務的SSL連接，而非登錄時已經建立好的SSL連接。當Telnet對其它資源發起訪問時情況類似，建立新的TCP連接後，端口轉發客戶端也會再填寫一份“端口轉發業務單”，並共享這條SSL連接進行發送。這樣，在客戶端和虛擬網關之間會始終保持一條唯一的SSL連接。總之，所有的“端口轉發業務單”都將送往這條SSL連接，經過加密後再發往虛擬網關，大大減輕了虛擬網關的工作量。
5. 虛擬網關與內網服務器建立連接
虛擬網關收到加密後的報文，對其進行解密，在“端口轉發業務單”中獲取到Telnet真實的目的IP地址和端口、命令字等信息，此時虛擬網關將作爲Telnet客戶端與內網服務器進行交互建立Telnet連接。通過查看防火牆的會話表，可以得出防火牆隨機啓用了端口10010向10.1.1.1:23發起訪問請求，建立了TCP連接2。
6+7 內網服務器響應報文返回Telnet客戶端
虛擬網關收到內網服務器的響應報文（登錄界面），在發給遠程客戶之前，虛擬網關依然會構造私有報文頭， 填寫TCP連接2的socket ID（服務器socket ID），這樣便可以與TCP連接1建立對應關係。最終，虛擬網關把經過SSL加密後的私有報文頭+數據發送給端口轉發客戶端；端口轉發客戶端根據私有頭中客戶端socket ID找到TCP連接1，再根據本地環回記錄表找到Telnet客戶端真實IP地址，最終返回真實的數據。
端口轉發客戶端收到經SSL解密後的數據如下，從截圖中標識的部分已經依稀看到登錄頁面的文字了，也就是Telnet數據報文，而上半部分的內容正是私有頭的內容。
Telnet客戶端收到的Telnet登錄界面如下。
數據通信階段
後續的Telnet數據報文，會繼續使用之前建立的TCP連接1和TCP連接2，然後通過私有報文頭將兩個連接進行關聯，最終打通“Telnet客戶端—端口轉發客戶端—虛擬網關—Telnet服務器”之間的傳輸通道，實現數據通信。
Telnet應用的端口轉發流程就介紹到這裏， Telnet協議只是最簡單的單通道協議，除此之外，端口轉發還支持如下類型應用：
l 多通道協議，支持FTP和Oracle SQL NET。在實際的配置中，對於FTP協議只需要指定控制通道的端口21，協商後的數據端口會被自動“聆聽”，無需額外配置。
l 多協議應用。對於有些應用，需要多個協議支持，例如Email，需要在配置端口轉發業務前，弄清楚使用發送協議（SMTP:25）和接收協議（POP3:110或者IMAP:143）的端口號，併爲每一種協議配置一條端口轉發資源。
l 多IP固定端口應用。例如IBM Lotus Notes，對應的數據庫存在於多個服務器上，但是對外提供服務時，均使用1352端口。這類應用在配置端口轉發業務時，無需遍歷配置所有服務器，只需要在“主機地址類型”中選擇“任意IP地址”即可。
在實際應用中，端口轉發的配置和使用都十分簡單（SSL VPN的特色嘛），但殊不知神功練就的背後夾雜了多少淚水，也許在實際的使用中用不到這些生僻的內容，但是相信有那麼一瞬間，強叔會助你靈光一現，發現更大的世界。那麼接下來，將進入SSL VPN的最後一篇，與L2TP VPN十分類似的三層VPN功能，將SSL VPN的資源訪問控制，延伸無界……