段小煥

（甘肅交通職業(yè)技術(shù)學(xué)院 甘肅省蘭州市 730070）

隨著移動(dòng)互聯(lián)網(wǎng)不斷的發(fā)展，無(wú)線網(wǎng)絡(luò)在園區(qū)網(wǎng)的建設(shè)中越來(lái)越被重視。伴隨著園區(qū)規(guī)模的不斷發(fā)展壯大,分公司和分支機(jī)構(gòu)遍布了不同城市和區(qū)域。為了實(shí)現(xiàn)統(tǒng)一管理，避免重復(fù)投資、節(jié)約成本、提高安全性，分公司和分支機(jī)構(gòu)的無(wú)線網(wǎng)絡(luò)接入點(diǎn)需要在總部統(tǒng)一規(guī)劃，統(tǒng)籌實(shí)現(xiàn)配置的遠(yuǎn)程下發(fā)和AP 的遠(yuǎn)程管理。因此在共享的Internet 上的通過(guò)VPN 技術(shù)實(shí)現(xiàn)私有網(wǎng)絡(luò)數(shù)據(jù)的傳輸是一種有效的途徑。對(duì)于企業(yè)內(nèi)部網(wǎng)絡(luò)跨區(qū)域通信，基于IPSec 構(gòu)建的VPN 網(wǎng)絡(luò)，可以保證數(shù)據(jù)傳輸?shù)陌踩?，但不支持組播，無(wú)法通過(guò)組播方式實(shí)現(xiàn)無(wú)線網(wǎng)絡(luò)統(tǒng)一注冊(cè)和管理。GRE 協(xié)議作為一種通用路由封裝協(xié)議，可以封裝任意一種協(xié)議，可以很好的支持組播業(yè)務(wù)。因此需要將IPSec 協(xié)議與GRE 協(xié)議結(jié)合起來(lái)，構(gòu)建基于GRE over IPSec VPN 隧道，實(shí)現(xiàn)對(duì)任意一種協(xié)議封裝，提供更好的安全性保障[1]，實(shí)現(xiàn)了跨區(qū)域無(wú)線網(wǎng)絡(luò)的統(tǒng)一注冊(cè)和管理。但由于GRE over IPSec VPN 對(duì)接口發(fā)出的IP 報(bào)文頭進(jìn)行了封裝，當(dāng)數(shù)據(jù)報(bào)文本身的長(zhǎng)度超過(guò)接口能夠轉(zhuǎn)發(fā)的最大傳輸單元（MTU）后，導(dǎo)致通信異常。 本文重點(diǎn)研究通過(guò)GRE over IPsec VPN 技術(shù)實(shí)現(xiàn)園區(qū)無(wú)線網(wǎng)絡(luò)的部署后，總部AC 統(tǒng)一管理和維護(hù)分部AP 的過(guò)程中存在的問(wèn)題，通過(guò)在ENSP 進(jìn)行仿真實(shí)驗(yàn)，抓包分析產(chǎn)生問(wèn)題的原因，經(jīng)過(guò)實(shí)驗(yàn)驗(yàn)證，提出通過(guò)優(yōu)化接口MTU 值，基于GRE over IPsec VPN 技術(shù)實(shí)現(xiàn)跨區(qū)域無(wú)線局域網(wǎng)的統(tǒng)一管理和維護(hù)。

1 跨區(qū)域無(wú)線網(wǎng)絡(luò)的安全管理的實(shí)現(xiàn)

1.1 跨區(qū)域無(wú)線網(wǎng)絡(luò)整體設(shè)計(jì)

隨著移動(dòng)互聯(lián)網(wǎng)應(yīng)用的飛速發(fā)展，為用戶提供高速、可靠、安全的無(wú)線網(wǎng)絡(luò)已經(jīng)成為公司為用戶提供的一項(xiàng)重要的服務(wù)。目前，對(duì)于大規(guī)模的公司，無(wú)線網(wǎng)絡(luò)的部署一般采用集中式網(wǎng)絡(luò)架構(gòu)，即通過(guò)AC 對(duì)無(wú)線局域網(wǎng)中的所有AP 進(jìn)行控制和管理[2-3]。由于總部與分部處于不同城市或地區(qū)，需要跨越公共的互聯(lián)網(wǎng)實(shí)現(xiàn)它們之間的通信，而在公共的互聯(lián)網(wǎng)上傳輸私網(wǎng)的數(shù)據(jù)，數(shù)據(jù)的機(jī)密性和完整性無(wú)法保證。因此，需要通過(guò)VPN 技術(shù)來(lái)解決。在VPN 技術(shù)的選擇時(shí)，GRE VPN 技術(shù)可以封裝任意一種協(xié)議，但安全性不高。IPsec VPN 技術(shù)可以實(shí)現(xiàn)對(duì)數(shù)據(jù)的加解密、完整性校驗(yàn)等，但支持的協(xié)議只有IP 協(xié)議，不支持組播[4]。為了即保證數(shù)據(jù)傳輸?shù)臋C(jī)密性、完整性，又能夠很好的支持組播報(bào)文在VPN 隧道內(nèi)正常的傳輸，因此通過(guò)GRE OVER IPsec 的VPN 技術(shù)既可以實(shí)現(xiàn)總部與分部之間無(wú)線網(wǎng)絡(luò)通信，又可以提高數(shù)據(jù)在公共的Internet 傳輸?shù)陌踩??？鐓^(qū)域無(wú)線網(wǎng)絡(luò)總體架構(gòu)如圖1 所示。

