H3C与天融信IPsec对接大战三百回合

       这场大战真是惊天动地，上回说到整个拓扑结构很简单，总部采用H3C防火墙使用模板方式，分支使用天融信设备，采用野蛮模式对接。两边设备都是直接接在公网上，前面没有NAT设备。以前已经有部分分支是使用的H3C设备对接成功了。

       第298回，天融信防火墙参照其余分支配置了参数，对接失败。首先比对两边的各类算法，确认没有错误；接着查看日志，天融信设备上日志简单，而且是分支，仍是要去总部的设备上查看。在总部防火墙上开启DEBUG，发如今IKE第一阶段就协商失败，查看发现协商的时候报用户名不对，查看了天融信的配置，天融信在选择野蛮模式的状况下，必须配置总部和分支的用户名，而对应华三这边，只配置了分支的用户名，这里就能够看到不一样厂家在一样的标准协议上的不一样理解了。在总部添加了本地用户名后，隧道创建正常，测试完成。

       第299回，不到很多天，又说隧道不通，到现场查看，原来此次换了对手，上次是防火墙，此次是上网行为管理，参数配置和防火墙如出一辙。开始和上次同样，打开总部DEBUG，发现此次用户名是正确了，可是类型不同了总部是fqdn，分支是user fqdn。并且分支还无法改，这下可就难办，总部已经接入了大量分支，修改总部参数的话就须要同步修改全部正在使用的分支配置。思考以后，决定分支改成使用IP地址协商，总部在模板里新建一个策略，用于和采用IP地址方式的分支对接。测试正常。

       第300回，仅仅次日，问题又来了。这回现象是一次只能通一条数据流。这就很奇怪了，总部是不会对这个作限制的，随后天融信的后台技术说上网行为管理是采用在一个隧道里跑多条数据流的方式。这我就真的是第一次听到了，以前都是一个隧道跑一条数据流，多个数据流就建多个隧道。我想到的惟一办法就是把地址段扩大，把几个数据流都包括进来，可是一分析不行，会出现冲突。没有办法求助厂家工程师。还真有这样一条命令，能够实现一个隧道内跑多条数据流。security  acl   XXXX  aggregation 

        经历了300回合，总算是完全解决了对接中的各类问题。从这个案例能够看出来，各个厂家都宣称支持标准协议，能够和第三方对接，可是实际对接中，产品研发不一样的理解就会致使对接失败，特别是对协议进行的内部优化。遇到这种状况，只能是对报错逐条分析，将各项参数恢复为各大厂家都通行的方式进行测试，少见的参数要求，则必需要求助厂家工程师的支持才能解决了