配置錯誤導致IPSec VPN不通

最近，筆者所在的公司為了開展一項新的業(yè)務，需要與外地的另一家公司進行內(nèi)部數(shù)據(jù)上的互訪，我們選擇了在互聯(lián)網(wǎng)出口建立IPSec VPN，通過加密隧道，在用互聯(lián)網(wǎng)傳送內(nèi)部專網(wǎng)的內(nèi)容的同時，保證內(nèi)部數(shù)據(jù)的安全性，實現(xiàn)企業(yè)之間的業(yè)務互通。

雖然IPSec VPN對企業(yè)虛擬業(yè)務專網(wǎng)的構(gòu)建有著諸多好處，但是由于互聯(lián)網(wǎng)環(huán)境的復雜，真正實施起來卻并不輕松，筆者負責我公司這邊的接口建立，就遇到了一點小麻煩，甚至差點影響到新業(yè)務的開展，處理故障所積累的一些經(jīng)驗，與大家分享。

我們知道，IPSec VPN的建立分為兩個階段：第一階段，VPN客戶端和接入點互相認證，確認對方身份；第二階段，主要是協(xié)商針對特定的流量采用什么樣的加密傳輸策略以及傳輸數(shù)據(jù)的完整性校驗策略。通常情況下，我們只要把兩邊的IPSec參數(shù)設(shè)置成相同，并且感興趣數(shù)據(jù)流匹配了，通道就能建立起來了。于是，按照對方提供的參數(shù)，配置了本端設(shè)備。

故障現(xiàn)象

配置完成后，發(fā)現(xiàn)通道并沒有建立。難道是參數(shù)提供有誤嗎？聯(lián)系了對方的工程師，確認了配置參數(shù)是一致的，并用display ike peer和display ike proposal查看配置信息確認也是一致的。對方工程師告訴筆者，對方使用的設(shè)備與本端是同一廠家不同系列的，比我方的配置要高，版本要新。會不會是新版本的設(shè)備和老版本的兼容性有問題呢？設(shè)備廠家的售后工程師告訴筆者，以前并沒有遇到過這種情況，還是應該從IPSec的配置上找原因。

故障排查

使用debug命令抓取VPN設(shè)備的IKE和IPSec數(shù)據(jù)，發(fā)現(xiàn)了“IKE/7/DEBUG:recv ID: find ike peer by address (0x0affff01)failed!”這樣一條數(shù)據(jù)，意思是尋找對端的IP地址失敗，和對端的IP地址之間無法通信?？蓪Χ说腎P地址是可以Ping通的呀。使用display firewall session table verbose destination-port 500命令查看設(shè)備的連接信息，發(fā)現(xiàn)對端設(shè)備一直有數(shù)據(jù)包發(fā)過來，而我方設(shè)備沒有回去的數(shù)據(jù)包，這是怎么回事呢？難道是設(shè)備的訪問策略有問題嗎？再次聯(lián)系對方的工程師，雙方將設(shè)備的訪問策略暫時全部放開，通道仍然沒有建立起來。對方的工程師告訴筆者，IPSec的配置信息是參照其他正在運行的鏈路的，應該不會有問題。

配置信息沒問題，那會不會鏈路上有什么問題呢？一籌莫展之時，公司為其他項目采購的一批新的防火墻到貨了。對了，本地搭建一個環(huán)境測試一下吧，正好也熟悉一下新的設(shè)備。雖然不是同一個品牌的防火墻，通道還是成功地建立了，也證實了筆者的猜測，鏈路上一定有問題。

又一次聯(lián)系對方的工程師，這次大概摸清了整個網(wǎng)絡的結(jié)構(gòu)。筆者這邊比較簡單，支持IPSec VPN的一臺防火墻架設(shè)在公網(wǎng)的接口上，內(nèi)網(wǎng)的客戶端需要去訪問對方的服務器。而對方公司的網(wǎng)絡結(jié)構(gòu)就比較復雜了，對方的防火墻是在內(nèi)網(wǎng)，通過端口映射成公網(wǎng)IP，筆者這邊的內(nèi)網(wǎng)IP需要先轉(zhuǎn)換成特定的IP地址，經(jīng)過IPSec通道到達對方網(wǎng)內(nèi)后，再經(jīng)過對方的再次地址轉(zhuǎn)換去訪問第三方的服務器。

