使用 GitHub Actions 科学上网

涛叔 2022-08-04 ⏳5.9分钟(2.4千字) 🕸️

本文介绍一种科学上网的思路，基于 GitHub Actions 服务，可以流畅观看 YouTube 4k 视频，不限流量，完全免费！

GitHub Actions 是微软为开发者提供的免费构建工具。每当有任务需要运行时，GitHub 会在在 Azure 云创建虚拟机(2C4G)。这台虚拟机可以访问公网，但它没有公网IP，所以无法从外界直接访问。如果能找到一种从外界访问的方法，我们就可以把 GitHub Actions 虚拟机当成普通的VPS来用，从而实现科学上网。这个办法就是NAT打洞🕳️，也叫NAT穿透。

假设整个网络拓扑如下：

                     /- 1.1.1.1               /- 10.0.0.1
      Client <---> C-NAT <------> S-NAT <---> Server
10.1.0.1 -/              2.2.2.2 -/

服务器(Server)就是前面说的 GitHub Actions 虚拟机。Azure 为所有虚拟机提供地址转换功能，我们称之为 S-NAT。我们自己的设备为客户端(Client)。一般家用设备或者办公设备都会通过路由器上网，同样也提供地址转换功能，我们称之为 C-NAT。

以上是最典型的架构。如果你的设备有公网IP，则会简化 NAT 打洞的难度。我们先说典型场景。因为 NAT 打洞通常只面向 UDP 通信，所以下文所说的报文如非说明都是 UDP 数据。

S-NAT 的作用是帮助 Server 访问外网。具体来说就是修改所有来自 Server 的 IP 报文，把它的源地址改成 S-NAT 的公网IP，并把源端口改为按照某个特定策略分配的数字。举个例子。

假设 Server 想给 3.3.3.3 的 80 端口发送数据，则从 Server 端看到的数据流是

10.0.0.1:11111 -> 3.3.3.3:80

这里的 11111 是 Server 的本机端口，一般是随机选取，也可以手工指定。取值不重要，重要的是数据通信需要四元组<源地址,源端口,目标地址，目标端口>。

显然，源地址为私有地址，无法在公网上路由。Server 发出的报文被转发给 S-NAT。S-NAT 收到后发现是发给外网的数据，于是把报文的源地址改成了 2.2.2.2。然后根据既定策略选择了一个端口，比如 22222 作为报文的源端口。于是数据流变成：

10.0.0.1:11111 -> 2.2.2.2:22222 -> 3.3.3.3:80

3.3.3.3 收到的数据看起来就是从 2.2.2.2:22222 发出来的。它并不知道数据是由 Server 发出的。于是 3.3.3.3 开始回复数据：

3.3.3.3:80 -> 2.2.2.2:22222

S-NAT 收到数据后将目标地址改成 10.0.0.1，并将目标端口改成 11111，然后再发给 Server。

可是，当 S-NAT 收到来自 3.3.3.3 的报文之后，它是怎么确定数据要转发给 Server 呢？S-NAT 后面可能有很多设备。为此，S-NAT 会维护一个列表，临时保存内网设备跟本地端口的映射关系。因为设备容量有限，NAT 设备会定时清理长时间不活跃的映射关系。

以上面场景为例，映射关系如下：

2.2.2.2:22222 -> 10.0.0.1:11111

S-NAT 每完成一次地址和端口转换，就记录一条反向的关联映射。这样当收到外网报文时，只要根据目标地址和目标端口就能查到对应的内网设备。因为来自 2.2.2.2:22222 数据目标一定是 10.0.0.1:11111，所以 S-NAT 就会转发给 10.0.0.1:11111。

到这里，我们就理解了 NAT 的工作原理。如果可以让 S-NAT 为 Server 添加一条映射关系，那么就有可能实现从公网访问 Server。这是 NAT 打洞的核心原理。

为什么是有可能呢？因为 NAT 设备地址转换的时候有多种端口选择策略，有的能打洞，有的不能。就 Azure 云的 NAT 设备来说，它有如下特性：

Random port
Independent Mapping
Port Dependent Filter

Random port 的意思是在地址转换的时候会随机选择端口。也就是说我们没办法在发数据之前确定 NAT 使用的端口。

Independent Mapping 的意思是映射规则跟目标地址和目标端口无关，只源地址和源端口有关。也就是说，如果 Server 分别向 3.3.3.3:80 和 4.4.4.4:443 发送数据，使用的的本地端口都是 11111：

10.0.0.1:11111 -> 3.3.3.3:80
10.0.0.1:11111 -> 4.4.4.4:443

那么 S-NAT 只会保存一条反向映射关系：

2.2.2.2:22222 -> 10.0.0.1:11111

不论从什么地方发来的数据，只要目标是 2.2.2.2:22222，都会被转发给 10.0.0.1:1111。这就让 NAT 穿透成为可能。

假如 Server 想让外界访问自己的 11111 端口，它需要找一台有网IP的设备当作协调服务器。Server 给协调服务器的某端口发一条消息，协调服务器收到后就会得到 S-NAT 的公网 IP 以及 S-NAT 为 Server 的 11111 端口分配的映射端口（比如 22222）。协议服务器需要把这些信息再返回给 Server。到现在，就完成了 NAT 打洞的第一步。Server 可以把收到的 IP 和端口发给别人。收到的设备只要给 2.2.2.2:22222 发包，这些包就会转发给 Server 的 11111 端口。

