譽天Security技術——加密技術應用

思維導圖

01

加密學的應用

在資訊安全領域，主要使用數字信封、數字簽名和數字證書等密碼技術。

：結合對稱和非對稱加密，進而保證資料傳輸的機密性。

：采用雜湊演算法，進而保證資料傳輸的完整性。

：通過第三方機構（CA）對公鑰進行公證，進而保證資料傳輸的不可否認性。

結合到實際的網絡應用場景，數字信封、數字簽名和數字證書可以用于以下場景：、、、

在各種應用場景中，其中最主要的應用場景就是在VPN上的應用。本課程主要介紹幾種加密VPN及一些其他常用的VPN技術。

02

VPN産生背景

在VPN（Virtual Private Network）出現之前，跨越Internet的資料傳輸隻能依靠現有實體網絡，具有很多的不安全因素。

如下圖所示，某企業的總部和分支機構位于不同區域（如位于不同的國家或城市），當分支機構員工需通路總部伺服器的時候，資料傳輸要經過Internet。由于Internet中存在多種不安全因素，則當分支機構的員工向總部伺服器發送通路請求時，封包容易被網絡中的黑客竊取或篡改，最終造成資料洩密、重要資料被破壞等後果。

03

VPN定義與封裝原理

VPN即虛拟專用網，用于在公用網絡上建構私人專用虛拟網絡，并在此虛拟網絡中傳輸私網流量。VPN把現有的實體網絡分解成邏輯上隔離的網絡，在不改變網絡現狀的情況下實作安全、可靠的連接配接。

VPN的基本原理是利用隧道（Tunnel）技術，對傳輸封包進行封裝，利用VPN骨幹網建立專用資料傳輸通道，實作封包的安全傳輸。

VPN具有以下兩個基本特征：專用（Private）、虛拟（Virtual）

VPN對資料進行封裝和加密，即使網絡黑客竊取到資料也無法破解，確定了資料的安全性，且搭建VPN不需改變現有網絡拓撲，沒有額外費用。

VPN和傳統的資料專網相比具有如下優勢：、、、、。

04

VPN分類

VPN現在廣泛應用于企業網絡分支機構和出差員工連接配接總部網絡的場景，以下是VPN常見的幾種分類方式。

根據應用場景不同分類：

• ：即用戶端與企業内網之間通過VPN隧道建立連接配接，用戶端可以是一台防火牆、路由器，也可以是個人計算機。此場景可以使用以下幾種VPN技術實作：SSL、IPSec、L2TP和L2TP over IPSec；又稱為Remote Access VPN

• ：即兩個區域網路之間通過VPN隧道建立連接配接，部署的裝置通常為路由器或者防火牆。此場景可以使用以下幾種VPN技術實作：IPSec、L2TP、L2TP over IPSec、GRE over IPSec和IPSec over GRE。

根據應用對象不同分類：

• Extranet VPN： 利用VPN将企業網延伸至合作夥伴處，使不同企業間通過Internet來構築VPN；
• Intranet VPN：通過公用網絡進行企業内部各個網絡的互連；
• Access VPN：面向出差員工，允許出差員工跨越公用網絡遠端接入公司内部網絡。

根據VPN技術實作的網絡層次分類：應用層SSL VPN、網絡層GRE IPSec L3VPN、資料鍊路層PPTP L2F L2TP L2VPN

05

VPN的關鍵技術

隧道技術：

VPN的基本原理是利用隧道（Tunnel）技術，對傳輸封包進行封裝，利用VPN骨幹網建立專用資料傳輸通道，實作封包的安全傳輸。

隧道技術使用一種協定封裝另外一種協定封包（通常是IP封包），而封裝後的封包也可以再次被其他封裝協定所封裝。對使用者來說，隧道是其所在網絡的邏輯延伸，在使用效果上與實際實體鍊路相同。

隧道技術是VPN的基本技術，類似于點對點連接配接技術。如圖所示，分支VPN網關收到原始封包後，将封包封裝，然後通過Internet傳輸到總部VPN網關。總部VPN網關再對封包進行解封裝，最後得到原始封包。

“封裝/解封裝”過程本身就可以為原始封包提供安全防護功能，所有被封裝的封包在Internet上傳輸時所經過的邏輯路徑被稱為“隧道”。

身份認證技術：

身份認證技術，其主要用于移動辦公使用者遠端接入的情況。總部的VPN網關對使用者的身份進行認證，確定接入内部網絡的使用者是合法使用者，而非惡意使用者。不同的VPN技術能提供的使用者身份認證方法不同：

• GRE：不支援針對使用者的身份認證技術；
• L2TP：依賴PPP提供的認證。
• IPSec：使用IKEv2時，支援對使用者進行EAP認證。
• SSL VPN：對接入使用者進行認證時，支援本地認證、證書認證和伺服器認證

加密技術：

加密技術就是把明文加密成密文的過程，這樣即便黑客截獲了封包也無法知道其真實含義。加密對象有資料封包和協定封包之分，能夠實作協定封包和資料封包都加密的協定安全系數更高。

GRE和L2TP協定本身不提供加密技術，是以通常結合IPSec協定一起使用，依賴IPSec的加密技術。

：支援對資料封包和協定封包進行加密。

：支援對資料封包和協定封包加密。

資料驗證技術：

資料驗證技術就是對封包的真僞進行檢查，丢棄僞造的、被篡改的封包。那麼驗證是如何實作的呢？它采用一種稱為“摘要”的技術。

“摘要”技術主要采用Hash函數将一段長的封包通過函數變換，映射為一段短的封包。在收發兩端都對封包進行驗證，隻有摘要一緻的封包才被接受。

VPN技術對比

06

GRE VPN

Generic Routing Encapsulation，簡稱GRE，是一種三層VPN封裝技術。GRE可以對某些網絡層協定（如IPX、Apple Talk、IP等）的封包進行封裝，使封裝後的封包能夠在另一種網絡中（如IPv4）傳輸，進而解決了跨越異種網絡的封包傳輸問題。

異種封包傳輸的通道稱為Tunnel（隧道）。通常通過在IPv4網絡上建立GRE隧道，解決兩個IPv6網絡的通信問題。

07

GRE協定棧

