楊柳，張忠培

(1.上海行健職業(yè)學(xué)院，信息技術(shù)與機(jī)電工程系，上海 200072；2.電子科技大學(xué)，通信抗干擾技術(shù)國家級重點實驗室，四川，成都 611731)

0 引言

隨著我國綜合國力的不斷攀升，各行各業(yè)蓬勃涌現(xiàn)出規(guī)模巨大的企業(yè)，企業(yè)架構(gòu)普遍呈現(xiàn)出層級化趨勢。突如其來的新冠疫情迫使企業(yè)主流的工作模式向線上遷移，企業(yè)總部及各分部更加迫切地期望能實時安全地互相訪問內(nèi)部資源。VPN是企業(yè)用來保障局域網(wǎng)信息跨區(qū)域傳輸?shù)某Ｓ冒踩夹g(shù)。DMVPN是一種適用于大規(guī)模企業(yè)的IPsec VPN解決方案，第三階段DMVPN適用于當(dāng)前主流企業(yè)的層級化架構(gòu)。通過文獻(xiàn)調(diào)研發(fā)現(xiàn)，國內(nèi)外對于DMVPN的主要研究集中于傳統(tǒng)技術(shù)的實際應(yīng)用和性能分析[1-5]，秦柯[6]提出了將不同的VPN技術(shù)進(jìn)行融合應(yīng)用，僅論述了理論可行性，實際應(yīng)用過程中當(dāng)公司規(guī)模較大時，總部中心站點會出現(xiàn)負(fù)載過大的問題。陳遙等[7]提出了雙云DMVPN設(shè)計方案，只是總部與分部間的平行隧道云,在當(dāng)前企業(yè)主流層級化網(wǎng)絡(luò)架構(gòu)下，并不能緩解總部站點壓力。本文模擬層級化企業(yè)架構(gòu)，優(yōu)化傳統(tǒng)DMVPN單個隧道云方案，創(chuàng)新性地提出了DMVPN分層隧道云與GETVPN融合技術(shù)，采用雙核心和雙密鑰服務(wù)器設(shè)計，避免單點故障。在實現(xiàn)企業(yè)內(nèi)部局域網(wǎng)資源安全傳輸?shù)那疤嵯拢喕鞒隹谡军c設(shè)備配置，大大降低了中心站點的負(fù)載壓力。

1 網(wǎng)絡(luò)架構(gòu)優(yōu)化設(shè)計

圖1為模擬大型企業(yè)當(dāng)前主流的層級化網(wǎng)絡(luò)拓?fù)鋄8]。廣州總部采用雙核心架構(gòu)，GM-HQ1和GM-HQ11為主用和備用出口站點，R2、R5和R6模擬互聯(lián)網(wǎng)，上海分部GM-BR3下設(shè)崇明GM-BR3-7和臨港GM-BR3-8分部，北京分部GM-BR4下設(shè)通州GM-BR4-9和雄安GM-BR4-10分部，因此形成多級網(wǎng)絡(luò)架構(gòu)。KS1和KS2分別為基于GETVPN技術(shù)的主用和備用KS，用以向各加密站點提供策略服務(wù)，具體IP地址規(guī)劃如表1所示。

本網(wǎng)絡(luò)在模擬當(dāng)前企業(yè)主流層級化架構(gòu)下，優(yōu)化傳統(tǒng)DMVPN單個隧道云方案，使用分層隧道云，同時采用雙核心和雙密鑰服務(wù)器設(shè)計，避免單點故障，合理規(guī)劃各站點的隧道地址以及局域網(wǎng)內(nèi)部地址，使各分部站點的地址能夠匯總，以簡化各出口站點的路由配置工作量。

圖1 企業(yè)網(wǎng)絡(luò)拓?fù)鋱D

表1 IP地址規(guī)劃表

2 DMVPN和GETVPN 融合方案

