杨柳，张忠培

(1.上海行健职业学院，信息技术与机电工程系，上海 200072；2.电子科技大学，通信抗干扰技术国家级重点实验室，四川，成都 611731)

0 引言

随着我国综合国力的不断攀升，各行各业蓬勃涌现出规模巨大的企业，企业架构普遍呈现出层级化趋势。突如其来的新冠疫情迫使企业主流的工作模式向线上迁移，企业总部及各分部更加迫切地期望能实时安全地互相访问内部资源。VPN是企业用来保障局域网信息跨区域传输的常用安全技术。DMVPN是一种适用于大规模企业的IPsec VPN解决方案，第三阶段DMVPN适用于当前主流企业的层级化架构。通过文献调研发现，国内外对于DMVPN的主要研究集中于传统技术的实际应用和性能分析[1-5]，秦柯[6]提出了将不同的VPN技术进行融合应用，仅论述了理论可行性，实际应用过程中当公司规模较大时，总部中心站点会出现负载过大的问题。陈遥等[7]提出了双云DMVPN设计方案，只是总部与分部间的平行隧道云,在当前企业主流层级化网络架构下，并不能缓解总部站点压力。本文模拟层级化企业架构，优化传统DMVPN单个隧道云方案，创新性地提出了DMVPN分层隧道云与GETVPN融合技术，采用双核心和双密钥服务器设计，避免单点故障。在实现企业内部局域网资源安全传输的前提下，简化各出口站点设备配置，大大降低了中心站点的负载压力。

1 网络架构优化设计

图1为模拟大型企业当前主流的层级化网络拓扑[8]。广州总部采用双核心架构，GM-HQ1和GM-HQ11为主用和备用出口站点，R2、R5和R6模拟互联网，上海分部GM-BR3下设崇明GM-BR3-7和临港GM-BR3-8分部，北京分部GM-BR4下设通州GM-BR4-9和雄安GM-BR4-10分部，因此形成多级网络架构。KS1和KS2分别为基于GETVPN技术的主用和备用KS，用以向各加密站点提供策略服务，具体IP地址规划如表1所示。

本网络在模拟当前企业主流层级化架构下，优化传统DMVPN单个隧道云方案，使用分层隧道云，同时采用双核心和双密钥服务器设计，避免单点故障，合理规划各站点的隧道地址以及局域网内部地址，使各分部站点的地址能够汇总，以简化各出口站点的路由配置工作量。

图1 企业网络拓扑图

表1 IP地址规划表

2 DMVPN和GETVPN 融合方案

在图1的网络架构中，在互联网畅通的前提下，要实现总部核心站点与各分部出口站点，以及各分部站点间的局域网安全通信。本方案在传统第三阶段DMVPN 的基础上结合GETVPN技术，主要由分层隧道云、NHRP、静态路由协议和GETVPN四部分组成。其中,使用DMVPN的mGRE隧道和NHRP技术结合本文提出的分层隧道云设计实现隧道畅通，在此基础上使用静态路由协议连通各站点的局域网，但此时通信流量并没有安全保护措施，进而使用GETVPN技术保证各站点的局域网间能够安全通信。为实现总部双核心站点互相备份，用到浮动静态路由和HSRP技术。融合方案实现流程如图2所示，以下重点介绍DMVPN中的分层隧道云和NHRP，以及GETVPN技术。

2.1 DMVPN技术

DMVPN是一种适用于大规模企业VPN部署的解决方案，主要由mGRE、NHRP、动态路由协议和IPsec VPN四大关键技术结合实现，DMVPN有3个发展阶段，每个阶段有不同的特点[6]。本文模拟的企业网络符合第三阶段DMVPN的层次化架构特征，其关键技术介绍如下。

图2 融合方案实现流程图

(1) mGRE隧道

mGRE协议是一种特殊的GRE技术，处于同一个隧道云中的站点接口处于同一个网段，通过隧道云可以实现站点间虚拟网状连通性[9]。图1所模拟的网络在公网畅通的前提下，多层隧道云有利于大型企业多级分公司架构部署，本文采用多层隧道云方案，广州与上海、北京间的隧道网络为172.16.1.0/24，上海、北京与其各自分部间的网络隧道为172.16.2.0/24，具体隧道地址如表2所示。

