IPSec VPN應(yīng)用場(chǎng)景分析與實(shí)驗(yàn)仿真

李超凡，馬凱

（1.宿遷市第一人民醫(yī)院 信息處，江蘇 宿遷 223800；2.徐州醫(yī)科大學(xué) 醫(yī)學(xué)信息與工程學(xué)院，江蘇 徐州 221004）

虛擬專用網(wǎng)絡(luò)（Virtual Private Network，VPN）是指在運(yùn)營(yíng)商的公網(wǎng)資源上建立加密通訊的專用網(wǎng)絡(luò)［1］。從專線連接發(fā)展至穿越公共網(wǎng)絡(luò)，數(shù)據(jù)安全和帶寬保障仍是主要的考慮因素。企業(yè)級(jí)的VPN解決方案主要分為：端對(duì)端（Site-to-Site）和遠(yuǎn)程接入（Easy VPN）［2］，其中端對(duì)端VPN 主要依托的技術(shù)包括幀中繼協(xié)議（Frame Relay）、多協(xié)議標(biāo)簽交換虛擬專網(wǎng)技術(shù)（Multi-Protocol Label Switching，MPLS）、互聯(lián)網(wǎng)安全協(xié)議（Internet Protocol Security，IPSec）；遠(yuǎn)程接入VPN 主要依托的技術(shù)包括點(diǎn)對(duì)點(diǎn)隧道協(xié)議（Point to Point Tunneling Protocol，PPTP）、第二層隧道協(xié)議（Layer 2 Tunneling Protocol，L2TP）、IPSec 協(xié)議族和安全套接字協(xié)議（Secure Sockets Layer，SSL）。

目前，基于運(yùn)營(yíng)商運(yùn)維的跨域MPLS VPN和基于Web網(wǎng)頁(yè)認(rèn)證的SSL VPN是進(jìn)行VPN接入的主要方式，但是對(duì)于企業(yè)級(jí)的網(wǎng)絡(luò)運(yùn)維方案，IPSec VPN 仍是解決站點(diǎn)到站點(diǎn)之間大規(guī)模流量通信的主要技術(shù)手段。因此，文章基于EVE-NG 虛擬仿真環(huán)境，探討企業(yè)網(wǎng)Site-to-Site 架構(gòu)建立VPN 通道的動(dòng)態(tài)IP 地址、流量放行、地址轉(zhuǎn)換和隧道技術(shù)的應(yīng)用等多種網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)。

1 相關(guān)技術(shù)

1.1 虛擬仿真環(huán)境

EVE-NG（Emulated Virtual Environment—Next Generation）是深度定制的Ubuntu 操作系統(tǒng)，融合了Dynamips，基于Linux的互聯(lián)網(wǎng)操作系統(tǒng)（IOS on Linux，IOL），基于內(nèi)核的虛擬機(jī)（Kernel-based Virtual Machine，KVM）［3］，可以直接安裝在帶有CentOS7操作系統(tǒng)的服務(wù)器中，通過(guò)用戶管理或者創(chuàng)建虛擬化接口的形式，實(shí)現(xiàn)B/S 結(jié)構(gòu)的虛擬網(wǎng)絡(luò)教學(xué)平臺(tái)的仿真環(huán)境［4］。用戶端使用http/https 訪問(wèn)EVE-NG 服務(wù)端地址，通過(guò)導(dǎo)入不同設(shè)備廠商的鏡像文件，搭建各種類型的網(wǎng)絡(luò)邏輯拓?fù)溥M(jìn)行虛擬仿真實(shí)驗(yàn)。

1.2 IPSec框架

IPSec是一種開放標(biāo)準(zhǔn)的框架結(jié)構(gòu)［5］，由一組關(guān)聯(lián)協(xié)議組成，為IP協(xié)議的分組提供加密和認(rèn)證服務(wù)，從數(shù)據(jù)包傳遞的角度分為數(shù)據(jù)層面和控制層面。

