IPSec ×××基本原理(圖解)

IPSec ×××是目前×××技術中點擊率很是高的一種技術，同時提供×××和信息加密兩項技術，這一期專欄就來介紹一下IPSec ×××的原理。
IPSec ×××應用場景

IPSec ×××的應用場景分爲3種：
1.
Site-to-Site（站點到站點或者網關到網關）：如彎曲評論的3個機構分佈在互聯網的3個不一樣的地方，各使用一個商務領航網關相互創建×××隧道，企業內網（若干PC）之間的數據經過這些網關創建的IPSec隧道實現安全互聯。
2.
End-to-End（端到端或者PC到PC）： 兩個PC之間的通訊由兩個PC之間的IPSec會話保護，而不是網關。
3.
End-to-Site（端到站點或者PC到網關）：兩個PC之間的通訊由網關和異地PC之間的IPSec進行保護。
×××只是IPSec的一種應用方式，IPSec實際上是IP Security的簡稱，它的目的是爲IP提供高安全性特性，×××則是在實現這種安全特性的方式下產生的解決方案。IPSec是一個框架性架構，具體由兩類協議組成：
1.
AH協議（Authentication Header，使用較少）：能夠同時提供數據完整性確認、數據來源確認、防重放等安全特性；AH經常使用摘要算法（單向Hash函數）MD5和SHA1實現該特性。
2.
ESP協議（Encapsulated Security Payload，使用較廣）：能夠同時提供數據完整性確認、數據加密、防重放等安全特性；ESP一般使用DES、3DES、AES等加密算法實現數據加密，使用MD5或SHA1來實現數據完整性。
爲什麼AH使用較少呢？由於AH沒法提供數據加密，全部數據在傳輸時以明文傳輸，而ESP提供數據加密；其次AH由於提供數據來源確認（源IP地址一旦改變，AH校驗失敗），因此沒法穿越NAT。固然，IPSec在極端的狀況下能夠同時使用AH和ESP實現最完整的安全特性，可是此種方案極其少見。
IPSec封裝模式介紹完IPSec ×××的場景和IPSec協議組成，再來看一下IPSec提供的兩種封裝模式（傳輸Transport模式和隧道Tunnel模式）

上圖是傳輸模式的封裝結構，再來對比一下隧道模式：

能夠發現傳輸模式和隧道模式的區別：
1.
傳輸模式在AH、ESP處理先後IP頭部保持不變，主要用於End-to-End的應用場景。
2.
隧道模式則在AH、ESP處理以後再封裝了一個外網IP頭，主要用於Site-to-Site的應用場景。
從上圖咱們還能夠驗證上一節所介紹AH和ESP的差異。下圖是對傳輸模式、隧道模式適用於何種場景的說明。

從這張圖的對比能夠看出：
1.
隧道模式能夠適用於任何場景
2.
傳輸模式只能適合PC到PC的場景
隧道模式雖然能夠適用於任何場景，可是隧道模式須要多一層IP頭（一般爲20字節長度）開銷，因此在PC到PC的場景，建議仍是使用傳輸模式。
爲了使你們有個更直觀的瞭解，咱們看看下圖，分析一下爲什麼在Site-to-Site場景中只能使用隧道模式：

如上圖所示，若是發起方內網PC發往響應方內網PC的流量知足網關的興趣流匹配條件，發起方使用傳輸模式進行封裝：
1.
IPSec會話創建在發起方、響應方兩個網關之間。
2.
因爲使用傳輸模式，因此IP頭部並不會有任何變化，IP源地址是192.168.1.2，目的地址是10.1.1.2。
3.
這個數據包發到互聯網後，其命運註定是杯具的，爲何這麼講，就由於其目的地址是10.1.1.2嗎？這並非根源，根源在於互聯網並不會維護企業網絡的路由，因此丟棄的可能性很大。
4.
即便數據包沒有在互聯網中丟棄，而且幸運地抵達了響應方網關，那麼咱們期望響應方網關進行解密工做嗎？憑什麼，的確沒什麼好的憑據，數據包的目的地址是內網PC的10.1.1.2，因此直接轉發了事。
5.
最杯具的是響應方內網PC收到數據包了，由於沒有參與IPSec會話的協商會議，沒有對應的SA，這個數據包沒法解密，而被丟棄。
咱們利用這個反證法，巧妙地解釋了在Site-to-Site狀況下不能使用傳輸模式的緣由。而且提出了使用傳輸模式的充要條件：興趣流必須徹底在發起方、響應方IP地址範圍內的流量。好比在圖中，發起方IP地址爲6.24.1.2，響應方IP地址爲2.17.1.2，那麼興趣流能夠是源6.24.1.2/3二、目的是2.17.1.2/32，協議能夠是任意的，假若數據包的源、目的IP地址稍有不一樣，對不起，請使用隧道模式。
IPSec協商