表2 mGRE隧道地址规划

(2) NHRP

NHRP协议可以实现物理地址与隧道地址的映射，进而实现各隧道地址连通[10]。第三阶段DMVPN的NHRP处理方法是各分部出口站点需静态映射总部站点的隧道地址和公网地址，通过NHRP协议向总部站点注册自身信息，总部站点会掌握所有分部站点的映射信息。当分部间需要互相通信时，将数据首先发送给总部站点[11]。

2.2 组加密传输VPN

组加密传输VPN即GETVPN，它为所有成员提供了单一的SA和密钥，用以实现任意站点到任意站点间的即时通信。它由密钥服务器(KS)、组成员(GM)和GDOI协议[12]三部分构成，使所有参与加密的站点都先加入一个GETVPN组，成为GM，由KS认证GM，接受各GM注册，并统一分发SA策略和密钥更新策略，各GM之间不需要再一一协商SA，因而大大降低了通信时延。

(1) GETVPN核心组件

密钥服务器(Key Server)是网络中负责创建和维护安全策略的路由器。在组成员向KS注册成功后，KS负责提供策略给组成员，同时负责密钥的更新和推送。

组成员(Group Member)是负责传递VPN流量的出口站点路由器。它会先在KS上进行注册，成功注册后，将从KS上获得这个组的安全策略和密钥信息，之后就可以使用获取到的策略与其他组成员进行VPN通信。

GDOI协议用在GM和KS之间建立安全关联，实现安全的组内通信，它取代了传统IPsec VPN中的IKE第二阶段协商，在GM与KS之间的协商，并生成IPsec SA，GDOI协议的端口号为UDP/848[13]。

(2) GETVPN工作流程

GETVPN工作流程如图3所示。GM和KS之间首先进行IKE第一阶段协商，协商成功后GM开始向KS注册，并将安全关联策略和密钥资源“拉”到本地，此时便可以利用这些信息与其他GM之间进行数据加解密。除此以外，KS还会将密钥更新信息“推”给GM，即Rekey SA。正常情况下GM应该能够周期性地接收到KS“推”来的密钥更新信息，如果密钥超时仍没有收到，GM则需向KS重新注册[14]。

图3 GETVPN工作流程图

(3) 协作KS

KS在GETVPN整个工作流程中具有至关重要的作用。为避免单点故障，GETVPN支持多个KS协同工作，并根据优先级选举主用KS和备用KS，主用KS在将策略分发给各GM的同时，向备用KS发送消息通告，如果备用KS长时间没有收到通告，将主动请求更新，若无响应，则启用备用KS。

3 系统配置和仿真测试

3.1 系统配置

根据流程图2和前文关于关键技术的分析，在图1的网络拓扑下DMVPN多层隧道云与GETVPN技术融合方案配置过程介绍如下。

3.1.1 基本配置

要实现各站点局域网间的安全互联，首要前提是局域网内部互联，其次还需要互联网畅通。

本网络架构中各分部站点都使用环回口模拟局域网，广州总部采用双核心架构，不仅为总部局域网提供主备网关，还为各分部站点访问总部提供核心站点冗余。这里在广州总部主用和备用站点的内网口使用HSRP生成虚拟网关[15]，当主用网关故障时，备用网关自动检测并充当活动网关，实现内部网关冗余。总部局域网设备HQ-R12使用默认路由，下一跳指向虚拟网关地址，实现总部局域网连通。

3.1.2 DMVPN配置

(1) 分层隧道云

根据第2.1节分析使用分层DMVPN技术(第三阶段)在总部及各分部出口站点上创建分层隧道，如表2中第一层隧道云mGRE1的隧道地址均属于172.16.1.0/24，第二层隧道云mGRE2的隧道地址均属于172.16.2.0/24。其关键性配置如图4(以上海站点为例)所示。

图4 分层隧道云配置

(2) NHRP配置

本文层次化企业网络架构中，总部核心站点需动态接受两直属分部的组播映射注册，同时主备核心站点间还需要互相配置静态映射。上海与北京站点需设置与总部核心站点的静态映射，同时还需分别接受崇明、临港和通州、雄安站点的动态组播映射。崇明、临港、通州和雄安站点需要向其各自的上级公司站点设置静态映射。

