密鑰管家IKE登場
上回說到手工方式的IPSec VPN幫助天地會解決了總舵和分舵之間祕密通信的問題，但隨着分舵數量的增加新的問題又出現了。手工方式下防火牆的加密和驗證所使用的密鑰都是手工配置的，爲了保證IPSec VPN的長期安全，需要經常修改這些密鑰。分舵數量越多，密鑰的配置和修改工作量越大。隨着天地會的壯大，IPSec VPN的維護管理工作越來越讓人吃不消了。
爲了降低IPSec VPN管理工作量，天地會總舵主再訪高人尋求靈丹妙藥。靈丹已練，妙藥天成——原來IPSec協議框架中早就考慮了這個問題——智能的密鑰管家IKE（Internet Key Exchange）協議可以幫助解決這個問題。IKE綜合了三大協議：ISAKMP（Internet Security Association and Key Management Protocol）、Oakley協議和SKEME協議。ISAKMP主要定義了IKE夥伴（IKE Peer）之間合作關係（IKE SA，跟IPSec
SA類似）的建立過程。Oakley協議和SKEME協議的核心是DH（Diffie-Hellman）算法，主要用於在Internet上安全地分發密鑰、驗證身份，以保證數據傳輸的安全性。有了IKE加盟，IPSec VPN的安全和管理問題不再困擾天地會，各地分舵申請建立VPN的流程終於可以進入“實施”狀態了。
揭開ISAKMP本來面目
IKE協議的終極目標是通過協商在總舵和分舵之間動態建立IPSec SA，並能夠實時維護IPSec SA。爲建立IPSec SA而進行的IKE協商工作是由ISAKMP報文來完成的，所以在部署IKE之前，強叔先領大家認識一下ISAKMP報文。ISAKMP報文封裝如下：
IP報文頭
- 源地址src：本端發起IKE協商的IP地址，可能是接口IP地址，也可能是通過命令配置的IP地址。
- 目的IP地址Dst：對端發起IKE協商的IP地址，由命令配置。
UDP報文頭
IKE協議使用端口號500發起協商、響應協商。在總舵和分舵都有固定IP地址時，這個端口在協商過程中保持不變。當總舵和分舵之間有NAT設備時（NAT穿越場景），IKE協議會有特殊處理（後續揭祕）。
ISAKMP報文頭
- Initiator’s Cookie（SPI）和responder’s Cookie（SPI）：在IKEv1版本中爲Cookie，在IKEv2版本中Cookie爲IKE的SPI，唯一標識一個IKE SA。
- Version：IKE版本號1。
- Exchange Type：IKE定義的交互類型2。交換類型定義了ISAKMP消息遵循的交換順序。
- Next Payload：標識消息中下一個載荷的類型。一個ISAKMP報文中可能裝載多個載荷，該字段提供載荷之間的“鏈接”能力。若當前載荷是消息中最後一個載荷，則該字段爲0。
- Type Payload：載荷類型，ISAKMP報文攜帶的用於協商IKE SA和IPSec SA的“參數包”。載荷類型有很多種，不同載荷攜帶的“參數包”不同。不同載荷的具體作用我們後面會結合抓包過程逐一分析。
說明：
1：IKE誕生以來，有過一次大的改進。老的IKE被稱爲IKEv1，改進後的IKE被稱爲IKEv2。二者可以看做是父子關係，血脈相承，基本功能不變；但青勝於藍，後者有了長足的進步。
2：IKEv1版本中可以在交換類型字段查看協商模式，階段1分爲兩種模式：主模式和野蠻模式，階段2採用快速模式。主模式是主流技術，野蠻模式是爲解決現實問題而產生的。IKEv2版本中定義了查看創建IKE SA和CHILD SA（對應IKEv1的IPSec SA）的IKE_SA_INIT、IKE_AUTH（創建第一對CHILD SA）、CREATE_CHILD_SA（創建後續的CHILD SA）。
IKEv1和IKEv2的精華之處正是本文的重點，各位看官莫急，容強叔一一道來。
IKEv1小試牛刀
IKE最適合於在總舵和衆多分舵之間建立IPSec VPN的場景，分舵越多IKE的優勢越能凸顯。爲了講解方便，這裏僅給出總舵和一個分舵之間建立IPSec VPN的組網圖。
相比手工方式，IKE方式僅增加了兩步：配置IKE安全提議和IKE對等體。IKE安全提議主要用於配置建立IKE SA用到的加密和驗證算法。IKE對等體主要配置IKE版本、身份認證和交換模式。
|
配置項 |
網關A |
網關B |
|
IKE安全提議 |
ike proposal 10 |
ike proposal 10 |
|
IKE對等體 |
ike peer b ike-proposal 10 undo version 2 //IKEv1 exchange-mode main//主模式（缺省） remote-address 2.2.3.2//對端發起IKE協商的地址 pre-shared-key tiandihui2 |
ike peer a ike-proposal 10 undo version 2 //IKEv1 exchange-mode main//主模式（缺省） remote-address 1.1.1.1//對端發起IKE協商的地址 pre-shared-key tiandihui2 |
|
ACL |
acl number 3001 rule 5 permit ip source 192.168.0.0 0.0.0.255 destination 172.16.2.0 0.0.0.255 |
acl number 3000 rule 5 permit ip source 172.16.2.0 0.0.0.255 destination 192.168.0.0 0.0.0.255 |
|
IPSec安全提議 |
ipsec proposal a transform esp encapsulation-mode tunnel esp authentication-algorithm md5 esp encryption-algorithm des |
ipsec proposal a transform esp encapsulation-mode tunnel esp authentication-algorithm md5 esp encryption-algorithm des |
|
IPSec安全策略 |
ipsec policy policy1 11 isakmp security acl 3001 proposal a ike-peer b |
ipsec policy policy1 1 isakmp security acl 3000 proposal a ike-peer a |
|
應用IPSec安全策略 |
interface GigabitEthernet0/0/1 ip address 1.1.1.1 255.255.255.0 ipsec policy policy1 |
interface GigabitEthernet0/0/1 ip address 2.2.3.2 255.255.255.0 ipsec policy policy1 |
說明：兩條紅色命令表示本例採用了IKEv1版本主模式。缺省同時開啓IKEv1和IKEv2，關閉IKEv2後採用IKEv1版本進行協商。
配置完成之後，總舵和分舵之間有互訪數據流時即可觸發建立IPSec VPN隧道，下面強叔通過抓包來爲大家詳解一下IKEv1的精妙之處。
IKEv1招式拆解
IKEv1版本分兩個階段來完成動態建立IPSec SA的任務：
階段1-建立IKE SA：階段1採用主模式或野蠻模式協商。
階段2-建立IPSec SA：階段2此採用快速模式協商。
下面先介紹主模式+快速模式下的IPSec SA建立過程。
階段1-建立IKE SA（主模式）
主模式下IKEv1採用3個步驟6條ISAKMP消息建立IKE SA。下面以網關A主動發起IKE協商爲例進行講解。
1. 協商IKE安全提議。
協商分兩種情況：
- 發起方的IKE Peer中引用了IKE Proposal
- 發起方的IKE peer中沒有引用IKE Proposal
二種情況下響應方都會在自己配置的IKE安全提議中尋找與發送方相匹配的IKE安全提議，如果沒有匹配的安全提議則協商失敗。IKE Peer雙方安全提議匹配的原則爲協商雙方有相同的加密算法、認證算法、身份認證方法和DH組標識（不包括IKE SA生存週期）。
說明：通過IKEv1協議協商建立IPSec安全聯盟時，採用本地生存週期和對端生存週期中較小的一個，不必保證隧道兩端設備配置的生存週期相同（sa duration）。
通過抓包可以看出ISAKMP消息的SA載荷中攜帶用於協商的IKE安全提議。以消息1爲例：
2. 使用DH算法交換密鑰材料，並生成密鑰。
網關A和B利用ISAKMP消息的Key Exchange和nonce載荷交換彼此的密鑰材料。Key Exchange用於交換DH公開值，nonce用於傳送臨時隨機數。由於DH算法中IKE Peer雙方只交換密鑰材料，並不交換真正的共享密鑰，所以即使黑客竊取了DH值和臨時值也無法計算出共享密鑰，這一點正是DH算法的精髓所在。從抓包中可以看到IKE Peer雙方交換密鑰材料，以消息3爲例：
密鑰材料交換完成後，IKE Peer雙方結合自身配置的身份驗證方法各自開始複雜的密鑰計算過程（預共享密鑰或數字證書都會參與到密鑰計算過程中），最終會產生三個密鑰：
- SKEYID_a：ISAKMP消息完整性驗證密鑰——誰也別想篡改ISAKMP消息了，只要消息稍有改動，響應端完整性檢查就會發現！
- SKEYID_e：ISAKMP消息加密密鑰——再也別想竊取ISAKMP消息了，竊取了也看不懂！
以上兩個密鑰保證了後續交換的ISAKMP消息的安全性！
- SKEYID_d：用於衍生出IPSec報文加密和驗證密鑰——最終是由這個密鑰保證IPSec封裝的數據報文的安全性！
整個密鑰交換和計算過程在IKE SA超時時間的控制下以一定的週期進行自動刷新，避免了密鑰長期不變帶來的安全隱患。
3. 身份認證
IKE Peer通過兩條ISAKMP消息（5、6）交換身份信息，進行身份認證。目前有兩種身份認證技術比較常用：
- 預共享密鑰方式（pre-share）：設備的身份信息爲IP地址或名稱。
- 數字證書方式：設備的身份信息爲證書和通過證書私鑰加密的部分消息Hash值（俗稱簽名）。
以上身份信息都由SKEYID_e進行加密，所以在抓包中我們只能看到標識爲“Encrypted”的ISAKMP消息，看不到消息的內容（身份信息）。以消息5爲例：
預共享密鑰是最簡單、最常用的身份認證方法。這種方式下設備的身份信息可以用IP地址或名稱（包括FQDN和USER-FQDN兩種形式）來標識。當IKE Peer兩端都有固定IP地址的時候，一般都用IP地址作爲身份標識；當一端爲動態獲取IP地址的時候，沒有固定IP地址的一端只能用名稱來標識。本篇強叔給大家展示的案例爲前者，後者晚些再講。
這裏有個小問題提醒大家關注：
總舵收到分舵1發來的身份信息後，需要用密鑰（SKEYID_a和SKEYID_e）進行完整性驗證和解密，只有先找到正確的預共享密鑰才能計算出這兩個密鑰。但總舵網關爲每個IKE Peer都配置了一個預共享密鑰。怎麼找呢？此時只能根據IKE Peer發來的ISAKMP報文的源IP地址（src）來查找預共享密鑰，只要報文源地址與本端IKE Peer視圖下remote-address命令配置的IP地址一致，就認爲該視圖下配置的pre-shared-key是分舵1的預共享密鑰。
以上是IPSec協議內部處理過程，不需要大家操心。大家只要記住在IKE Peer兩端都有固定IP地址的場景下，remote-address命令配置的IP地址要跟對端發起IKE協商的IP地址保持一致即可。這個IP地址的作用不僅僅是指定了隧道對端的IP地址，還參與了預共享密鑰的查找。
階段1協商完成後，進入階段2。
階段2-建立IPSec SA
在階段2中IKEv1採用快速交換模式通過3條ISAKMP消息建立IPSec SA。由於快速交換模式使用IKEv1階段1中生成的密鑰SKEYID_e對ISAKMP消息進行加密，所以我們抓到的報文都是加密的，看不到載荷裏面的具體內容。故下面只能文字介紹一下每一步的作用。
下面以網關A發起IPSec協商爲例進行講解。
1. 發起方發送IPSec安全提議、被保護的數據流（ACL）和密鑰材料給響應方。
2. 響應方迴應匹配的IPSec安全提議、被保護的數據流，同時雙方生成用於IPSec SA的密鑰。
IPSec對等體兩端協商IPSec安全提議的過程跟協商IKE安全提議的過程類似，不再贅述。
IKEv1不協商ACL規則，建議兩端設備配置的ACL規則互爲鏡像，避免IPSec SA協商失敗。
IPSec對等體兩端交換密鑰材料（SKEYID_d、SPI和協議1、nonce等參數），然後各自進行密鑰計算生成用於IPSec SA加密驗證的密鑰，這樣可以保證每個IPSec SA都有自己獨一無二的密鑰。由於IPSec SA的密鑰都是由SKEYID_d衍生的，一旦SKEYID_d泄露將可能導致IPSec VPN受到侵犯。爲提升密鑰管理的安全性，IKE提供了PFS（完美向前保密）功能。啓用PFS後，在進行IPSec SA協商時會進行一次附加的DH交換，重新生成新的IPSec
SA密鑰，提高了IPSec SA的安全性。
說明：1、協議指AH和/或ESP協議。
3. 發起方發送確認結果。
協商完成後發送方開始發送IPSec（ESP）報文。
檢查IPSec VPN狀態信息
以總舵顯示信息爲例。
- 在總舵和分舵上查看IKE SA的建立情況。
<FW_A> display ike sa
current ike sa number: 2
---------------------------------------------------------------------
conn-id peer flag phase vpn
---------------------------------------------------------------------
40129 2.2.3.2 RD|ST v1:2 public
40121 2.2.3.2 RD|ST v1:1 public
這裏統一顯示了IKE SA（v1:1）和IPSec SA（v1:2）的狀態，RD表示SA狀態爲READY。IKE Peer之間只有一個IKE SA，IKE SA是雙向邏輯連接（不區分源和目的）。 - 在總舵和分舵上查看IPSec SA的建立情況。
<FW_A> display ipsec sa brief
current ipsec sa number: 2
current ipsec tunnel number: 1
---------------------------------------------------------------------
Src Address Dst Address SPI Protocol Algorithm
---------------------------------------------------------------------
1.1.1.1 2.2.3.2 4090666525 ESP E:DES;A:HMAC-MD5-96;
2.2.3.2 1.1.1.1 2927012373 ESP E:DES;A:HMAC-MD5-96;
IPSec SA是單向的（區分源和目的），兩個方向的IPSec SA共同組成一條IPSec隧道。
說明：一般來說一條數據流對應一個IPSec SA。但當IPSec同時採用了ESP+AH封裝時，一條數據流會對應兩個IPSec SA。 - 在總舵和分舵上查看會話表。
<FW_A > display firewall session table
11:01:45 2014/07/08
Current Total Sessions : 6
esp VPN:public --> public 1.1.1.1:0-->2.2.3.2:0
icmp VPN:public --> public 172.16.2.2:7264-->192.168.0.2:2048
icmp VPN:public --> public 172.16.2.2:7520-->192.168.0.2:2048
icmp VPN:public --> public 172.16.2.2:7776-->192.168.0.2:2048
icmp VPN:public --> public 172.16.2.2:8032-->192.168.0.2:2048
icmp VPN:public --> public 172.16.2.2:8288-->192.168.0.2:2048
防火牆會爲IPSec VPN建立了會話表（1.1.1.1:0-->2.2.3.2:0）。
下面簡單介紹一下野蠻模式
配置命令exchange-mode aggressive即可將IKEv1的協商模式改爲野蠻模式。抓包看一下野蠻模式的情況：
野蠻模式只用了3條ISAKMP消息就完成了階段1的協商過程，階段2仍舊是快速模式不變。
發起方和響應方把IKE安全提議、密鑰相關信息和身份信息一股腦地全放在一個ISAKMP消息中發送給對方，IKE協商效率提高了。但由於身份信息是明文傳輸，沒有加密和完整性驗證過程，IKE SA的安全性降低了。既然這樣不夠安全，爲什麼野蠻模式還會出現？
在IPSec VPN出現的早期，由於主模式+預共享密鑰身份認證方式下，IPSec需要通過對端的IP地址來在本地查找預共享密鑰（主模式中已經詳細解釋了這個問題）。這種密鑰查找方式在對端沒有固定IP地址的情況下（比如IPSec NAT穿越場景，網絡出口動態獲取IP地址場景）行不通。此時，野蠻模式可以“野蠻”地解決這個問題。野蠻模式中“身份信息”沒有加密，IPSec就直接用對端發送來的身份信息來查找預共享密鑰即可。所以在IPSec VPN應用初期，野蠻模式主要用於解決沒有固定IP地址的節點部署IPSec VPN的問題。現在，IPSec
VPN解決這個問題有很多方法，不安全的野蠻模式已經不是最好的選擇了。具體方法待後續再呈現給大家。
IKEv2應運而生
IKEv1似乎已經很完美了，但用得久了仍舊會發現不盡人意之處。
- 協商建立IPSec SA的時間太長
IKEv1主模式協商一對IPSec SA，需要6（協商IKE SA）+3（協商IPSec SA）=9條消息。
IKEv1野蠻模式協商一對IPSec SA，需要3（協商IKE SA）+3（協商IPSec SA）=6條消息。
- 不支持遠程用戶接入
IKEv1不能對遠程用戶進行認證。若想支持遠程用戶接入，只能藉助L2TP，通過PPP來對遠程用戶進行AAA認證。
這些問題怎麼解決呢？辦法總比問題多！IKEv2中完美的解決了這些問題。
IKEv2相比IKEv1：
- 協商建立IPSec SA的速度大大提升
正常情況IKEv2協商一對IPSec SA只需要2（協商IKE SA）+2（協商IPSec SA）=4條消息。後續每建立一對IPSec SA只會增加2條消息。 - 增加了EAP（Extensible Authentication Protocol）方式的身份認證。
IKEv2通過EAP協議解決了遠程接入用戶認證的問題，徹底擺脫了L2TP的牽制。目前IKEv2已經廣泛應用於遠程接入網絡中了。今天強叔只介紹IKEv2的基本協商過程，EAP認證留待後續再講。
IKEv2的配置思路與IKEv1完全相同，只是細節稍有不同：
說明：紅色命令與IKEv1不同。缺省情況下，防火牆同時開啓IKEv1和IKEv2協議。本端發起協商時，採用IKEv2，接受協商時，同時支持IKEv1和IKEv2。可以不關閉IKEv1。
IKEv2協商IPSec SA的過程跟IKEv1有很大差別：
1. 初始交換4條消息同時搞定IKE SA和IPSec SA。
初始交換包括IKE安全聯盟初始交換（IKE_SA_INIT交換）和IKE認證交換（IKE_AUTH交換）。
第一個消息對（IKE_SA_INIT）：負責IKE安全聯盟參數的協商，包括IKE Proposal，臨時隨機數（nonce）和DH值。
SA載荷主要用來協商IKE Proposal。
KE（Key Exchange）載荷和Nonce載荷主要用來交換密鑰材料。
IKEv2通過IKE_SA_INIT交換後最終也生成三類密鑰：
SK_e：用於加密第二個消息對。
SK_a：用於第二個消息對的完整性驗證。
SK_d：用於爲Child SA（IPSec SA）衍生出加密材料。
第二個消息對（IKE_AUTH）：負責身份認證，並創建第一個Child SA（一對IPSec SA）。
目前三種身份認證技術比較常用：
- 預共享密鑰方式（pre-share）：設備的身份信息爲IP地址或名稱。
- 數字證書方式：設備的身份信息爲證書和通過證書私鑰加密的部分消息Hash值（簽名）。
- EAP方式：採用EAP認證的交換過程屬於擴展交換的內容，將在後面講解。
以上身份信息都通過SKEYID_e加密。
創建Child SA時，當然也要協商IPSec安全提議、被保護的數據流。IKEv2通過TS載荷（TSi和TSr）來協商兩端設備的ACL規則，最終結果是取雙方ACL規則的交集（這點跟IKEv1不同，IKEv1沒有TS載荷不協商ACL規則）。
當一個IKE SA需要創建多對IPSec SA時，例如兩個IPSec對等體之間有多條數據流的時候，需要使用創建子SA交換來協商後續的IPSec SA。
2. 子SA交換2條消息建立一對IPSec SA。
子SA交換必須在IKE初始交換完成之後才能進行，交換的發起者可以是IKE初始交換的發起者，也可以是IKE初始交換的響應者。這2條消息由IKE初始交換協商的密鑰進行保護。
IKEv2也支持PFS功能，創建子SA交換階段可以重新進行一次DH交換，生成新的IPSec SA密鑰。
IKEv1和IKEv2大PK
IKEv1和IKEv2的細節寫了這麼多，現在總結一下二者的異同點吧：
|
功能項 |
IKEv1 |
IKEv2 |
|
IPSec SA建立過程 |
分兩個階段，階段1分兩種模式：主模式和野蠻模式，階段2爲快速模式。 主模式+快速模式需要9條信息建立IPSec SA。 野蠻模式+快速模式需要6條信息建立IPSec SA。 |
不分階段，最少4條消息即可建立IPSec SA。 |
|
ISAKMP |
二者支持的載荷類型不同 |
|
|
認證方法 |
預共享密鑰 數字證書 數字信封（較少使用） |
預共享密鑰 數字證書 EAP 數字信封（較少使用） |
|
IKE SA完整性算法 |
不支持 |
支持 |
|
PFS |
支持 |
支持 |
|
遠程接入 |
通過L2TP over IPSec來實現 |
支持 |
顯然IKEv2以其更加快捷、更加安全的服務勝出，長江後浪推前浪又成爲了沒有任何懸念的事實。
IPSec協議框架總結
安全協議（AH和ESP）、加密算法（DES、3DES、AES）、驗證算法（MD5、SHA1、SHA2）、IKE、DH，好多的縮寫，大家搞清楚他們之間的關係了麼？強叔做了一下總結，看看能否幫助大家：l 安全協議（AH和ESP）——IP報文的安全封裝。穿上AH或/和ESP馬甲的IP報文稱爲IPSec報文。此“馬甲”並非一般的馬甲，是交織了“加密”和“驗證”算法的刀槍不入的“軟蝟甲”。
說明：AH封裝的驗證範圍實際要還更大一些，包括新的IP頭。
l 加密算法（DES、3DES、AES）——IPSec報文的易容之術。IPSec數據報文采用對稱加密算法進行加密，但只有ESP協議支持加密，AH協議不支持。另外，IKE協商報文也會進行加密。
l 驗證（MD5、SHA1、SHA2）——IPSec報文的驗明正身之法。加密後的報文經過驗證算法處理生成數字簽名，數字簽名填寫在AH和ESP報文頭的完整性校驗值ICV字段發送給對端；在接收設備中，通過比較數字簽名進行數據完整性和真實性驗證。
l IKE——手握密鑰管理大權的貼心管家。IPSec使用IKE協議在發送、接收設備之間安全地協商密鑰、更新密鑰。
l DH算法——貼心管家的鐵算盤。DH被稱爲公共密鑰交換方法，它用於產生密鑰材料，並通過ISAKMP消息進行交換，並最終在收發兩端計算出加密密鑰和驗證密鑰。
這些概念一一梳理過來，強叔不得不感嘆IPSec協議設計者的強大——這麼多新的老的協議、算法拼接起來如此天衣無縫，自此Internet的險惡被屏蔽在隧道之外！爲了方便大家記憶這些縮寫，強叔用一張簡圖概括之：
寫到這裏，強叔心情舒暢，暗自爲天地會網絡的順利推動得意。可是問題又來了——將IKE應用於IPSec VPN之後，那些有固定公網IP地址的大中型分舵的通信問題很快就解決了。但一些小型分舵IP地址不固定或只有私網IP地址，用常規的IKE方式部署IPSec VPN行不通。這種情況下怎麼辦呢？別擔心，IKE的精彩之處還在於不出招則已、出招即能克敵；招招有戲、變化無窮，欲聽詳解請見下回分解。