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