配置錯誤導致IPSec VPN不通

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

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

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

故障現象

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

故障排查

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

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

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

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

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

故障解決

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

經驗總結

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

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

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

1.感興趣流是否匹配

可以用display acl acl-number命令來檢查流量是否匹配了acl規則，例 如 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)。

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

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

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

3.對端IP地址或對端域名配置錯誤、兩端設備的預共享密鑰配置是否一致、是否啟用了NAT穿越功能。

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

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

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

5.兩端設備的PFS功能配置參數是否一致

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

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

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

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

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

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

為了保證IPSec隧道正常建立，需要正確配置安全策略，包括Local區域與應用IPSec策略的接口所在區域間的安全策略，以及內網接口所在安全區域與應用IPSec策略的接口所在區域間的安全策略；配置NAT策略時需要對IPSec保護的數據流不做NAT轉換。

9.是否已清除舊的或已經存在的SA（安全聯盟）

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

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