目錄
協議概述
IP Sec全稱：IP Security
IPSec協議，不是一個單獨的協議，而是一系列為IP網絡提供完整安全性的協議和服務的集合。
IPSec協議是一個工作在IP網絡層的協議
作為一個隧道協議實現了VPN通信
第三層隧道協議，可以在IP層上創建一個安全的隧道，使兩個異地的私有網絡連接起來，或者使公網上的計算機可以訪問遠程的企業私有網絡。
2、IPSec作用
1、保證數據來源可靠
在IPSec通信之前雙方要先用IKE認證對方身份並協商密鑰，只有IKE協商成功之后才能通信。由於第三方不可能知道驗證和加密的算法以及相關密鑰，因此無法冒充發送方，即使冒充，也會被接收方檢測出來。
2、保證數據完整性
IPSec通過驗證算法保證數據從發送方到接收方的傳送過程中的任何數據篡改和丟失都可以被檢測。
3、保證數據機密性
IPSec通過加密算法使只有真正的接收方才能獲取真正的發送內容，而他人無法獲知數據的真正內容
3、認證方式
3.1、預共享密鑰
預共享密鑰認證是IPSec雙方配置時手工指定的密鑰，無需在網絡中互相告知密鑰
3.2、數字證書
- 響應端發送數字證書到客戶端
- 發送端收到響應端的數字證書后，會取出附帶的數字證書，並讀取證書中的發布機構（Issuer），然后從操作系統的受信任證書機構列表中查找該證書辦發機構的公鑰，如果找不到，說明這個證書頒發機構是個不受信任的，響應端發過來的信息是不安全的。
- 使用上一步取到的證書頒發機構的公鑰，解出數字證書，得到響應端的用戶信息和數字簽名
- 發送端通過證書中指定的加密算法對響應端的用戶信息進行hash加密
- 加密后的結果和證書中解出的數字簽名進行對比，如果相同，就說明這份用戶信息確實是響應端的，也就是說用戶信息中包含的公鑰確實是響應端的
- 后續響應端使用私鑰加密數據，發送端使用公鑰解密。
- 發送端使用公鑰加密，響應端使用私鑰解密
4、ESP加密算法
4.1、ESP完整性檢測
ESP報文最后有一個驗證數據字段，數據驗證字段包含完整性校驗值 (ICV)，也稱為消息身份驗證碼，用於驗證消息身份驗證與完整性。接收方計算 ICV 值並對照發送方計算的值校驗它，以驗證完整性。ICV 是通過 ESP 報頭、負載數據與 ESP 尾端計算的。
4.2、ESP防重放
作為可選功能，ESP還能進行防重放保護。防重放保護驗證每個報文是唯一的且沒有被復制，這種保護確保黑客不能攔截報文和在數據流中插入改變后的報文。
防重放的工作原理：
- 跟蹤報文順序號並在目的端使用一個滑動窗口。當在源和目的間建立了一條連接時，兩端的計數器被初始化為0。
- 每次有報文發送時，源給報文追加一個順序號，目的端使用滑動窗口確定預期的順序號。目的端驗證的報文的順序號不是復制的，並且以正確的順序被接收。
例：
1、客戶端發送ESP封裝報文到服務端，序列號為81
2、服務端響應報文通過ESP加密，響應報文的序列號為81
3、客戶端收到服務端發送的ESP報文后，查看ESP序列號，序列號排序正確則沒有重放，排序錯誤則出現重放。
4.3、ESP防竊聽
ESP通過3DES、DES、AES機密算法加密數據，做到防竊聽功能
5、IPSec工作原理
ESP有兩種模式：隧道模式和傳輸模式。
隧道模式將發送的整個數據報文作為一個數據整體來處理，在整段數據前加上新的IP進行傳輸，不修改原報文。
對於傳輸模式而言，需要拆解報文，對原報文的數據部分進行處理，加上ESP頭部后，再裝上原報文的IP部分。
5.1、傳輸模式
ESP處理流程：
1、 將原IP報文的IP頭和數據報文部分分離，在數據報文部分的尾部添加ESP尾部。ESP尾部包含：選擇的加密算法需要對明文進行填充的數據Padding、填充長度Padding Length、下一頭部Next Header標注被加密的數據報文類型，例如TCP協議。
2、 對第一步得到的整體信息（原數據報文和ESP尾部）進行加密。具體的加密算法以及密鑰由SA給出。
3、對第二步得到的已經加密的信息添加ESP頭部(SPI和序列號)，組裝成Enchilada。
4、對第三步得到的Enchilada做摘要，得到完整性度量結果(ICV)，附加在Enchilada尾部
5、在第四步得到的數據前加上原IP頭，將原IP頭中的Protocol中的值改成50，代表ESP
5.2、隧道模式
ESP處理流程：
1. 在原IP報文末尾添加尾部(ESP trailer)信息。如上圖所示,尾部包含三部分。由所選加密算法可能是塊加密,那么當最后一塊長度不夠時就需要進行填充(padding),附上填充長度(Pad length)方便解包時順利找出用來填充的那一段數據。而Next header則用來標明被加密的數據報文的類型，例如TCP協議。
2. 將原IP報文以及第1步得到的ESP尾部作為一個整體進行加密。具體的加密算法與密鑰由SA給出。
3. 為第2步得到的加密數據添加ESP頭部。如上圖所示,ESP頭由兩部分組成,SPI和序號(Sequence number)。加密數據與ESP頭合稱為“enchilada”。
4. 附加完整性度量結果(ICV,Integrity check value)。對第三步得到的“enchilada”做摘要,得到一個完整性度量值,並附在ESP報文的尾部。
5. 加上新的IP頭。新構造的IP頭附在ESP報文的前面組成一個新的IP報文。注意這個新的IP頭的目的地址跟源地址可以不一樣。協議類型為50,說明它里面裝的是一個IPsec報文。
- IPSec協商模式
IPSec建立分為兩個階段，第一接端為IKE協商，第二階段為IPSec協商。
6.1、主動模式
6.1.1、Ikev1協商
包1：發起端協商SA，使用的是UDP協議，端口號是500，上層協議是ISAKMP，該協議提供的是一個框架，里面的負載Next payload類似模塊，可以自由使用。可以看到發起端提供了自己的cookie值，以及SA的加密套件，加密套件主要是加密算法，哈希算法，認證算法，生存時間等。
- Initiator SPI：b0b5887b632a532b
發起者的SPI值，告知響應端主機要使用IPSEC的哪一把密鑰來加密這個封包。
- Responder SPI：
響應者的SPI值，第一個包只有發起者沒有響應者所以響應者的SPI為空
- Version：1.0
IKE版本號，1.0表示使用ikev1建立連接
- Exchange type:Identity Protection (Main Mode) (2)
IKE協商模式為主模式
- IKE Attribute (t=12,l=4): Life-Duration: 86400
密鑰周期86400，密鑰周期超過86400后會重新協商IKE
- IKE Attribute (t=1,l=2): Encryption-Algorithm: DES-CBC
IKE使用DES-CBC加密算法加密數據
- IKE Attribute (t=2,l=2): Hash-Algorithm: MD5
IKE使用MD5算法校驗數據完整性
- IKE Attribute (t=3,l=2): Authentication-Method: Pre-shared key
使用預共享密鑰認證
- IKE Attribute (t=4,l=2): Group-Description: Alternate 1024-bit MODP group
Diffie-Hellman (DH) 組在密鑰交換進程中使用的1024 bit的密鑰的強度。
包2：響應端收到發送端發送的加密套件后，對比自己是否有相對應的加密套件，如果有就使用和發送端相同的加密套件加密數據，把自己的cookie值和選擇好的加密套件發送給發送端；如果沒有相同加密套件則IKE建立失敗響應。
- Initiator SPI：b0b5887b632a532b
發送端的SPI值，告知響應端主機要使用IPSEC的哪一把密鑰來加密這個封包。
- Responder SPI：e5dd838c8d5138b9
響應者的SPI值，告知發送端使用哪一把密鑰加密數據包
- Version：1.0
IKE版本號，1.0表示使用ikev1建立連接
- Exchange type:Identity Protection (Main Mode) (2)
IKE協商模式為主模式
- IKE Attribute (t=12,l=4): Life-Duration: 86400
密鑰周期86400，密鑰周期超過86400后會重新協商IKE
- IKE Attribute (t=1,l=2): Encryption-Algorithm: DES-CBC
IKE使用DES-CBC加密算法加密數據
- IKE Attribute (t=2,l=2): Hash-Algorithm: MD5
IKE使用MD5算法校驗數據完整性
- IKE Attribute (t=3,l=2): Authentication-Method: Pre-shared key
使用預共享密鑰認證
- IKE Attribute (t=4,l=2): Group-Description: Alternate 1024-bit MODP group
Diffie-Hellman (DH) 組在密鑰交換進程中使用的1024 bit的密鑰的強度。
包3：發送端生成隨機數和DH公共值，包3的主要目的是向響應端發送自己的DH公共值和Nonce隨機數。用於生成加密時所需要的KEY值。
- Version：1.0
IKE版本號，1.0表示使用ikev1建立連接
- Exchange type:Identity Protection (Main Mode) (2)
IKE協商模式為主模式
- Key Exchange Data: aba538345be9d5bfa1dff1e169b2db2a72d3771038f4cc8e...
DH公共值，DH公共值通過Diffie-Hellman算法計算出來；在包1和包2中所協商的算法，它們必須需要一個相同的KEY（即，共享密鑰中設置的密碼），但同時這個KEY不能在鏈路中傳遞。所以，該過程的目的是分別在兩個對等體間獨立地生成一個DH公共值，然后在報文中發送給對端，對端通過公式計算出相同的KEY值
包4：響應端收到包3后，自己生成一個隨機數，然后通過Diffie-Hellman算法計算出DH公共值，把隨機數和DH公共值傳輸給發送端。
- Version：1.0
IKE版本號，1.0表示使用ikev1建立連接
- Exchange type:Identity Protection (Main Mode) (2)
IKE協商模式為主模式
- Key Exchange Data：74d204991cd082a20289989380d3b953e1505fc21af6bafc...
DH公共值，用於生成加密時所需要的KEY值
包5：發起方發起身份驗證，報文中帶有認證的數據（預共享密鑰或者數字簽名）。由於包1和包2已經協商好了加密算法，包3和包4協商好了加密的KEY值，所以包5的消息被加密了。
- Version：1.0
IKE版本號，1.0表示使用ikev1建立連接
- Exchange type:Identity Protection (Main Mode) (2)
IKE協商模式為主模式
包6：響應端回應報文，同樣發送認證的數據（預共享密鑰或者數字簽名），驗證對方身份信息。包6的數據同樣使用包1、包2協商的算法和包3、包4協商的key值加密數據，所以包6的認證數據是加密的。雙方身份驗證通過后，IKE協商結束。
- Version：1.0
IKE版本號，1.0表示使用ikev1建立連接
- Exchange type:Identity Protection (Main Mode) (2)
IKE協商模式為主模式
6.1.2、IPSec加密協商
包7：發起方主要是進行IPSEC SA的協商，建立安全聯盟，報文內容主要是協商用的封裝方式以及后面的加密算法以及生存時間和感興趣流等等。由於數據加密所以無法查看。
- Initiator SPI：b0b5887b632a532b
發起者的SPI值是由上階段IKE協商時已經確定的，所以IPSec協商依然使用上階段的SPI
- Responder SPI：e5dd838c8d5138b9
響應者的SPI值是由上階段IKE協商時已經確定的，所以IPSec協商依然使用上階段的SPI
- Version：1.0
IKE版本號，1.0表示使用ikev1建立連接
- Exchange type：Quick Mode（32）
交換類型使用快速模式，IPSec協商時只有快速模式
包8：響應方回包，同意包7發送的封裝方式、加密算法、生存時間、感興趣流等等，同時，也能起到確認收到對端消息的作用。由於數據加密所以無法查看。
- Version：1.0
IKE版本號，1.0表示使用ikev1建立連接
- Exchange type：Quick Mode（32）
交換類型使用快速模式，IPSec協商時只有快速模式
包9：發送確認報文。其中包含一個HASH，其作用是確認接收方的消息以及證明發送方處於主動狀態（表示發送方的第一條消息不是偽造的）。由於數據加密所以無法查看。
- Version：1.0
IKE版本號，1.0表示使用ikev1建立連接
- Exchange type：Quick Mode（32）
交換類型使用快速模式，IPSec協商時只有快速模式
6.2、野蠻模式
野蠻模式使用3個報文進行交換加密方式等消息
- 發起端協商SA，發起端提供了自己的cookie值，以及SA的傳輸集
- 響應端收到后，會將自己的sa協商消息附上簽名認證信息后發回給sa的發起者
- 發起端發送自己的數字簽名認證等信息
野蠻模式無論是共享密鑰認證還是證書認證都支持NAT穿越
7、IPsec穿越NAT
7.1、IPSec穿越NAT遇到的問題
1、穿越NAT后的身份確認問題
IPSec VPN中標准身份標識是IP地址，NAT處理過程中會改變IP地址，因此IPSec的身份確認機制必須能夠適應IP地址變化；
解決此問題的方法主要有兩種：第一種是使用數字證書替代IP地址作為身份標識，第二種是使用字符串取代IP地址作為身份標識。
2、IP地址復用
IPSec由AH和ESP兩個協議組成。
因為AH對數據進行完整性檢查，會對包括IP地址在內的整個IP包進行Hash運算。而NAT會改變IP地址，從而破壞AH的Hash值。因此AH報文無法通過NAT網關。
ESP對數據進行完整性檢查，不包括外部的IP頭，IP地址轉換不會破壞ESP的Hash值。但ESP報文中TCP的端口已經加密無法修改，所以對於同時轉換端口的NAT來說，ESP沒法支持。
7.2、IKE身份確認及協商
IPSec的身份確認最常見是通過IKE協議代勞，IKE支持的身份認證機制有兩種：
1、數字證書方式，通過CA數字證書體系確認身份，是最為安全、可靠的方式。
2、身份標識+預共享密鑰方式，通過發起方和響應方預先配置相同的密鑰，如bigtree，完成雙方對彼此身份的認證，這是最為常見的方式；在預共享秘密鑰認證機制中，身份標識則可以分為幾類：
a> 指定IP地址，使用IP地址作為身份標識，是IKE的默認方式，響應方只允許指定IP地址發起協商，安全性比較高；
認證成功：
認證失敗：
b> 指定IP地址范圍，這種方式依然使用IP地址作為身份標識，由於發起方必須要指定IP地址，否則無法發起協商，指定IP地址范圍是響應方特性，如響應方可以指定2.0.0.0/8范圍內的地址都可以發起協商，而不是只允許2.1.1.2發起協商，能夠減少配置，但安全性略有下降；
認證成功：
認證失敗：
c> 什么都不指定，也是使用IP地址作為身份標識，但允許任意IP地址發起協商，只要預共享密鑰一致，雙方就能夠通過身份確認，這種方式雖然不是非常安全，但是可以簡化配置，安全性再次下降；
認證成功：
認證失敗：
d> 指定對端名字，發起方和響應方都預先配置好本端名字，使用該名字作為身份標識，與指定IP地址類似，通過指定對端名字方式，即使雙方預共享密鑰一致，只要對端名字不合法，立即中斷協商，由於名字未與IP地址進行綁定，而且名字在網絡中明文傳遞，故安全性不如指定IP地址方式高，但這種身份標識方式可以穿越NAT。
認證成功：
認證失敗：
7.3、穿越NAT原理抓包解釋
1. 開啟NAT穿越時，IKEv1協商第一階段的前兩個消息會發送標識NAT穿越（NAT Traversal，簡稱NAT-T）能力的Vendor ID載荷（主模式和野蠻模式都是）。用於檢查通信雙方是否支持NAT-T。
當雙方都在各自的消息中包含了該載荷時，才會進行相關的NAT-T協商。
2. 主模式消息3和消息4（野蠻模式消息2和消息3）中發送NAT-D（NAT Discovery）載荷。NAT-D載荷用於探測兩個要建立IPSec隧道的網關之間是否存在NAT網關以及NAT網關的位置。
通過協商雙方向對端發送源和目的的IP地址與端口的Hash值，就可以檢測到地址和端口在傳輸過程中是否發生變化。若果協商雙方計算出來的Hash值與它收到的Hash值一樣，則表示它們之間沒有NAT。否則，則說明傳輸過程中對IP或端口進行了NAT轉換。
第一個NAT-D載荷為對端IP和端口的Hash值，第二個NAT-D載荷為本端IP和端口的Hash值。
3. 發現NAT網關后，后續ISAKMP消息（主模式從消息5、野蠻模式從消息3開始）的端口號轉換為4500。ISAKMP報文標識了“Non-ESP Marker”。
4. 在第二階段會啟用NAT穿越協商。在IKE中增加了兩種IPSec報文封裝模式：UDP封裝隧道模式報文（UDP-Encapsulated-Tunnel）和UDP封裝傳輸模式報文（UDP-Encapsulated-Transport）通過為ESP報文封裝UDP頭，當封裝后的報文通過NAT設備時，NAT設備對該報文的外層IP頭和增加的UDP頭進行地址和端口號轉換。UDP報文端口號修改為4500。
