時效性
本篇撰寫時間為2021.12.12，由於計算機技術日新月異，博客中所有內容都有時效和版本限制，具體做法不一定總行得通，鏈接可能改動失效，各種軟件的用法可能有修改。但是其中透露的思想往往是值得學習的。
本篇前置：
- ExpRe[6] 雲服務器[0] 基礎使用，ssh連接
https://www.cnblogs.com/minor-second/p/15553737.html - ExpRe[10] Ubuntu[2] 准備神秘軟件、備份恢復軟件
https://www.cnblogs.com/minor-second/p/15578767.html
在第6期我們對雲服務器有了基本的操作和使用能力。這期我們加強雲與本地的聯系。
訪問指定端口並神秘
我們現在需要服務器能神秘（神秘是什么？神秘a又是什么？請參考第10期）
第一種方法是采用和第10期類似的方式。安裝神秘a，然后通過:2017端口進行配置。
ssh登錄上服務器，根據第10期命令在服務器安裝神秘a，自己curl 127.0.0.1:2017自己，發現能連上
而且curl 127.0.0.1:2017 | grep 神秘是有輸出的。
這時就可以嘗試用本地瀏覽器訪問2017端口，去配置了- 但是默認情況下，雲服務器提供商的入站規則里肯定是不開放這個端口的，所以需要手動增加入站規則
注：雖然我們使用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)
另一種神秘方式：你的本地可以神秘
不妨設本地神秘這邊入站是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結果是不同的
上圖第一個結果是export http_proxy='http://127.0.0.1:18889'的，然后改成export http_proxy='http://127.0.0.1:20171'之后就是第二個結果。
本地轉發(-L)
另一種轉發恰好相反，是讓本地可以通過某個端口訪問遠程主機的端口。可以讓本地借用遠程主機神秘。
比如遠程主機可以上神秘地帶（就是剛剛配置到20171的）
我們現在在MobaXterm中ssh -L localhost:11111:localhost:20171 <神秘服務器賬號>@<神秘服務器IP>
驗證現象：
- 首先我們用本地機器（並在代理服務器設置中關掉代理），因此不能神秘
- 然后我們只需在“代理”設置中選擇對應的本地端口，即可通過不同的遠程主機神秘。有趣的是，我們現在有兩台遠程服務器，還有本機的神秘軟件，所以在代理設置處共有可能設置3個端口（11111，22222，8889），分別對應不同的ip
動態轉發(-D)
找到一台直接可以神秘的機器（比如“可用區：新加坡”），而不是像之前那樣神秘軟件“共享來共享去”的
ssh -D localhost:11111 root@<可以直接神秘的公網IP>
動態轉發用的是sock5協議，設置比較復雜。需要左下角搜索Internet選項，然后連接 - 局域網設置 - 高級，如圖設置（把其它類型的代理服務器地址去掉，只留下SOCKS5）
注：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之類本地能解析域名的就可以用socks5，google.com之類的就要用socks5h
總結和問答練習
- 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
- Q: 雲服務器上神秘了，有時導致
apt install用雲服務器提供商的源時，不成功，怎么辦？
A: 要不然加其它源，要不然對提供商的源加no_proxy不使用代理