1.2 總部無(wú)線網(wǎng)絡(luò)的規(guī)劃與實(shí)現(xiàn)

圖1：跨區(qū)域無(wú)線網(wǎng)絡(luò)總體架構(gòu)

總部無(wú)線網(wǎng)絡(luò)設(shè)計(jì)采用三層組網(wǎng)的架構(gòu)，AC 旁掛在核心層，如圖1 所示。AC 與AP 之通過(guò)CAPWAP（Control And Provisioning of Wirеlеss Accеss Points Protocol Spеcification，無(wú)線接入點(diǎn)的控制和規(guī)范）進(jìn)行通信。CAPWAP 協(xié)議實(shí)現(xiàn)AP 在AC 上的注冊(cè)，建立控制信道，下發(fā)配置和遠(yuǎn)程管理[5]。為了保證圖1 中AP 與AC控制信道的建立，需要為總部和分部AP 統(tǒng)一分配管理地址，本實(shí)驗(yàn)中，將設(shè)計(jì)AC 作為DHCP 服務(wù)器為AP 分配管理IP 地址，核心交換機(jī)作為DHCP 服務(wù)器為AP 下接入用戶分配IP 地址。AP管理VLAN 規(guī)劃為VLAN100、VLAN200，AP 業(yè) 務(wù)VLAN規(guī) 劃 為VLAN10~VLAN90，AC源接口用VLAN100，地址為10.23.100.1/24。AC 上創(chuàng)建全局地址池為AP 分發(fā)管理地址，根據(jù)如圖1 的架構(gòu)，在仿真軟件ENSP 下搭建模擬環(huán)境，并對(duì)AC 做如下配置。

通過(guò)如上配置，AP 以廣播的方式發(fā)送DHCP 協(xié)議報(bào)文，在獲得管理地址的同時(shí)，獲得了AC 的IP 地址，通過(guò)交互CAPWAP 協(xié)議，建立控制隧道，實(shí)現(xiàn)區(qū)域內(nèi)部AC 對(duì)AP 的管理。

1.3 GRE over IPsec VPN的實(shí)現(xiàn)區(qū)域間安全通信

總部與分部之間的通信，通過(guò)GRE over IPsec VPN 實(shí)現(xiàn)。需要在總部和分步的路由器上做如下核心配置：

（1）在總部與分部的路由器上配置建立GRE 隧道

（2）配置私網(wǎng)的路由通過(guò)GRE 隧道轉(zhuǎn)發(fā)

圖2：AP 上線狀態(tài)過(guò)程

圖3：Wireshark 定位到的錯(cuò)誤報(bào)文

圖4：標(biāo)準(zhǔn)以太網(wǎng)幀格式

圖5：GRE over IPSec 封裝后的數(shù)據(jù)包格式

（3）配置IPSec，保護(hù)GRE 隧道兩端傳輸?shù)臄?shù)據(jù)

（4）將IPSec 安全策略應(yīng)用到接口

通過(guò)在總部與分部的路由器上配置建立GRE 隧道，指定目標(biāo)地址和源地址，總部和分部之間通過(guò)靜態(tài)路由，將下一條指向到Tunnel0/0/0 口。IPSec 配置需要保護(hù)GRE 隧道，匹配的數(shù)據(jù)流是公網(wǎng)源和目標(biāo)兩端的地址，配置待加密的數(shù)據(jù)流和安全提議，最后將策略應(yīng)用到兩端公網(wǎng)的出接口。通過(guò)GRE over IPsec VPN 既實(shí)現(xiàn)了總部與分部之間的通信，有了IPsec 的保障，對(duì)兩個(gè)節(jié)點(diǎn)之間傳輸?shù)臄?shù)據(jù)進(jìn)行加密和驗(yàn)證，保證了數(shù)據(jù)傳輸?shù)臋C(jī)密性和完整性，為跨區(qū)域無(wú)線網(wǎng)絡(luò)的統(tǒng)一管理提供有效的安全保障[7-10]。

2 實(shí)驗(yàn)結(jié)果分析