在圖1的網(wǎng)絡(luò)架構(gòu)中，在互聯(lián)網(wǎng)暢通的前提下，要實現(xiàn)總部核心站點與各分部出口站點，以及各分部站點間的局域網(wǎng)安全通信。本方案在傳統(tǒng)第三階段DMVPN 的基礎(chǔ)上結(jié)合GETVPN技術(shù)，主要由分層隧道云、NHRP、靜態(tài)路由協(xié)議和GETVPN四部分組成。其中,使用DMVPN的mGRE隧道和NHRP技術(shù)結(jié)合本文提出的分層隧道云設(shè)計實現(xiàn)隧道暢通，在此基礎(chǔ)上使用靜態(tài)路由協(xié)議連通各站點的局域網(wǎng)，但此時通信流量并沒有安全保護(hù)措施，進(jìn)而使用GETVPN技術(shù)保證各站點的局域網(wǎng)間能夠安全通信。為實現(xiàn)總部雙核心站點互相備份，用到浮動靜態(tài)路由和HSRP技術(shù)。融合方案實現(xiàn)流程如圖2所示，以下重點介紹DMVPN中的分層隧道云和NHRP，以及GETVPN技術(shù)。

2.1 DMVPN技術(shù)

DMVPN是一種適用于大規(guī)模企業(yè)VPN部署的解決方案，主要由mGRE、NHRP、動態(tài)路由協(xié)議和IPsec VPN四大關(guān)鍵技術(shù)結(jié)合實現(xiàn)，DMVPN有3個發(fā)展階段，每個階段有不同的特點[6]。本文模擬的企業(yè)網(wǎng)絡(luò)符合第三階段DMVPN的層次化架構(gòu)特征，其關(guān)鍵技術(shù)介紹如下。

圖2 融合方案實現(xiàn)流程圖

(1) mGRE隧道

mGRE協(xié)議是一種特殊的GRE技術(shù)，處于同一個隧道云中的站點接口處于同一個網(wǎng)段，通過隧道云可以實現(xiàn)站點間虛擬網(wǎng)狀連通性[9]。圖1所模擬的網(wǎng)絡(luò)在公網(wǎng)暢通的前提下，多層隧道云有利于大型企業(yè)多級分公司架構(gòu)部署，本文采用多層隧道云方案，廣州與上海、北京間的隧道網(wǎng)絡(luò)為172.16.1.0/24，上海、北京與其各自分部間的網(wǎng)絡(luò)隧道為172.16.2.0/24，具體隧道地址如表2所示。

表2 mGRE隧道地址規(guī)劃

(2) NHRP

NHRP協(xié)議可以實現(xiàn)物理地址與隧道地址的映射，進(jìn)而實現(xiàn)各隧道地址連通[10]。第三階段DMVPN的NHRP處理方法是各分部出口站點需靜態(tài)映射總部站點的隧道地址和公網(wǎng)地址，通過NHRP協(xié)議向總部站點注冊自身信息，總部站點會掌握所有分部站點的映射信息。當(dāng)分部間需要互相通信時，將數(shù)據(jù)首先發(fā)送給總部站點[11]。

2.2 組加密傳輸VPN

組加密傳輸VPN即GETVPN，它為所有成員提供了單一的SA和密鑰，用以實現(xiàn)任意站點到任意站點間的即時通信。它由密鑰服務(wù)器(KS)、組成員(GM)和GDOI協(xié)議[12]三部分構(gòu)成，使所有參與加密的站點都先加入一個GETVPN組，成為GM，由KS認(rèn)證GM，接受各GM注冊，并統(tǒng)一分發(fā)SA策略和密鑰更新策略，各GM之間不需要再一一協(xié)商SA，因而大大降低了通信時延。

(1) GETVPN核心組件

密鑰服務(wù)器(Key Server)是網(wǎng)絡(luò)中負(fù)責(zé)創(chuàng)建和維護(hù)安全策略的路由器。在組成員向KS注冊成功后，KS負(fù)責(zé)提供策略給組成員，同時負(fù)責(zé)密鑰的更新和推送。