這樣的網(wǎng)絡環(huán)境，我們在防火墻上啟用了NAT穿越，于是筆者懷疑是對端NAT設(shè)備的映射有問題。對方的工程師給筆者提供了一條不經(jīng)過NAT的鏈路測試，也證實了筆者的猜想是正確的，通道能夠正常建立起來。于是，我們一起對設(shè)備的NAT映射做了一一比對，卻沒有發(fā)現(xiàn)任何問題。

在這里介紹一下IPSec的作用，即數(shù)據(jù)的機密性、完整性、認證性。機密性就是保證數(shù)據(jù)包的原始內(nèi)容不被看到；完整性即保證數(shù)據(jù)包的內(nèi)容不會被修改；認證性保證數(shù)據(jù)來自被信任的客戶端。IPSec中的封裝格式有兩種（AH和 ESP），AH在IP數(shù)據(jù)包中插入了一個包頭，其中包含對整個數(shù)據(jù)包內(nèi)容的校驗值；ESP用戶加密整個數(shù)據(jù)包內(nèi)容，同時也可以對數(shù)據(jù)包進行認證。IPSec有兩種不同的模式：傳輸模式和隧道模式。一種是傳輸模式，主要用于主機到主機之間的直接通信。另一種是隧道模式主要用于主機到網(wǎng)關(guān)或網(wǎng)關(guān)到網(wǎng)關(guān)之間。傳輸模式和隧道模式主要在數(shù)據(jù)包封裝時有所不同。無論傳輸模式還是隧道模式，AH都會認證整個數(shù)據(jù)包，并且AH還會認證位于AH頭之前的IP 頭。當NAT設(shè)備修改了IP 頭之后，IPSec就會認為這是對數(shù)據(jù)包完整性的破壞，從而丟棄數(shù)據(jù)包，因此，AH是不可能和NAT 在一起工作的。而ESP在傳輸模式時會保護TCP/UDP頭，但是并不保護IP頭，因此，修改IP地址并不會破壞整個數(shù)據(jù)包的完整性。但是，如果數(shù)據(jù)包是TCP/UDP數(shù)據(jù)包，NAT設(shè)備就需要修改數(shù)據(jù)包的校驗值，而這個校驗值是被ESP所保護的，這樣卻會導致完整性校驗失敗。所以，最終可能和NAT一起工作的只能是隧道模式下的ESP。

故障解決

正在我們一籌莫展的時候，我在一個技術(shù)論壇里看到了這樣一句話，“IKE V2和IKE V1一樣，也是使用UDP500端口進行IKE SA和IPSec SA的協(xié)商,但是不再存在ESP和AH的流量了,因為在后續(xù)的流量中，統(tǒng)一流量都是UDP4500傳輸了。也就是說，在IKE V2的環(huán)境里，不再擔心NAT環(huán)境了”。之前的防火墻配置里面，我們一直使用的是IKE V1，換成IKE V2試試看，通道終于建立起來了！

經(jīng)驗總結(jié)

這真是想不到，IKE的版本居然會受到NAT的影響，印象中無論是哪個版本都應該支持NAT穿越的！

IKE V1階段1的目的是建立IKE SA，它支持兩種協(xié)商模式：主模式和野蠻模式。主模式用6條ISAKMP消息完成協(xié)商。野蠻模式用3條ISAKMP消息完成協(xié)商。野蠻模式的優(yōu)點是建立IKE SA的速度較快，但是由于野蠻模式密鑰交換與身份認證一起進行而無法提供身份保護。IKE V1階段2的目的就是建立用來傳輸數(shù)據(jù)的IPSec SA，通過快速交換模式（3條ISAKMP消息）完成協(xié)商。而IKE V2簡化了協(xié)商過程，IKE V2正常情況使用2次交換共4條消息就可以完成一個IKE SA和一對IPSec SA，如果要求建立的IPSec SA大于一對時，每一對SA只需額外增加1次交換，也就是2條消息就可以完成。

