前言
最近在使用msf转发流量时遇到了个问题，就是使用auxiliary/server/socks4a做代理时，burpsuite不支持socks4a代理，导致无法使用burp去抓包。而使用auxiliary/server/socks5做代理却失败了，可能是脚本的bug，官方issues也有人反馈这个问题。
具体问题
演示环境
我所在的环境比较特殊，工作机（192.168.1.2，Windows）位于A地内网，MSF机器（172.16.1.2，Linux）位于B地内网，两内网不相通，但是可以通过11.11.11.11:22 SSH访问MSF机器，遂用SSH隧道将172.16.1.2:11080端口转发到工作机的127.0.0.1:1083端口，如果不清楚这个操作，可以理解为工作机访问本机127.0.0.1:1083端口等价于访问MSF机172.16.1.2:11080端口。
测试步骤
在MSF机器启动socks4a代理（前面获取反弹shell、设置路由的步骤略过）
1
2
3msf5 auxiliary(server/socks4a) > use auxiliary/server/socks4a
msf5 auxiliary(server/socks4a) > set SRVPORT 11080
msf5 auxiliary(server/socks4a) > exploit
在配置代理前，我的ip地址是A地公网ip
使用Firefox配置代理测试转发是否正常，这时ip由联通变成电信了，证明代理转发隧道工作正常
这个时候，如果直接在burpsuite配置前置socks代理的话是不能使用的，因为burpsuite不支持socks4协议，所以会打不开网页
解决方法
使用sockscap64工具，把socks4a转发为http代理。当然，使用其它工具将socks4a转为http代理或socks5代理也行，比如Linux下的privoxy，socks4a转socks5的工具找了很久都没找到，遂放弃。
步骤
打开sockscap64工具，创建代理配置，代理服务器为127.0.0.1:1083（MSF socks4a端口地址）
burpsuite配置前置http代理，代理服务地址为127.0.0.1:25378，这个端口是sockscap64监听的端口
打开Firefox测试，可以看到现在已经是MSF机器的电信ip了，问题成功解决。
回顾下出口流量走向，如下：
为什么是25378端口
SockScap64支持系统代理
启用系统代理可发现其使用25378端口做代理服务