組成員(Group Member)是負(fù)責(zé)傳遞VPN流量的出口站點路由器。它會先在KS上進(jìn)行注冊，成功注冊后，將從KS上獲得這個組的安全策略和密鑰信息，之后就可以使用獲取到的策略與其他組成員進(jìn)行VPN通信。

GDOI協(xié)議用在GM和KS之間建立安全關(guān)聯(lián)，實現(xiàn)安全的組內(nèi)通信，它取代了傳統(tǒng)IPsec VPN中的IKE第二階段協(xié)商，在GM與KS之間的協(xié)商，并生成IPsec SA，GDOI協(xié)議的端口號為UDP/848[13]。

(2) GETVPN工作流程

GETVPN工作流程如圖3所示。GM和KS之間首先進(jìn)行IKE第一階段協(xié)商，協(xié)商成功后GM開始向KS注冊，并將安全關(guān)聯(lián)策略和密鑰資源“拉”到本地，此時便可以利用這些信息與其他GM之間進(jìn)行數(shù)據(jù)加解密。除此以外，KS還會將密鑰更新信息“推”給GM，即Rekey SA。正常情況下GM應(yīng)該能夠周期性地接收到KS“推”來的密鑰更新信息，如果密鑰超時仍沒有收到，GM則需向KS重新注冊[14]。

圖3 GETVPN工作流程圖

(3) 協(xié)作KS

KS在GETVPN整個工作流程中具有至關(guān)重要的作用。為避免單點故障，GETVPN支持多個KS協(xié)同工作，并根據(jù)優(yōu)先級選舉主用KS和備用KS，主用KS在將策略分發(fā)給各GM的同時，向備用KS發(fā)送消息通告，如果備用KS長時間沒有收到通告，將主動請求更新，若無響應(yīng)，則啟用備用KS。

3 系統(tǒng)配置和仿真測試

3.1 系統(tǒng)配置

根據(jù)流程圖2和前文關(guān)于關(guān)鍵技術(shù)的分析，在圖1的網(wǎng)絡(luò)拓?fù)湎翫MVPN多層隧道云與GETVPN技術(shù)融合方案配置過程介紹如下。

3.1.1 基本配置

要實現(xiàn)各站點局域網(wǎng)間的安全互聯(lián)，首要前提是局域網(wǎng)內(nèi)部互聯(lián)，其次還需要互聯(lián)網(wǎng)暢通。

本網(wǎng)絡(luò)架構(gòu)中各分部站點都使用環(huán)回口模擬局域網(wǎng)，廣州總部采用雙核心架構(gòu)，不僅為總部局域網(wǎng)提供主備網(wǎng)關(guān)，還為各分部站點訪問總部提供核心站點冗余。這里在廣州總部主用和備用站點的內(nèi)網(wǎng)口使用HSRP生成虛擬網(wǎng)關(guān)[15]，當(dāng)主用網(wǎng)關(guān)故障時，備用網(wǎng)關(guān)自動檢測并充當(dāng)活動網(wǎng)關(guān)，實現(xiàn)內(nèi)部網(wǎng)關(guān)冗余。總部局域網(wǎng)設(shè)備HQ-R12使用默認(rèn)路由，下一跳指向虛擬網(wǎng)關(guān)地址，實現(xiàn)總部局域網(wǎng)連通。

3.1.2 DMVPN配置

(1) 分層隧道云

根據(jù)第2.1節(jié)分析使用分層DMVPN技術(shù)(第三階段)在總部及各分部出口站點上創(chuàng)建分層隧道，如表2中第一層隧道云mGRE1的隧道地址均屬于172.16.1.0/24，第二層隧道云mGRE2的隧道地址均屬于172.16.2.0/24。其關(guān)鍵性配置如圖4(以上海站點為例)所示。