網絡封裝技術，其基本的構成要素都可以分為三個部分：乘客協定、封裝協定、傳輸協定。GRE也不例外，為了友善了解，我們用郵政系統打個比方：

• 乘客協定就是我們自己寫的信，信的語言可以是漢語、英語、法語等，具體的内容由寫信人、讀信人自己負責；
• 封裝協定可以了解為信封，可以是平信、挂号或者EMS，不同的信封就對應于多種封裝協定；
• 運輸協定就是信的運輸方式，可以是陸運、海運或者空運，不同的運輸方式就對應于多種運輸協定。

GRE封裝封包時，封裝前的封包稱為淨荷，封裝前的封包協定稱為乘客協定，然後GRE會封裝GRE頭部，GRE成為封裝協定，也叫運載協定，最後負責對封裝後的封包進行轉發的協定稱為傳輸協定。

08

GRE封裝

GRE是按照協定棧對封包進行逐層封裝。封裝過程可以分成兩步：

• 第一步是為原始封包添加GRE頭；
• 第二步是在GRE頭前面再加上新的IP頭。

GRE的封裝操作是通過邏輯接口Tunnel完成的，Tunnel接口是一個通用的隧道接口，是以GRE協定在使用這個接口的時候，會将接口的封裝協定設定為GRE協定。

GRE封裝和解封裝封包的過程如下：

• 裝置從連接配接私網的接口接收到封包後，檢查封包頭中的目的IP位址字段，在路由表查找出接口，如果發現出接口是隧道接口，則将封包發送給隧道子產品進行處理；
• 隧道子產品接收到封包後首先根據乘客協定的類型和目前GRE隧道配置的校驗參數，對封包進行GRE封裝，即添加GRE封包頭；
• 然後，裝置給封包添加傳輸協定封包頭，即IP封包頭。該IP封包頭的源位址就是隧道源位址，目的位址就是隧道目的位址；
• 最後，裝置根據新添加的IP封包頭目的位址，在路由表中查找相應的出接口，并發送封包。之後，封裝後的封包将在公網中傳輸。
• 接收端裝置從連接配接公網的接口收到封包後，首先分析IP封包頭，如果發現協定類型字段的值為47，表示協定為GRE，于是出接口将封包交給GRE子產品處理。GRE子產品去掉IP封包頭和GRE封包頭，并根據GRE封包頭的協定類型字段，發現此封包的乘客協定為私網中運作的協定，于是将封包交給該協定處理。

09

GRE封包處理過程

PC_A通過GRE隧道通路PC_B時，防火牆A和防火牆B上的封包轉發過程如下：

• PC_A通路PC_B的原始封包進入防火牆A後，首先比對路由表；
• 根據路由查找結果，防火牆A将封包送到Tunnel接口進行GRE封裝，增加GRE頭，外層加新IP頭；
• 防火牆A根據GRE封包的新IP頭的目的位址（2.2.2.2），再次查找路由表；
• 防火牆A根據路由查找結果将封包發送至防火牆B，圖中假設防火牆A查找到的去往防火牆B的下一跳位址是1.1.1.2；
• 防火牆B收到GRE封包後，首先判斷這個封包是不是GRE封包。封裝後的GRE封包會有個新的IP頭，這個新的IP頭中有個Protocol字段，字段中辨別了内層協定類型，如果這個Protocol字段值是47，就表示這個封包是GRE封包。如果是GRE封包，防火牆B則将該封包送到Tunnel接口解封裝，去掉新的IP頭和GRE頭，恢複為原始封包；如果不是，則封包按照普通封包進行處理；
• 防火牆B根據原始封包的目的位址再次查找路由表，然後根據路由比對結果将封包發送至PC_B。

010

GRE安全政策

PC_A發出的原始封包進入Tunnel接口這個過程中，封包經過的安全域間是Trust > DMZ；原始封包被GRE封裝後，防火牆A在轉發這個封包時，封包經過的安全域間是Local > Untrust。

當封包到達防火牆B時，防火牆B會進行解封裝。在此過程中，封包經過的安全域間是Untrust > Local；GRE封包被解封裝後，防火牆B在轉發原始封包時，封包經過的安全域間是DMZ > Trust。

011

IPSec VPN

IPSec（IP Security）協定族是IETF制定的一系列安全協定，它為端到端IP封包互動提供了基于密碼學的、可互操作的、高品質的安全保護機制。IPSec VPN是利用IPSec隧道建立的網絡層VPN。

IPSec通過加密與驗證等方式，從以下幾個方面保障了使用者業務資料在Internet中的安全傳輸：

• 資料來源驗證：接收方驗證發送方身份是否合法；
• 資料加密：發送方對資料進行加密，以密文的形式在Internet上傳送，接收方對接收的加密資料進行解密後處理或直接轉發；
• 資料完整性：接收方對接收的資料進行驗證，以判定封包是否被篡改；
• 抗重放：接收方拒絕舊的或重複的資料包，防止惡意使用者通過重複發送捕獲到的資料包所進行的攻擊。

012

IPSec VPN體系結構

IPSec VPN體系結構主要由AH、ESP和IKE協定套件組成。具體介紹如下：

• AH協定：AH是封包頭驗證協定，主要提供的功能有資料源驗證、資料完整性校驗和防封包重放功能。然而，AH并不加密所保護的資料報；
• ESP協定：ESP是封裝安全載荷協定。它除提供AH協定的所有功能外（但其資料完整性校驗不包括IP頭），還可提供對IP封包的加密功能；
• IKE協定：IKE協定用于自動協商AH和ESP所使用的密碼算法。

013

IPSec協定體系

IPSec通過驗證頭AH（Authentication Header）和封裝安全載荷ESP（Encapsulating Security Payload）兩個安全協定實作IP封包的安全保護。

• AH是封包頭驗證協定，主要提供資料源驗證、資料完整性驗證和防封包重放功能，不提供加密功能；
• ESP是封裝安全載荷協定，主要提供加密、資料源驗證、資料完整性驗證和防封包重放功能。

AH和ESP協定提供的安全功能依賴于協定采用的驗證、加密算法。

IPSec加密和驗證算法所使用的密鑰可以手工配置，也可以通過網際網路密鑰交換IKE（Internet Key Exchange）協定動态協商。本課程主要講解手工方式的IPSec隧道建立。

014

AH和ESP封包格式對比