这里说的协议服务器在现实中叫作 STUN 服务器。其最主要的作用就是帮助 NAT 后面的设备发现自己对应的公网 IP 和端口。

那么 NAT 打洞是不是就完成了呢？非也。因为我们还没说 Azure 地址转换的第二个特性 Port Dependent Filter。这是一条防火墙规则。简单来说就是需要内网设备先发数据，然后才允许外网设备回复数据。再举个例子。

4.4.4.4:33333 -> 2.2.2.2:22222 # 丢弃

2.2.2.2:22222 -> 4.4.4.4:33333
4.4.4.4:33333 -> 2.2.2.2:22222 # 接收

如果 S-NAT 直接收到来自 4.4.4.4:33333 的报文，它会认为这是非法数据，直接丢弃。如果 Server 先通过 2.2.2.2:2222 给 4.4.4.4:33333 发送一条数据，那么 S-NAT 就会记录该事件，并允许在一定时间内接收来自 4.4.4.4:33333 的数据。该记录通常只会保存三十秒。

所以，为了让来自 4.4.4.4:33333 的报文顺利通过 NAT 设备转发给 10.0.0.1:11111，我们需要让 Server 先发送一条数据给 4.4.4.4:33333。因为 S-NAT 的访问记录很快就会过期，所以需要 Sever 周期性发送数据。这可以使用 nping 实现：

sudo nping --udp \
           --ttl 4 \
	   --count 20 \
	   --delay 28s \
           --no-capture \
	   --source-port 443 \
           --dest-port 33333 4.4.4.4

这里比较有意思的是--ttl 4参数，把数据的 TTL 设置为四跳。数据每经过一个路由器后 TTL 都会减一。这样数据离开 S-NAT 后很快就会因为 TTL 达到零而被丢弃。这样数据就不会真正发送到目标设备。

还有一个需要注意的重点是，如果 Client 想要连接 Server，它必须事先确定自己的IP和端口。因为只有这样，Sever 才好设置 S-NAT 为来自 Client 数据放行。

但是因为公网 IP 比较稀缺，Client 一般也是通过 NAT 访问互联网。所以 C-NAT 也会做跟 S-NAT 一样的工作。但是家用的 C-NAT 跟公司商用的 C-NAT 有很大的区别。

家用 NAT 设备的端口映射规则比较简单，一般是跟报文的源端口保持一致。也就是说来自 10.1.0.1:1024 的数据一般也会被 C-NAT 映射成 1.1.1.1:1024。这样我们只需要确定 C-NAT 的公网 IP 就可以了。如果设备不用这样的规则，那我们还可以使用 UPnP 手工指定端口映射。

以上是说家用设备有公网 IP 的情况。如果没有，那家用跟公司的商用设备就没什么区别了。

现在进行技术总结：

首先客户端最好有公网IP。通信之前选定一个端口。如果没有公网IP，也需要通过配置 C-NAT 设备拿到明确的公网IP和对应的映射端口。如果这一步做不到，就不用往下看了。
然后将客户端对应的公网IP和端口通过 GitHub 发送给虚拟机。
虚拟机选定监听端口并通过 STUN 获取 S-NAT 的公网的 IP 及其对应的映射端口（这个端口跟监听端口一一对应）
再后虚拟机不停地给客户端对应的IP和映射端口发数据，确保 S-NAT 接受来自客户端的数据。
最后客户端以之前选定的端口给虚拟机发现的公网 IP 和映射端口发送数据。整个通信过程建立。

整个过程被 ValdikSS 封装成一个开源项目。大家可以自由食用。食用办法如下：

克隆 ValdikSS 的项目，并重新上传到 GitHub。这一步不能用 Fork，因为 Fork 之后的项目不能改成私库。
将自己的 SSH 密钥添加到 authorized_keys
安装 stun-client 用于探测本机对应的公网IP和端口。
执行 ./run.sh wireguard。目前仅支持 linux，macos 需要额外定制。
查看仓库的 GitHub Actions 找到对应的 WG:XXXX 任务，从 Print WireGuard configuration file 查看配置
终止 run.sh 脚本，启动 WireGuard 客户端
使用 ssh root@192.168.166.1 登录到虚拟机

到这里我们便得到了一台 VPS，配置为2C4G，网速不慢。最简单的科学上网办法是使用 ssh 转发：

ssh -D 1337 -q -C -N root@192.168.166.1

这样就会在 127.0.0.1:1337 启动一个 sock5 代理。修改浏览器代理配置后就可以畅游世界了👏。

这么好的东西有没有缺点呢？当然有。

第一个缺点是免费。免费就可能被滥用。滥用就可能被回收。大家一定要保持克制，小心被封号⚠️
第二个缺点是需要客户端公网可达。最好是有公网IP。没有的话也要有一个可以打洞的NAT环境。
第三个缺点是一次的使用时长不能超过一个小时，因为 GitHub Actions 单任务的最长执行时间就是58分钟。而且一个月总时长不能超过33小时。

但无论如何，做为一种应急梯子🪜还是绰绰有余的🎉另外 ValdikSS 的脑洞是真的大！