圖4 分層隧道云配置

(2) NHRP配置

本文層次化企業(yè)網(wǎng)絡(luò)架構(gòu)中，總部核心站點需動態(tài)接受兩直屬分部的組播映射注冊，同時主備核心站點間還需要互相配置靜態(tài)映射。上海與北京站點需設(shè)置與總部核心站點的靜態(tài)映射，同時還需分別接受崇明、臨港和通州、雄安站點的動態(tài)組播映射。崇明、臨港、通州和雄安站點需要向其各自的上級公司站點設(shè)置靜態(tài)映射。

3.1.3 靜態(tài)路由協(xié)議

要實現(xiàn)隧道間地址互通和各出口站點內(nèi)部局域網(wǎng)互通，傳統(tǒng)DMVPN技術(shù)采用動態(tài)路由協(xié)議來實現(xiàn)，但動態(tài)路由協(xié)議需要維護(hù)大量的更新數(shù)據(jù)包，為出口站點加解密數(shù)據(jù)帶來沉重的負(fù)擔(dān)，在此采用靜態(tài)路由協(xié)議。需合理規(guī)劃各站點的隧道地址以及局域網(wǎng)內(nèi)部地址，各分部站點的地址需能夠匯總。如表1所示，上海、崇明、臨港3個分部的局域網(wǎng)192.168.3.0/27、192.168.3.32/27、192.168.3.128/27均為192.168.3.0/24的子網(wǎng)，北京、通州、雄安3個分部的局域網(wǎng)192.168.4.0/27、192.168.4.48/27、192.168.4.128/27均為192.168.4.0/24的子網(wǎng)，上海、北京各分部的所有局域網(wǎng)可匯總為192.168.0.0/16。如表2所示，mGRE2隧道云中，上海、崇明和臨港3個站點的地址可匯總為172.16.2.32/27，北京、通州和雄安3個站點的地址可匯總為172.16.2.128/27，所有站點的地址都可匯總為172.16.2.0/24。

根據(jù)第三階段DMVPN的特性，總部出口站點上需配置到達(dá)各分部局域網(wǎng)內(nèi)部的明細(xì)路由，分部站點只需配置指向總部站點的匯總路由，但廣州總部的雙核心架構(gòu)使得其分部需使用浮動靜態(tài)路由，當(dāng)檢測到主用核心設(shè)備故障時，啟用備用線路。圖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的路由配置示例圖

不同隧道云之間也需要路由協(xié)議連通，圖6為廣州站點的路由配置，到上海及其2個分部站點都指向上海站點，到北京及其2個分部都指向北京站點。

ip route 192.168.12.0 255.255.255.0 192.168.1.12 // 向廣州總部局域網(wǎng)的路由

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 //向上海分部局域網(wǎng)的路由

ip route 192.168.4.0 255.255.255.0 172.16.1.4 //向北京分部局域網(wǎng)的路由

圖6 廣州站點路由配置示例圖

3.1.4 GETVPN配置

KS1和KS2為各站點共用的協(xié)作KS組，總部及分部所有出口站點均為GETVPN的GM，圖1設(shè)備命名含GM的設(shè)備均為GM。

(1) KS配置

根據(jù)第3節(jié)GETVPN流程分析，主用KS需承擔(dān)以下任務(wù)：接受GM注冊、產(chǎn)生密鑰、分發(fā)密鑰、通知備用KS同步密鑰、發(fā)送密鑰更新信息。備用KS除了需要接受GM的注冊外，還需檢測主用KS是否正常工作、同步GM信息，無需發(fā)送密鑰更新信息。主用KS關(guān)鍵配置如圖7所示。

圖7 主用KS的關(guān)鍵配置

(2) GM配置

因所有GM都只需要與KS進(jìn)行IKE第一階段協(xié)商，進(jìn)而通過GDOI協(xié)議向KS注冊并“拉”策略到本地，所以配置比較簡單并且此部分所有GM的配置相同，如圖8所示。

