ssh端口转发(隧道技术)

1.本地端口转发

  假设有以下场景,本地客户端A,  远端服务器有B和C, B和C处于同一个内网,且 B上配置了公网ip,C只有内网ip。  那么现在存在一个需求, 我想让A能够访问到C上面部署的一个nginx(监听80端口)的服务。那么怎么解决这个问题?  (前提:  A能够发起ssh连接到B服务器上)。 如图所示,可以使用ssh提供的本地端口转发技术来实现。

(红色箭头表示数据返回流向,黑色代表请求数据流向)。

此时我们可以在ssh和ssh的服务端ssl数据流向是:     客户端A到服务器B, 再到C的这么一个过程。

curl和nginx的应用数据流向也是:  从A到B再到C

命令:

ssh -L 80:192.168.1.3:80 root@192.168.1.2(这个可以配置ssh通过key登录的形式,则不用输入密码,否则要输入密码)

那么此时在A上执行,   curl    localhost:80  就能访问到C服务器的nginx页面。

如果ssl数据流向和应用数据流向是一致的,那么我们叫本地端口转发。  反之成为远程端口转发, 下面会讲到。

在本地端口转发中,我们可以看到B其实充当了一个proxy代理服务器的功能,把A从本地80端口走的数据, 在经过B的时候,发现数据包是A的80转发过来的,那么B会转发到C上从而拿到数据原路返回给A。

 

常见实际应用场景:   远程docker容器开发,但是你不能直接连接容器,只能通过一个代理proxy的形式ssh连接容器上。 远程phpstorm只能通过sftp的形式直接ssh连接的方式, 目前phpstorm没有可以配置proxy代理的方式连接fstp的远程开发功能。此时本地端口转发发挥作用了, 打一个隧道到远程docker的端口就可以了, 这样phpstorm  sftp连接信息直接连接本地端口即可实现sfpt文件上传功能。

 

2.远程端口转发

假设上面的情况现在反过来,  B能ssh连接A,但是A确主动不能连接B。 那么此时ssl数据流向变成了B->A, 但是应用数据流向还是A->B->C 此时应用数据流向和ssl流向不一致称之为远程端口转发。

命令:

ssh -f -N -L 80:192.168.1.3:80 root@A服务器ip(这个可以配置ssh通过key登录的形式,则不用输入密码,否则要输入密码)

这样,应用数据流向还是A->B->C实现A访问本地80端口,就能访问到C上面的nginx服务。

具体使用本地端口转发还是远程端口转发, 根据实际情况而定。

 

3.动态端口转发

这个和本地端口转发应用数据流向和ssl流向一致, 只不过在动态端口转发里面,ssh-server服务器充当socks5的代理的这么一个角色。  能够突破防火墙的功能实现访问境外网站, 前提是你这个ssh-server能访问境外网站。

 

ssh -D 1080 root@境外服务器ip

 此时通过设置本地浏览器代理为socks5为本地的1080端口即可突破防火墙限制访问境外服务器。

 本质上还是那么原理,  数据在经过防火墙的时候都是被ssh-server加密的所以判断不出来你的数据合法性,从而不能拦截你的请求了。  数据返回的时候道理也是一样的。 不过ssl握手具有明显流量特征,防火墙只要下功夫也是能识别出来你的数据类型。

 文章参考:  https://www.ibm.com/developerworks/cn/linux/l-cn-sshforward/index.html

 
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页