一次奇葩的IPsec ***故障

先放出拓撲說明一下結構。

分支有兩條線路，一條IPsec ***訪問分部的內部資源，一條MSTP專線訪問總部資源。若是MSTP線路斷了，也能夠從***訪問總部資源。本來的配置已經完成，使用正常，這次客戶從新規劃地址段，要改一下分支的地址段，因此IPsec這塊就須要從新配置了。一樣的，MSTP那邊也要改配置。

       按照客戶要求，完成了配置修改，首先測試去訪問總部資源，沒有問題，正常的。而後測試從IPsec訪問分部的資源，也沒問題。最後一步，斷開MSTP線路訪問總部資源，發現不行了，而後此時，訪問分部資源也不行了。這裏就出現了奇怪的現場，斷開MSTP怎麼會影響到***線路。

       以後再次測試，插回MSTP線路，業務訪問就都恢復正常了。反覆幾回都是這樣，內心就懷疑是否是出BUG了，那就這樣，把MSTP專線的配置全刪了，只插線，這樣測試，這時候仍是不通，而後把接口地址配上，這時候竟然就通了，指數據走MSTP的路由這時候都還沒配。

       這下更確認是產品問題了，聯繫了客服看配置，又抓包，啥也沒看出來，說配置沒問題。我看了一下分部抓包的信息，PING包的來回，好像有規律，收到的請求是迴應的1/2，再一看，分部迴應一次發2個報文，並且這2個報文的MAC都不同。雖然不知道爲何會這樣，感受既然不正常，那就查查MAC究竟是哪的。覈對了設備上的接口MAC，發現其中一個是分部設備去往總部的接口MAC，這就有點感受了。立刻看了路由，發現問題了，分部有一條大段的路由指向總部專線的路由器，而分支新的地址段就被包括在裏面。解決辦法也簡單，寫一條明細的路由指向公網出口就好了。

        最後說一下故障現象是怎麼回事，分支是從***到了分部，分部回包到達出口設備時，匹配了一條大段路由，指到了去往總部的路由器了，接着又從MSTP線路回來了。這時候，即便分支的設備沒寫MSTP路由，可是有接口地址就能夠收到報文。並且分支設備不是安全設備，不檢測來回報文路徑問題，不記錄會話狀態，只轉發。這幾個因素加一塊兒，就出現了上面的現象。

        總結一下此次的經驗，IPsec ***這個東西，很煩人，須要注意的東西不少，可是隻要規範的作，其實也不會出問題。出現這個問題的首要緣由就是忽視了路由問題，覺得默認的路由確定是能夠的，沒去檢查；第二就是廠家400，真的不要迷信他們，這和他們無法瞭解現場狀況有關係，找他們最好是確認一些明確的小問題，好比這個功能設備有沒有，這個特別的現象，是否是BUG，這樣的問題。

        再奇葩的問題，最後都會有答案，耐心耐心，不放過任何一個細節。