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

IPSec VPN應用場景

IPSec VPN的應用場景分為3種：

1. Site-to-Site（站點到站點或者網關到網關）：如彎曲評論的3個機構分布在互聯網的3個不同的地方，各使用一個商務領航網關相互建立VPN隧道，企業內網（若干PC）之間的數據通過這些網關建立的IPSec隧道實現安全互聯。

2. End-to-End（端到端或者PC到PC）：兩個PC之間的通信由兩個PC之間的IPSec會話保護，而不是網關。

3. End-to-Site（端到站點或者PC到網關）：兩個PC之間的通信由網關和異地PC之間的IPSec進行保護。

VPN只是IPSec的一種應用方式，IPSec其實是IP Security的簡稱，它的目的是為IP提供高安全性特性，VPN則是在實現這種安全特性的方式下產生的解決方案。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 VPN的場景和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/32、目的是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的協商過程：