AH封包頭字段含義如下：

• Next Header（下一頭部）：8比特，辨別AH封包頭後面的負載類型。傳輸模式下，是被保護的上層協定（TCP或UDP）或ESP協定的編号；隧道模式下，是IP協定或ESP協定的編号；
• Pad Length（負載長度）：8比特，表示以32比特為機關的AH頭部長度減2，預設為4；
• Reserved（保留字段）：16比特，保留将來使用，預設為0；
• SPI（安全參數索引）：32比特，用于唯一辨別IPSec安全聯盟；
• Sequence Number（序列号）：32比特，是一個從1開始的單項遞增的計數器，唯一地辨別每一個資料包，用于防止重播攻擊；
• Authentication Data（認證資料）：一個變長字段，長度為32比特的整數倍，通常為96比特。該字段包含資料完整性校驗值ICV（Integrity Check Value），用于接收方進行完整性校驗。可選擇的認證算法有MD5（Message Digest）、SHA-1（Secure Hash Algorithm）、SHA-2、SM3。前三個認證算法的安全性由低到高依次排列，安全性高的認證算法實作機制複雜，運算速度慢。SM3密碼雜湊算法是中國國家密碼管理局規定的IPSec協定規範。

015

封裝模式

傳輸模式：在傳輸模式中，AH頭或ESP頭被插入到IP頭與傳輸層協定頭之間，保護TCP/UDP/ICMP負載。以TCP封包為例，原始封包經過傳輸模式封裝後，封包格式如圖所示。

傳輸模式不改變封包頭，故隧道的源和目的位址必須與IP封包頭中的源和目的位址一緻，是以隻适合兩台主機或一台主機和一台VPN網關之間通信。

隧道模式：在隧道模式下，AH頭或ESP頭被插到原始IP頭之前，另外生成一個新的封包頭放到AH頭或ESP頭之前，保護IP頭和負載。以TCP封包為例，原始封包經隧道模式封裝後的封包結構如圖所示。

隧道模式主要應用于兩台VPN網關之間或一台主機與一台VPN網關之間的通信。

傳輸模式和隧道模式的差別在于：

• 從安全性來講，隧道模式優于傳輸模式，它可以完全地對原始IP資料報進行驗證和加密，隐藏内部IP位址、協定類型和端口；
• 從性能來講，隧道模式因為有一個額外的IP頭，是以它将比傳輸模式占用更多帶寬。

當安全協定同時采用AH和ESP時，AH和ESP協定必須采用相同的封裝模式。

016

IPSec資料加密及認證

IPSec提供了兩種安全機制：加密和認證。

• IPSec采用對稱加密算法對資料進行加密和解密。資料發送方和接收方使用相同的密鑰進行加密和解密；
• IPSec采用HMAC（Hash-based Message Authentication Code）功能，比較數字簽名進行資料完整性和真實性認證。

ICV(Integrity Check Value)用于接收方進行完整性校驗。可選擇的認證算法有、、、。

：Message Authentication Code秘鑰，用于HMAC算法。

：資料加密标準DES（Data Encryption Standard）、3DES（Triple Data Encryption Standard）、先進加密标準AES（Advanced Encryption Standard）和國密算法（SM1和SM4）。其中，DES和3DES算法安全性低，存在安全風險，不推薦使用。

：消息摘要MD5（Message Digest 5）、安全雜湊演算法SHA1（Secure Hash Algorithm 1）、SHA2和國密算法SM3（Senior Middle 3）。其中，MD5、SHA1算法安全性低，存在安全風險，不推薦使用。

IPSec的加密功能，無法驗證解密後的資訊是否是原始發送的資訊或完整。IPSec采用HMAC（Hash-based Message Authentication Code）功能，比較數字簽名進行資料包完整性和真實性驗證。通常情況下，加密和驗證通常配合使用。

如圖所示，在IPSec發送方側，加密後的封包通過驗證算法和對稱密鑰生成完整性校驗值ICV，将IP封包和完整性校驗值ICV同時發給對端；在IPSec接收方側，使用相同的驗證算法和對稱密鑰對加密封包進行處理，同樣得到完整性校驗值ICV，然後比較完整性校驗值ICV，進行資料完整性和真實性驗證，驗證不通過的封包直接丢棄，驗證通過的封包再進行解密。

017

IKE與AH/ESP之間關系

IKE是UDP之上的一個應用層協定，是IPSec的信令協定。IKE為IPSec協商生成密鑰,供AH/ESP加解密和驗證使用。AH協定和ESP協定有自己的協定号，分别是51和50。

IKE協定有IKEv1和IKEv2兩個版本。

018

IKE的交換階段

IKE使用了兩個階段為IPSec進行密鑰協商并建立安全聯盟。

• 第一階段：通信各方彼此間建立了一個已認證身份驗證和安全保護的隧道，即IKE SA。協商模式包括主模式、野蠻模式。認證方式包括預共享密鑰、數字簽名方式、公鑰加密；
• 第二階段：用在第一階段建立的安全隧道為IPSec協商安全服務，建立IPSec SA。IPSec SA用于最終的IP資料安全傳送。協商模式為快速模式。

IKE使用了兩個階段的ISAKMP。第一階段建立IKE安全聯盟（IKE SA），第二階段利用這個既定的安全聯盟，為IPSec協商具體的安全聯盟。

IKE的工作流程如下：

• 當一個封包從某接口外出時，如果此接口應用了IPSec，會進行安全政策的比對；
• 如果找到比對的安全政策，會查找相應的安全聯盟。如果安全聯盟還沒有建立，則觸發IKE進行協商。IKE首先建立第一階段的安全聯盟，即IKE SA；
• 在第一階段安全聯盟的保護下協商第二階段的安全聯盟，即IPSec SA；
• 使用IPSec SA保護通訊資料。

019

IPSec SA

IPSec安全傳輸資料的前提是在IPSec對等體（即運作IPSec協定的兩個端點）之間成功建立安全聯盟SA（Security Association）。

建立IPSec SA一般有兩種方式：手工方式和IKE方式。

IPSec技術在資料加密，資料驗證，資料封裝等方面有多種實作方式或算法，兩端的裝置使用IPSec進行通信時需要保證一緻的加密算法，驗證算法等。是以需要一種機制幫助兩端裝置協商這些參數。