2.1 實(shí)驗(yàn)結(jié)果

根據(jù)參考文獻(xiàn)[7-10]完成以上的配置。通過(guò)在ENSP 下實(shí)驗(yàn)分析驗(yàn)證，當(dāng)無(wú)線控制器AC 控制并管理到無(wú)線AP 時(shí)，則AP 的狀態(tài)顯示為nomal 狀態(tài)，AP 正常上線。從實(shí)驗(yàn)結(jié)果來(lái)分析，總部所接入的AP，顯示均為nomal 狀態(tài)，AP 已經(jīng)正常上線。但分部AP在獲取IP 地址之后，長(zhǎng)時(shí)間停留在cfg 狀態(tài)，經(jīng)過(guò)一段時(shí)間進(jìn)入cfgca 狀態(tài)，最后處于fault 狀態(tài)，實(shí)驗(yàn)結(jié)果如圖2。

當(dāng)AP 的狀態(tài)處于cfgca 時(shí)，表示AC 正在為AP 下發(fā)配置和版本信息，而配置信息相對(duì)比較小，大小不到1K，版本信息比較大，一般超過(guò)了2M。

2.2 通過(guò)Wireshark抓包分析

由于通過(guò)ESP 對(duì)數(shù)據(jù)包封裝后，數(shù)據(jù)被加密無(wú)法定位出錯(cuò)的原因。因此，在本文中，借助仿真軟件ENSP，先不對(duì)數(shù)據(jù)進(jìn)行加密，獲取被GRE 協(xié)議封裝后的數(shù)據(jù)報(bào)文如圖3 所示。

從圖中可以看到，總部和分部之間VPN 隧道已經(jīng)建立起來(lái)，但報(bào)文中標(biāo)紅的字段存在異常，錯(cuò)誤提示為Bad length value 1480 > IP payload length，即通過(guò)UDP 協(xié)議封裝capwap 報(bào)文時(shí)，數(shù)據(jù)字段長(zhǎng)度大于IP 報(bào)文載荷長(zhǎng)度。根據(jù)Wireshark 獲取此段報(bào)文分析，從AC 發(fā)出的數(shù)據(jù)幀，經(jīng)過(guò)AC 源接口封裝后，到達(dá)到出口路由器，出口路由器再進(jìn)行GRE 封裝，封裝后的報(bào)文長(zhǎng)度超出了接口能夠轉(zhuǎn)發(fā)的最大傳輸單元MTU[11]。

2.3 最大傳輸單元（MTU）

MTU 為最大傳輸單元（Maxitum Transmission Unit）的簡(jiǎn)稱，一般是指以太網(wǎng)幀結(jié)構(gòu)中數(shù)據(jù)字段最大的長(zhǎng)度（單位為byte）。標(biāo)準(zhǔn)以太網(wǎng)數(shù)據(jù)幀由幀頭、數(shù)據(jù)部分及校驗(yàn)位構(gòu)成，大小占1518 字節(jié)，如圖4 所示，其中數(shù)據(jù)鏈路層數(shù)據(jù)幀頭占14 個(gè)字節(jié)（DMAC目的MAC 地址6bytes，SMAC 源MAC 地址6bytes，Type 字段占2bytes），尾部校驗(yàn)和FCS 占4 個(gè)字節(jié)，中間部分為承載上層協(xié)議（IP數(shù)據(jù)包）字段，即圖中的Data 字段，大小為46-1500bytes，Data字段的最大長(zhǎng)度稱之為MTU，即MTU 值最大為1500bytes[12]。當(dāng)接口承載的數(shù)據(jù)報(bào)文大小超過(guò)了MTU 的最大值后，數(shù)據(jù)幀會(huì)被直接丟棄，導(dǎo)致通信異常。

本文中AC 為AP 下發(fā)版本信息時(shí)，數(shù)據(jù)報(bào)文比較大，超過(guò)了2M，需要進(jìn)行分片，默認(rèn)分片的大小為1480bytes，這就導(dǎo)致通過(guò)GRE 協(xié)議封裝包含CAPWAP 報(bào)文的UDP 數(shù)據(jù)包后，報(bào)文總體長(zhǎng)度超出了接口能夠轉(zhuǎn)發(fā)的MTU，從而報(bào)告Bad length value 的提示。

圖6：AP 正常上線狀態(tài)

2.4 計(jì)算分析，優(yōu)化MTU值