IPSec除了一些協議原理外，咱們更關注的是協議中涉及到方案制定的內容：
1.
興趣流：IPSec是須要消耗資源的保護措施，並不是全部流量都須要IPSec進行處理，而須要IPSec進行保護的流量就稱爲興趣流，最後協商出來的興趣流是由發起方和響應方所指定興趣流的交集，如發起方指定興趣流爲192.168.1.0/24à10.0.0.0/8，而響應方的興趣流爲10.0.0.0/8à192.168.0.0/16，那麼其交集是192.168.1.0/24à10.0.0.0/8，這就是最後會被IPSec所保護的興趣流。
2.
發起方：Initiator，IPSec會話協商的觸發方，IPSec會話一般是由指定興趣流觸發協商，觸發的過程一般是將數據包中的源、目的地址、協議以及源、目的端口號與提早指定的IPSec興趣流匹配模板如ACL進行匹配，若是匹配成功則屬於指定興趣流。指定興趣流只是用於觸發協商，至因而否會被IPSec保護要看是否匹配協商興趣流，可是在一般實施方案過程當中，一般會設計成發起方指定興趣流屬於協商興趣流。
3.
響應方：Responder，IPSec會話協商的接收方，響應方是被動協商，響應方能夠指定興趣流，也能夠不指定（徹底由發起方指定）。
4.
發起方和響應方協商的內容主要包括：雙方身份的確認和密鑰種子刷新週期、AH/ESP的組合方式及各自使用的算法，還包括興趣流、封裝模式等。
5.
SA：發起方、響應方協商的結果就是曝光率很高的SA，SA一般是包括密鑰及密鑰生存期、算法、封裝模式、發起方、響應方地址、興趣流等內容。
咱們以最多見的IPSec隧道模式爲例，解釋一下IPSec的協商過程：

上圖描述了由興趣流觸發的IPSec協商流程，原生IPSec並沒有身份確認等協商過程，在方案上存在諸多缺陷，如沒法支持發起方地址動態變化狀況下的身份確認、密鑰動態更新等。伴隨IPSec出現的IKE（Internet Key Exchange）協議專門用來彌補這些不足：
1.
發起方定義的興趣流是源192.168.1.0/24目的10.0.0.0/8，因此在接口發送發起方內網PC發給響應方內網PC的數據包，可以得以匹配。
2.
知足興趣流條件，在轉發接口上檢查SA不存在、過時或不可用，都會進行協商，不然使用當前SA對數據包進行處理。
3.
協商的過程一般分爲兩個階段，第一階段是爲第二階段服務，第二階段是真正的爲興趣流服務的SA，兩個階段協商的側重有所不一樣，第一階段主要確認雙方身份的正確性，第二階段則是爲興趣流建立一個指定的安全套件，其最顯著的結果就是第二階段中的興趣流在會話中是密文。
IPSec中安全性還體如今第二階段SA永遠是單向的：

從上圖能夠發現，在協商第二階段SA時，SA是分方向性的，發起方到響應方所用SA和響應放到發起方SA是單獨協商的，這樣作的好處在於即便某個方向的SA被破解並不會波及到另外一個方向的SA。這種設計相似於雙向車道設計。
IPSec雖然只是5個字母的排列組合，但其所涉及的協議功能衆多、方案又極其靈活，本期主要介紹IPSec的基本原理，在後續專欄還會繼續介紹IPSec的其它方面知識。

轉自：http://bbs.51cto.com/viewthread.php?tid=1119459