1.2.1 數(shù)據(jù)層面

加密算法：對(duì)稱加密算法應(yīng)用同一個(gè)密鑰進(jìn)行數(shù)據(jù)包加解密，明文傳輸共享密鑰，密鑰數(shù)量指數(shù)增長(zhǎng)［6］。非對(duì)稱加密算法運(yùn)行速度慢，密文較長(zhǎng)。因此，IPSec VPN采用非對(duì)稱密鑰進(jìn)行密鑰交換和數(shù)字簽名，采用對(duì)稱密鑰進(jìn)行數(shù)據(jù)包加密，實(shí)現(xiàn)安全，速度快，加密后的密文緊湊，無(wú)連接服務(wù)，支持?jǐn)?shù)字簽名和不可否認(rèn)性。

驗(yàn)證：應(yīng)用散列函數(shù)進(jìn)行完整性校驗(yàn)，常用散列函數(shù)包括MD5（Message Digest Algorithm MD5）和SHA-1（Secure Hash Algorithm 1），散列函數(shù)對(duì)數(shù)據(jù)包產(chǎn)生固定大小散列值，單向且避免沖突［7］。

封裝協(xié)議：認(rèn)證頭（Authentication Header，AH）提供無(wú)連接完整性與防重放服務(wù)。封裝安全載荷（Encapsulate Security Payload，ESP）除了具備AH的功能外，還提供數(shù)據(jù)源認(rèn)證、數(shù)據(jù)加密和有限的傳輸流機(jī)密性。

傳輸模式：隧道模式（Tunnel Mode）用于通訊站點(diǎn)和加密站點(diǎn)不是同一臺(tái)設(shè)備，需要保護(hù)的是多臺(tái)站點(diǎn)的其中兩個(gè)站點(diǎn)。傳輸模式（Transport Mode）用于通訊站點(diǎn)和加密站點(diǎn)是同一臺(tái)設(shè)備，需要保護(hù)兩個(gè)獨(dú)立站點(diǎn)之間的通信［8］。

1.2.2 控制層面

網(wǎng)絡(luò)密鑰交換協(xié)議（Internet Key Exchange，IKE）是由安全關(guān)聯(lián)和秘鑰管理協(xié)議（ISAKMP）、密鑰交換模式（OAKLEY）與共享和秘鑰更新技術(shù)（SKEME）組成的混合協(xié)議［9］。安全關(guān)聯(lián)（Security Association，SA）是對(duì)等體兩端協(xié)商的信息保護(hù)策略和密鑰，IKE 負(fù)責(zé)建立與維護(hù)IKE SAs 和IPSec SAs，對(duì)雙方進(jìn)行認(rèn)證、交換非對(duì)稱加密公鑰、管理密鑰資源與協(xié)商數(shù)據(jù)層面的策略參數(shù)。

2 端到端IPSec VPN實(shí)驗(yàn)設(shè)計(jì)與仿真

為探討端對(duì)端IPSec VPN 建立過(guò)程中數(shù)據(jù)層面的流量轉(zhuǎn)發(fā)與控制層面的策略協(xié)商，仿真實(shí)驗(yàn)的邏輯網(wǎng)絡(luò)拓?fù)浼跋鄳?yīng)地址規(guī)劃如圖1所示。

圖1 IPSec VPN邏輯網(wǎng)絡(luò)拓?fù)?/p>

在IKE 的協(xié)商過(guò)程中，存在主模式和快速模式的兩種信息交互階段，如圖2 所示，（1）—（4）是明文傳遞的數(shù)據(jù)包，（5）—（9）是密文傳遞的數(shù)據(jù)包。IKE協(xié)商兩套信息加密策略，其中主模式階段通過(guò)驗(yàn)證對(duì)等體身份并確定會(huì)話密鑰，快速模式在ISAKMP SA 的保護(hù)下，密文協(xié)商用于真正保護(hù)感興趣數(shù)據(jù)流的IPSec SA。各數(shù)據(jù)包進(jìn)行交互的作用如下：