3.1.3 静态路由协议

要实现隧道间地址互通和各出口站点内部局域网互通，传统DMVPN技术采用动态路由协议来实现，但动态路由协议需要维护大量的更新数据包，为出口站点加解密数据带来沉重的负担，在此采用静态路由协议。需合理规划各站点的隧道地址以及局域网内部地址，各分部站点的地址需能够汇总。如表1所示，上海、崇明、临港3个分部的局域网192.168.3.0/27、192.168.3.32/27、192.168.3.128/27均为192.168.3.0/24的子网，北京、通州、雄安3个分部的局域网192.168.4.0/27、192.168.4.48/27、192.168.4.128/27均为192.168.4.0/24的子网，上海、北京各分部的所有局域网可汇总为192.168.0.0/16。如表2所示，mGRE2隧道云中，上海、崇明和临港3个站点的地址可汇总为172.16.2.32/27，北京、通州和雄安3个站点的地址可汇总为172.16.2.128/27，所有站点的地址都可汇总为172.16.2.0/24。

根据第三阶段DMVPN的特性，总部出口站点上需配置到达各分部局域网内部的明细路由，分部站点只需配置指向总部站点的汇总路由，但广州总部的双核心架构使得其分部需使用浮动静态路由，当检测到主用核心设备故障时，启用备用线路。图1中上海站点BR3的路由配置示例如图5所示。

ip route 192.168.3.32 255.255.255.224 172.16.2.37 //向崇明分部的路由

ip route 192.168.3.128 255.255.255.224 172.16.2.38 //向临港分部的路由

ip route 192.168.0.0 255.255.0.0 172.16.1.1 track 1 //向总部的汇总路由(主用)

ip route 192.168.0.0 255.255.0.0 172.16.1.11 10 //向总部的汇总路由(备用)

图5 上海站点BR3的路由配置示例图

不同隧道云之间也需要路由协议连通，图6为广州站点的路由配置，到上海及其2个分部站点都指向上海站点，到北京及其2个分部都指向北京站点。

ip route 192.168.12.0 255.255.255.0 192.168.1.12 // 向广州总部局域网的路由

ip route 172.16.2.32 255.255.255.224 172.16.1.3 //向上海分部隧道的路由

ip route 172.16.2.128 255.255.255.224 172.16.1.4 //向北京分部隧道的路由

ip route 192.168.3.0 255.255.255.0 172.16.1.3 //向上海分部局域网的路由

ip route 192.168.4.0 255.255.255.0 172.16.1.4 //向北京分部局域网的路由

图6 广州站点路由配置示例图

3.1.4 GETVPN配置

KS1和KS2为各站点共用的协作KS组，总部及分部所有出口站点均为GETVPN的GM，图1设备命名含GM的设备均为GM。

(1) KS配置

根据第3节GETVPN流程分析，主用KS需承担以下任务：接受GM注册、产生密钥、分发密钥、通知备用KS同步密钥、发送密钥更新信息。备用KS除了需要接受GM的注册外，还需检测主用KS是否正常工作、同步GM信息，无需发送密钥更新信息。主用KS关键配置如图7所示。

图7 主用KS的关键配置

(2) GM配置

因所有GM都只需要与KS进行IKE第一阶段协商，进而通过GDOI协议向KS注册并“拉”策略到本地，所以配置比较简单并且此部分所有GM的配置相同，如图8所示。

图8 GM的GETVPN配置

3.2 仿真测试

采用GNS3模拟软件结合VMware Workstation中运行的Ubuntu系统搭建如图1的网络拓扑，配置各设备并测试验证结果。

3.2.1 站点GETVPN状态测试

图9为融合技术下连通测试前临港站点的加解密情况和GDOI组状态，可以看到作为GM的临港站点在没有数据加解密的情况下，已经存在IPsec SA和Rekey SA，这是GETVPN特性决定的，不管有没有数据加解密，在GM向KS注册时已经将相关的安全策略“拉”到本地，并且经验证所有站点间的IPsec SA使用图9中统一的安全策略。有了这些统一的策略，站点间将不必再协商IPsec隧道，大大减少了路由器的资源消耗，从而实现GM间实时通信。