通過(guò)GRE over IPSec VPN 技術(shù)實(shí)現(xiàn)總部與分部之間無(wú)線網(wǎng)絡(luò)的統(tǒng)一管理，從GRE over IPSec 數(shù)據(jù)報(bào)格式來(lái)分析，數(shù)據(jù)字段首先經(jīng)過(guò)原始IP 頭進(jìn)行封裝，從AC 的源接口轉(zhuǎn)發(fā)到總部路由器，總部路由器通過(guò)查找路由，發(fā)現(xiàn)匹配了192.168.20.0 255.255.255.0 Tunnel0/0/0 這條路由，路由的下一條交給了Tunnel0/0/0。因此數(shù)據(jù)報(bào)文要經(jīng)過(guò)GRE 報(bào)文進(jìn)行封裝，添加了4 個(gè)字節(jié)的GRE 報(bào)文頭，同時(shí)添加20 個(gè)字節(jié)的IP 報(bào)文頭[13]。經(jīng)過(guò)GRE 封裝的IP 報(bào)文目標(biāo)地址是GRE 隧道制定的目標(biāo)地址，該目標(biāo)地址與IPSec 中應(yīng)用的ACL 匹配，ESP 要對(duì)其進(jìn)行封裝，添加上了10 個(gè)字節(jié)的ESP 報(bào)文頭，再一次被路由器的出接口封裝，添加上了20個(gè)字節(jié)的IP報(bào)文頭，在公共的Internet 上傳輸，到達(dá)分布，進(jìn)行解封裝[14]。具體封裝的格式及每個(gè)字段大小如圖5 所示。

從圖5 中可以計(jì)算出，從AC 源接口發(fā)出的數(shù)據(jù)包，接口能夠承載的最大MTU 值計(jì)算公式方法為：MTU=1500-（3×IP 頭+ESP頭+GRE 頭），即經(jīng)過(guò)GRE 和ESP 封裝，接口承載的最大MTU值為1426。

2.5 調(diào)整MTU值，驗(yàn)證AP的上線情況

通過(guò)上文的分析，以太網(wǎng)接口的MTU 值必須小于等于1426bytes，GRE over IPSec VPN 技術(shù)才能有效保障跨區(qū)域無(wú)線網(wǎng)絡(luò)的AC 對(duì)AP 的統(tǒng)一管理。通過(guò)實(shí)驗(yàn)再次驗(yàn)證，設(shè)置接口的MTU 值，由于從AC 源接口發(fā)出的IP 報(bào)文到達(dá)出口路由器后，還要進(jìn)行兩次封裝，根據(jù)計(jì)算的結(jié)果，將AC 源接口MTU 值設(shè)置為1426bytes。具體配置如下：

通過(guò)如上配置，在通過(guò)命令行查看AP 的運(yùn)行狀態(tài)。顯示如圖6，分部AP 狀態(tài)顯示為nor，表示AP 正常上線，統(tǒng)一通信和管理得以實(shí)現(xiàn)。

3 結(jié)語(yǔ)

隨著園區(qū)規(guī)模的不斷擴(kuò)大，分布在不同區(qū)域園區(qū)用戶之間的互聯(lián)互通需求不斷增多，通過(guò)GRE over IPSec VPN 技術(shù)可以很好的解決用戶的需求。在園區(qū)之間通過(guò)公共的Internet 傳輸私網(wǎng)數(shù)據(jù)時(shí)，如果數(shù)據(jù)報(bào)文比較大，接口發(fā)出的數(shù)據(jù)報(bào)文超過(guò)了規(guī)定的值，將導(dǎo)致通信異常。本文根據(jù)無(wú)線網(wǎng)絡(luò)在跨區(qū)域環(huán)境中的應(yīng)用情況，通過(guò)仿真實(shí)驗(yàn)，對(duì)基于GRE over IPSEC VPN 技術(shù)實(shí)現(xiàn)跨區(qū)域無(wú)線網(wǎng)絡(luò)通信中遇到的問(wèn)題進(jìn)行了分析，通過(guò)抓取數(shù)據(jù)報(bào)文，定位產(chǎn)生問(wèn)題的原因。通過(guò)對(duì)標(biāo)準(zhǔn)以太網(wǎng)報(bào)文和經(jīng)過(guò)GRE over IPSec 封裝后的IP 報(bào)文進(jìn)行分析，計(jì)算得出GRE over IPsec VPN 對(duì)報(bào)文封裝后接口MTU 的取值范圍，最后在仿真軟件中，優(yōu)化MTU 值實(shí)現(xiàn)了跨區(qū)域無(wú)線網(wǎng)絡(luò)的統(tǒng)一管理與維護(hù)。

本文通過(guò)分析MTU 值對(duì)GRE over IPsec VPN 數(shù)據(jù)傳輸?shù)挠绊?，探索研究了MTU 值在GRE over IPSec VPN 中的計(jì)算過(guò)程，提出的MTU 值設(shè)置大小，即可以適用跨區(qū)域無(wú)線網(wǎng)絡(luò)的環(huán)境，也適用于跨區(qū)域的視頻會(huì)議、視頻監(jiān)控領(lǐng)域，具有實(shí)際的應(yīng)用價(jià)值。