摘 要：在应对突发事件救援行动中，指挥中心能否通过互联网取得第一手资料，必要的条件是存在一个安全的连接。虚拟专用网（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.