针对移动虚拟专用网(VPN)中存在的问题，提出一种新的内部网络检测机制。该机制采用移动IPv6作为对移动VPN的支持，并将移动IP的检测与VPN检测相结合，以获得较高的检测准确率，同时实现了VPN。实验结果表明，该机制是有效可行的。

互联网和移动通信的发展使无线上网日趋广泛，而随之带来的安全问题也令人担忧。对于企业用户来说，仅仅能够接入互联网是不够的，他们更关心企业资源的安全性，必须保证出差在外的员工能够在移动环境下安全地访问食业内部网络。正是在这种需求的推动下，将虚拟专用网(VPN)技术与支持移动性的移动IP技术相结合，为用户提供无缝、安全按入服务的移动VPN技术应运而生。

1 移动VPN技术分析

移动VPN技术是移动IP和VPN两种技术的融合，既能够实现节点移动性，同时又能获得VPN的安全性。但技术的复杂性带来了更多问题不管是基于移动IPv4还是移动Pv6的移动VPN,当移动节点在VPN内部时，为了节省网络带宽的开销，都必须采用明文通信，这一点虽然没有移动VPN标准规范的规定，但是移动VPN作为VPN技术的扩展也应该遵守这一约定。

当它移动到公共网络环境时，出于安全的考虑，又都需要有一条隧道建立在移动书点(MN)和网关(GW)之间，MN发往内部网络的数据在公网上是通过隧道传输的，到达GW后由GW负责解封装再查询路由并发往日的节点。显然，移动VPN的实现面临2个问题：

(1)隧道建立时机的判断；

(2)隧道的频繁建立问题。这足实现移动VPN最核心也是最关键的问题。

2 现有技术方案及存在的问题

关于移动VPN面临的问题及解决方案，提出了在IPv4环境下的若干解决方案。该解决方案的拓扑是一个在VPN两侧对称的网络结构，在VPN内部和外部分别配置了家乡代理和外地代理，相应地称为内部家乡代理(i—HA)，内部外地代理(i—FA)，外部家乡代理(x—HA)和外部外地代理(x—FA)。但该方案也有不足之处：

(1)网络环境复杂

该方案需要在VPN内部和外部均配置家乡代理，增加了网络复杂度。从组网投入来看，设备的增加也就意味着成本的提高；从组网的技术来看，家乡代理的位置选择和功能的配置都需要仔细斟酌，特别是部署在VPN外部的家乡代理。

(2)网络负担增加

MN(一般为一台主机或路由器)向VPN网络内外的2个家乡代理同时发送注册请求，并通过接收到的注册应答来源来判断当前MN的位置，由于这种双向注册请求的存在使得网络负担增大，因此不利于有效利用网络带宽。

(3)隧道建立难

即使是移动节点顺利地判断出某一时候需要建立隧道，VPN的实现也并不是一帆风顺的。

(4)该方案的讨论集中在IPv4的网络环境，而并没有提及IPv6。

事实上，从互联网的发展趋势来看，IPv6取代IPv4的步伐越来越坚定，且随着IPv6技术的日益完善和发展，IPv4向IPv6的过渡会越来越快。

因此，必须考虑IPv4与IPv6共存的情况，从更长远的角度看，还要考虑纯IPv6的情况。

3 移动VPN新方案

本文提供的方案充分利用了IPv6的优越性，实现了移动VPN的功能，和现有方案相比有如下特点：

(1)对公共网络没有特殊的要求，不需要特殊功能节点的存在。只要能够接入互联网，就可以建立到VPN网关的隧道，从而保证数据的安全传输。这在一定程度上降低了企业的组网成本。

(2)技术实现简单。对干公共网络环境来说，由于不存在特殊的功能节点，MN只需借助无线网络接入互联网即可，因此在IPv4下面临的外地代理不支持IPSec、不能实现端到端的安全连接以及配置转交地址情况下IP地址预留的问题都不会出现；对于内部网络来说，只需要修改内部路由器的路由通告，同时在移动终端和网关上增加新的功能即可。

(3)组网成本低。本文方案中所有的变动都是针对现有设备的软件升级，不需要投入大量的资金用于设备购入。至于在将企业内部网升级为IPv6网络时的开销，应该看到这一步升级不仅是为了实现移动VPN，还是为了适应互联网发展的趋势，因此，这一步的成本不该完全归于移动VPN。

(4)可扩展性好。本文给出了纯IPv6网络环境下的解决方案，同时也表明本方案可以适应IPv4/v6共存的情况。

