一、基本原理介紹：
IPSec VPN是目前VPN技術中點擊率較高的一種技術，同時提供VPN和信息加密兩項技術，這一期專欄就來介紹一下IPSec VPN的原理。
一.IPSec VPN應用場景
1.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實現最完整的安全特性，但是此種方案極其少見。
2.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源地址是92.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地址稍有不同，對不起，請使用隧道模式。
3.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。這種設計類似于雙向車道設計。
二、案例分析：
1、拓撲
2、要求：
1．R2、R3、R4 模擬運營商網絡，運行 ISIS 協議。
2．R1、R5 分別模擬企業網的邊界路由器，其分別具備公網 IP 地址 12.1.1.1/24 和 45.1.1.5/24。
3． R1、R5 之間配置 IPSEC，保證企業數據可以通過加密安全傳輸。
4. R1、R5 背后的企業網可以正常訪問 Internet。
3、配置
1．基本配置（省略）。
2．在 R2、R3、R4 上配置 ISP 網絡。
① R3 上的配置
② R2 上的配置
③ R4 上的配置
配置完成之后，在 R3 上查看 ISIS 鄰居關系。
使用 R2 的 e0/0 接口測試 R4 的 e0/1 接口，查看公網路由的連通性。
可以看到公網路由完好。
3. 企業邊界路由器 R1、R5 上的配置
① R1 上配置Gre Tunnel
在配置 Gre Tunnel 前，必須保證企業邊界路由器 R1、R5 之間的互通，并且要保證企業內的PC 可以正常訪問 ISP 的公網，所以在 R1 和 R5 上配置缺省路由。
② R5 上配置Gre Tunnel
此時在 R1 和 R5 上測試 tunnel 的連通性。
③ 在 R1 和 R5 上配置 NAT 功能
因為企業網內部的 PC 要訪問 ISP 上的公網，并且不需要加密，故需配置NAT 功能。
配置完 NAT 后，在 R1 上使用 loopback 訪問 ISP 網絡地址。
④ R1、R5 上配置 loopback0 互訪的路由，用于模擬企業網中的 PC 互訪，亦即需要加密的流量部分。
此時再測試 R1、R5 的 loopback0 的連通性。
此時說明 R1、R5 背后的企業網可以互通，我們下面對其進行加密。
⑥ R1 上的 IPSEC 配置
⑦ R5 上的 IPSEC 配置
此時 IPSEC 配置完成。
4、測試
① 測試 R1、R5 背后的企業網互訪時是否加密。
明顯看到 R1、R5 背后的企業網互訪時是加密的。
② 測試 R1、R5 背后的企業網訪問 ISP 網絡時是否加密。
由于要 R5 的 e0/1 上進行了 NAT 轉換，故抓包時使用的是 R5 的 e0/1 接口上的地址做為源地址。
③ 使用 R1 的 loopback0 訪問 R5 的公網地址（即 R5 的 e0/1 接口）。
明顯看到 R1 背后的企業網訪問另一側的邊界路由器 R5 的公網 IP 時，還是加密的。
從抓包中可以看，企業網內部的 PC 訪問公網中的任何地址時，不會對流量加密。
至此，帶 NAT 功能的 IPSEC 配置完成，并且保證了該加密的流量，不該加密的不加密，綜合考慮了效率和安全的需求。
最后思考：為什么可以在 GRE OVER IPSEC 中可以帶上 NAT？
因為當 R1 背后的企業網訪問公網中時，經過 NAT 轉換，源 IP 地址轉換為 R1 的公網 IP— —12.1.1.1/24，而目標地址卻為公網中的 IP 地址，即并非為 R5 側的企業網地址 5.5.5.0/24，故不會被訪問控制列表 R1TOR5 抓取，這樣就不會被加密。
而當 R1 背后的企業網訪問 R5 背后的企業網時，則由于 R1 上定義了去往 R5 背后企業網的靜態路由Ip route 5.5.5.0 255.255.255.0 tunnel 15 。故該流量會走 tunnel15，而走 tunnel15 時，必會帶上 GRE 頭部和 tunnel15 的源、目地址，即會加上 R1 的 e0/0 和 R5 的 e0/1 地址，這樣，就會被 R1TOR5 抓取，這樣就會進行加密。