3.2.2 总部站点压力对比测试

图10显示融合技术下各站点的局域网间正常通信，但无论怎样通信，各站点都只有一对IPsec SA负责加解密数据(如图10虚线框所示)，并且由加解密包数量5和10可知，融合技术下各站点只负责加解密局域网间的通信数据包，没有其他多余流量。广州总部站点只负责加解密自己局域网与其他局域网的流量，分部站点的局域网间通信并不需要占用总部站点带宽。

图9 连通测试前临港站点的GDOI状态

图10 局域网通信和站点的加解密情况

为了对比与传统DMVPN技术的差异，在此网络架构中使用传统DMVPN技术做仿真对比，同样使用ping命令测试局域网间的连通性，在发送相同数量数据包的情况下，如图9所示，上海和广州站点分别有5对和2对IPsec SA，即需要和多个站点维护点对点IPsec SA。同时，图11中的加解密数据包数量远远超过测试数据包数量。

图11 传统DMVPN技术下站点的加解密情况

3.2.3 双核心冗余测试

如图12，跟踪由上海内网到广州总部内网的通信路径可知，当广州总部主用核心站点GM-HQ1正常工作时，数据包经GM-HQ1到达总部内网设备HQ-R12；使用ping命令连续测试上海到广州内网间的连通性，此时关闭GM-HQ1的任一端口，上海站点检测到GM-HQ1故障后会启用浮动静态路由，经短暂的丢包后继续连通；再次跟踪通信路径可知，数据包经广州总部备用核心站点GM-HQ11到达总部局域网设备HQ-R12。

图12 核心站点冗余测试-分部到总部

如图13，跟踪由广州总部内网到上海内网的通信路径可知，当GM-HQ1正常工作时，数据包经GM-HQ1到达上海内网，使用ping命令连续测试广州到上海内网间的连通性，此时关闭GM-HQ1的任一端口，HSRP将启用GM-HQ11为活动路由器，经短暂的丢包后继续连通；再次跟踪通信路径可知，数据包经GM-HQ11到达上海内网。

图13 核心站点冗余测试-总部到分部

3.2.4 协作KS测试

图14为KS1正常工作时，临港站点的第一阶段IKE SA状态，可以看出和KS1建立了IKE SA。此时断开KS1，在KS2上查看协作KS状态可知，KS2为当前活动KS。再次测试临港与通州站点间局域网的连通情况和IKE状态，如图15所示，KS1故障并没有影响站点间的通信和数据加解密，但改变为和KS2建立IKE SA。

图14 KS1故障前测试和故障后协作KS状态

图15 KS1故障后站点间的加解密和IKE SA情况

4 总结

本文在模拟当前大规模企业主流分层网络架构的前提下，详细描述了使用DMVPN和GETVPN相融合的技术实现各站点局域网的安全通信解决方案。通过仿真验证了方案的可行性，与传统DMVPN技术方案对比，体现了融合技术所具备的优势，分析本方案主要有以下几方面特点：

(1) 减轻部署工作量

此方案中VPN第二阶段协商所用到的策略和信息都在KS上配置并统一，所有GM的GETVPN相关配置大大简化并且完全一致，避免了传统VPN方案中各个站点分别配置安全策略带来的巨大工作量。

(2) 实现即时通信

根据第3.2.1节测试，在GETVPN技术下不需要像传统IPSec VPN一样需要被感兴趣流触发产生，进而协商安全关联而产生时延，现有的安全关联可以保证站点与任意站点实时通信。

(3) 减轻总部站点压力

通过第3.2.2节仿真对比，传统DMVPN技术时加解密数据包数量明显多于融合技术时。在融合技术下，总部站点只需维护单一的安全关联并且不存在路由协议更新数据包，大大减轻了其负载压力。

(4) 双核心和双KS

根据第3.2.3和3.2.4节测试，广州总部的双核心架构实现了总公司出口站点互相备份，采用浮动静态路由和HSRP技术分别实现了双向冗余。同时启用协作KS，实现了KS备份。

随着近年来国产设备的崛起与发展，目前国内网络设备市场国产设备占有率稳步增长，本文下一步的工作是研究国产设备网络环境下大规模企业的DMVPN部署，以及不同厂商设备间VPN技术兼容性问题。