建立IPSec SA一般有兩種方式：

• 手工方式：手工方式建立IPSec SA管理成本很高，加密驗證方式需要手工配置，手工重新整理SA，且SA資訊永久存在安全性較低，适用于小型網絡；
• IKE方式：IKE方式建立IPSec SA管理成本比較低，加密驗證方式通過DH算法生成，SA資訊有生成周期，且SA動态重新整理，适用于小型，中大型網絡。

IPSec SA，由一個三元組來唯一辨別，這個三元組包括安全參數索引SPI（Security Parameter Index）、目的IP位址和使用的安全協定号（AH或ESP）。

IKE SA的主要作用是建構一條安全的通道，用于互動IPSec SA。

020

IKE SA

現網中互動對稱密鑰一般會使用密鑰分發協定：IKE（Internet Key Exchange，網際網路密鑰交換）。

IKE協定建立在ISAKMP（Internet安全聯盟和密鑰管理協定）定義的架構上，是基于UDP的應用層協定。它為IPSec提供了自動協商密鑰、建立IPSec安全聯盟的服務，能夠簡化IPSec的配置和維護工作。

：MD5、SHA1、SHA2-256、SHA2-384、SHA2-512、SM3。

：DES、3DES、AES-128、AES-192、AES-256、SM1和SM4。

ISAKMP由RFC2408定義，定義了協商、建立、修改和删除SA的過程和包格式。ISAKMP隻是為SA的屬性和協商、修改、删除SA的方法提供了一個通用的架構，并沒有定義具體的SA格式。

ISAKMP封包可以利用UDP或者TCP，端口都是500，一般情況下常用UDP協定。

021

IKEv1第一階段協商

主模式預共享密鑰協商過程

IKE交換階段第一階段——主模式交換

• 主模式被設計成将密鑰交換資訊與身份認證資訊相分離的一種交換技術。這種分離保證了身份資訊在傳輸過程中的安全性，這是因為交換的身份資訊受到了加密保護；
• 主模式總共需要經過三個步驟共6條消息來完成第一階段的協商，最終建立IKE SA。這三個步驟分别是模式協商、Diffie-Hellman交換和nonce交換、以及對對方身份的驗證；
• 主模式的特點包括身份保護以及對ISAKMP協商能力的完全利用。其中，身份保護在對方希望隐藏自己的身份時顯得尤為重要。在我們讨論野蠻模式時，協商能力的完全利用與否也會凸顯出其重要性。若使用預共享密鑰方法驗證。在消息1、2發送之前，協商發起者和響應者必須計算産生自己的cookie，用于唯一辨別每個單獨的協商交換。cookie使用源/目的IP位址、随機數字、日期和時間進行MD5運算得出，并且放入消息1的ISAKMP中，用以辨別單獨的一個協商交換；
• 在第一次交換中，需要交換雙方的cookie和SA載荷，在SA載荷中攜帶需要協商的IKE SA的各項參數，主要包括IKE的散列類型、加密算法、認證算法和IKE SA的協商時間限制等；
• 第一次交換後到第二次交換前，通信雙方需要生成用于産生Diffie-Hellman共享密鑰的DH值。生成方法是雙方各自生成一個随機數字，通過DH算法對随機數字進行運算，得出一個DH值Xa和Xb（Xa是發起方的DH值，Xb是響應者的DH值），然後雙方再根據DH算法運算得出一個臨時值Ni和Nr；
• 第二次交換中，雙方交換各自的密鑰交換載荷（即Diffie-Hellman交換）以及臨時值載荷（即nonce交換）。其中密鑰交換載荷包含了Xa和Xb，臨時值交換包含了Ni和Nr；
• 雙方交換了臨時值載荷Ni和Nr之後，配合事先預置好的預共享密鑰，再通過随機函數運算便可産生一個密鑰SKEYID，這個密鑰是後續所有密鑰生成的基礎。随後，通過自己算出來的DH值、交換得到的DH值以及SKEYID進行運算便可産生一個隻有雙方才知道的共享密鑰SKEYID_d。此共享密鑰并不進行傳輸，傳輸的隻是是DH值以及臨時值，是以即使第三方得到了這些材料也無法計算出共享密鑰；
• 在第二次交換完成之後，雙方所需的計算材料都已經交換完畢，此時，雙方就可以将所有的密鑰計算出來，并使用該密鑰對随後的IKE消息提供安全保護。這些密鑰包括：SKEYID_a以及SKEYID_e。SKEYID_a用來為IKE消息提供完整性以及資料源身份驗證等安全服務；SKEYID_e則用于對IKE消息進行加密；
• 第三次交換是對辨別載荷和散列載荷進行交換。辨別載荷包含了發起者的辨別資訊、IP位址或主機名，散列載荷包含上一過程中産生的三組密鑰進行Hash運算得出的值。這兩個載荷通過SKEYID_e進行加密，如果雙方的載荷相同，那麼認證成功。IKE第一階段主模式預共享密鑰交換也就完成了。

野蠻模式預共享密鑰協商過程

野蠻模式一共需要交換3個消息：

• 消息1交換SA載荷、密鑰材料、和身份資訊；
• 消息2在交換消息1内容的同時增加了Hash認證載荷；
• 消息3是響應方對發起方的認證。

IKE交換階段第一階段——野蠻模式交換

• 從上述主模式協商的叙述中可以看到，在第二次交換之後便可生成會話密鑰，會話密鑰的生成材料中包含了預共享密鑰。而當一個對等體同時與多個對等體進行協商SA時，則需要為每個對等體設定一個預共享密鑰。為了對每個對等體正确地選擇對應的預共享密鑰，主模式需要根據前面交換資訊中的IP位址來區分不同的對等體；
• 但是當發起者的IP位址是動态配置設定獲得時，由于發起者的IP位址不可能被響應者提前知道，而且雙方都打算采用預共享密鑰驗證方法，此時響應者就無法根據IP位址選擇對應的預共享密鑰。野蠻模式就是被用于解決這個沖突的；
• 與主模式不同，野蠻模式僅用3條資訊便完成了IKE SA的建立。由于對消息數進行了限制，野蠻模式同時也限制了它的協商能力，而且不會提供身份保護；
• 在野蠻模式的協商過程中，發起者會提供一個保護套件清單、Diffie-Hellman公共值、nonce以及身份資料。所有這些資訊都是随第一條資訊進行交換的。作為響應者，則需要回應選擇一個保護套件、Diffie-Hellman公共值、nonce、身份資料以及一個驗證載荷。發起者将它的驗證載荷在最後一條消息交換；
• 野蠻模式由于在其第一條資訊中就攜帶了身份資訊，是以本身無法對身份資訊進行加密保護，這就降低了協商的安全性，但也是以不依賴IP位址辨別身份，在野蠻模式下也就有了更多靈活的應用。

