记一次逆向追踪请求ip的经历

事发

某日下午，部门使用的测试环境出现问题，所有集成测试case都执行失败。查询测试用服务器发现是磁盘已满，造成请求失败。

应急处理

发现磁盘空间问题后，首先想到的是程序日志过大，因为这台机器上部署了部门的几十个应用,以前也出现过日志造成磁盘空间不足的问题。所以，迅速执行日志删除，发现集成测试case都可以正确执行了。

但是过了不一会，发现某些应用报服务已宕机。再去服务器看，磁盘空间又满了，而且删除之后，几分钟磁盘就会再次填满，速度十分之快。应急之下首先增加了一个2分钟清理一次的定时脚本，但是磁盘空间告急。

寻找问题原因

这时候，只能看增长最快的日志文件，然后去看具体是什么东西打印了这么多的日志。查询发现是网关的请求量达到了4k的qps，因为是内网所以怀疑是有人在进行压测，分析请求之后发现基本都是同事负责的一个接口的流量。询问发现，下午执行了压力测试，但是压测平台出了问题，不能正常停止压测。估计问题就找到了。

封锁请求进入

但是，和压测平台负责的同事沟通，他们说已经杀死了压测程序，而且压测机没有root权限，不能进行tcpdump。很无奈，压测平台的同事也是信誓旦旦，觉得不是自己平台的问题。

无奈之下，我们进行了对流量的分析和封锁，进行请求参数、来源ip的封锁。但是封锁之后发现来源ip是公司的一个出口ip，导致其他业务的测试环境调我们调不通了。这种情况下，暂时让其他业务方使用ip地址直连我们的测试环境。

定位请求的内网ip

最终的最终，我们找到了一种可以定位到来源内网ip的方法，用铁一般的证据证明就是压测平台的几台机器在向我们发请求，才推动压测平台的同事重启服务器，从而彻底关闭了发送请求的进程。

我们采用的方案是：在请求接入层针对来源流量执行一个301跳转，跳转到一个内网ip地址，这样就可以抓取到来源的内网ip了。

~~~~~~~~~~~~~~~~~~~~~~~~~ 福利分割线~~~~~~~~~~~~~~~~~~~~~~~~~~~
-长期内推-：头条、快手、美团、阿里、陌陌、当当。有需要的朋友可以发邮件到我的邮箱xiaofan860412@163.com。