机房计算节点登录服务器发现大量来自企业VPN隧道内的攻击，看IP地址段是来自IPSECVPN的。怀疑又是哪个用户的终端机中毒了，结果拿着IP到VPN服务器上去查询XAUTH认证，居然没有和这个IP对应的账号登录信息！但是防火墙会话表中又确实能看到这个IP和服务器的会话记录，源安全域也是来自VPNHUB，并非内网其它机器伪造源IP，这就很奇怪了。冥思苦想也只能往伪造IP地址上去靠，但是VPN客户端需要认证才能分配到IP，理论上是没法伪造IP和绕过认证记录的，这个VPN隧道内的虚拟IP到底是怎么获取到的搞得我很头疼。

从攻击的目的IP来看，都是同一个用户租用的独立服务器，根据这个用户之前出过的一系列问题，基本上还是锁定问题出在这个用户的终端上。与用户系统工程师沟通，果然发现对方的服务器配置有问题。

这个用户其实相当于我们的一个代理商，他们终端通过vpnc客户端登录IPSECVPN访问我们数据中心的资源。

然后又在这台服务器上做了dnat，将VPN隧道内的资源以公网IP+端口的形式给他的子用户访问，同时通过snat转换成VPN隧道的虚拟IP地址来访问资源。问题就出在转snat这一步，代理商以为每次登陆IPSECVPN分配到虚拟IP不变，所以在snat中使用了静态的ip地址，而IPSECVPN隧道的生存时间最高为24小时，也就是其实每天都在重新连接重新分配虚拟ip。但是因为snat配置静态ip地址，实际转发过来的源地址又与分配的虚拟ip不同，所以导致在VPN服务器这边看到的XUATH认证记录与实际会话的源ip没有关联。

也就是VPN服务器网关往客户端虚拟IP转发的时候并没有去关联XUATH认证分配的IP地址，这么狗血的bug还真是头一回碰到，现在也无法确认是ipsecvpn本身没考虑这个问题，又或者是VPN服务器厂商的锅？

幸运的是，这次产生的攻击并非真实攻击者，代理商的服务器是租用在阿里云的，同时也启用了阿里云盾的漏扫和弱口令检测，通过VPN隧道跑进来的这些扫描和攻击都是来自阿里云盾的检测。

总之已经将bug反馈给厂商了，等待他们先搭建实验环境复现这种情况吧~至于是否能修复，按厂商一贯表现，估计又是一次漫长的等待。还好在防火墙上对snat后的源ip做安全策略能起到阻断攻击的效果，在防火墙阻断假ip的时候客户端那边也会出现访问受限的现象，如果是客户端的无心之举倒也能通过这种方式排查。如果是心怀不轨利用这个漏洞攻击，那就很恶心了，无法确认ip和用户账号的关联，根本找不到事主。

后记补充：我傻了，突然才反应过来，原来可以在安全策略中配置源ip的账户匹配~进入隧道的流量经过VPN的封装后，抵达防火墙，防火墙对流量解封装，得到明文流量。VPN仅仅只是对数据包加解封装，然后流量的筛选和转发依然是由policy和route来做，明文中是包含用户信息的~~~

问题顺利解决，撒花完结~~