(5)顺应下一代网络的发展。本方案采用下一代网络基础技术IPv6作为依托。下一代网络的发展只会使本方案更加成熟，应用更加广泛，而不会像IPv4那样面临被淘汰的命运。

4 移动VPN具体实现

以理论分析为指导，将移动VPN的实现分2步完成：

(1)完成内部网络检测机制的实现，主要通过对VPN内部路由器的升级和对MN功能函数的添加；

(2)完成VPN隧道机制的实现，主要通过对MN功能的进一步补允和新功能节点网关的加入来完成。

4.1内部网络检侧机创实现

实现移动VPN有2个关键问题：(1)是否利用隧道通信的判断；(2)隧道如何建立。

以下给出内部网络检测机制的实现方法，主要涉及对路由器的升级和对移动节点的改造。

4.1.1内部路由器的升级

Radvd是IPv6的路由通告守护程序，它按照“IPv6的邻居发现”描述来监听路由请求并发送路由通告。通过这些通告消息，主机可以自动配置它们的地址和一些其他参数，同时也可以根据这些通告来选择一个默认路由器。

Radvd运行在Linux或BSD上,因其代码的开放性，便于对路由器发送的路由通告的修改，因此，关于路由通告的修改采用修改Radvd代码的方式实现。这里关心的是对发送路由通告信息的处理，在发送的路由通告中需要添加一个新的变量用来表示VPN信息。因此，需要一个新的路由通告信息数据结构来替换原始数据结构，其具体内容为：

将原有接口更新为上述数据结构以后，在接口配置阶段程序会为系统初始化上述数据结构等待调用。因为该数据结构仅获得了初始化定义，新增加的变量并没有参与之后的处理，所以还要加入对新数据结构的处理。由于新数据结构是在原有数据结构的基础上增加新的变量得到的，因此对于新数据的处理可以考虑仍然利用原有处理函数，这样做有2个好处：

(1)由于不必要编写新的函数，只需在函数中加入对新增变量的处理语句，从而减少了对原有代码的更改；

(2)仍然能够处理不具备VPN标识的路由通告信息，在实际运行过程中，如果没有在配置文件中指明是否发送带有VPN标识信息的路由通告，则默认该标识值为零。图1给出了send_ra函数的流程。

图1 send_ra函数的流程

在图1中，send_ra函数(Radvd中的一个重要函数)流程虚线框所示为新增加的对VPN信息的处理部分，主要涉及语句为
radvert->nd_ra_flags_reserved=(iface->AdvVPNFIag)? ND_RA_FLAG_VPN：O：

该语句的作用是从配置文件中读取VPN信息，并将该信息以整型值1或0的形式赋给数据结构中的对应变量。如果配置文件中没有VPN信息，则此时该标识位的值置0，否则置1。在Radvd中还存在另外一个函数Radvdumpa。

这个函数在用户空间解析接收到的路由通告数据，将接收到的路由通告数据打印到屏幕上，用于调试程序及实验。尽管Radvdump并不影响ra的发送，但是不管是程序本身的正确运行还是利用该程序进行深层次的实验时调试都是十分重要的，因此，必须对该文件进行修改，使得通过该命令的运行能够得到关于配置了VPN信息的路由通告的工作情况。其主要操作为
prinlf(“\tAdvManxgedFlag： %s\n”,(radvert->nd_ra_flags_reserved&ND_RA_ FLAG_MANAGED)？”on“off”)；
通过对Radvdump的修改，可以得到另外一个收获，也就是如何在MN上实现。

4.1.2移动节点的改造

