一次奇葩的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，这样的问题。

        再奇葩的问题，最后都会有答案，耐心耐心，不放过任何一个细节。