MSRG2路由器 ipsec+双向NAT 实现访问云端服务器与远端服务器互访案例

客户需求如下：

1.CloudServer与PartnerServer之间可以双向主动触发tcp访问连接。

2.MSR与PartnerRouter之间建立IPSec vpn隧道。PartnerServer的流量经过隧道传到MSR路由器，再由MSR进行NAT转换后和与CloudServer实现交互。

3.CloudServer对PartnerServer真实地址不可知，通过访问MSR提供的地址实现与PartnerServer的通信。

4.Partner要求与其通信的地址为MSR内网地址192.168.85.137/29；

5.因业务应用需求，服务器要求仅与其指定TCP端口通信

实际组网中PartnerRouter为第三方IPSec VPN网关设备。

客户按照双向NAT映射的思路自行配置后发现虽然IPSec sa可以成功建立，但从云端进行流量触发测试，却无法与合作方服务器实现通信。

附客户关键配置：

1.定位报文交互失败原因：

a)在MSR路由器上开启debug ip packet ACL XXX (匹配从源目为云端地址或者源目为合作方服务器地址的报文)观察，发现流量在经过NAT转换后已通过IPSec隧道达到合作方，但合作方的回程报文在达到MSR后出现问题：反向报文从ipsec隧道返回后直接走黑洞路由丢弃报文而再不会匹配接口的转换策略.

b)查看黑洞路由的生成原因——当接口配置一条nat-server时，若global地址不是接口地址即会自动生成一条路由优先级为1的直连黑洞路由：

 nat server protocol tcp global 192.168.85.137 1410 inside 47.95.71.154 1410 counting

192.168.85.137/32 Direct 1 0 0.0.0.0 NULL0 

在有此黑洞路由存在的情况下，任何目的地址是192.168.85.137的转发流量都会直接被黑洞丢弃。

至此云端访问合作方的流量已可以实现交互。

2.随后客户进行合作方发起访问测试，发现反向触发依旧处于失败。

通过开启debug IP packet acl XXX和debug nat packet 观察，可以确认原因为：

当前配置下，NAT相关功能均在G0/0接口配置生效，而实际上流量经过IPSec隧道到达MSR后不会进行目的地址的转换而是仅进行源地址转换。报文最终以私网IP为目的地址发出MSR设备，被外部网络设备直接丢弃。

从上述分析中可以发现，通过在接口进行两个natServer+两个nat inbound实现转换的思路是不可行的。

需要调整NAT部署的方法为静态NAT+NAT Outbound+NAT Server方式实现过IPSec隧道转发的需求：

验证测试：

云端——>合作方

合作方——>云端