H3C與天融信IPsec對接大戰三百回合

       這場大戰真是驚天動地，上回說到整個拓撲結構很簡單，總部採用H3C防火牆使用模板方式，分支使用天融信設備，採用野蠻模式對接。兩邊設備都是直接接在公網上，前面沒有NAT設備。以前已經有部分分支是使用的H3C設備對接成功了。

       第298回，天融信防火牆參照其餘分支配置了參數，對接失敗。首先比對兩邊的各類算法，確認沒有錯誤；接着查看日誌，天融信設備上日誌簡單，而且是分支，仍是要去總部的設備上查看。在總部防火牆上開啓DEBUG，發如今IKE第一階段就協商失敗，查看發現協商的時候報用戶名不對，查看了天融信的配置，天融信在選擇野蠻模式的狀況下，必須配置總部和分支的用戶名，而對應華三這邊，只配置了分支的用戶名，這裏就能夠看到不一樣廠家在一樣的標準協議上的不一樣理解了。在總部添加了本地用戶名後，隧道創建正常，測試完成。

       第299回，不到很多天，又說隧道不通，到現場查看，原來此次換了對手，上次是防火牆，此次是上網行爲管理，參數配置和防火牆如出一轍。開始和上次同樣，打開總部DEBUG，發現此次用戶名是正確了，可是類型不同了總部是fqdn，分支是user fqdn。並且分支還無法改，這下可就難辦，總部已經接入了大量分支，修改總部參數的話就須要同步修改全部正在使用的分支配置。思考以後，決定分支改成使用IP地址協商，總部在模板裏新建一個策略，用於和採用IP地址方式的分支對接。測試正常。

       第300回，僅僅次日，問題又來了。這回現象是一次只能通一條數據流。這就很奇怪了，總部是不會對這個作限制的，隨後天融信的後臺技術說上網行爲管理是採用在一個隧道里跑多條數據流的方式。這我就真的是第一次聽到了，以前都是一個隧道跑一條數據流，多個數據流就建多個隧道。我想到的惟一辦法就是把地址段擴大，把幾個數據流都包括進來，可是一分析不行，會出現衝突。沒有辦法求助廠家工程師。還真有這樣一條命令，能夠實現一個隧道內跑多條數據流。security  acl   XXXX  aggregation 

        經歷了300回合，總算是完全解決了對接中的各類問題。從這個案例能夠看出來，各個廠家都宣稱支持標準協議，能夠和第三方對接，可是實際對接中，產品研發不一樣的理解就會致使對接失敗，特別是對協議進行的內部優化。遇到這種狀況，只能是對報錯逐條分析，將各項參數恢復爲各大廠家都通行的方式進行測試，少見的參數要求，則必需要求助廠家工程師的支持才能解決了