摘 要： 在應對突發事件救援行動中，指揮中心能否通過互聯網取得第一手資料，必要的條件是存在一個安全的連接。虛擬專用網（VPN）是應急現場組織、指揮的重要通信手段。但是，如果車載無線移動終端移動，由于IP的變化，安全連接將會消失，新的連接將會重新建立，造成應急現場與指揮中心之間通信不流暢。為克服以上不足，詳細闡述了由L2TP和IPSec集成的一種新穎的隧道網絡過程，并介紹了L2TP和IPSec的集成方案，最后完成了對本方案的測試。
關鍵詞： L2TP；IPSec；VPN；車載無線終端
突發事件的發生給人民生命和國家財產造成巨大的破壞，這種破壞有時甚至是毀滅性的[1]?？紤]我國應急管理實踐經驗，在處置突發事件中，有效的通信網絡保障是應急響應和救援工作成敗的關鍵。隨著現代通信技術和網絡技術的高速發展，車載無線終端在現場采集的大量信息需要實時傳輸到指揮中心，為防止信息在3G網和互聯網上傳輸時被竊取或篡改，數據需要在采集端加密后再經由3G網和互聯網傳輸。
本文結合L2TP和IPSec的技術特點，提出了一種新穎的L2TP/IPSec安全隧道網絡遠程數據傳輸方案。本方案能重新發送丟失的數據包，具有更好的安全性和切換性能。該方案利用IPSec的強安全性彌補了L2TP在安全方面的不足，同時又利用L2TP的靈活性彌補了IPSec在用戶級鑒別、授權以及多協議支持等方面的不足，有效提升了系統的安全性。本文完成了對整個網絡系統的設計，展望了該系統設計的價值和前景。
１ L2TP和IPSec的集成
１.1 L2TP協議
L2TP協議是PPTP與L2F的組合，代表了PPTP和L2F的最佳功能，是一個開放源碼的第2層隧道協議[2-3]。L2TP將PPP分組進行隧道封裝成UDP包，并通過網絡傳輸。L2TP特別適合于組建遠程訪問型VPN，己經成為事實上的工業標準。L2TP隧道的兩個端點分別是LAC（L2TP訪問集中器）和LNS（L2TP網絡服務器）。LAC接收來自采集端的PPP數據包，并將之封裝成UDP數據包發送到LNS。LNS拆封UDP數據包，并發送PPP報文到指揮中心。
L2TP協議只對通道的終端實體進行身份驗證，而非流過的每一個數據報文，且L2TP本身不提供任何數據加密手段，對控制數據包本身未進行保護，當數據需要加密時需要其他技術的支持。因此，利用L2TP構建的VPN不能滿足安全虛擬專用網絡的要求。
在UNIX下L2TP的實現可以分為兩部分：內核和用戶空間。本設計所使用的是FreeBSD[4]和用戶空間的守護進程——多鏈路PPP守護進程MPD[5]。內核部分負責接收和發送PPP包到指揮中心、L2TP數據包的封裝和解封，以及發送和接收LAC與LNS之間的UDP數據包。用戶空間部分負責創建和管理L2TP隧道，保存和管理L2TP信息。為了減少調試內核和用戶空間，使它們之間的通信更容易，對用戶空間代碼作了修改。這是因為大多數的L2TP隧道信息被保存在用戶空間內。
１.2 IPSec協議
IPSec是由IETF IPSec工作組制訂的一組基于密碼學的開放網絡安全協議簇[2-3]。IPSec作為一種隧道傳輸技術，提供網絡層之上的保護：將IP幀封裝成ESP包[6]或AH包，并發送到網絡的另一端；使用IKE協議處理密鑰交換和使用ESP和AH對數據包提供真實性、完整性和機密性保護。IPSec操作有兩種模式：傳輸模式和隧道模式。在傳輸模式下，IPSec通過AH或ESP報頭只對IP數據包負載加密，而在隧道模式下，IPSec通過AH或ESP報頭與其IP報頭對IP報頭和IP數據包負載兩者加密。
在UNIX下IPSec的實施主要可以分為兩部分：內核（UNIX內核的一部分）和用戶空間（Racoon2[7]項目）。內核部分負責發送和接收IP數據包、封裝和解封ESP數據包，并檢查安全信息。用戶空間部分有3個組件：iked（用IKE協議和ISAKMP處理密鑰交換）、SPMD（安全管理政策；真正的安全數據庫在IPSec內核中）與kinkd（除了它處理KINK協議外與“iked”類似）。
１.3 L2TP和IPSec的集成實現
通過以上對L2TP和IPSec協議的分析，在VPN建設中可以考慮將L2TP協議和IPSec協議綜合起來使用，形成一個L2TP/IPSec隧道，它既支持IPSec的隧道模式又支持IPSec的傳輸模式[8]，利用IPSec AH或IPSec ESP[4]保護L2TP數據包能夠提供數據源驗證、數據完整性驗證、抗重放攻擊、數據保密性保護和有效的密鑰管理等服務。在IPSec隧道模式下的L2TP/IPSec隧道的數據包結構如圖1所示。
IPSec/L2TP VPN建立的過程是：(1)通常通過Internet密鑰交換（IKE），協商IPSec安全關聯（SA，共享兩個網絡之間的安全信息實體）。數字證書（通過證書頒發機構）應在此步驟之前發布。(2)在隧道模式下通過IP數據包發送封裝安全載荷（ESP）[6]。(3)在SA的兩端點之間協商和建立L2TP隧道。
在數據傳輸階段的L2TP/IPSec隧道的認證過程如下：(1)根據ESP頭和IP頭，驗證IPSec中安全協會（SA）的信息。IPSec組件從安全協會數據庫（SADB）使用的目的地址（IPSec隧道的結束點）和安全參數索引（SPI）中獲取并檢驗SA，根據SA對有效載荷進行解密[9]。(2)通過查詢安全策略數據庫檢驗數據包的安全策略[9]。(3)驗證L2TP數據包的IP地址和端口值相匹配的信息，用以設置L2TP隧道[8]。
２ 無線傳輸網絡設計
該系統的網絡架構如圖2所示。選擇安徽創世科技有限公司的CR3000R系列嵌入式硬盤錄像機安裝在應急指揮車上作為數據采集設備，選擇Racoon2[7]（為IPSec）和MPD[5]（為L2TP）安裝在L2TP/IPSec隧道集中器和服務器上。L2TP/IPSec集中器用于封裝PPP包和創建到遠程服務器的隧道，也可用于封裝L2TP/IPSec隧道內的IP數據包。L2TP/IPSec隧道服務器連接到UNIX服務器時，首先打開一個IPSec隧道，然后利用這個隧道連接到UNIX服務器上的L2TP守護進程，這樣服務器就可以訪問指揮現場內網的計算機。
當應急指揮車靜止時，無線設備的IP地址未發生改變，這就意味著圖2中A點和B點的IP地址是內部的IP地址；當應急指揮車移動時，C點的IP地址就會改變，但指揮現場的服務器兩端和指揮中心的所有IP地址保持不變。
本設計的目標是：在無重建隧道成本和無丟失數據包的情況下，由L2TP和IPSec集成的VPN隧道能繼續發送低延時包。因此，本設計決定在沒有任何代理的情況下，讓L2TP/IPSec隧道集中器與L2TP/IPSec隧道服務器直接通信。詳細步驟如下：
(1)隧道集中器更新IPSec隧道信息，并直接通知隧道服務器的IP地址，IPSec從舊的IP地址改變為新的IP地址。出于安全原因，本方案將IP變化信息添加到ESP有效載荷[4]，首先因為發送ESP負載內的信息可以修改現有的SA而無需創建一個新的SA，從而避免了SA的重建[10]。再者修改的SA數據庫和發送的ESP信息可以消除UNIX下的內核和用戶空間之間的通信。在IPSec的地址更新包中，當設置隧道地址和當前地址時，ESP有效載荷包含了IPSec隧道端點的IP地址。在IPSec地址回復包中，當ESP有效載荷[6]包含了同在IPSec地址更新消息和VPN網關中相同的信息時，證明IPSec中的IP地址更新成功。
(2)隧道服務器確認IP變化，更新IPSec隧道的信息，并發送備份確認消息。
(3)隧道集中器直接通知隧道服務器IP地址的L2TP從舊的IP地址改變為新的IP地址，同時進行加密。最后接收到的數據的序列號也在該數據包內傳送。
(4)隧道服務器進行解密和驗證數據包。如果數據包驗證成功，那么隧道服務器更新L2TP內的隧道信息。隧道服務器緩沖了足夠的數據包后發送應答信息指令。L2TP隧道端口號在本方案中沒有改變，如果端口號改變，那么 L2TP隧道就必須重新建立。L2TP和IPSec的IP變化信息更新完后，將L2TP信息保存在用戶空間，IPSec信息保存在UNIX內核中。
(5)隧道集中器進行解密和驗證答復包。在L2TP隧道中增加了一個固定大小的循環緩沖區，循環緩沖區的大小必須在L2TP隧道的安裝階段協商。如果沒有足夠的數據包，隧道集中器就會切斷用戶連接。如果集中器緩沖了足夠多的數據包，隧道集中器就會更新L2TP隧道信息并要求隧道服務器發送丟失的數據包（沒有達到的舊IP地址的數據包）。為了支持丟失數據包的傳輸，數據序列號必須添加到L2TP數據信息中。
(6)隧道服務器發送丟失的數據包。最后VPN可重新獲得新的數據包。
２.1 L2TP/IPSec隧道的認證
IPSec安全信息有兩個數據庫：安全策略數據庫SPD和安全關聯數據庫SADB。SPD含有圖2中A點和F點的信息，SADB含有圖2中C點和D點的連接和加密信息。本方案僅對圖2中C點的SA（安全關聯）信息作了修改。
IPSec驗證的修改如下：(1)當在SADB中建立一個SA時，隧道端點地址保存為初始的隧道端點地址或者當前地址。(2)當IPSec隧道服務器或集中器發送IPSec數據包時，數據包被發送到隧道的當前地址。初始的隧道端點地址只檢驗IPSec的更新數據包。(3)當IPSec隧道服務器或集中器接收IPSec數據包時，根據隧道的當前地址檢驗數據包。(4)在IPSec服務器或集中器發送IPSec地址更新數據包前，更新SADB中SA的當前地址，否則，IPSec地址更新數據包將發送到舊的隧道端點地址。(5)當IPSec隧道服務器或集中器接收IPSec地址更新數據包時，根據SPI解密數據包。當數據包是IPSec地址更新數據包并且根據初始的隧道端點地址發現SA時，則更新SADB中SA的當前地址。(6)SPD的節點不會改變，因為SPD中的地址是圖2中A點和F點的地址，這些地址在設計中不改變。
L2TP驗證的修改如下：(1)當創建一個L2TP隧道時，在L2TP連接列表中，隧道端點地址保存為初始的隧道端點地址或者當前地址。(2)對于正常的L2TP數據包，驗證L2TP中的IP地址和端口值時，應與保存的移動節點地址和端口號相匹配。(3)對于L2TP地址更新消息，驗證L2TP連接列表中初始的隧道端點地址和更新的當前地址。
２.2 更新路由信息
隧道集中器中的路由表應在IPSec更新消息被發送前更新，隧道服務器的路由表應在IPSec的更新消息收到后更新。如果網絡接口改變它們的IP地址，與此有關的所有路由的網絡接口在FreeBSD[4]下將被自動刪除，并且將引起新的系統來檢測IP變化和更新L2TP/IPSec隧道。當IP地址被改變時應添加一個相關的路由。
３ 系統測試
３.1 L2TP/IPSec隧道傳輸效率測試
測試中，在車載無線終端與指揮中心之間傳送UDP數據包，每個數據包都要進行多次傳送，然后計算出平均時間。分別測試單獨使用L2TP隧道和使用L2TP/IPSec隧道時的傳輸時間，比較結果如表1所示。
對于相同的傳輸任務，使用L2TP/IPSec隧道進行傳輸比單獨使用L2TP隧道傳輸所用時間要長，這是因為使用L2TP/IPSec協議封裝，在原有L2TP分組外面又封裝了ESP頭和IP頭，提升了對數據包處理的復雜度，進而增加了系統的開銷，降低了系統的傳輸效率。這說明，安全保護越復雜，系統開銷就越大，安全性的提高會使系統性能有所降低。
３.2 L2TP/IPSec隧道切換時間測試
在系統測試時，測試中的主要延遲為VPN協商時間。在設計時，以修改現有的隧道替代創建新的隧道，盡量減少IP地址改變后L2TP/IPSec隧道的協商時間。模擬裝置中，通過使用ifconfig命令盡量減少從無線網絡獲得一個新IP地址的時間。從車載無線終端向指揮中心發送有一定間隔的UDP數據包，測試時間為5 ms～50 ms。首先，測試未更改的FreeBSD7.0[4]軟件設置，其L2TP/IPSec隧道中的IP變化的平均切換時間為1.53 s，由于中斷和丟包，這是用戶所不能接受的；其次，測試更改的FreeBSD7.0[6]軟件設置，需要在內核空間中增加約1 500行的代碼和在用戶空間增加大約400行代碼。在L2TP/IPSec隧道中切換時間的測試結果如圖3所示。結果達到預期的目標條件下，L2TP/IPSec隧道中的IP變化的平均切換時間為0.079 s，還不會丟失數據包，這是用戶所能接受的。
本方案用一個很小的VPN切換延遲在傳輸網絡中創建了一個改進的L2TP/IPSec隧道，突出體現了L2TP/IPSec隧道的優勢：具有較強的安全性，能夠為用戶提供安全、方便、支持多種協議封裝的VPN遠程接入服務。方案的實施取得了較好的效果，指揮中心能夠取得第一手資料，對突發事件現場迅速采取有效的措施，提高了現場辦公效率，減小了經濟損失，具有重大的意義。
參考文獻
[1] 孫玉．應急通信技術總體框架討論［Ｍ］．北京：人民郵電出版社，200７．
[2] 李慧，李濤．IPSec和L2TP集成的多安全連接技術研究及實現[Ｊ].微計算機信息，2010(26)：93-95.
[3] HOEKSTRA B.Comparing TCP performance of tunneled and non-tunneled traffic using OpenVPN[D].2011.
[4] FreeBSD the power to serve[EB/OL].[2008-06-01).http://www.freebsd.org/.2008.
[5] MPD project from sourceforge[EB/OL].[2009-07-06].http://mpd.sourceforge.net/.2009.
[6] HAFIZ M，ZAHARUDDIN M，RAHMAN R A，et al.Technical Comparison Analysis of Encryption Algorithm on Siteto-Site IPSec VPN[C].IEEE Trans Consumer Electronics，2010：641-645.
[7] Racoon2 website[EB/OL].[2010-05-26].http://www.racoon2.wide.ad.jp/w/.
[8] PATEL B，ABOBA B，DIXON W，et al.Securing L2TP using IPSec[Z].RFC3193.2001.11.
[9] DANALACHI I，PETRESCU M L.Interoperability Issues for VPN IPSec Solutions[C].SECITC，2011：30-33.
[10] MAUGHAN D，SCHERTLER M.Internet security association and key management protocol(ISAKMP)[C].RFC 2408.1998.