在客户端访问远程Linux服务器的私有IP地址的URL

7 篇文章 0 订阅
3 篇文章 0 订阅

环境

  • 服务器:Ubuntu 22.04
  • 客户端:Mac 14.2.1

背景

在远程Linux服务器上搭建了minikube环境。minikube提供了dashboard功能,可以在浏览器里以图形化的方式和Kubernetes集群交互。访问的URL为 http://127.0.0.1:45891/xxxxx

注:关于minikube,参见我另一篇文档( https://mp.csdn.net/mp_blog/creation/success/135585639 )。

但是,远程服务器只有命令行,没有图形界面。而且由于网络设置问题,服务器里的服务并没有暴露在公有IP上,在客户端无法直接访问服务器的URL。

client ⇒ (inaccessible) ⇒ server(private IP)

一种解决办法是给远程服务器安装图形界面,然后用VNC或远程桌面连接等工具连接,打开浏览器。通过私有IP访问URL,但是这样会消耗大量资源,而且巨慢无比,点一下鼠标好几秒都没反应。

另一种解决办法是,通过mobaxterm等软件,在客户端打开服务器的浏览器(注意是在客户端显示),和在服务器桌面上打开浏览器的效果一样,同样在浏览器里通过私有IP访问URL。我没有试过,是否需要在服务器安装图形界面。但是同样会消耗大量资源,而且网络也很慢,貌似还有字符集等乱七八糟的问题。此外,mobaxterm貌似只有Windows版,没有Mac版。我没有深入研究,应该也有别的替代工具或者手工方法。

本文介绍的SSH tunnel方法,简单直观,只用几条SSH命令,不需要借助其它工具和命令,就能在客户端浏览器通过访问localhost,达到访问远程服务器URL的效果。

SSH tunnel和正向/反向代理

首先需要了解一下SSH tunnel和正向/反向代理,可参见我另外两篇文档:

  • ssh端口转发实例: https://blog.csdn.net/duke_ding2/article/details/106878081
  • Nginx正向代理与反向代理的简单例子: https://blog.csdn.net/duke_ding2/article/details/107108962

本文使用的是SSH正向tunnel(ssh连接的方向和tunnel的方向是一致的)和反向代理(代理的是服务器,客户端无需知道服务器,只需访问代理)。

创建tunnel的命令为:

ssh -qTfnN -L <source port>:<dest host>:<dest port> <ssh server>

其中:

  • -L :表示local,也就是正向tunnel,tunnel的方向和ssh的方向是一致的。
  • <source port> :tunnel的client端的端口,对于正向tunnel,tunnel的client端就是SSH的client端,所以也就是运行ssh命令的主机的端口。
  • <dest host> :把请求转发到哪个主机,可以是localhost(注意是tunnel的server端),也可以是指定的主机(比如github)。
  • <dest port> :把请求转发到目的主机的哪个端口上。
  • <ssh server> :ssh命令登录的server,对于正向tunnel,ssh的server端就是tunnel的server端。

所以,该命令会把tunnel client端(也就是运行该ssh命令的机器)的 <source port> 的请求转发 <dest host>:<dest> 上。

注意: <dest host> 是从tunnel server端(也就是 <ssh server> )指定的(所以localhost指的是tunnel server端本身),从tunnel server到 <dest host>应该确保是可访问的。

步骤

网络拓扑结构如下:

client ⇒ server (public IP) ⇒ server(private IP)

说白了就是,客户端无法直接访问服务器的私有IP地址,所以通过服务器的公有IP地址转发一下。

所以,需要两步走:

  1. 在服务器上,创建一个tunnel,把公有IP地址特定端口(为了方便,也用45891)的请求转发到私有IP地址的45891端口上。
  2. 在客户端上,创建一个tunnel,把访问本地(localhost)特定端口(为了方便,也用45891)的请求转发到服务器的公有IP地址的45891端口上。

第一步实现了网络拓扑结构里的右边箭头,第二步实现了网络拓扑结构里的左边箭头。

你可能觉得,第二步貌似是多余的,只需要第一步搭建好转发规则,然后在客户端直接访问服务器的公有IP地址不就行了。但是,第二步还是必需的,因为做完第一步之后,在客户端nc服务器的公有IP地址和45891是nc不通的:

➜  ~ nc -zv 9.30.123.105 31578
nc: connectx to 9.30.123.105 port 31578 (tcp) failed: Connection refused

原因我也不太明白,有待研究。总之,需要在客户端本机上再转一道才行。

第一步

首先,在服务器上,创建一个tunnel,把公有IP地址45891端口的请求转发到127.0.0.1的45891端口上:

ssh -qTfnN -L 45891:127.0.0.1:45891 127.0.0.1

注意:该命令里有两个 127.0.0.1

  • 第一个 127.0.0.1 是转发的目的地址,因为在服务器本机上能访问的URL是 http://127.0.0.1:45891/xxxxx ,所以转发的目的地址就是 127.0.0.1 。记住,此处和URL保持一致就对了。
  • 第二个 127.0.0.1 是SSH的登录地址,因为登录的是本机,所以这个地方只要写 127.0.0.1 就行了。

第二步

接下来,在客户端,创建一个tunnel,把localhost的45891端口的请求转发到服务器公有IP地址的45891端口上:

ssh -qTfnN -L 45891:localhost:45891 root@9.30.123.105

注意:该命令里的两个地址:

  • localhost :表示转发地址。前面提到,此处的localhost并不是运行ssh命令的机器的localhost,而是tunnel server端的localhost,本例中,tunnel server端就是ssh的server端,所以,转发的地址是 9.30.123.105
  • 9.30.123.105 :ssh的server端(也就是tunnel的server端)。

效果

现在,在客户端打开浏览器,访问 http://127.0.0.1:45891/xxxxx ,就能访问服务器了:

在这里插入图片描述

考一考

现在,我在服务器 9.30.188.63 上部署了一个应用,并且把它暴露到了 http://192.168.49.2:30633

root@kai0116ubuntu1:~# minikube service hello-node --url
http://192.168.49.2:30633

同时,使用 minikube tunnel 命令,把应用暴露到了 http://10.105.215.100:8080

root@kai0116ubuntu1:~# kubectl get services hello-node
NAME         TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)          AGE
hello-node   LoadBalancer   10.105.215.100   10.105.215.100   8080:30633/TCP   7m23s