圖2 IKE協(xié)商過(guò)程

（1）—（2）：用于準(zhǔn)確的依據(jù)對(duì)等體IP地址進(jìn)行策略提議與回應(yīng)；

（3）—（4）：交換非對(duì)稱密鑰的公鑰和隨機(jī)數(shù)，生成非對(duì)稱密鑰和對(duì)稱密鑰［10］；

（5）—（6）：利用公鑰體制對(duì)預(yù)共享密鑰進(jìn)行加密，驗(yàn)證對(duì)等體身份；

（7）—（8）：對(duì)實(shí)際的感興趣數(shù)據(jù)流的加密策略的加密協(xié)商；

（9）：信息確認(rèn)并生成安全參數(shù)索引（Security Parameter Index，SPI）。

2.1 端到端IPSec VPN

依據(jù)圖1 的拓?fù)浣Y(jié)構(gòu)，在EVE-NG 中搭建虛擬仿真實(shí)驗(yàn)，使用SecureCRT 客戶端軟件Telnet 設(shè)備節(jié)點(diǎn)的服務(wù)IP地址和端口進(jìn)行網(wǎng)絡(luò)配置。VPN Site經(jīng)創(chuàng)建ISAKMP Policy、設(shè)置預(yù)共享密鑰、轉(zhuǎn)換集策略、抓取感興趣流，在安全策略（Crypto Map）下匹配，最后在物理接口下調(diào)用，完成端到端的IPSec VPN 配置步驟。通過(guò)Wireshark網(wǎng)絡(luò)封包分析軟件抓取VPN Site接口的IKE的協(xié)商過(guò)程如圖3所示。由圖可知，No.11—19的數(shù)據(jù)包為IKE協(xié)商數(shù)據(jù)包，使用UDP協(xié)議封裝，端口號(hào)500；No.21—22的數(shù)據(jù)包是IPSec VPN建立后的通信流量。打開No.11—14的數(shù)據(jù)包的ISAKMP封裝，Payload承載數(shù)據(jù)包信息，No.15—19的數(shù)據(jù)包的ISAKMP封裝中只存在加密數(shù)據(jù)的字節(jié)數(shù)。在No.22的加密數(shù)據(jù)包中，只存在由ESP封裝的SPI和Sequence，SPI是目標(biāo)對(duì)等體在IKE 協(xié)商期間隨機(jī)選擇的數(shù)字，類似于索引，用于在安全關(guān)聯(lián)數(shù)據(jù)庫(kù)（SADB）中查找對(duì)應(yīng)的IPSec SA，Sequence是發(fā)送方插入ESP包頭的序列號(hào)，提供抗重放服務(wù)。

圖3 Wireshark抓取的IKE協(xié)商報(bào)文

IPSec VPN 的真實(shí)流量轉(zhuǎn)發(fā)如圖4 所示，其中ID 序號(hào)為1 是ISAKMP SA 的加密通道，用于以密文傳遞預(yù)共享密鑰驗(yàn)證對(duì)等體身份，ID 序號(hào)為2001、2002 是IPSec SA 為感興趣流創(chuàng)建的加密通道，用于真實(shí)流量轉(zhuǎn)發(fā)，且在站點(diǎn)VPN Site1上，數(shù)據(jù)包的加解密個(gè)數(shù)一致，沒有丟包現(xiàn)象。

圖4 IP加密數(shù)據(jù)包轉(zhuǎn)發(fā)情況

2.2 ISAKMP/IPSec Profile