圖8 GM的GETVPN配置

3.2 仿真測試

采用GNS3模擬軟件結(jié)合VMware Workstation中運行的Ubuntu系統(tǒng)搭建如圖1的網(wǎng)絡(luò)拓?fù)?，配置各設(shè)備并測試驗證結(jié)果。

3.2.1 站點GETVPN狀態(tài)測試

圖9為融合技術(shù)下連通測試前臨港站點的加解密情況和GDOI組狀態(tài)，可以看到作為GM的臨港站點在沒有數(shù)據(jù)加解密的情況下，已經(jīng)存在IPsec SA和Rekey SA，這是GETVPN特性決定的，不管有沒有數(shù)據(jù)加解密，在GM向KS注冊時已經(jīng)將相關(guān)的安全策略“拉”到本地，并且經(jīng)驗證所有站點間的IPsec SA使用圖9中統(tǒng)一的安全策略。有了這些統(tǒng)一的策略，站點間將不必再協(xié)商IPsec隧道，大大減少了路由器的資源消耗，從而實現(xiàn)GM間實時通信。

3.2.2 總部站點壓力對比測試

圖10顯示融合技術(shù)下各站點的局域網(wǎng)間正常通信，但無論怎樣通信，各站點都只有一對IPsec SA負(fù)責(zé)加解密數(shù)據(jù)(如圖10虛線框所示)，并且由加解密包數(shù)量5和10可知，融合技術(shù)下各站點只負(fù)責(zé)加解密局域網(wǎng)間的通信數(shù)據(jù)包，沒有其他多余流量。廣州總部站點只負(fù)責(zé)加解密自己局域網(wǎng)與其他局域網(wǎng)的流量，分部站點的局域網(wǎng)間通信并不需要占用總部站點帶寬。

圖9 連通測試前臨港站點的GDOI狀態(tài)

圖10 局域網(wǎng)通信和站點的加解密情況

為了對比與傳統(tǒng)DMVPN技術(shù)的差異，在此網(wǎng)絡(luò)架構(gòu)中使用傳統(tǒng)DMVPN技術(shù)做仿真對比，同樣使用ping命令測試局域網(wǎng)間的連通性，在發(fā)送相同數(shù)量數(shù)據(jù)包的情況下，如圖9所示，上海和廣州站點分別有5對和2對IPsec SA，即需要和多個站點維護(hù)點對點IPsec SA。同時，圖11中的加解密數(shù)據(jù)包數(shù)量遠(yuǎn)遠(yuǎn)超過測試數(shù)據(jù)包數(shù)量。

圖11 傳統(tǒng)DMVPN技術(shù)下站點的加解密情況

3.2.3 雙核心冗余測試

如圖12，跟蹤由上海內(nèi)網(wǎng)到廣州總部內(nèi)網(wǎng)的通信路徑可知，當(dāng)廣州總部主用核心站點GM-HQ1正常工作時，數(shù)據(jù)包經(jīng)GM-HQ1到達(dá)總部內(nèi)網(wǎng)設(shè)備HQ-R12；使用ping命令連續(xù)測試上海到廣州內(nèi)網(wǎng)間的連通性，此時關(guān)閉GM-HQ1的任一端口，上海站點檢測到GM-HQ1故障后會啟用浮動靜態(tài)路由，經(jīng)短暫的丟包后繼續(xù)連通；再次跟蹤通信路徑可知，數(shù)據(jù)包經(jīng)廣州總部備用核心站點GM-HQ11到達(dá)總部局域網(wǎng)設(shè)備HQ-R12。

圖12 核心站點冗余測試-分部到總部