该如何设置tunnel,以便在客户端通过浏览器访问呢?


答:

  1. 对于 http://192.168.49.2:30633
  • 在服务器:
ssh -qTfnN -L 30633:192.168.49.2:30633 127.0.0.1
  • 在客户端:
ssh -qTfnN -L 30633:localhost:30633 root@9.30.188.63

在客户端打开浏览器,访问 http://localhost:30633 ,如下:

在这里插入图片描述

  1. 对于 http://10.105.215.100:8080
  • 在服务器:
ssh -qTfnN -L 8080:10.105.215.100:8080 127.0.0.1
  • 在客户端:
ssh -qTfnN -L 8080:localhost:8080 root@9.30.188.63

在客户端打开浏览器,访问 http://localhost:8080 ,如下:

在这里插入图片描述

再次说明,在服务器端设置tunnel时,目的地址和能访问的URL里的地址保持一致:

  • 第一个URL里是 192.168.49.2 ,所以就设置为 192.168.49.2
  • 第二个URL里是 10.105.215.100 ,所以就设置为 10.105.215.100

其它

多次跳转

你可能会想,这个问题其实应该去调整服务器的网络设置,把服务暴露在公网IP地址上。这确实有道理,本文只是是一个示例,如果做端口转发。

但是,考虑以下场景:

client ⇒ jump server (public IP) ⇒ internal server(private IP)

服务器在内网里,内网和外界隔离,在外界只能通过jump server跳转,才能访问服务器。

此时SSH tunnel就非常有用了。该模型其实和本文的tunnel模型是完全一样的,只不过在本文的模型里,右侧箭头指向的是服务器本身而已,其实在处理上并无差异。

另一种方法:正向代理

文本介绍的方法,其实是一个“笨办法”,如果服务器暴露了新的端口,或者重启服务导致端口发生变化时,都得重新建立SSH tunnel。

还有一种方法是使用正向代理,说白了就是使用浏览器代理,和通过代理访问google是一样。

第一步:在客户端上建立一个到服务器的动态转发:

ssh -o ExitOnForwardFailure=yes -qTfN -D 6666 root@9.30.188.63

其中,端口可以任意指定。

第二步:把客户端的浏览器的代理设置为 localhost:6666

我使用的是Chrome浏览器和SwitchyOmega插件,设置如下:

在这里插入图片描述

这样,当在浏览器里访问 http://127.0.0.1:39783/xxxxx 的时候,通过代理,也就是 localhost:6666 ,会把请求转发到 9.30.188.63 ,也就是相当于在服务器上访问 http://127.0.0.1:39783/xxxxx ,效果如下:

在这里插入图片描述

注意:默认情况下 127.0.0.1 的访问是不通过代理的,需要显式指定一下。

同理,如果访问 http://192.168.49.2:30633 ,通过代理转发,就相当于在服务器上访问 http://192.168.49.2:30633 ,效果如下:

在这里插入图片描述

如果失败了,检查一下 192.168.49.2 是否设置为通过代理转发了。

同理,如果访问 http://10.105.215.100:8080 ,通过代理转发,就相当于在服务器上访问 http://10.105.215.100:8080 ,效果如下:

在这里插入图片描述

如果失败了,检查一下 10.105.215.100 是否设置为通过代理转发了。

这种方法看起来更简便一些。只需设置一次SSH tunnel,而之前的“笨办法”则需要对不同的端口设置多次。

我之所以没采用这个方法,是因为设置浏览器代理是一个“重量级”操作,而且我的浏览器本身已经设置了其它代理,不想改变。前面的“笨办法”适合于临时的、一次性的设置。大家可根据所遇到的情况以及个人喜好,自行选择。

参考

  • https://blog.csdn.net/duke_ding2/article/details/106878081
  • https://blog.csdn.net/duke_ding2/article/details/107108962
  • 30
    点赞
  • 24
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值