IKEv1主模式和野蠻模式差別

：主模式為6個；野蠻模式為3個。

：主模式的最後兩條消息有加密，可以提供身份保護功能；而野蠻模式消息內建度過高，是以無身份保護功能。

：主模式隻能采用IP位址方式辨別對等體；而野蠻模式可以采用IP位址方式或者Name方式辨別對等體。

022

IKEv1第二階段協商

快速模式協商過程

快速模式一共需要交換3個消息：

• 消息1和消息2中，交換SA、KEY、Nonce和ID。用以協商算法、保證PFS以及提供“在場證據”；
• 消息3是用于驗證響應者是否可以通信，相當于确認資訊。

IKE交換階段第二階段——快速模式交換

• 建立好IKE SA之後（無論通過主模式還是通過野蠻模式交換），便可用它為IPSec生成相應的SA。IPSec SA是通過快速模式交換來建立的，對快速模式交換來說，它是在已經建立好的IKE SA的保護下完成的；
• 在一次快速交換模式中，通信雙方需要協商拟定IPSec安全聯盟的各項特征，并為其生成密鑰。IKE SA保護快速模式交換的方法是：對其進行加密，并對消息進行驗證。消息的驗證是通過僞随機函數來進行的。來自IKE SA的SKEYID_a的值作為一個密鑰，對快速模式交換的整個消息進行驗證。這種驗證除了能提供資料完整性保證之外，還能對資料源的身份進行驗證。在消息接收到之後，我們知道它隻有可能來自驗證通過的實體，而且那條消息在傳送過程并未發生改變。而通過加密（使用SKEYID_e），則可保障交換的機密性；
• 快速模式需要從SKEYID_d狀态中衍生出用于IPSec SA的密鑰，這個密鑰将在僞随機函數中使用，這樣便可確定每個SA都有自己獨一無二的密鑰。每個SA都有一個不同的SPI，是以入方向SA的密鑰也會與出方向SA不同。所有IPSec密鑰都是根據相同的來源衍生的，是以互相間都有關聯。假如一名攻擊者能夠根據IKE SA判斷出SKEYID_d的值，那麼就能非常容易地掌握自那個SKEYID_d衍生出來的IPSec SA的任何密鑰。另外，還能繼續掌握未來将要衍生的所有密鑰，這顯然是個大問題，所有這些密鑰都不能保證所謂的“完美向前保密（PFS）”。快速模式為此專門提供了一個PFS選項，來滿足這方面的需要，使用者可根據自己地安全需要選擇是否使用PFS；
• 為了在快速模式交換中實作PFS，需要執行一次額外的Diffie-Hellman交換，最終生成的共享密鑰将在為IPSec生成密鑰的過程中用到。顯然，一旦交換完成，這個密鑰便不複存在。一旦完成，它所駐留的那個記憶體位置必須清零和釋放。進而保證了密鑰之間地不相關性；
• 我們前面将快速模式描述成一種簡單的請求／響應交換，但它的實際功用遠不止于此。發起者可能需要一個“在場”證據，證明響應者線上，而且已經實際地處理了它的初始快速模式消息。為了達到這個要求，響應者需要在驗證散列載荷中，加入交換的發起者nonce以及消息ID。這個摘要現在不僅能保障消息的完整性，也能為發起者提供源驗證功能，另外還能提供在場證據；
• 響應者也需要一個在場證據，從發起者傳來的可能是一條過期的消息，是由不懷好意的人重播的。這個人可能不知道消息的内容，但通過對通信的分析，能夠知道它是一條快速模式消息。如果重播那條消息，響應者便不得不建立多餘的SA。我們可将其想像成一種“服務否認”攻擊，隻是屬于比較溫和的那種，因為響應者會根據這條消息，增加不必要的記憶體及SA管理開銷。想要防範此類攻擊，需在快速模式交換中增加第三條消息。在這條消息中，發起者需要同時包括nonce和此次交換的消息ID，并把它們儲存在一個驗證散列載荷中。這樣發起者便可向響應者證明：自己是此次交換的活動參與者；
• 在前兩條消息中，發起者和響應者都發送了SA載荷，和主模式、野蠻模式一樣，SA載荷是用來協商各種保護算法的。而Ni、Nr以及ID則是用來提供“在場證據”的。Xa以及Xb則是用來生成新的DH共享密鑰，保證PFS的。Xa以及Xb将與IKE第一階段生成的SKEYID_d、Ni、Nr以及SPI等資訊共同生成最終用于IPSec加密的密鑰；
• 最後發起者會發送一條确認資訊，響應者收到該資訊後就知道發起者已經收到了第二條消息。此時IKE第二階段結束。

初始交換

IKEv2定義了三種交換：、以及。

正常情況下，IKEv2通過初始交換就可以完成第一對IPSec SA的協商建立。IKEv2初始交換對應IKEv1的第一階段，初始交換包含兩次交換四條消息。

采用IKEv2協商安全聯盟比IKEv1協商過程要簡化的多。要建立一對IPSec SA，IKEv1需要經曆兩個階段：或者，前者至少需要交換9條消息，後者也至少需要6條消息。而IKEv2正常情況使用2次交換共4條消息就可以完成一對IPSec SA的建立，如果要求建立的IPSec SA大于一對時，每一對IPSec SA隻需額外增加1次建立子SA交換，也就是2條消息就可以完成。

初始交換過程：

