自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

IPSec VPN基本原理

安全
IPSec VPN是目前VPN技術(shù)中點擊率非常高的一種技術(shù),同時提供VPN和信息加密兩項技術(shù),這一期專欄就來介紹一下IPSec VPN的原理。

IPSec VPN是目前VPN技術(shù)中點擊率非常高的一種技術(shù),同時提供VPN和信息加密兩項技術(shù),這一期專欄就來介紹一下IPSec VPN的原理。

 

IPSec VPN的應(yīng)用場景分為3種:

1.      Site-to-Site(站點到站點或者網(wǎng)關(guān)到網(wǎng)關(guān)):如彎曲評論的3個機構(gòu)分布在互聯(lián)網(wǎng)的3個不同的地方,各使用一個商務(wù)領(lǐng)航網(wǎng)關(guān)相互建立VPN隧道,企業(yè)內(nèi)網(wǎng)(若干PC)之間的數(shù)據(jù)通過這些網(wǎng)關(guān)建立的IPSec隧道實現(xiàn)安全互聯(lián)。

2.      End-to-End(端到端或者PC到PC): 兩個PC之間的通信由兩個PC之間的IPSec會話保護,而不是網(wǎng)關(guān)。

3.      End-to-Site(端到站點或者PC到網(wǎng)關(guān)):兩個PC之間的通信由網(wǎng)關(guān)和異地PC之間的IPSec進行保護。

VPN只是IPSec的一種應(yīng)用方式,IPSec其實是IP Security的簡稱,它的目的是為IP提供高安全性特性,VPN則是在實現(xiàn)這種安全特性的方式下產(chǎn)生的解決方案。IPSec是一個框架性架構(gòu),具體由兩類協(xié)議組成:

1.      AH協(xié)議(Authentication Header,使用較少):可以同時提供數(shù)據(jù)完整性確認(rèn)、數(shù)據(jù)來源確認(rèn)、防重放等安全特性;AH常用摘要算法(單向Hash函數(shù))MD5和SHA1實現(xiàn)該特性。

2.      ESP協(xié)議(Encapsulated Security Payload,使用較廣):可以同時提供數(shù)據(jù)完整性確認(rèn)、數(shù)據(jù)加密、防重放等安全特性;ESP通常使用DES、3DES、AES等加密算法實現(xiàn)數(shù)據(jù)加密,使用MD5或SHA1來實現(xiàn)數(shù)據(jù)完整性。

為何AH使用較少呢?因為AH無法提供數(shù)據(jù)加密,所有數(shù)據(jù)在傳輸時以明文傳輸,而ESP提供數(shù)據(jù)加密;其次AH因為提供數(shù)據(jù)來源確認(rèn)(源IP地址一旦改變,AH校驗失敗),所以無法穿越NAT。當(dāng)然,IPSec在極端的情況下可以同時使用AH和ESP實現(xiàn)最完整的安全特性,但是此種方案極其少見。

IPSec封裝模式

介紹完IPSec VPN的場景和IPSec協(xié)議組成,再來看一下IPSec提供的兩種封裝模式(傳輸Transport模式和隧道Tunnel模式)

 

上圖是傳輸模式的封裝結(jié)構(gòu),再來對比一下隧道模式:#p#

 

可以發(fā)現(xiàn)傳輸模式和隧道模式的區(qū)別:

1.      傳輸模式在AH、ESP處理前后IP頭部保持不變,主要用于End-to-End的應(yīng)用場景。

2.      隧道模式則在AH、ESP處理之后再封裝了一個外網(wǎng)IP頭,主要用于Site-to-Site的應(yīng)用場景。

從上圖我們還可以驗證上一節(jié)所介紹AH和ESP的差別。下圖是對傳輸模式、隧道模式適用于何種場景的說明

 

從這張圖的對比可以看出:#p#

1.      隧道模式可以適用于任何場景

2.      傳輸模式只能適合PC到PC的場景

隧道模式雖然可以適用于任何場景,但是隧道模式需要多一層IP頭(通常為20字節(jié)長度)開銷,所以在PC到PC的場景,建議還是使用傳輸模式。

為了使大家有個更直觀的了解,我們看看下圖,分析一下為何在Site-to-Site場景中只能使用隧道模式:

 

