IPSec模板海納百川
自從天地會採用了IKE方式協商IPSec安全策略，IPSec配置和維護的工作量大減。然而之前天地會用過的手工方式IPSec安全策略或IKE方式IPSec安全策略都要求IPSec對端的IP固定。可是在公網IP幾近枯竭的Internet上要擁有一個固定的公網IP談何容易！天地會每次要申請一個固定公網IP地址都要大費周折。於是天地會提出疑問：配置IPSec VPN的通信雙方必須使用固定的公網IP地址嗎？
當然不是。下面強叔就給大家介紹一種新的IPSec安全策略：模板方式IPSec安全策略。
跟IKE方式IPSec安全策略一樣，模板方式IPSec安全策略也要依靠IKE協商IPSec隧道。模板方式IPSec安全策略最大的改進就是不要求對端IP地址固定：可以嚴格指定對端IP地址（單個IP），可以寬泛指定對端IP地址（IP地址段）也可以乾脆不指定對端IP（意味着對端IP可以是任意IP）。
模板方式IPSec安全策略就好像一員猛將，根本不把對端IP放在眼裏，什麼固定IP、動態地址、私網IP統統不在話下。只管放馬過來，來多少都照單全收。正因爲這種大將風範，模板方式IPSec安全策略特別適用於天地會總舵，用於響應衆多分舵的協商請求。且分舵數量越多越明顯：
- 採用IKE方式IPSec策略。總舵需要配置N個IPSec策略，N個IKE對等體。N=分舵數量
- 採用模板方式IPSec策略。總舵需要配置1個IPSec策略，一個IKE對等體。與N的取值無關。
總之，模板方式IPSec安全策略的兩大優點令他在IPSec陣營中始終保持明星地位：
- 對對端要求甚少，有固定IP或者沒有無所謂
- 配置簡單，只要配置一個IKE Peer即可
但明星也是有缺點的，這個缺點也可以說是模板方式IPSec安全策略“不拘小節”的地方：模板方式IPSec安全策略只能響應對端發起的協商請求，不能主動發起協商。
至此強叔已經介紹了三種IPSec安全策略：手工方式IPSec安全策略、IKE方式IPSec安全策略、模板方式IPSec安全策略。這三種IPSec安全策略都可以配置在一個IPSec安全策略組中。所謂IPSec安全策略組就是一組名稱相同的IPSec安全策略。在一個IPSec安全策略組中最多隻能存在一個模板方式IPSec安全策略，且其序號必須最大，即優先級最小。否則接入請求被模板接收了，優先級低的IKE方式IPSec策略則無法施展。切記！
分舵接入IP變，模板接收只等閒
總舵跟分舵1和分舵2之間建立IPSec VPN的組網圖如下所示。本圖中分舵1和分舵2的出接口採用動態方式獲取公網IP地址。要求在分舵1跟總舵、分舵2跟總舵之間建立IPSec隧道，分舵1跟分舵2之間也可以通過IPSec通信。
模板方式IPSec安全策略配置流程如下：
分舵2的配置與分舵1類似，請參考分舵1的配置。IKE安全提議和IPSec安全提議採用缺省配置（每個版本的缺省配置可能不同，請配置時注意）。
|
配置項 |
天地會總舵（採用模板方式IPSec策略） |
天地會分舵1（採用IKE方式IPSec策略） |
|
配置IKE安全提議 |
ike proposal 10 |
ike proposal 10 |
|
配置IKE對等體 |
ike peer a ike-proposal 10 pre-shared-key tiandihui1 //可以不配置remote-address，也可以通過remote-address指定IP地址段。 |
ike peer a ike-proposal 10 remote-address 1.1.1.1 pre-shared-key tiandihui1 |
|
ACL |
acl number 3000 rule 5 permit ip destination 172.16.1.0 0.0.0.255 rule 10 permit ip destination 172.16.2.0 0.0.0.255 //配置一條ACL： rule5允許分舵2和總舵訪問分舵1，source必須包括分舵2和總舵，destination爲分舵1。本例中不指定source，表明source可以爲分舵2也可以爲總舵或其他IP地址段。 rule10允許分舵1和總舵訪問分舵2，source必須包括分舵1和總舵，destination爲分舵2。本例中不指定source，表明source可以爲分舵1也可以爲總舵或其他IP地址段。
|
acl number 3000 rule 5 permit ip source 172.16.1.0 0.0.0.255 //允許分舵1訪問分舵2和總舵，source爲分舵1，destination爲分舵2和總舵。本例中不指定destination，表明source可以爲分舵2也可以爲總舵或其他IP地址段。 |
|
IPSec安全提議 |
ipsec proposal a |
ipsec proposal a |
|
IPSec安全策略 |
ipsec policy-template tem1 1 //配置IPSec策略模板 security acl 3000 proposal a ike-peer a ipsec policy policy1 12 isakmp template tem1//配置模板方式IPSec策略 |
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.2.2 255.255.255.0 ipsec policy policy1 auto-neg//配置auto-neg後，不需要流量觸發就直接建立IPSec隧道。 |
部署完成後進行驗證：
1. 在總舵IPSec網關上可以查看到總舵跟分舵1和分舵2都正常建立了第一階段和第二階段安全聯盟。
2. 分舵1、分舵2、總舵可以互相通信。
問題：若在接口上應用IPSec策略時不配置auto-neg參數，分舵1跟分舵2可以直接通信嗎？
1. 在分舵1和分舵2的網關取消接口上應用的IPSec策略後，重新應用時不配置auto-neg參數。由分舵1的PC2 ping分舵2的PC3，無法ping通。
2. 查看分舵1上安全聯盟的建立情況。
<FW_B> display ike sa
current ike sa number: 2
---------------------------------------------------------------------
conn-id peer flag phase vpn
---------------------------------------------------------------------
40022 1.1.1.1 RD|ST v2:2 public
7 1.1.1.1 RD|ST v2:1 public
分舵1跟總舵之間的安全聯盟正常建立。
3. 查看分舵2上安全聯盟的建立情況。
<FW_C> display ike sa
current sa Num :0
分舵2跟總部之間沒有建立安全聯盟。原因在於總部配置了模板方式IPSec安全策略，只能響應協商。所以分舵1到總舵的安全聯盟正常創建了，而總舵到分舵2的安全聯盟沒法建立。在分舵1跟分舵2上應用IPSec安全策略時帶上auto-neg參數後，IPSec安全聯盟自動創建。由於分舵1到總舵、總舵到分舵2之間的安全聯盟都已創建好，所以分舵1跟分舵2可以通信。同樣總舵可以ping通分舵。
模板方式IPSec安全策略與IKE方式IPSec安全策略都需要通過IKE來協商IPSec隧道。協商的過程一樣，這裏強叔就不多說了。本篇重點講講模板方式IPSec安全策略的“特色”之處。
模板神功露破綻，個性化接入化圓滿（僅USG9000系列防火牆支持）
IPSec模板中只能引用一個IKE Peer。而一個IKE Peer中只能配置一個預共享密鑰，因此所有與之對接的對端都必須配置相同的預共享密鑰。於是問題來了，只要有一個IPSec網關的預共享密鑰泄露，則所有其他網關的IPSec安全都受到威脅。
那麼在總舵跟多個分舵對接的點到多點的組網中，分舵可以配置不同的預共享密鑰嗎？既然預共享密鑰跟密鑰生成和身份認證相關，只要把預共享密鑰與設備身份掛鉤就可以。預共享密鑰認證方式下可以採用本地IP地址或設備名稱進行身份認證。那通過IP地址來指定預共享密鑰或通過設備名稱來指定預共享密鑰就可以爲每個接入對端配置“個性化的預共享密鑰”了。
- 在總舵通過對端IP地址爲每個分舵指定個性化預共享密鑰
此方式適用於分舵出口IP地址固定的情況。將總舵在ike peer下面配置的remote-address和pre-shared-key刪掉，改爲在全局下爲每個分舵配置remote-address和pre-shared-key就成，這樣既保留模板的先進性，又巧妙規避了模板的侷限性。
|
配置項 |
天地會總舵 |
天地會分舵（分舵2的配置跟分舵1類似） |
|
配置IKE對等體 |
ike peer a local-id-type ip ike-proposal 10
|
ike peer a local-id-type ip ike-proposal 10 remote-address 1.1.1.1 pre-shared-key tiandihui1 |
|
配置個性化預共享密鑰 |
ike remote-address 2.2.2.2 pre-shared-key tiandihui1 ike remote-address 2.2.3.2 pre-shared-key tiandihui2 |
- |
- 在總舵通過對端設備名稱指定預共享密鑰
當分舵出口沒有固定IP地址時，可以通過設備名稱來標識身份（ike local-name），此時總舵在全局下爲每個分舵配置remote-id和pre-shared-key即可。
|
配置項 |
天地會總舵 |
天地會分舵1（分舵2的配置跟分舵1類似） |
|
配置IKE對等體 |
ike peer a local-id-type ip ike-proposal 10 |
ike peer a local-id-type fqdn//通過設備名稱進行身份認證時本地認證類型需配置爲FQDN或USER-FQDN。 ike-proposal 10 remote-address 1.1.1.1 pre-shared-key tiandihui1
|
|
配置本地名稱 |
- |
ike local-name tdhfd1 |
|
配置個性化預共享密鑰 |
ike remote-id tdhfd1 pre-shared-key tiandihui1 ike remote-id tdhfd1 pre-shared-key tiandihui2 |
- |
說明：本地配置的“對端IP”或“對端ID”必須與對端網關上配置的“本地ID”一致。
IP變化不打緊，域名映射獲真身
分舵用動態IP地址接入的情況，IKE方式IPSec安全策略是否真的束手無策呢？
強叔閉目打坐通過對數通知識的融會貫通、舉一反三，也找到了一個可以幫助IKE方式IPSec安全策略解決問題的方法：對端IP地址不固定，當然也就無法配置remote-address，但總部可以通過其他方式間接獲知IP地址，比如通過域名。即總部可以用指定remote-domain代替remote-address；分部配置DNS獲得域名和IP地址之間的映射關係，開啓DDNS保證映射關係能夠實時更新。當然配置動態域名的方式也適用於模板方式IPSec策略。
說明：此處僅給出配置差異部分。
|
配置調整 |
總舵 |
分舵 |
|
IPSec配置 |
僅IKE Peer中配置有變化 ike peer a ike-proposal 10 pre-shared-key tiandihui1 remote-domain www.adcd.3322.org |
無變化 |
|
新增配置 |
|
1、開啓域名解析 dns resolve dns server 200.1.1.1 2、配置DDNS策略//以下配置需聯繫DDNS服務提供商，並根據DDNS服務提供商的說明操作。 ddns policy abc ddns client www.adcd.3322.org ddns server www.3322.org ddns username abc123 password abc123 3、應用DDNS策略 ddns client enable interface dialer 1 ddns apply policy abc |
此方案的侷限在於動態接入方必須有固定域名，另外增加了DNS和DDNS的配置，有點小複雜，所以強叔至今的感受是“不得不用時纔會使用”。
模板方式IPSec安全策略很強大吧？實際場景中，他並不是孤軍作戰的，只有模板方式IPSec安全策略和IKE方式IPSec安全策略聯合作戰才能全線告捷：
|
場景 |
總舵 |
分舵 |
|
總舵IP地址固定+分舵IP地址固定 |
IKE方式IPSec策略或模板方式IPSec策略 |
IKE方式IPSec策略
|
|
總舵IP地址固定+分舵IP地址動態獲取 |
IKE方式IPSec策略（指定對端域名）或模板方式IPSec策略 |
IKE方式IPSec策略 |
|
總舵IP地址動態獲取+分舵IP地址動態獲取 |
IKE方式IPSec策略（指定對端域名）或模板方式IPSec策略 |
IKE方式IPSec策略（指定對端域名） |
看似通過上面三大方案基本可以完美應對總舵-分舵IPSec VPN的各種場景了，但實際上是江湖之所以爲江湖就是因爲永遠會有點風浪：分舵申請不到公網IP地址，只能配置私網IP地址。怎麼辦，強叔？強叔之所以爲強叔，就是因爲真的強大，敬請關注下期的強叔侃牆。