• 消息①和②屬于第一次交換（稱為IKE_SA_INIT交換），以明文方式完成IKE SA的參數協商，包括協商加密和驗證算法、交換臨時随機數和DH交換。IKE_SA_INIT交換後生成一個共享密鑰材料，通過這個共享密鑰材料可以衍生出IPSec SA的所有密鑰；
• 消息③和④屬于第二次交換（稱為IKE_AUTH交換），以加密方式完成身份認證、對前兩條資訊的認證和IPSec SA的參數協商。IKEv2支援RSA簽名認證、預共享密鑰認證以及擴充認證方法EAP（Extensible Authentication Protocol）。EAP認證是作為附加的IKE_AUTH交換在IKE中實作的，發起者通過在消息3中省去認證載荷來表明需要使用EAP認證。

建立子SA交換：

• 當一個IKE SA需要建立多對IPSec SA時，需要使用建立子SA交換來協商多于一對的IPSec SA。另外，建立子SA交換還可以用于IKE SA的重協商；
• 建立子SA交換包含一個交換兩條消息，對應IKEv1協商階段2，交換的發起者可以是初始交換的協商發起方，也可以是初始交換的協商響應方。建立子SA交換必須在初始交換完成後進行，交換消息由初始交換協商的密鑰進行保護；
• 類似于IKEv1，如果啟用PFS，建立子SA交換需要額外進行一次DH交換，生成新的密鑰材料。生成密鑰材料後，子SA的所有密鑰都從這個密鑰材料衍生出來。

通知交換

運作IKE協商的兩端有時會傳遞一些控制資訊，例如錯誤資訊或者通告資訊，這些資訊在IKEv2中是通過通知交換完成的。

通知交換必須在IKE SA保護下進行，也就是說通知交換隻能發生在初始交換之後。控制資訊如果是IKE SA的，那麼通知交換必須由該IKE SA來保護進行；控制資訊如果是某子SA的，那麼該通知交換必須由生成該子SA的IKE SA來保護進行。

023

L2TP VPN

L2TP（Layer Two Tunneling Protocol）二層隧道協定是另一種常見VPN協定。

• L2TP是虛拟私有撥号網VPDN（Virtual Private Dial-up Network）隧道協定的一種，它擴充了點到點協定PPP的應用，是一種在遠端辦公場景中為出差員工或企業分支遠端通路企業内網資源提供接入服務的VPN。

L2TP VPN主要有三種使用場景：

• ：由遠端撥号使用者發起，遠端系統通過PSTN/ISDN撥入LAC。由LAC通過Internet向LNS發起建立隧道連接配接請求，撥号使用者位址則由LNS配置設定。對遠端撥号使用者的驗證與計費既可由LAC側的代理完成，也可在LNS完成；
• ：L2TP除了可以為出差員工提供遠端接入服務以外，還可以進行企業分支與總部的内網互聯，實作分支使用者與總部使用者的互訪；
• ：直接由LAC客戶（指可在本地支援L2TP協定的使用者）發起。客戶需要知道LNS的IP位址。LAC客戶可直接向LNS發起隧道連接配接請求，無需再經過一個單獨的LAC裝置。在LNS裝置上收到了LAC客戶的請求之後，根據使用者名、密碼進行驗證，并且給LAC客戶配置設定私有IP位址。

024

Client-Initiated場景中的L2TP VPN原理

從隧道協商、封包封裝、安全政策這3個方面介紹Client-Initiated場景中L2TP VPN的工作原理。

：移動辦公使用者在通路企業總部伺服器之前，需要先通過L2TP VPN軟體與LNS建立L2TP VPN隧道。下圖所示是移動辦公使用者與LNS協商建立L2TP VPN隧道，直至最後成功通路企業内網資源的完整過程。

：封包的封裝和解封裝過程如圖所示。

L2TP Client發往内網伺服器的封包的轉發過程如下：

• L2TP Client将原始封包用PPP頭、L2TP頭、UDP頭、外層公網IP頭層層封裝，成為L2TP封包；
• L2TP 封包穿過Internet到達LNS；
• LNS收到封包後，在L2TP子產品中完成了身份認證和封包的解封裝，去掉PPP頭、L2TP頭、UDP頭、外層公網IP頭，還原成原始封包；
• 原始封包隻攜帶了内層私網IP頭，内層私網IP頭中的源位址是L2TP Client擷取到的私網IP位址，目的位址是内網伺服器的私網IP位址。LNS根據目的位址查找路由表，然後根據路由比對結果轉發封包。

：下圖所示為LNS裝置上封包所經過的安全域間，以及LNS的安全政策比對條件。

移動辦公使用者通路企業總部伺服器的過程中，經過LNS的流量分為以下2類，對應流量的安全政策處理原則如下。

• 移動辦公使用者與LNS間的L2TP封包：此處的L2TP封包既包含移動辦公使用者與LNS建立隧道時的L2TP協商封包，也包含移動辦公使用者通路企業總部伺服器被解封裝前的業務封包，這些L2TP封包會經過Untrust > Local區域；
• 移動辦公使用者通路企業總部内網伺服器的業務封包：LNS通過VT接口将移動辦公使用者通路企業總部伺服器的業務封包解封裝以後，這些封包經過的安全域間為DMZ > Trust。DMZ區域為LNS上Tunnel接口所在的安全區域，Trust為LNS連接配接總部内網接口所在的安全區域。

025

SSL VPN

IPSec、L2TP等早期出現的VPN技術雖然可以支援遠端接入這個應用場景，但這些VPN技術存在以下問題：

• 移動辦公使用者需要安裝指定的用戶端軟體；
• 網絡部署和維護都比較麻煩；
• 無法對移動辦公使用者的通路權限做精細化控制。

SSL VPN作為新型的輕量級遠端接入方案，可以有效地解決上述問題。SSL VPN是通過SSL協定實作遠端安全接入的VPN技術，保證移動辦公使用者能夠在企業外部安全、高效地通路企業内部的網絡資源。

SSL VPN主要應用場景：企業出差員工

如上圖所示，防火牆作為企業出口網關連接配接至Internet，并向移動辦公使用者（即出差員工）提供SSL VPN接入服務。移動辦公使用者使用終端（如便攜機、PAD或智能手機）與防火牆建立SSL VPN隧道以後，就能通過SSL VPN隧道遠端通路企業内網的Web伺服器、檔案伺服器、郵件伺服器等資源。

SSL封裝位于傳輸層與各種應用層協定之間，為資料通訊提供安全支援，建立在可靠的傳輸協定（如TCP）之上，為高層協定提供資料封裝、壓縮、加密等基本功能的支援。

