ipsecvpn是VPN技術中一種點擊率很高的技術。它還提供VPN和信息加密。本專欄將介紹IPSecVPN的原理。
IPSecVPN有三種應用場景：
1.站點到站點（站點到站點或網關到網關）：例如，這三個組織分布在互聯網的三個不同位置，每個組織使用業務試點網關彼此建立VPN隧道，企業內部網（多臺PC）之間的數據可以通過這些網關建立的IPSec隧道進行安全互連。
2.端到端（端到端或PC到PC）：兩臺PC之間的通信由兩臺PC之間的IPSec會話保護，而不是由網關保護。
3.端到站點（端到站點或PC到網關）：網關和遠程PC之間的通信受IPSec保護。
VPN只是IPSec的一種應用模式。IPSec實際上是IP安全的縮寫。其目的是為IP提供高安全性功能。VPN是通過實現此安全功能而生成的解決方案。IPSec是一種框架體系結構，由兩種類型的協議組成：
1、Ah協議（認證頭，較少使用）：可同時提供數據完整性確認、數據源確認、反重放等安全功能；ah通常使用摘要算法（單向散列函數）MD5和SHA1來實現此功能。
2、ESP協議（廣泛使用）：可同時提供數據完整性確認、數據加密、防重放等安全功能；ESP通常使用DES、3DES、AES等加密算法實現數據加密，使用MD5或SHA1實現數據完整性。
為什么ah使用較少？因為ah不能提供數據加密，所以所有數據都以明文傳輸，而ESP提供數據加密；其次，ah不能跨越NAT，因為它提供了數據源確認（一旦源IP地址更改，ah驗證就會失敗）。當然，在極端情況下，IPSec可以使用ah和ESP實現最完整的安全功能，但這種方案非常罕見。
IPSec封裝模式
在介紹了IPSecVPN的場景和IPSec協議的組成之后，我們來看看IPSec（傳輸模式和隧道模式）提供的兩種封裝模式。
上圖顯示了傳輸模式的封裝結構，然后比較隧道模式：
傳輸模式和隧道模式之間的差異可以發現：
1.傳輸方式在ah和ESP處理前后保持IP報頭不變，主要用于端到端應用場景。
2.隧道模式封裝ah和ESP處理后的外部IP報頭，主要用于點對點應用場景。
從上圖中，我們還可以驗證上一節介紹的ah和ESP之間的差異。下圖描述了傳輸模式和隧道模式適用于哪些場景。
從這個數字的比較中可以看出：
1.隧道模式可應用于任何場景
2.傳輸模式僅適用于PC到PC的場景
盡管隧道模式可以應用于任何場景，但隧道模式需要額外的IP報頭層（長度通常為20字節），因此建議在PC到PC場景中使用傳輸模式。
為了讓妳有一個更直觀的理解，讓我們看看下面的圖來分析為什么隧道模式只能在站點到站點場景中使用：
如上圖所示，如果發起方內網PC發送到響應方內網PC的流量滿足網關的興趣流匹配條件，則發起方使用傳輸方式進行封裝：
1.在發起方和響應方之間建立IPSec會話。
2.由于使用了傳輸模式，IP報頭不會改變。IP源地址為192.1681.2，目標地址為10.11.2
3.當這個數據包被發送到互聯網后，它的命運注定是一個杯子。為什么這么說，因為它的目標地址是10.1.2？這不是根本原因。根本原因是互聯網沒有維護企業網絡的路由，因此很可能被丟棄。
4.即使數據包沒有在互聯網上被丟棄，并且幸運地到達了響應者網關，我們是否期望響應者網關對其進行解密？哎呀，真的沒有好的證件。數據包的目標地址是intranetPC1.2的10.1，因此直接轉發它。
5.最重要的是，響應者的內聯網PC收到了數據包。由于未參與IPSec會話的協商會議，且沒有相應的SA，該數據包無法解密并被丟棄。
我們使用這種反證法巧妙地解釋了在站點到站點的案例中無法使用傳輸模式的原因。提出了采用傳輸方式的充要條件：感興趣的流必須完全在發起方和響應方的IP地址范圍內。例如，在圖中，啟動器的IP地址為6.241.2。響應者的IP地址為2.171.2，則興趣流可以是源6.241.2/32。目的是2.171.2/32，協議可以是任意的。如果數據包的源IP地址和目標IP地址略有不同，對不起，請使用隧道模式。
IPSec協商
除了IPSec的一些協議原則外，我們更關注協議中與方案制定相關的內容：
1.興趣流：IPSec是一種需要消耗資源的保護措施。并非所有流量都需要IPSec處理，但需要IPSec保護的流量稱為興趣流。最終協商的興趣流是發起方和響應方指定的興趣流的交集。例如，發起者指定的興趣流是192.1681.0/24á10.0。0.0/8，而受訪者的利息流為10.00.0/8á192.168。0.0/16，則其交點為192.1681.0/24乘以10.0。0.0/8，這是受IPSec保護的最后一個興趣流。
2.啟動器：啟動器，IPSec會話協商的觸發器。IPSec會話通常由指定的興趣流觸發。觸發過程通常是將數據包中的源、目標地址、協議、源和目標端口號與預先指定的IPSec興趣流匹配模板（如ACL）匹配。如果匹配成功，則它屬于指定的興趣流。指定的利息流僅用于觸發協商。它是否受IPSec保護取決于它是否匹配協商興趣流。然而，在一般實現過程中，通常設計為發起方指定興趣流屬于協商興趣流。
3.響應者：響應者，IPSec會話協商的接收者。回應者是被動談判。響應者可以指定興趣流，也可以不指定（完全由發起人指定）。
4.發起方與響應方協商的內容主要包括：雙方身份確認和密鑰種子刷新周期、ah/ESP組合模式及其各自算法、興趣流、封裝模式等。
5.Sa：發起方和響應方協商的結果是高暴露的Sa。SA通常包括密鑰和密鑰生存期、算法、封裝模式、發起方、響應方地址、興趣流等。
我們以最常見的IPSec隧道模式為例來說明IPSec的協商過程：
上圖描述了由興趣流觸發的IPSec協商過程。原始IPSec沒有身份確認和其他協商過程。該方案存在許多缺陷，如當啟動器地址發生動態變化時，無法支持身份確認和密鑰動態更新。帶IPSec的Ike（Internet密鑰交換）協議專門用于彌補這些缺點：
1.發起方定義的興趣流為source192.1681.0/24purpose10.00.0/8，因此從發起方的內聯網PC發送到響應方的內聯網PC的數據包可以在接口處進行匹配。
2.如果滿足利息流條件，且轉發界面上SA不存在、到期或不可用，則進行協商。否則，當前SA將用于處理數據包。
3.談判過程通常分為兩個階段。第一階段是服務于第二階段，第二階段是服務于利益流的真正SA。這兩個階段的重點是不同的。第一階段主要是確認雙方身份的正確性，第二階段是為興趣流創建指定的安全套件，最重要的結果是第二階段的興趣流是對話中的密文。