如上圖所示,如果發(fā)起方內(nèi)網(wǎng)PC發(fā)往響應(yīng)方內(nèi)網(wǎng)PC的流量滿足網(wǎng)關(guān)的興趣流匹配條件,發(fā)起方使用傳輸模式進行封裝:

1.      IPSec會話建立在發(fā)起方、響應(yīng)方兩個網(wǎng)關(guān)之間。

2.      由于使用傳輸模式,所以IP頭部并不會有任何變化,IP源地址是192.168.1.2,目的地址是10.1.1.2。

3.      這個數(shù)據(jù)包發(fā)到互聯(lián)網(wǎng)后,其命運注定是杯具的,為什么這么講,就因為其目的地址是10.1.1.2嗎?這并不是根源,根源在于互聯(lián)網(wǎng)并不會維護企業(yè)網(wǎng)絡(luò)的路由,所以丟棄的可能性很大。

4.      即使數(shù)據(jù)包沒有在互聯(lián)網(wǎng)中丟棄,并且幸運地抵達了響應(yīng)方網(wǎng)關(guān),那么我們指望響應(yīng)方網(wǎng)關(guān)進行解密工作嗎?憑什么,的確沒什么好的憑據(jù),數(shù)據(jù)包的目的地址是內(nèi)網(wǎng)PC的10.1.1.2,所以直接轉(zhuǎn)發(fā)了事。

5.      最杯具的是響應(yīng)方內(nèi)網(wǎng)PC收到數(shù)據(jù)包了,因為沒有參與IPSec會話的協(xié)商會議,沒有對應(yīng)的SA,這個數(shù)據(jù)包無法解密,而被丟棄。

我們利用這個反證法,巧妙地解釋了在Site-to-Site情況下不能使用傳輸模式的原因。并且提出了使用傳輸模式的充要條件:興趣流必須完全在發(fā)起方、響應(yīng)方IP地址范圍內(nèi)的流量。比如在圖中,發(fā)起方IP地址為6.24.1.2,響應(yīng)方IP地址為2.17.1.2,那么興趣流可以是源6.24.1.2/32、目的是2.17.1.2/32,協(xié)議可以是任意的,倘若數(shù)據(jù)包的源、目的IP地址稍有不同,對不起,請使用隧道模式。

IPSec協(xié)商#p#

  

IPSec除了一些協(xié)議原理外,我們更關(guān)注的是協(xié)議中涉及到方案制定的內(nèi)容:

1.      興趣流:IPSec是需要消耗資源的保護措施,并非所有流量都需要IPSec進行處理,而需要IPSec進行保護的流量就稱為興趣流,最后協(xié)商出來的興趣流是由發(fā)起方和響應(yīng)方所指定興趣流的交集,如發(fā)起方指定興趣流為192.168.1.0/24à10.0.0.0/8,而響應(yīng)方的興趣流為10.0.0.0/8à192.168.0.0/16,那么其交集是192.168.1.0/24?à10.0.0.0/8,這就是最后會被IPSec所保護的興趣流。

2.      發(fā)起方:Initiator,IPSec會話協(xié)商的觸發(fā)方,IPSec會話通常是由指定興趣流觸發(fā)協(xié)商,觸發(fā)的過程通常是將數(shù)據(jù)包中的源、目的地址、協(xié)議以及源、目的端口號與提前指定的IPSec興趣流匹配模板如ACL進行匹配,如果匹配成功則屬于指定興趣流。指定興趣流只是用于觸發(fā)協(xié)商,至于是否會被IPSec保護要看是否匹配協(xié)商興趣流,但是在通常實施方案過程中,通常會設(shè)計成發(fā)起方指定興趣流屬于協(xié)商興趣流。

3.      響應(yīng)方:Responder,IPSec會話協(xié)商的接收方,響應(yīng)方是被動協(xié)商,響應(yīng)方可以指定興趣流,也可以不指定(完全由發(fā)起方指定)。

4.      發(fā)起方和響應(yīng)方協(xié)商的內(nèi)容主要包括:雙方身份的確認(rèn)和密鑰種子刷新周期、AH/ESP的組合方式及各自使用的算法,還包括興趣流、封裝模式等。