026

SSL VPN虛拟網關

防火牆通過虛拟網關向移動辦公使用者提供SSL VPN接入服務，虛拟網關是移動辦公使用者通路企業内網資源的統一入口。下圖是移動辦公使用者登入SSL VPN虛拟網關并通路企業内網資源的總體流程。系統管理者在防火牆上建立SSL VPN虛拟網關，并通過虛拟網關對移動辦公使用者提供SSL VPN接入服務。

移動辦公使用者登入SSL VPN虛拟網關并通路企業内網資源的過程如下：

• ：移動辦公使用者在浏覽器中輸入SSL VPN虛拟網關的IP位址或域名，請求建立SSL連接配接。虛拟網關向遠端使用者發送自己的證書，遠端使用者對虛拟網關的證書進行身份認證。認證通過後，遠端使用者與虛拟網關成功建立SSL連接配接，進入SSL VPN虛拟網關的登入頁面；
• ：在登入頁面輸入使用者名、密碼後，虛拟網關将對該使用者進行身份認證。
• ：使用者身份認證通過後，虛拟網關會查詢該使用者所屬的角色資訊，然後再将該角色所擁有的資源連結推送給使用者。
• ：使用者點選虛拟網關資源清單中的連結就可以通路對應資源。

027

SSL VPN業務

Web代理業務

移動辦公使用者通路内網Web資源時使用Web代理業務。

Web代理按照實作方式的不同分為了和兩種。

Web代理業務互動流程：

• 遠端使用者通過域名（https://svn）來通路虛拟網關；
• 登入虛拟網關成功後，遠端使用者會在虛拟網關中看到自己有權通路的Web資源清單，然後單擊要通路的資源連結。防火牆在将内網資源（http://website/resource.html）呈現給遠端使用者時，會改寫該資源的URL。遠端使用者點選資源連結後，發送給防火牆的HTTPS連結請求就是虛拟網關改寫以後的URL，改寫後的URL實質上是由https://svn和http://website/resource.html這兩個URL拼接而成；
• 防火牆收到上述URL後，會向Web Server重新發起一個HTTP請求，這個HTTP請求就是Web資源實際的URL（http://website/resource.html）；
• Web Server以HTTP方式向防火牆傳回資源頁面；
• 虛拟網關将Web Server傳回的資源頁面，再經過HTTPS方式轉發給遠端使用者。

Web改寫：Web改寫中的“改寫”包含兩層含義。第一層含義是加密，即遠端使用者在點選虛拟網關資源清單中的連結時，虛拟網關會将使用者要通路的真實URL進行加密。第二層含義是适配。

Web link：Web Link不會進行加密和适配，隻做單純轉發遠端使用者的Web資源請求。

檔案共享業務

遠端使用者通路内網檔案伺服器（如支援SMB協定的Windows系統、支援NFS協定的Linux系統）時使用檔案共享業務。

遠端使用者直接通過Web浏覽器就能在内網檔案系統上建立和浏覽目錄，進行下載下傳、上傳、改名、删除等檔案操作，就像對本機檔案系統進行操作一樣友善。

在檔案共享業務中防火牆起到了協定轉換器的作用，以通路内網Windows檔案伺服器為例，具體實作過程如圖所示。

端口轉發業務

遠端使用者通路内網TCP資源時使用端口轉發業務。适用于TCP的應用服務包括Telnet、遠端桌面、FTP、Email等。端口轉發提供了一種端口級的安全通路内網資源的方式。

端口轉發需要在用戶端上運作一個ActiveX控件作為端口轉發器，用于偵聽指定端口上的連接配接。以使用者Telnet到内網伺服器為例，端口轉發的實作過程如圖所示。

網絡擴充業務

遠端使用者通路内網IP資源時使用網絡擴充業務，Web資源、檔案資源以及TCP資源都屬于IP資源。

通常在不區分使用者通路的資源類型時為對應使用者開通網絡擴充業務。

遠端使用者通過Web浏覽器登入虛拟網關。成功登入虛拟網關後啟動網絡擴充功能。啟動網絡擴充功能，會觸發以下幾個動作：

• 遠端使用者與虛拟網關之間會建立一條SSL VPN隧道；
• 遠端使用者本地PC會自動生成一個虛拟網卡。虛拟網關從位址池中随機選擇一個IP位址，配置設定給遠端使用者的虛拟網卡，該位址作為遠端使用者與企業内網Server之間通信之用。有了該私網IP位址，遠端使用者就如同企業内網使用者一樣可以友善通路内網IP資源；
• 虛拟網關向遠端使用者下發到達企業内網伺服器的路由資訊。虛拟網關會根據網絡擴充業務中的配置，向遠端使用者下發不同的路由資訊。

遠端使用者向企業内網的伺服器發送業務請求封包，該封包通過SSL VPN隧道到達虛拟網關。

虛拟網關收到封包後進行解封裝，并将解封裝後的業務請求封包發送給内網伺服器。

内網伺服器響應遠端使用者的業務請求。

響應封包到達虛拟網關後進入SSL VPN隧道。

028

VPN配置

IPSec VPN配置舉例

需求描述：

• 兩個網關之間通過IKE方式協商IPSec VPN隧道（采用預共享密鑰認證），進而實作區域網路之間安全地互訪；
• 網絡A和網絡B通過防火牆A和B之間建立的IPSec隧道互聯互通；
• 網絡A屬于10.1.1.0/24子網，通過接口GigabitEthernet 0/0/3與防火牆A連接配接；
• 網絡B屬于10.1.2.0/24子網，通過接口GigabitEthernet 0/0/3與防火牆B連接配接；
• 防火牆A和防火牆B路由可達。

配置思路：

• 完成接口基本配置；
• 配置安全政策，允許私網指定網段進行封包互動；
• 配置到對端内網的路由；
• 配置IPSec政策，包括配置IPSec政策的基本資訊、配置待加密的資料流、配置安全提議的協商參數。

定義被保護的資料流。

防火牆A：配置進階ACL 3000，允許10.1.1.0/24網段通路10.1.2.0/24網段。

[FW_A] acl 3000
[FW_A-acl-adv-3000]
rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0
0.0.0.255 [FW_A-acl-adv-3000] quit           

