故事的始末追溯到2011年，研一末那次ISCC。全队披荆斩棘获得了网关的Shell，但是继续探身进入内网就卡住了。虽然都多少了解一些端口转发的知识，但实际操作似乎又都没经验可谈。Jarett提出用 SSH -D 搭建sock代理，但最后仓促的结果并不佳。赛后总结时，我誓弄清楚SSH端口转发的前因后果。可惜两年光景匆匆呼啸，也没能运筹帷幄出片刻给它

这一周单位其他部门做代理方面的研究，碰巧邀我帮助编译openvpn，dropbear等工具（编译他俩Android下的静态二进制文件可以查看这里），借此机会终于把SSH端口转发玩明白了。关于SSH的端口转发详细讨论可以参考IBM的文章， 另外，端口转发也可以用MSF实现，详细可参考链接

我们拥有一台公网的主机A，以及公司内网环境中完全可控的主机B，目标是通过A可以访问内网中的所有资源。倒不是说端口转发智能用SSH来做，但*inux原生支持的工具显然比其他额外安装的工具来得简洁。A主机可以是任何linux类型的系统，Ubuntu，Backtrack，Kali，whatever you like。B主机可以是桌面的linux也可以是Android等嵌入式的操作系统（如果是Android的话，需要用dbclient和dropbear代替ssh和sshd来完成以下任务，效果完全相同）

实现方案如下（A的ip为A.A.A.A，B的ip为192.168.10.10，所在网段为192.168.10.X）：

• A和B开启sshd服务，侦听22端口
• B执行 ssh -R 1122:localhost:22 A.A.A.A -p 22
• 此时A主机本地会因此开放1122端口，连接1122端口等于连接B的22端口，这里假设B连接A的SSHD服务所用的端口为3022，下图虚线框部分就是B和A建立的SSH通道
• A执行 ssh -g -D 1080 127.0.0.1 -p 1122 

至此，A主机的1080端口已经成为了sock代理的服务端口，可用于访问B所在的内网192.168.10.X。A或任何主机只要将浏览器的sock代理填写为A.A.A.A:1080就可以访问到192.168.10.X了。比如一台主机C通过A访问B的内网（比如C打开192.168.10.11的80端口的Web服务页面），其数据流向如下图所示：