时效性
本篇撰写时间为2021.12.12,由于计算机技术日新月异,博客中所有内容都有时效和版本限制,具体做法不一定总行得通,链接可能改动失效,各种软件的用法可能有修改。但是其中透露的思想往往是值得学习的。
本篇前置:

在第6期我们对云服务器有了基本的操作和使用能力。这期我们加强云与本地的联系。

访问指定端口并神秘

我们现在需要服务器能神秘(神秘是什么?神秘a又是什么?请参考第10期)
image
第一种方法是采用和第10期类似的方式。安装神秘a,然后通过:2017端口进行配置。

  • ssh登录上服务器,根据第10期命令在服务器安装神秘a,自己curl 127.0.0.1:2017自己,发现能连上
    而且curl 127.0.0.1:2017 | grep 神秘是有输出的。
    image
    这时就可以尝试用本地浏览器访问2017端口,去配置了
  • 但是默认情况下,云服务器提供商的入站规则里肯定是不开放这个端口的,所以需要手动增加入站规则
    image
    注:虽然我们使用http://<公网IP>:2017访问,其中有http字样,但开放的不应是:80端口,而应该是:2017
    参考:

一般80作为网页服务器的访问端口,比如一个网站的ip地址是123.123.123.123,我们访问的是123.123.123.123:80,只是80是默认端口可以省略

也就是说并不是http出现了就是访问80,而是http://,且后面没有:xx,则默认访问80

  • 于是现在http://<公网IP>:2017可以访问,并可以配置了(用第10期的方法导入服务器等)
    (当然vim ~/.bashrc啥的也需要)
  • 验证:curl -L www.google.com,有输出了

端口转发

远程转发(-R)

另一种神秘方式:你的本地可以神秘
image
不妨设本地神秘这边入站是8889端口,如图(对于win10,在左下方搜索按钮搜索代理即可找到该设置界面。对于其它系统就各自在相应的地方找)
那么你可以把这个可以神秘的端口做远程转发,即让远程主机能访问你本地的8889端口
即首先
ssh -R 18889:localhost:8889 root@<公网IP>
这样服务器的18889就对应了你本地可以神秘的8889
接下来尝试

export http_proxy='http://127.0.0.1:18889'
curl cip.cc
export http_proxy='http://127.0.0.1:20171'
curl cip.cc

如果你本地使用的神秘节点和上节通过http://<公网IP>:2017配置使用的神秘节点不同,那么两次curl结果是不同的
image
上图第一个结果是export http_proxy='http://127.0.0.1:18889'的,然后改成export http_proxy='http://127.0.0.1:20171'之后就是第二个结果。

本地转发(-L)

另一种转发恰好相反,是让本地可以通过某个端口访问远程主机的端口。可以让本地借用远程主机神秘。
比如远程主机可以上神秘地带(就是刚刚配置到20171的)
我们现在在MobaXtermssh -L localhost:11111:localhost:20171 <神秘服务器账号>@<神秘服务器IP>
验证现象:

  • 首先我们用本地机器(并在代理服务器设置中关掉代理),因此不能神秘
    image
  • 然后我们只需在“代理”设置中选择对应的本地端口,即可通过不同的远程主机神秘。有趣的是,我们现在有两台远程服务器,还有本机的神秘软件,所以在代理设置处共有可能设置3个端口(11111,22222,8889),分别对应不同的ip
    • image
      image
    • image
      image
    • image
      image
    • image
      image

动态转发(-D)

找到一台直接可以神秘的机器(比如“可用区:新加坡”),而不是像之前那样神秘软件“共享来共享去”的
image
ssh -D localhost:11111 root@<可以直接神秘的公网IP>
动态转发用的是sock5协议,设置比较复杂。需要左下角搜索Internet选项,然后连接 - 局域网设置 - 高级,如图设置(把其它类型的代理服务器地址去掉,只留下SOCKS5)
image
注:Ubuntu的这个界面就没藏这么深,很难说这不是Windows历史遗留问题。Windows“两种风格设置界面”已经被吐槽很久了……
此时在新的MobaXterm终端中尝试curl -x socks5://127.0.0.1:11111 cip.cc可以神秘,但curl -x socks5://127.0.0.1:11111 -L google.com不行,原因是google.com不能被本地DNS解析。应该改成curl -x socks5h://127.0.0.1:11111 -L google.com
由此看出,(时效性:截至2021.12.12)像github.com之类本地能解析域名的就可以用socks5google.com之类的就要用socks5h

总结和问答练习

  1. Q: 转发实际上更常用的是“跳板”功能,即涉及三台机器的关系(而不是两台)。试举例说明。
    A: 设计一个场景:比如远程服务器可以按172开头的内网IP地址,访问内网的某个机器X(其它机器不行)。
    我们通过远程服务器作为跳板,即可通过本地转发,用本地端口访问的X端口。应用:访问X中的tensorboard等。
    现在,用docker容器模拟一个类似的场景
    (当然想看容器的tensorboard是不推荐如上操作的。根据docker官方文档,不推荐手动改iptables使得curl <内网IP>:<端口>能访问。推荐端口映射。22用于ssh是个特例)
  • 在docker容器中cat /etc/hosts看到容器的内网IP地址
  • 按照19期做出适当设置使得容器允许ssh连接
  • 在容器的宿主尝试ssh <内网IP>可以连接容器
  • 宿主适当设置no_proxy(如localhost,127.0.0.1这种,否则宿主的127.0.0.1:2017访问代理的2017端口。此处我们需要的是<内网IP>不过代理)
  • 在容器中curl 127.0.0.1:22看到输出(如Protocal mismatch等)
  • 在宿主中curl <内网IP>:22也可以看到同样输出

本地新开一个ssh终端,使用ssh -L localhost:2022:<容器IP>:22 root@<宿主IP>
本地再新开一个终端,curl localhost:2022,即可看到Protocol mismatch

  1. Q: 云服务器上神秘了,有时导致apt install用云服务器提供商的源时,不成功,怎么办?
    A: 要不然加其它源,要不然对提供商的源加no_proxy不使用代理