如圖13，跟蹤由廣州總部內(nèi)網(wǎng)到上海內(nèi)網(wǎng)的通信路徑可知，當(dāng)GM-HQ1正常工作時，數(shù)據(jù)包經(jīng)GM-HQ1到達(dá)上海內(nèi)網(wǎng)，使用ping命令連續(xù)測試廣州到上海內(nèi)網(wǎng)間的連通性，此時關(guān)閉GM-HQ1的任一端口，HSRP將啟用GM-HQ11為活動路由器，經(jīng)短暫的丟包后繼續(xù)連通；再次跟蹤通信路徑可知，數(shù)據(jù)包經(jīng)GM-HQ11到達(dá)上海內(nèi)網(wǎng)。

圖13 核心站點冗余測試-總部到分部

3.2.4 協(xié)作KS測試

圖14為KS1正常工作時，臨港站點的第一階段IKE SA狀態(tài)，可以看出和KS1建立了IKE SA。此時斷開KS1，在KS2上查看協(xié)作KS狀態(tài)可知，KS2為當(dāng)前活動KS。再次測試臨港與通州站點間局域網(wǎng)的連通情況和IKE狀態(tài)，如圖15所示，KS1故障并沒有影響站點間的通信和數(shù)據(jù)加解密，但改變?yōu)楹蚄S2建立IKE SA。

圖14 KS1故障前測試和故障后協(xié)作KS狀態(tài)

圖15 KS1故障后站點間的加解密和IKE SA情況

4 總結(jié)

本文在模擬當(dāng)前大規(guī)模企業(yè)主流分層網(wǎng)絡(luò)架構(gòu)的前提下，詳細(xì)描述了使用DMVPN和GETVPN相融合的技術(shù)實現(xiàn)各站點局域網(wǎng)的安全通信解決方案。通過仿真驗證了方案的可行性，與傳統(tǒng)DMVPN技術(shù)方案對比，體現(xiàn)了融合技術(shù)所具備的優(yōu)勢，分析本方案主要有以下幾方面特點：

(1) 減輕部署工作量

此方案中VPN第二階段協(xié)商所用到的策略和信息都在KS上配置并統(tǒng)一，所有GM的GETVPN相關(guān)配置大大簡化并且完全一致，避免了傳統(tǒng)VPN方案中各個站點分別配置安全策略帶來的巨大工作量。

(2) 實現(xiàn)即時通信

根據(jù)第3.2.1節(jié)測試，在GETVPN技術(shù)下不需要像傳統(tǒng)IPSec VPN一樣需要被感興趣流觸發(fā)產(chǎn)生，進(jìn)而協(xié)商安全關(guān)聯(lián)而產(chǎn)生時延，現(xiàn)有的安全關(guān)聯(lián)可以保證站點與任意站點實時通信。

(3) 減輕總部站點壓力

通過第3.2.2節(jié)仿真對比，傳統(tǒng)DMVPN技術(shù)時加解密數(shù)據(jù)包數(shù)量明顯多于融合技術(shù)時。在融合技術(shù)下，總部站點只需維護(hù)單一的安全關(guān)聯(lián)并且不存在路由協(xié)議更新數(shù)據(jù)包，大大減輕了其負(fù)載壓力。

(4) 雙核心和雙KS

根據(jù)第3.2.3和3.2.4節(jié)測試，廣州總部的雙核心架構(gòu)實現(xiàn)了總公司出口站點互相備份，采用浮動靜態(tài)路由和HSRP技術(shù)分別實現(xiàn)了雙向冗余。同時啟用協(xié)作KS，實現(xiàn)了KS備份。

隨著近年來國產(chǎn)設(shè)備的崛起與發(fā)展，目前國內(nèi)網(wǎng)絡(luò)設(shè)備市場國產(chǎn)設(shè)備占有率穩(wěn)步增長，本文下一步的工作是研究國產(chǎn)設(shè)備網(wǎng)絡(luò)環(huán)境下大規(guī)模企業(yè)的DMVPN部署，以及不同廠商設(shè)備間VPN技術(shù)兼容性問題。