防火牆B：配置進階ACL 3000，允許10.1.2.0/24網段通路10.1.1.0/24網段。

[FW_B] acl 3000
[FW_B-acl-adv-3000]
rule 5 permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0
0.0.0.255 [FW_B-acl-adv-3000] quit           

配置IPSec安全提議。（防火牆A與防火牆B配置相同，預設參數可不配置）

[FW_A] IPSec
proposal tran1
[FW_A-IPSec-proposal-tran1]
esp authentication-algorithm sha2-256
[FW_A-IPSec-proposal-tran1]
esp encryption-algorithm aes-256
[FW_A-IPSec-proposal-tran1]
quit           

配置IKE安全提議。（防火牆A與防火牆B配置相同）

[FW_A] ike proposal
10
[FW_A-ike-proposal-10]
authentication-method pre-share
[FW_A-ike-proposal-10]
prf hmac-sha2-256
[FW_A-ike-proposal-10]
encryption-algorithm aes-256
[FW_A-ike-proposal-10]
dh group14
[FW_A-ike-proposal-10]
integrity-algorithm hmac-sha2-256
[FW_A-ike-proposal-10]
quit           

配置IKE peer

[FW_A] ike peer b
[FW_A-ike-peer-b]
ike-proposal 10
[FW_A-ike-peer-b]
remote-address 1.1.5.1
[FW_A-ike-peer-b]
pre-shared-key Test!1234
[FW_A-ike-peer-b]
quit
[FW_B] ike peer a
[FW_B-ike-peer-a]
ike-proposal 10
[FW_B-ike-peer-a]
remote-address 1.1.3.1
[FW_B-ike-peer-a]
pre-shared-key Test!1234
[FW_B-ike-peer-a]
quit           

配置IPSec政策

[FW_A] IPSec policy
map1 10 isakmp
[FW_A-IPSec-policy-isakmp-map1-10]
security acl 3000
[FW_A-IPSec-policy-isakmp-map1-10]
proposal tran1
[FW_A-IPSec-policy-isakmp-map1-10]
ike-peer b
[FW_A-IPSec-policy-isakmp-map1-10]
quit
[FW_B] IPSec policy
map1 10 isakmp
[FW_B-IPSec-policy-isakmp-map1-10]
security acl 3000
[FW_B-IPSec-policy-isakmp-map1-10]
proposal tran1
[FW_B-IPSec-policy-isakmp-map1-10]
ike-peer a
[FW_B-IPSec-policy-isakmp-map1-10]
quit           

引用IPSec政策。

防火牆A：在接口GigabitEthernet 0/0/1上應用IPSec政策組map1。

[FW_A]
interface GigabitEthernet 0/0/1
[FW_A-GigabitEthernet0/0/1]
IPSec policy map1
[FW_A-GigabitEthernet0/0/1]
quit           

防火牆B：在接口GigabitEthernet 0/0/1上應用IPSec政策組map1。

[FW_B] interface
GigabitEthernet 0/0/1
[FW_B-GigabitEthernet0/0/1]
IPSec policy map1
[FW_B-GigabitEthernet0/0/1]
quit           

SSL VPN配置舉例

需求描述：

• 企業網絡如圖所示，企業希望移動辦公使用者通過Web代理通路企業Web伺服器（Web Link）;
• 企業使用防火牆的本地認證對各部門的員工進行使用者認證，通過認證的使用者能夠獲得接入企業内部網絡的權限。

配置思路：

• 完成接口基本配置；
• 配置使用者和認證：配置認證域，建立使用者組和使用者；
• 配置SSL VPN虛拟網關；
• 配置Web Link功能：啟用Web Link功能，配置Web Link資源；
• 配置角色授權：将使用者組添加到虛拟網關中，建立角色，将角色與使用者組綁定，同時啟用Web Link功能；
• 配置安全政策，允許移動辦公使用者登入SSL VPN網關；允許出差員工通路Web代理資源。

配置使用者與認證。選擇“對象> 使用者 > default”，按如下參數配置，然後單擊“應用”。

使用者user0001所屬的使用者組為“/default/group1”，認證類型為本地認證，密碼為Password@123。需要注意，在建立使用者user0001之前，應先建立使用者組“/default/group1”，這樣才能在建立使用者時引用已建立好的使用者組。

指令行配置如下：

[FW]
aaa
[FW-aaa]
domain default
[FW-aaa-domain-default]
authentication-scheme default
[FW-aaa-domain-default]
service-type ssl-vpn
[FW-aaa-domain-default]
quit
[FW-aaa]
quit
[FW]
user-manage group /default/group1
[FW-usergroup-/default/group1]
quit
[FW]
user-manage user user0001 domain default
[FW-localuser-user0001]
password Password@123
[FW-localuser-user0001]
parent-group /default/group1
[FW-localuser-user0001]
quit           

配置SSL VPN網關。選擇“網絡 > SSL VPN > SSL VPN > 建立”，按如下參數配置。

指令行配置如下：

[FW] v-gateway
gateway interface GigabitEthernet 0/0/1 private
[FW] v-gateway
gateway udp-port 443
[FW] v-gateway
gateway authentication-domain default           

配置SSL協定的版本、加密套件、會話逾時時間和生命周期。可直接使用預設值。選擇“Web代理”業務，單擊“下一步”。

指令行配置如下：

[FW]
v-gateway gateway interface GigabitEthernet 0/0/1 private
[FW]
v-gateway gateway udp-port 443
[FW]
v-gateway gateway authentication-domain default           

配置Web代理。選擇“Web代理資源清單> 建立”，按如下配置建立Web代理資源。

指令行配置如下：

[FW-gateway-service]
web-proxy link-resource Web-Server http://10.2.0.2:8080 show-link           

配置SSL VPN的角色授權。選擇“角色授權清單> 建立”，按下圖配置角色授權參數。

指令行配置如下：

[FW-gateway]
vpndb
[FW-gateway-vpndb]
group /default/sslvpn
[FW-gateway-vpndb]
quit
[FW-gateway]
role
[FW-gateway-role]
role role
[FW-gateway-role]
role role group /default/sslvpn
[FW-gateway-role]
role role web-proxy enable
[FW-gateway-role]
role role web-proxy resource Web-Server
[FW-gateway-role]
quit
[FW-gateway]
quit