IPsec是一套協議，為IP層的Internet通信提供安全性。IPsec的最常見用途是在兩個位置（網關到網關）之間或遠程用戶與企業網絡（主機到網關）之間提供虛擬專用網絡(VPN)。
IKE模式（第1階段）
主模式
當發起方向響應方發送建議或建議時，IKE會話開始。節點之間的首次交換建立了基本的安全策略；發起方提出了要使用的加密和身份驗證算法。響應方選擇適當的建議（我們假設已選擇建議）并將其發送給發起方。下一次交換會傳遞Diffie-Hellman公鑰和其他數據。所有進一步協商都在IKE SA內加密。第三個交換對ISAKMP會話進行身份驗證。建立IKE SA后，IPSec協商（快速模式）開始。
積極模式(野蠻模式)
主動模式將IKE SA協商壓縮為三個數據包，發起方傳遞SA所需的所有數據。響應方發送建議、密鑰材料和ID，并驗證下一個數據包中的會話。發起方回復并驗證會話。協商更快，且發起方和響應方ID以明文方式傳遞。
IPsec模式（第2階段）
快速模式
IPSec協商或快速模式類似于主動模式IKE協商，除協商外，必須在IKE SA內進行保護。快速模式會協商數據加密的SA并管理該IPSec SA的密鑰交換。
拓撲說明： R1和R3分別作為網關通過ISP 互通，各自內網要求通過IPSEC VPN互通
ISP配置
hostname isp
interface GigabitEthernet0/0
ip address 12.0.0.2 255.255.255.0
interface GigabitEthernet0/1
ip address 23.0.0.2 255.255.255.0
R1配置
hostname r1
interface Loopback0
ip address 192.168.1.1 255.255.255.255
//配置lo0模擬內網網段
interface GigabitEthernet0/0
ip address 12.0.0.1 255.255.255.0
ip route 0.0.0.0 0.0.0.0 12.0.0.2
access-list 100 permit ip host 192.168.1.1 host 172.16.1.1
//配置感興趣流
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
//配置IKE的策略加密方式認證方式DH算法
crypto isakmp key 0 cisco address 23.0.0.3
//配置與共享密鑰
crypto ipsec transform-set AA esp-3des esp-md5-hmac
//配置IPSEC轉換集加密驗證方式傳輸模式
crypto map aa 10 ipsec-isakmp
set peer 23.0.0.3
set transform-set AA
match address 100
//創建加密MAP，綁定IPSEC IKE，配置對等體，感興趣流，轉換集
interface GigabitEthernet0/0
crypto map aa
//接口應用IPSEC MAP
R3配置
hostname r3
interface Loopback0
ip address 172.16.1.1 255.255.255.255
interface GigabitEthernet0/0
ip address 23.0.0.3 255.255.255.0
ip route 0.0.0.0 0.0.0.0 23.0.0.2
access-list 100 permit ip host 172.16.1.1 host 192.168.1.1
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
crypto isakmp key 0 cisco address 12.0.0.1
crypto ipsec transform-set AA esp-3des esp-md5-hmac
crypto map aa 10 ipsec-isakmp
set peer 12.0.0.1
set transform-set AA
match address 100
conf t
interface GigabitEthernet0/0
crypto map aa
配置完成后檢查兩端配置
內網帶源Ping測正常
查看IKE sa 和IPSEC sa
配置排錯主要檢查：
1 雙方外網接口路由是否可達
2 雙方是否具有匹配的SA
3 雙發是否正確配置PSK
下午好，我的網工朋友。
IPSec算是比較復雜的協議之一了，對于很多朋友來說，大概是“熟悉又陌生”的。
熟悉是IPSec這個技術應該聽過很多次了，不管是在書中還是大佬聊天中，說用IPSec可以實現這個需求，保護數據的安全；
陌生則是并不知道IPSec具體是怎么工作的，為什么能夠保證到數據的安全性，又在工作中應用這么廣泛？
今天就給你梳理一遍，從基本原理到框架，再到加密算法、封裝協議等等，多個角度解析IPSec。文中還有幾個有趣圖解案例，給你加深理解哈。
今日文章閱讀福利：《 IPSec：新一代因特網安全標準.pdf 》
IPSec相關的經典好書，給你找來了完整的pdf書籍，可以轉存下。私信我，備注“IPSec”，限時獲取資源。
IPSec 是一項標準的安全技術，它通過在數據包中插人一個預定義頭部的方式，來保障 OSI 上層協議數據的安全。
IPSec 主要用于保護網絡層(IP)數據，因此它提供了網絡層的安全性。
它對 VPN 流量提供了如下3 個方面的保護：
如上圖所示，不難看出，IPSec 技術在原始IP 頭部和 IP 負載之間插入了一個IPSec 頭部，這樣可以對原始的IP負載實現加密，同時還可以實現對IPSec 頭部和原始IP 負載的驗證，以確保數據的完整性。
一些傳統的安全技術(如HTTPS)以及無線安全術(如WEP/WPA)，往往會采用某種固定的加密和散列函數。
這種做法帶有明顯的賭博性質，因為如果某天這個加密算法曝出嚴重漏洞，那么使用這個加密算法或者散列函數的安全技術也就難免要遭到淘汰。
為了避免這種在一棵樹上吊死的悲慘事件發生，IPSec 并沒有定義具體的加密和散列函數。
IPSec 的做法是提供一個框架性的結構，但每一次IPSec 會話所使用的具體算法，都是通過協商來決定的。
也就是說如果我們覺得 3DES 這個算法所提供的 168 位的加密強度能夠滿當的需要，那么就不妨暫且使用這個協議來加密數據。
但是只要有一天 3DES 出現了嚴重漏洞，或者出現了一個更好的加密協議，那么我們也可以馬上更換加密協議，使 IPSec VPN 總是使用最新最好的協議來進行加密。
下圖所示為 IPSec 框架示意圖：
這張圖在說明不僅僅是散列函數加密算法，還包括封裝協議和模式、密鑰有效期等內容都可以通過協商決定，在兩個IP Sec 對等體之間協商的協議叫做IKE，下面以 IPSec 框架涉及的技術為主線，詳細介紹這些技術的特點和工作原理。
散列函數也叫做 HASH 函數，主流的散列算法有 MD5與SHA-1。
散列函數的主要任務是驗證數據的完整性。
通過散列函數計算得到的結果叫做散列值，這個散列值也常常被稱為數據的指紋 (Fingerprint)。
如上圖所示：文件內容為111，通過MD5、SHA1算法之后，分別得到了不同的散列值。
01 散列函數特點
1.固定大小
散列函數可以接收任意大小的數據，并輸出固定大小的散列值。
以 MD5 這個散列算法為例，不管原始數據有多大，通過 MD5 算得到列值總 128 比特，而SHA-1的輸出長度則為 160 比特。
2.雪崩效應
原始數據就算修改哪怕一個比特，計算得到的散列值也會發生巨大的變化。
3.單向
只可能從原始數據計算得到散列值，不可能從散列值恢復哪怕一個比特的原始數據。
4.沖突避免
幾乎不能夠找到另外一個數據和當前數據計算的散列值相同，因此散列函數能夠確保數據的唯一性。
散列函數雖然能夠很好地確認數據的完整性，但是卻容易遭受中間人攻擊。合法與非法用戶都可以對他們發送的信息進行散列函數計算，并得到散列值。
因此他們也都能把文件和散列值一起打包發送給接收方，而接收方也都能夠通過散列函數來校驗數據的完整性。
散列函數雖然能夠確認數據的完整性，卻不能確保這個數據來自于可信的源(不提供源認證)，所以散列函數存在中間人攻擊的問題。
為了彌補這個漏洞，我們可以使用一個叫做密鑰化散列信息認證代碼 (HMAC Keyed-hash Message Authentication Code)的技術，這項技術不僅僅能夠實現完整性校驗，還能完成源認證的任務。
加密，顧名思義就是把明文數據轉換為密文數據。
這樣一來，即使第三方截獲到了密文數據，也無法將其恢復為明文。而解密過程則正好相反，合法的接收者通過正確的解密算法和密鑰恢復密文到明文。
加密算法可以分為如下兩大類:
01 對稱密鑰算法
上圖所示為對稱密鑰算法的工作示意圖，從圖中可以看到一個很明顯的特點：加解密雙方使用相同的密鑰與算法進行加解密。
因此，使用相同密鑰與算法進行加解密運算的算法就叫做對稱密鑰算法。
對稱密鑰算法有如下特點：
優點：速度快、安全、緊湊
缺點：
對稱密鑰算法的主流協議：
DES、3DES、AES、RC4
02 非對稱密鑰算法加密
在使用非對稱密鑰技術之前，所有參與者，不管是用戶還是路由器等網絡設備，都需要預先使用非對稱加密算法(如 RSA)產生一對密鑰。
非對稱加密需要4個密鑰。通信雙方各自準備一對公鑰和私鑰。
其中公鑰是公開的，由信息接受方提供給信息發送方。公鑰用來對信息加密。
私鑰由信息接受方保留，用來解密。公鑰是公開的，就不存在保密問題。
也就是說非對稱加密完全不存在密鑰配送問題！
03 案例：非對稱加、解密過程
假設小明想約小紅出來玩：
1、小明確定了自己的私鑰 mPrivateKey，公鑰 mPublicKey。自己保留私鑰，將公鑰mPublicKey發給了小紅；
2、小紅確定了自己的私鑰 hPrivateKey，公鑰 hPublicKey。自己保留私鑰，將公鑰 hPublicKey 發給了小明；
3、小明發送信息 “周六早10點T1樓下見”，并且用小紅的公鑰 hPublicKey 進行加密。
4、小紅收到信息后用自己的私鑰 hPrivateKey 進行解密。然后回復 “收到，不要遲到” 并用小明的公鑰mPublicKey加密。
5、小明收到信息后用自己的私鑰 mPrivateKey 進行解密。
以上過程是一次完整的request和response。
通過這個例子我們梳理出一次信息傳輸的非對稱加、解密過程：
1、消息接收方準備好公鑰和私鑰
2、私鑰接收方自己留存、公鑰發布給消息發送方
3、消息發送方使用接收方公鑰對消息進行加密
4、消息接收方用自己的私鑰對消息解密
通過私鑰加密的數據只能由公鑰解密，通過公鑰加密的數據只能由私鑰解密。由于加密和解密使用不同的密鑰，因此稱為非對稱加密。
04非對稱密鑰算法 實現數字簽名
非對稱密鑰算法的第二個用途就是實現數字簽名，為什么要簽名呢？
簽名的目的無非是對某一份文件進行確認。
例如，欠條。
張三欠李四 10000 元錢，欠款人張三在欠條上簽名確認。簽名的主要作用就是張三對這張欠條進行確認，事后不能抵賴(不可否認性)。
到底最后誰會看這個簽名呢？李四很明顯沒必要反復去確認簽名。
一般都是在出現糾紛后，例如，張三抵賴不還的時候，李四就可以把欠條拿出來，給法官這些有權威的第三方來進行驗證，如果他們確認此欠條上的簽名確實來自張三無疑，張三就不能再否認欠李四錢這一既定事實了。
我們來看看數字簽名是如何工作的：
步驟 1：重要明文信息通過散列函數計算得到散列值（明文）。
步驟 2：“用戶一”(發起者)使用自己的私鑰對步驟1計算的明文散列值進行加密，加密后的散列值就叫做數字簽名（密文）。
步驟3：把重要明文信息和數字簽名一起打包發送給“用戶二”(接收方)。
步驟4：“用戶二”從打包文件中提取出重要明文信息。
步驟5：“用戶二”使用和“用戶一”相同的散列函數對步驟4提取出來的重要明文信息計算散列值，得到的結果簡稱“散列值 1（明文）”。
步驟6：“用戶二”從打包文件中提取出數字簽名（密文）。
步驟7：“用戶二”使用預先獲取的“用戶一”的公鑰，對步驟6提取出的密文的數字簽名進行解密，得到明文的“散列值 2”。
步驟8：比較“散列值 1”和“散列值2”是否相等。如果相等，數字簽名校驗成功。
這樣說或許比較肝，接下來給你說個生動形象的案例，看完你就懂了。
05案例：數字簽名
1. 紅紅有兩把鑰匙，一把是公鑰，另一把是私鑰。
2. 紅紅把公鑰送給他的朋友們——帕蒂、道格、蘇珊——每人一把。
3. 蘇珊要給紅紅寫一封保密的信。她寫完后用紅紅的公鑰加密，就可以達到保密的效果。
4. 紅紅收信后，用私鑰解密，就看到了信件內容。這里要強調的是，只要紅紅的私鑰不泄露，這封信就是安全的，即使落在別人手里，也無法解密。
5. 紅紅給蘇珊回信，決定采用“數字簽名”。他寫完后先用Hash函數，生成信件的散列值（digest）。
6. 然后，紅紅使用私鑰，再對這個散列值（digest）加密，生成“數字簽名”（signature）。
7. 紅紅將這個簽名，附在信件下面，一起發給蘇珊。
8. 蘇珊收信后，取下“數字簽名”（signature），用紅紅的公鑰解密，得到信件的散列值1（digest 1）。由此證明，這封信確實是紅紅發出的。
9. 蘇珊再對信件本身使用Hash函數，將得到的散列值2（digest 2），與上一步得到的散列值1（digest 1）進行對比。如果兩者一致，就證明這封信未被修改過。
10. 復雜的情況出現了。道格想欺騙蘇珊，他偷偷使用了蘇珊的電腦，用自己的公鑰換走了紅紅的公鑰。此時，蘇珊實際擁有的是道格的公鑰，但是還以為這是紅紅的公鑰。
因此，道格就可以冒充紅紅，用自己的私鑰做成“數字簽名”，寫信給蘇珊，讓蘇珊用假的紅紅公鑰進行解密。
11. 后來，蘇珊感覺不對勁，發現自己無法確定公鑰是否真的屬于紅紅。
她想到了一個辦法，要求紅紅去找“證書中心”（certificate authority，簡稱CA），為公鑰做認證。證書中心用自己的私鑰，對紅紅的公鑰和一些相關信息一起加密，生成“數字證書”（Digital Certificate）。
12. 紅紅拿到數字證書以后，就可以放心了。以后再給蘇珊寫信，只要在簽名的同時，再附上數字證書就行了。
13. 蘇珊收信后，用CA的公鑰解開數字證書，就可以拿到紅紅真實的公鑰了，然后就能證明“數字簽名”是否真的是紅紅簽的。
看到這，你就完全明白了嗎？
非對稱密鑰算法有如下特點：
優點：更安全、不用擔心交換的公鑰被劫持、支持數字簽名和不可否認性
缺點：
非對稱密鑰算法的主流協議:
RSA (數字簽名和數字證書的主流協議)
DH (IPSec 產生密鑰資源的主要協議)
ECC (橢圓曲線算法)
由于上述缺點，與對稱密鑰算法一樣，在一套安全解決方案中不可能單獨使用非對稱密鑰算法。
那么我們應該如何利用對稱和非對稱密鑰算法的優勢來加密實際的數據呢？
下面來看一個巧妙的加密解決方案。
06巧妙的加密解決方案
對稱密鑰算法和非對稱密鑰算法，這兩種算法都各有其優缺點。
對稱密鑰算法加密速度快，但是密鑰數量過多不好管理，并且密鑰分發不安全。非對稱密鑰算法密鑰數量少，密鑰分發方便并且不存在安全隱患，但是加密速度奇慢，不可能用于大流量數據的加密。
所以在實際使用加密算法的時候，一般會讓兩種算法共同工作，發揮各自優點。
下面是一個非常巧妙的聯合對稱和非對稱算法的解決方案，這種解決問題的思路被大量運用到實際加密技術。
步驟1：“用戶一”(發起方)使用本地隨機數產生器，產生用于對稱密鑰算法的隨機密鑰，用于加密數據。
步驟2：使用步驟1產生的隨機密鑰，對重要的明文信息通過對稱密算法進行加密，并得到密文。
步驟3：“用戶一”(發送方)需要預先獲取“用戶二”(接收方)的公鑰，并且使用“用戶二”的公鑰對步驟1產生的隨機密鑰進行加密，得到加密的密鑰包。
步驟4：對步驟2和步驟3產生的密文和密鑰包一起發送給“用戶二（接收方）。
步驟5：“用戶二”首先提取出密鑰包，并且使用自己的私鑰對它進行解密，并得到明文的隨機密鑰。
步驟6：“用戶二”提取出密文，并且使用步驟5解密得到的隨機密鑰進行解密，得到明文的重要信息。
IP Sec有ESP和AH兩種封裝協議：
01ESP
ESP(Encapsulation Security Payload)的IP協議號為50，ESP能夠為數據提供私密性(加密)、完整性和源認證3大方面的保護，并且能夠抵御重放攻擊(反復發送相同的包，接收方由于不斷地解密消耗系統資源，實現拒絕服務攻擊(DOS))。
ESP 只能保護IP負載數據，不對原始 IP 頭部進行任何安全防護。
02AH
AH(Authentication Header) 的IP 協議號為 51，AH 只能夠為數據提供完整性和源認證兩方面的安全服務，并且抵御重放攻擊。AH 并不能為數據提供私密性服務，也就是說不加密，所以在實際部署IPSe VPN 的時候很少使用AH，絕大部分IPSec VPN都會使用 ESP 進行封裝。
AH不僅能保護IP負載數據，還能對原始 IP 頭部進行驗證。
當然 AH 不提供私密性服務，只是它不被廣泛采用的其中一個原因，另外一個原因是AH協議封裝的IPSec數據包不能穿越NAT。
IPSec有如下兩種數據封裝模式：
傳輸模式(Transport mode)
隧道模式(Tunnel mode)
01傳輸模式(Transport mode)
因為AH少使用所以封裝模式示意圖中我們都以ESP封裝協議為例來進行介紹。
傳輸模式實現起來很簡單，主要就是在原始 IP 頭部和 IP 負載(TCP頭部和應用層數據)之間插入一個ESP 頭部。當然ESP 還會在最后追加上ESP尾部和ESP驗證數據部分，并且對 IP負載和 ESP尾部進行加密和驗證處理，但原始 IP 頭部被完整地保留了下來。
02隧道模式(Tunnel mode)
隧道模式把原始 IP 數據包整個封裝到了一個新的 IP 數據包中，并且在新 IP 頭部和原始 IP 頭部中間插入了ESP 頭部，以此對整個原始IP 數據包進行了加密和驗證處理。
長期使用相同密鑰來加密數據是不明智的，應該周期性地更新密鑰，Cisco的IPSec VPN 用于加密實際數據的密鑰，默認每一個小時 (3600秒)就要更新一次。
Cisco的IPSec VPN 雖然默認每小時更換一次密鑰，但下一個小時使用的密鑰是由當前這個小時使用的密鑰，通過一系列的算法衍生得出的。也就是說這些密鑰之間存在推演關系。
這樣的密鑰更新就不能叫做完美向前保密 PFS(Prfect Forward Secrecy)。
PFS 要求每一次密鑰更新，都需要重新產生全新的密鑰，和以前使用的密鑰不存在任何衍生關系。
Cisco 的IPSec VPN一旦啟用了 PFS 技術，就會在每一個小時結束的時候，展開一次全新的 DH 交換算法，產生全新的密鑰用于下一個小時加密。
IPSec VPN需要預先協商加密協議、散列函數、封裝協議、封裝模式和密鑰有效期等內容。具體執行協商任務的協議叫做互聯網密交換協議 IKE。
IKE主要完成如下3個方面的任務：
協商完成后的結果就叫做安全關聯 SA，也可以說IKE 建立了安全關聯SA。
一共有兩種類型，一種叫做IKE SA，另一種叫做 IPSec SA。
ISAKMP是IKE的核心協議，所以經常會把IKE與ISAKMP 這兩個詞語換著使用。例如，IKE SA 也經常被說成ISAKMP SA。
在配置 IPSec VPN 的時候，主要的配置內容也是ISAKMP。SKEME 和Okley 沒有任何相關的配置內容。
如果一定要對IKE和ISAKMP進行區分的話，那么由于 SKEME 的存在，因此IKE 能夠決定密鑰交換的方式，但是ISAKMP只能夠為密鑰交換來交換數據包，但卻不能決定密鑰交換實現的方式。
IKE的2個階段與3個模式：
IKE協商分為兩個不同的階段：第一階段和第二階段。
第一階段協商分別可以使用 6 個包交換的主模式或者3個包交換的主動模式來完成，第一階段協商的主要目的就是對建立 IPSec 的雙方進行認證，以確保只有合法的對等體 (peer) 才能夠建立 IPSec VPN。協商得到的結果就是IKE SA。
第二階段總是使用 3 個包交換的快速模式來完成，第二階段的主要目的就是根據需要加密的實際流量(感興趣流)，來協商保護這些流量的策略。協商的結果就是IPSec SA。
整理：老楊丨10年資深網絡工程師，更多網工提升干貨，請關注公眾號：網絡工程師俱樂部