在IPSec VPN 的建立過(guò)程中，多個(gè)站點(diǎn)在IKE 協(xié)商時(shí)，會(huì)出現(xiàn)自由組合匹配，導(dǎo)致網(wǎng)絡(luò)混亂和誤差的情況。ISAKMP可以創(chuàng)建多個(gè)Keyring并設(shè)置預(yù)共享密鑰與多個(gè)ISAKMP Profile進(jìn)行相應(yīng)關(guān)聯(lián)，并在Crypto Map中調(diào)用，從而映射ISAKMP參數(shù)到IPSec隧道，關(guān)聯(lián)第一階段與第二階段的協(xié)商策略，普遍應(yīng)用于一個(gè)站點(diǎn)和不同站點(diǎn)配置多個(gè)IPSec隧道，并且每個(gè)站點(diǎn)需要不同第一階段策略的場(chǎng)合。

對(duì)于存在虛擬隧道接口的IPSec VPN架構(gòu)，與傳統(tǒng)端對(duì)端方式區(qū)別的是：IPSec Profile不再需要訪問(wèn)控制列表（Access-list）抓取感興趣流和Crypto Map，因?yàn)門unnel已經(jīng)指明了隧道的源和目的地址，并且通過(guò)Tunnel傳遞的數(shù)據(jù)都需要進(jìn)行加密。通過(guò)ISAKMP/IPSec Profile的匹配使用，可以有效地解決多站點(diǎn)間進(jìn)行IKE協(xié)商的問(wèn)題，增強(qiáng)IPSec VPN搭建的邏輯性。

2.3 動(dòng)態(tài)地址的VPN解決方案

依據(jù)圖1網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，清除VPN Site2的出接口地址，并設(shè)置動(dòng)態(tài)主機(jī)配置協(xié)議（Dynamic Host Configuration Protocol，DHCP）請(qǐng)求，在ISP Cloud開啟DHCP地址池，形成一端沒有固定IP地址的網(wǎng)絡(luò)場(chǎng)景。在此種場(chǎng)景下，Dynamic Map&Static Map是唯一的兼容方案，在VPN Site2的設(shè)置中，與普通的端對(duì)端配置沒有任何區(qū)別。而在VPN Site1 中，可以用全零代替預(yù)共享密鑰指定的對(duì)等體IP 地址，將轉(zhuǎn)換集指定在Dynamic Map中，并套接在Static Map 中。此類IPSec VPN 架構(gòu)由于固定IP 地址的站點(diǎn)無(wú)法獲得對(duì)等體IP 地址，所以無(wú)法主動(dòng)發(fā)起VPN 流量，必須由對(duì)等體獲取DHCP 地址池中的IP 地址，然后主動(dòng)觸發(fā)VPN 的感興趣流進(jìn)行正常通信。

對(duì)于兩端都沒有固定IP地址的場(chǎng)景，可以利用動(dòng)態(tài)域名解析技術(shù)（Dynamic Domain Name Server，DDNS）建立數(shù)據(jù)通道，同時(shí)也可以解決上述固定IP地址的站點(diǎn)無(wú)法主動(dòng)發(fā)起VPN流量的缺點(diǎn)。

3 網(wǎng)絡(luò)穿越實(shí)驗(yàn)設(shè)計(jì)與仿真

在邏輯網(wǎng)絡(luò)拓?fù)渲?，VPN Site除了建立加密信息通道外，對(duì)于真實(shí)工程環(huán)境必須啟動(dòng)網(wǎng)絡(luò)地址轉(zhuǎn)換協(xié)議（Network Address Translation，NAT）使得私網(wǎng)地址可以轉(zhuǎn)換為公網(wǎng)地址在運(yùn)營(yíng)商網(wǎng)絡(luò)進(jìn)行數(shù)據(jù)包傳遞。在此種場(chǎng)景下，邏輯網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)仍以圖1 為例，探討IPSec VPN 穿越NAT、端口多路復(fù)用（Port Address Translation，PAT）及使用隧道技術(shù)建立動(dòng)態(tài)路由協(xié)議的情況。

3.1 流量放行問(wèn)題