IPSec VPN配置完成后，出現(xiàn)故障的幾個可能原因及排查方法。

1.感興趣流是否匹配

可以用display acl acl-number命令來檢查流量是否匹配了acl規(guī)則，例 如 dis acl 3001，返 回信 息rule 5 permit ip source 10.11.12.0 0.0.0.7 destination 10.11.13.11 0 (0 times matched)。

命中次數(shù)為0表示流量沒有命中規(guī)則，不會觸發(fā)建立隧道。這時要檢查源地址和目的地址是不是符合實際數(shù)據(jù)流的信息。

2.兩端設(shè)備的IKE安全提議配置是否一致

分別在兩端的IPSec設(shè)備上執(zhí)行命令display ike proposal，查 看 兩 臺設(shè)備的IKE安全提議配置是否一致，包括加密算 法（authentication algorithm）、認 證 算 法（encryption algorithm）和DH組標識（Diffie-Hellman group）等。

3.對端IP地址或?qū)Χ擞蛎渲缅e誤、兩端設(shè)備的預共享密鑰配置是否一致、是否啟用了NAT穿越功能。

分別在兩端的IPSec設(shè)備上執(zhí)行命令display ike peer name，查看對端IP地址是否配置正確，兩端設(shè)備的預共享密鑰是否一致，兩端IKE版本是否一致，是否啟用了NAT穿越功能等。

4.兩端設(shè)備的IPSec安全提議配置是否一致

分別在兩端設(shè)備上上執(zhí)行命令display ipsec proposal，查看兩臺設(shè)備的IPSec安全提議配置是否一致，包括采用的安全協(xié)議、安全協(xié)議采用的認證算法和加密算法、報文封裝模式等。

5.兩端設(shè)備的PFS功能配置參數(shù)是否一致

兩臺設(shè)備的PFS功能指定的DH組必須一致，否則IPSec隧道協(xié)商失敗。分別在兩端設(shè)備上執(zhí)行命令display ipsec policy，查看兩臺設(shè)備的PFS功能參數(shù)配置是否一致。

6.IPSec安全策略順序號配置是否正確

在設(shè)備上可以創(chuàng)建多個具有相同名字的IPSec安全策略，這些IPSec安全策略可以組成一個IPSec安全策略組，序號越小優(yōu)先級越高，接口將優(yōu)先處理該IPSec安全策略，優(yōu)先為該IPSec安全策略定義的數(shù)據(jù)流建立IPSec隧道。因此確保需要使用的IPSec安全策略的序號最小。分別在兩端設(shè)備上執(zhí)行命令display ipsec policy，查看兩臺設(shè)備的IPSec安全策略順序號。

7.IPSec安全策略應用是否在正確的接口上

IPSec安全策略應用到的接口一定是建立隧道的接口，且該接口一定是到對端私網(wǎng)路由的出接口。誤將IPSec安全策略應用到其他接口會導致VPN業(yè)務不通。

8.安全策略和NAT策略配置問題

為了保證IPSec隧道正常建立，需要正確配置安全策略，包括Local區(qū)域與應用IPSec策略的接口所在區(qū)域間的安全策略，以及內(nèi)網(wǎng)接口所在安全區(qū)域與應用IPSec策略的接口所在區(qū)域間的安全策略；配置NAT策略時需要對IPSec保護的數(shù)據(jù)流不做NAT轉(zhuǎn)換。

9.是否已清除舊的或已經(jīng)存在的SA（安全聯(lián)盟）

當管理員修改或增加IPSec配置后，要使用reset ike sa和reset ipsec sa命令清除舊的或已經(jīng)存在的SA。

總的來說，在IPSec VPN的配置上，首先要保證兩端數(shù)據(jù)的一致性，然后在路由、安全策略和NAT策略上一定要正確，在故障篩查時，更是不能放過任何一個細節(jié)，多做測試，否則，有些故障真是想破了腦袋也想不出解決方法來啊。