工作中需要，參考網上的資料對IPSecVPN進行學習，並通過博客記錄下一些知識點作為學習記錄和后續復習的材料。
Transport Layer (TLS)
其中主要參考了以下文檔：
http://www.h3c.com.cn/Service/Channel_Service/Operational_Service/ICG_Technology/201005/675214_30005_0.htm
1、定義
IPSec VPN即指采用IPSec協議來實現遠程接入的一種VPN技術，IPSec全稱為Internet Protocol Security，是由Internet Engineering Task Force (IETF) 定義的安全標准框架，用以提供公用和專用網絡的端對端加密和驗證服務。
IPSEC協議通過包封裝技術，能夠利用Internet可路由的地址，封裝內部網絡的IP地址，實現異地網絡的互聯
IPSec是一個框架協議，直接構建在IP層之上，具體協議由AH和ESP組成，ESP協議號50，AH協議號51，它們都沒有類似於UDP/TCP端口號的概念，因此也就沒有NAT復用標識，ESP要穿越NAT還需要想其它辦法，而AH則因為保護源IP地址的關系，在NAT穿越中屬於天生無法支持。
2、應用場景
1、Site-to-Site（網關到網關），三個有安全要求的組織分布在不同地理位置上，但需要安全通信，則使用Site-to-Site網關實現內網中的多個PC或者服務器之間的通信。
2、End-to-End (端到端）：兩個PC之間的通信由IPSec會話保護，即在本地封裝。
3、End-to-Site （PC到網關）：兩個PC之間的通信由網關和異地PC之間的IPSec會話保護。
3、封裝模式
3.1 封裝模式和加密協議
傳輸（Transport）模式和隧道（Tunnel）模式，均可以使用兩種協議來加密。
1. AH協議（Authentication Header，使用較少）：可以同時提供數據完整性確認、數據來源確認、防重放等安全特性；AH常用摘要算法（單向Hash函數）MD5和SHA1實現該特性。
2. ESP協議（Encapsulated Security Payload，使用較廣）：可以同時提供數據完整性確認、數據加密、防重放等安全特性；ESP通常使用DES、3DES、AES等加密算法實現數據加密，使用MD5或SHA1來實現數據完整性。
3.2 兩種封裝模式和兩種加密協議的結構
傳輸（Transport）模式的封裝結構（上面是AH，下面是ESP） 隧道模式的封裝結構（上面是AH，下面是ESP）
3.2.1. 兩個封裝模式的區別
1. 傳輸模式在AH、ESP處理前后IP頭部保持不變，主要用於End-to-End的應用場景。
傳輸模式下end-to-end中的兩端必須都使用公網IP。
2. 隧道模式則在AH、ESP處理之后再封裝了一個外網IP頭，主要用於Site-to-Site的應用場景。
隧道模式雖然可以適用於任何場景，但是隧道模式需要多一層IP頭（通常為20字節長度）開銷，所以在PC到PC的場景，建議還是使用傳輸模式。
3.2.2. 兩種加密算法的區別
1. AH（Authentication Header）協議僅對數據和報頭生成AH認證頭摘要，對數據沒有進行加密，明文傳輸數據
2. ESP（Encapsulated Security Payload）協議首先對數據進行加密，生成了ESP加密后的數據，然后再作ESP摘要，傳輸過程中數據是加密的。
4、隧道建立過程
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。這種設計類似於雙向車道設計。
要點：
5、如何建立隧道
解決了Ip地址動態尋址的問題，現在來說一下Nat穿越的問題。我們知道，Udp和TCP是可以穿越防火牆的。直接的IPsec封裝，不能穿越防火牆，因為防火牆需要更改端口信息，這樣回來的數據包，才能轉到正確的內部主機。用UDP顯然比較合適，因為使用tcp的話，不僅三次握手占據時間很長，而且還有來回的確認。而實際上，這些工作屬於ipsec內部封裝的報文要干的事情，放在這里完成是不合適的。因此，用udp來封裝ipsec報文，以穿越nat，幾乎是唯一可以選擇的方案。
6、遺留問題