在RFC3775标准中规定了移动节点(MN)，家乡代理((HA)和对端节点(CN)3种功能实体。由于CN作为与MN通信的对端，井不关心MN是否进行移动。因此不涉及CN的改造。

对于HA而言，对Radvd的升级完成同时也意味着作为HA的路由器完成了必要的升级，因此，HA也不再需要改造。需要改造的是3个功能实体中最为复杂的MN。

N在初始化完成之后主要是通过icmp监听、netlink套接n监听和移动头监听3个线程来维护MN的正常工作。这里的核心间题是对接收到的路山通告的移动检测处理功能函数md_recv_ra()做相应修改。

md_recv_ra()原始函数的流程如图2所示，调整后的md_recv_ra()函数流程如图3所示。

图2 md_recv_ra函教流程

图3 整后的md_recv_ra函数流程

图3的流程仅给出了带有VPN内部网络检测机制的md_recv_ra()与原始函数不同部分的工作流程，而不是完整的流程图。通告的V标识是在新路由通告格式保留位中新添加的信息，TUNNEL变量用来存放是否已经具有隧道的信息。在移动IP检测到MN发生了移动时，首先进入的是VPN的检测阶段，读取V标识信息是否为1，若为1，此时是不需要隧道通信的，如果有隧道则必须拆除掉，因此，接下来的程序就进行隧道拆除工作，调用tunnel_cleano函数，井将TUNNEL变量置为0，表明此时不存在隧道了，接着程序进入原始函数中移动检测的后续处理部分也即触发移动事件；反之如果此时不存在隧道，则直接进入移动检测后续部分；若上面判断中v标识信息为0，此时需要通过隧道通信，对于TUNNEL=0的情况，程序直接调用tunnel_setup()函数，建立所需隧道，并将TUNNEL置为1，用来表明此时己经存在隧道，而对于TUNNEL=1的情况，则在建立好新的隧道之后还需要拆除之前己经存在的隧道，TUNNEL的值因为已经是1,所以保持不变。在对隧道的处理结束之后，程序进入移动IP后续处理部分直至结束。

4.2胜道机制实现

接下来的工作主要是解决tunnel_clean(), tunnel_setup()的具体实现，从而最终实现移动VPN功能。

关于这2个功能函数的实现，有2种可选方案：

(1)从移动IPv6本身出发，在移动IPv6的协议规范中明确规定了移动IPv6的安全要求，对于信令安全，MN与HA之间的信令交互要通过IPsec隧道完成，MN与CN之问通过返回路由可达过程实现安全性。由于移动IPv6中已经存在IPSec隧道，而VPN也需要IPSec隧道，因此可以沿用或说借鉴移动IPv6的隧道建立思想，完成VPN隧道的建立。

(2)从程序实现的简单快捷出发，以“工具制造工具”为指导思想，考虑能否使用已有工具完成隧道的建立。IPsec-tools是目前Linux中使用比较广泛也比较成熟的开源软件，用于主机或站点之问的IPsec连接。它配置简单，能支持site—to—site的站点模式和Leaf-Node模式，非常适合于VPN的创建，同时IPsec—tools还具有比较全面的功能，对密钥的自动协商提供了足够的支持。

5 移动VPN实验验证

5.1实脸环境

实验环境中无线环境为WLAN；在VPN内部，存在一个无线路由器作为家乡代理，同时还存在一个网络前缀与家乡不同的外地网络A, VPN内部的AR完成网络连接；VPN内部通过网关来与外部公共网络相隔；VPN的外地网络中存在B, C 2个网络；移动节点及路由器的操作系统均为Linux2.6.8.1 kernal；

各功能实体的相关信息如下：家乡代理地址3ffe：3240：8007：1005：：2/64； MN的家乡地址3ffc：3240：8007： 1005：：1/64；MN的本地链路地址fe80：：20c：cdff：fefl ：a2e9； VPN网关地址3ffe：3240：8007： 12：：2；外地网络A前缀 3ffe：3240：8007：2007：：/64；外地网络B前缀3ffe：3240：8007： 2006：：/64；外地网络C前缀3ffe：3240：8007：2005：：/64。

5.2移动VPN验证

按图4顺序进行实验。

图4 MN移动过程示意图

在图4中，步骤①~步骤⑥是MN由家乡向外部移动，先后经过VPN内部的外地网络A, VPN外部的外地网络B和VPN外部的外地网络C,再从网络C回到家乡网络的过程。图中序号上方的add变量和tunnel变量表明MN状态转变时应该具有的状态。

为便于清楚地了解MN的处理过程，在读取VPN标识信息、对TUNNEL值进行判断以及执行tunnel_setup()和tunnelclean()时，分别打印相关语句作为辅助信息。具体操作为：V=1，打印“we need no tunnel”；V=0，打印“we needtunnel”；TUNNEL=0，打印“no tunnel already”；TUNNEL=l，打印“tunnel already”；tunnel_setup()，打印“tunnel built”；tunnel_clean(),打印“tunnel cleaned”；

根据内部网络检测机制验证和移动VPN隧道验证实验过程，绘制实验结果如表1所示。

表1实验结果分析

显然，本文给出的方案完全符合移动VPN的要求。MN在VPN内部时始终能够采用明文通信，而当MN离开VPN时通信则有IPSec隧道的保护。

6 结束语

目前，移动VPN已经作为未来3G的一项主要业务为广大运营商所接受，可以说移动VPN蕴含着巨大商机。对于移动通信运营商来说，实现移动VPN可以借助蜂窝移动网络，也可以借助WLAN，甚至是WiMax。本文针对移动IP技术和VPN技术的研究旨在有效解决无线上网的安全问题，为企业和个人提供一个安全无缝的网络按入环境。