5.      SA:發(fā)起方、響應(yīng)方協(xié)商的結(jié)果就是曝光率很高的SA,SA通常是包括密鑰及密鑰生存期、算法、封裝模式、發(fā)起方、響應(yīng)方地址、興趣流等內(nèi)容。

我們以最常見的IPSec隧道模式為例,解釋一下IPSec的協(xié)商過程:

 

上圖描述了由興趣流觸發(fā)的IPSec協(xié)商流程,原生IPSec并無身份確認(rèn)等協(xié)商過程,在方案上存在諸多缺陷,如無法支持發(fā)起方地址動態(tài)變化情況下的身份確認(rèn)、密鑰動態(tài)更新等。伴隨IPSec出現(xiàn)的IKE(Internet Key Exchange)協(xié)議專門用來彌補這些不足:

1.      發(fā)起方定義的興趣流是源192.168.1.0/24目的10.0.0.0/8,所以在接口發(fā)送發(fā)起方內(nèi)網(wǎng)PC發(fā)給響應(yīng)方內(nèi)網(wǎng)PC的數(shù)據(jù)包,能夠得以匹配。

2.      滿足興趣流條件,在轉(zhuǎn)發(fā)接口上檢查SA不存在、過期或不可用,都會進行協(xié)商,否則使用當(dāng)前SA對數(shù)據(jù)包進行處理。

3.      協(xié)商的過程通常分為兩個階段,第一階段是為第二階段服務(wù),第二階段是真正的為興趣流服務(wù)的SA,兩個階段協(xié)商的側(cè)重有所不同,第一階段主要確認(rèn)雙方身份的正確性,第二階段則是為興趣流創(chuàng)建一個指定的安全套件,其最顯著的結(jié)果就是第二階段中的興趣流在會話中是密文。

IPSec中安全性還體現(xiàn)在第二階段SA永遠是單向的:#p#

 

從上圖可以發(fā)現(xiàn),在協(xié)商第二階段SA時,SA是分方向性的,發(fā)起方到響應(yīng)方所用SA和響應(yīng)放到發(fā)起方SA是單獨協(xié)商的,這樣做的好處在于即使某個方向的SA被破解并不會波及到另一個方向的SA。這種設(shè)計類似于雙向車道設(shè)計。

IPSec雖然只是5個字母的排列組合,但其所涉及的協(xié)議功能眾多、方案又極其靈活,本期主要介紹IPSec的基本原理,在后續(xù)專欄還會繼續(xù)介紹IPSec的其它方面知識。。

【編輯推薦】

  1. IPSec VPN的詳細介紹
  2. 最簡環(huán)境下的IPsec VPN配置舉例
  3. IPsec VPN基礎(chǔ):IPsec VPN相關(guān)概念與協(xié)議
  4. 采用積極模式并PSK的IPsec VPN配置
  5. IP MPLS VPN安全嗎?
責(zé)任編輯:Writer 來源: baidu
相關(guān)推薦

2019-04-30 08:15:31

2012-01-12 14:37:34

jQuery

2009-02-24 09:43:00

IP電話原理

2016-08-18 00:04:09

網(wǎng)絡(luò)爬蟲抓取系統(tǒng)服務(wù)器

2010-08-20 13:29:33

OFDM

2013-04-07 14:09:55

Android應(yīng)用基本

2019-11-28 10:45:28

ZooKeeper源碼分布式

2020-03-21 14:57:14

手機定位智能手機APP

2016-08-17 23:53:29

網(wǎng)絡(luò)爬蟲抓取系統(tǒng)

2021-02-08 21:40:04

SockmapBPF存儲

2020-12-29 16:55:44

ZooKeeper運維數(shù)據(jù)結(jié)構(gòu)

2011-07-07 14:10:21

Cocoa 內(nèi)省 hash

2009-06-11 09:56:09

MySQL Repli原理

2010-03-17 13:35:02

2011-07-07 14:46:10

Cocoa Xcode

2010-03-18 20:13:03

Java socket

2010-06-18 17:28:37

Linux Anacr

2010-01-07 09:53:09

Winform多線程編

2012-09-28 10:12:55

2020-11-26 13:54:03

容器LinuxDocker
點贊
收藏

51CTO技術(shù)棧公眾號