當(dāng)VPN Site 啟用NAT 協(xié)議后，內(nèi)部私有地址經(jīng)NAT 映射為VPN Site 的出接口地址進(jìn)行數(shù)據(jù)包傳遞，出現(xiàn)原有IPSec加密通道的目的地不可達(dá)現(xiàn)象。在端部存在NAT的情況下，IP數(shù)據(jù)包的轉(zhuǎn)發(fā)遵循：傳遞方向先進(jìn)行NAT 地址映射，再進(jìn)行IP 數(shù)據(jù)包的加密；接收方向先解密IP 數(shù)據(jù)包，再進(jìn)行地址轉(zhuǎn)換。因此，在VPN Site進(jìn)行通信時(shí)，私有地址經(jīng)NAT地址轉(zhuǎn)換不屬于安全策略保護(hù)的感興趣流，造成了數(shù)據(jù)包不可達(dá)。在此類場(chǎng)景下，禁止Access-list 應(yīng)用在NAT 中的感興趣流，不允許感興趣流的私有地址在通信時(shí)進(jìn)行地址轉(zhuǎn)換，解決IPSec通道存在NAT引起的問(wèn)題。

3.2 Crypto Map對(duì)流量的處理

依據(jù)上述IPSec 通道中存在NAT 情況下的IP 數(shù)據(jù)包轉(zhuǎn)發(fā)機(jī)制，依據(jù)圖1 邏輯拓?fù)?，VPN Site 均存在內(nèi)網(wǎng)服務(wù)器，設(shè)定VPN Site1內(nèi)部服務(wù)器開啟Telnet服務(wù)，VPN Site2內(nèi)部服務(wù)器開啟HTTP 服務(wù)，并限制服務(wù)器兩端的訪問(wèn)，以此探討在NAT存在的情況下，Crypto Map對(duì)訪問(wèn)流量的處理。

在此種場(chǎng)景下，數(shù)據(jù)加密站點(diǎn)與數(shù)據(jù)通信站點(diǎn)不是同一臺(tái)設(shè)備，需要考慮的主要因素包含兩點(diǎn)：IKE 協(xié)商的控制和IPSec通道的流量限制。IPSec通道的策略設(shè)置如圖5所示，以VPN Site1為例，IKE協(xié)商的控制需要在數(shù)據(jù)加密點(diǎn)，即VPN Site1 外連接口的入方向，放行對(duì)等體UDP：500 的IPSec 控制報(bào)文和ESP 的IPSec 數(shù)據(jù)報(bào)文；IPSec 通道的流量限制需要在Crypto Map 的入方向，放行對(duì)端通信站點(diǎn)的Telnet 服務(wù)請(qǐng)求報(bào)文和HTTP 服務(wù)回復(fù)報(bào)文，在出方向放行對(duì)端通信站點(diǎn)的Telnet 服務(wù)回復(fù)報(bào)文和HTTP 服務(wù)請(qǐng)求報(bào)文。由圖5 可知，擴(kuò)展訪問(wèn)控制列表均得到有效的匹配，VPN Site內(nèi)部服務(wù)器可以獲取相應(yīng)的Telnet服務(wù)和HTTP服務(wù)。

圖5 IPSec通道的訪問(wèn)控制策略

3.3 NAT-T技術(shù)應(yīng)用

