#原创分享#SSLVPN访问相同资源时源地址不相同案例排查分析。

前情：
某客户反馈说，客户端拨入VPN后，访问某服务器地址时，在中间路径上看到的源地址并非客户端获得的虚拟IP192.168.X.X，而是设备的lan口集群IP11.0.X.X,由于服务器有限制导致业务不通，并且还有一个关键的地方，有的客户可以，有的客户不行。
问题排查：
1.首先确定，选择的SSLVPN访问方式是以客户端虚拟网卡作为源IP访问。这个配置在系统-SSLVPN选项中可以确认。

2.使用客户提供的账号拨入vpn后，ping服务器地址测试，发现源地址是电脑的虚拟网卡IP。(如图所示，此处ping不通是因为服务器拒绝了ICMP，但是只是测试用，可以说明问题)

客户又反馈，ping的时候可以看到源地址是PC，但是实际上访问业务的时候不是这样，我也实际测试了一下，访问业务的时候使用同样的方式抓包确实看不到PC发的报文。

原因定位：

1.客户使用了路由模式集群。

2.如果设备路由模式部署，用户的资源是TCP资源，那么如果资源的方向在设备的wan口方向（就是说如果要访问这个资源，下一跳出接口是wan口），则设备会以lan口地址作为源地址发送报文。

3.客户有的用户使用了TCP资源，有的用户使用了L3VPN资源，如果对于一个地址，L3VPN和TCP资源都发布了，那么优先使用TCP资源。

原理验证：

1.给客户讲解原理之后进行测试：

2. 新建了2个资源，sangfortest2是TCP资源，sangfortest是L3VPN资源，资源内容仅设置了VPN设备和132.33.X.X这两个地址。

3.绑定角色，之后进行测试。

a：先测试了TCP资源

访问测试后使用正则表达式抓源地址是PC的，抓包，发现抓不到源地址是PC虚拟网卡发来的数据。

使用另一种正则表达式，可以看到，发包源地址是设备lan口地址。

b：再删除TCP资源，绑定L3VPN资源进行测试，抓包就可以看到源地址是我PC获得的网卡的地址了

c：把L3VPN和TCP资源都加进去进行测试

访问业务地址后进行抓包查看，可以看到原地址是lan口的数据包，但是没有源地址是PC的数据包。

至此，已经验证了上面的说法。

解决方案：

针对此场景的解决方案有两种

1：在去服务器的路径上开启nat，然后配置服务器，使得允许NAT后的地址进行访问。

2：重新规划用户的资源，如果需要使用PC地址访问，则全改为L3VPN。

感谢楼主的分享，整体很有思路，穿插着一些技术原理更加方便大家理解，截图很详细，好文章，需要大家耐心的看完，收获不少
再次感谢，期待您更多的好文章

问题表达明确，分析思路清晰，问题解决效果很好。又新学到一个知识点

get到新姿势

感谢楼主精彩的分享，举例非常详细，排查步骤思路清晰，还提到了TCP资源和L3VPN资源发布的原理，直击痛点，非常值得学习，当用户同时关联TCP资源和L3VPN资源（发布的同一个地址），会优先匹配TCP资源，建议只发布一个资源:感恩:

感谢分享。

学习学习~