远程访问方案设计

需求：放假了，实验不能停

在我们课题组，GPU 服务器是重要的实验设备，仅在校园网内部可以访问。对于研究生来说，我们每年的假期其实不多，寒暑假加节假日差不多只有 1.5 个月。每次放假的时候，一个比较理想的状态是在放假前把实验挂起来，跑完之后再续上下一个实验。总之，人可以多休息，但机器不要停。但这在不能远程访问时是无法实现的 —— 放假时自己的个人电脑基本上都带走了，不存在一个安装了远程桌面软件（向日葵）的跳板机。如果直接在 GPU 服务器上装向日葵，其实也不是很方便：首先需要接显示屏来操作软件并保持访问进程常开，此外登陆上去看到的也是Ubuntu的桌面，而不是一个熟悉的 CLI （如下图）。有没有办法像我们在学校里使用 MobaXterm 直接 SSH 各台服务器那样，在家里也有一样的体验呢？这就是远程访问需求。

向日葵远程桌面

FRP 还是 VPN ？

要在家直接 SSH 到校内服务器，本质是"内网穿透"问题：服务器在校园网内、家里的机器在另一张网，两边都没有公网 IP，找不到对方。怎么办呢？主流的内网穿透有好几种方案。

1. SSH 隧道方案： 用户每次连之前手动建隧道，很麻烦。而且速度也受限，公网 IP 想来也是必要的。可能是唯一的优点：隐蔽性很好！但是SSH隧道有大流量其实也是一个很明显的异常，哈哈。总之SSH隧道不适合我们这个场景。

2. VPN 方案： 自建需要依赖一台云服务器，而且每个用户都要装客户端，先连 VPN 再 SSH。如果用托管的 Tailscale / ZeroTier，确实能节省一个云服务器和公网 IP 的成本，但中继服务器在别人手上，不太可控且不一定稳定，而且还是要装客户端 —— 只要是 VPN ，就要安装客户端，用户天然多一个步骤。

3. FRP 方案： 选择 FRP 方案的决定因素就是用户透明 —— 跟在校内使用一模一样。我们组十多个人，每年来几个新同学，难道每个人都要培训一遍如何远程访问吗？可能多一个步骤就能阻挡10%的用户，哈哈。不要培训用户，对用户透明，我觉得这就挺好。公网 IP？这里当然需要一个，买一个云服务器就好。

当然还有第四种方案，通用的暴力解法 —— 花钱买服务。有钱确实能解决很多问题，例如这里我们就可以买个花生壳内网穿透。缺点是带宽不高，而且，是真滴贵啊，我觉得还不如买个云服务器自己搭。

架构设计

经过以上的讨论，我们终于确定了 —— 选择 FRP 方案：买一台有公网 IP 的云服务器作为中继，安装 frps，用户直接用云服务器的 IP 进行连接，校内 GPU 服务器主动连接到云服务器。整体架构图大致如下：

FRP 架构图

架构要点：

在每台内网服务器上部署 frpc，ssh 服务除了监听本地 22 端口，还额外监听一个用于 frp 连接的 22022 端口，强制 22022 端口访问进行 "密钥 + 密码" 双重验证。
frpc 向 frps 发起长连接，将本地 ssh 端口送到云服务器对应端口，例如将 2080Ti :22022 映射到云服务器 :12080；5070Ti-001 :22022 映射到云服务器 :15070；5070Ti-001 :22022 映射到云服务器 :25070。
用户在内网通过内网IP + 22端口访问服务器，在家里通过云服务器 IP + 对应端口访问各个服务器！

一个早期版本：集中手动配置

集中手动配置架构

在手工配置时代，为了集中控制、方便配置，有过这样一个 "把所有frpc配置放在一台内网主机上" 的架构，如图所示。其优点是 frpc 配置集中、便于手工管理；缺点是需要跳板机常开，跳板机故障会导致整个系统都不可用。

因此，为了防止跳板机单点故障瘫痪整个系统，在自动化摊平管理成本之后，我就迅速转为分布式架构了。