在3.1章節(jié)流量放行問(wèn)題中，已經(jīng)探討了對(duì)等體兩端都啟用NAT的情況，而在實(shí)際環(huán)境中也經(jīng)常會(huì)出現(xiàn)PAT 應(yīng)用的出口站點(diǎn)與VPN Site 不是同一站點(diǎn)的情況，所以在圖1 的邏輯拓?fù)渲?，在ISP Cloud 與VPN Site2之間引入一臺(tái)新的出口設(shè)備，VPN Site2作為私有網(wǎng)段的站點(diǎn)，IP 地址沿用192.168.1.0/24網(wǎng)段。在此類場(chǎng)景下，攜帶公網(wǎng)IP地址的VPN Site1需要與只有私有IP地址的VPN Site2建立IPSec VPN通道，VPN Site2的配置方式與3.1 章節(jié)所述一致，而VPN Site1 則需要指定對(duì)等體IP 地址為PAT 設(shè)備的出口地址。由此，VPN Site2可以遵循先進(jìn)行PAT 地址轉(zhuǎn)換，再進(jìn)行IP 數(shù)據(jù)包加密，與VPN Site1 進(jìn)行IKE 協(xié)商，這與VPN Site1 指定PAT設(shè)備為對(duì)等體是一致的，然后VPN Site1可以依據(jù)狀態(tài)化的SPI查詢本地SADB與VPN Site2進(jìn)行通信。

在上述情況下，VPN Site1 無(wú)法主動(dòng)對(duì)VPN Site2 發(fā)起VPN 流量，因?yàn)閂PN Site1 指定的PAT 設(shè)備上沒有公網(wǎng)地址與私有地址的轉(zhuǎn)換表項(xiàng)，IKE 協(xié)商出現(xiàn)誤差。NAT-T 技術(shù)（NAT-Traversal）通過(guò)在IP 包頭和ESP 包頭之間插入一個(gè)8字節(jié)的UDP頭部（端口號(hào)：4500），從本質(zhì)上解決ESP協(xié)議無(wú)法提供轉(zhuǎn)換端口的缺陷［11］。由此，可以在PAT設(shè)備上進(jìn)行IP地址與端口的靜態(tài)映射，同時(shí)映射UDP協(xié)議的500和4500端口，以滿足圖2中IKE的協(xié)商過(guò)程（圖6）。

圖6 靜態(tài)映射地址轉(zhuǎn)換

在圖2 的IKE 協(xié)商過(guò)程中，IPSec 網(wǎng)關(guān)在數(shù)據(jù)包（1）—（2）中交互Vendor ID 表示是否支持NAT-T，數(shù)據(jù)包（3）—（4）通過(guò)NAT-Discovery 負(fù)載計(jì)算源地址和端口號(hào)與目的地址和端口號(hào)的Hash 值，若Hash 值不相等，則IPSec通道存在NAT，然后IPSec網(wǎng)關(guān)在（5）—（9）數(shù)據(jù)包增加UDP包頭（圖7），完成IKE進(jìn)行NAT穿越的協(xié)商過(guò)程，并在之后始終封裝UDP：4500的包頭進(jìn)行加密通信。

圖7 NAT-T技術(shù)的IKE協(xié)商過(guò)程

3.4 GRE/VTI隧道技術(shù)應(yīng)用

在上述端對(duì)端IPSec VPN及網(wǎng)絡(luò)穿越仿真實(shí)驗(yàn)中，對(duì)于大型企業(yè)網(wǎng)的實(shí)際網(wǎng)絡(luò)部署，存在不支持直接加密組播、不支持動(dòng)態(tài)路由協(xié)議、不提供服務(wù)質(zhì)量（Quality of Service，QoS）等嚴(yán)重弊端。隧道技術(shù)的引入可以有效地解決這一問(wèn)題，通用路由封裝協(xié)議（General Routing Encapsulation，GRE）［12］和VTI 技術(shù)（Virtual Tunnel Interface）是常用與IPSec 框架組合的隧道類型。GRE 隧道通過(guò)在原始IP 數(shù)據(jù)包增加4 字節(jié)的GRE 頭部，創(chuàng)建虛擬隧道接口與對(duì)端建立動(dòng)態(tài)路由協(xié)議的鄰居關(guān)系，傳遞私有網(wǎng)段的路由信息，IPSec 進(jìn)行數(shù)據(jù)加密。VTI 是IPSec 內(nèi)嵌的隧道技術(shù)，可分為靜態(tài)的VTI（SVTI）和動(dòng)態(tài)的VTI（DVTI），SVTI 主要用于端對(duì)端VPN 類型，DVTI主要用于遠(yuǎn)程接入VPN類型。

為探討隧道技術(shù)在IPSec VPN 建立的應(yīng)用情況，沿用3.3 章節(jié)的邏輯拓?fù)浣Y(jié)構(gòu)，SVTI 接口相對(duì)于傳統(tǒng)的Crypto Map的優(yōu)勢(shì)在于可以在隧道口上運(yùn)用動(dòng)態(tài)路由協(xié)議，并且不需要額外的4個(gè)字節(jié)的GRE頭部，降低了發(fā)送數(shù)據(jù)的帶寬，所以仿真實(shí)驗(yàn)采用SVTI接口建立對(duì)等體的動(dòng)態(tài)路由鄰居關(guān)系和IPSec 加密通道。在VPN Site 啟用開放式最短路徑優(yōu)先路由協(xié)議（Open Shortest Path First，OSPF），依據(jù)各自端部的內(nèi)網(wǎng)劃分路由區(qū)域，設(shè)置SVTI 的隧道地址為同一網(wǎng)段并宣告進(jìn)OSPF 域內(nèi)。應(yīng)用SVTI 隧道建立的IPSec 加密通道的數(shù)據(jù)包轉(zhuǎn)發(fā)情況如圖8所示，加解密數(shù)據(jù)包的個(gè)數(shù)隨著OSPF進(jìn)行路由信息更新而不斷增長(zhǎng)。

圖8 應(yīng)用SVTI隧道的IP加密數(shù)據(jù)包轉(zhuǎn)發(fā)

與GRE 隧道不同的是，SVTI 隧道只有在調(diào)用IPSec 加密策略才會(huì)啟用并建立動(dòng)態(tài)路由鄰居關(guān)系，而GRE隧道可以隨時(shí)建立。相較于3.3章節(jié)中，因?yàn)镻AT中沒有轉(zhuǎn)換表項(xiàng)需要進(jìn)行靜態(tài)映射的情況，動(dòng)態(tài)路由協(xié)議有效地解決了這個(gè)問(wèn)題。綜上所述，應(yīng)用隧道技術(shù)建立IPSec VPN 在解決大型企業(yè)網(wǎng)進(jìn)行加密通信的業(yè)務(wù)需求下具有很大的實(shí)用價(jià)值。

4 結(jié)論

EVE-NG 通過(guò)導(dǎo)入網(wǎng)絡(luò)設(shè)備廠商的鏡像文件，并架構(gòu)在服務(wù)器中實(shí)現(xiàn)B/S模式的虛擬仿真環(huán)境，因其不占用客戶端資源和支持多用戶組的強(qiáng)大功能，適用于虛擬網(wǎng)絡(luò)實(shí)踐教學(xué)平臺(tái)。文章依托于EVE-NG仿真環(huán)境，著重探討了端對(duì)端IPSec VPN、IPSec通道搭建的高級(jí)特性、動(dòng)態(tài)地址的VPN解決方案、IPSec網(wǎng)絡(luò)穿越與隧道技術(shù)等多個(gè)應(yīng)用場(chǎng)景，設(shè)定多類型VPN 通道建立的業(yè)務(wù)需求，并提供相應(yīng)的解決方案。通過(guò)Wireshark 和SecureCRT等客戶端軟件，分析各類型VPN通道的建立過(guò)程和應(yīng)用效果。仿真實(shí)驗(yàn)方案依據(jù)實(shí)際情況可直接移植到真實(shí)的網(wǎng)絡(luò)環(huán)境，也為虛擬仿真平臺(tái)提供了相應(yīng)的實(shí)踐案例，是計(jì)算機(jī)網(wǎng)絡(luò)仿真實(shí)驗(yàn)的良好應(yīng)用。