HomeLab 搭建记录

前言

在今年暑假的时候，看到 SkyWT 发布了一篇关于 HomeLab 搭建的博客，使用闲置的 MINI PC 搭建了一个属于自己的内网 HomeLab。

正好，我手里也有一台闲置的 MINI PC。它之前主要用来打比赛、跑代码，后来基本闲置下来，唯一长期运行的服务就是一个 Minecraft 服务器。既然放在那里吃灰，不如把它重新利用起来，做成一个属于自己的 HomeLab。

这篇文章主要记录整个 HomeLab 的搭建过程，以及我为什么会这样设计。

前期规划

目前手上的主要设备包括：一台阿里云 ECS，一台海外 VPS，一台 MINI PC，手机、电脑、平板等个人设备等。根据不同设备的特性和资源，它们承担的职责也并不相同。

• ECS 有公网 IP，而且稳定性很好，因此更适合放一些必须公网访问，需要长期稳定运行的服务。ECS 上的服务优先使用 Docker 部署， 这样做一方面可以减少环境污染，另一方面也方便以后迁移、备份和升级。部署也优先选择使用 Go 等语言开发的，可以打包成二进制文件的服务，减少 Node.js 带来的运行时资源占用。
• VPS 同样拥有公网 IP，不过稳定性和资源条件相对一般，可以作为一个测试服务器和中转站，搭建一些小玩具，以及需要公网访问但不要求长期稳定的服务。
• MINI PC 是内网服务的核心，安装了 PVE 系统，作为整个 HomeLab 的计算和网络中心。MINI PC 通过自建的 Headscale 进行组网，提供安全，可靠的内网服务；Headscale 服务器搭建在 ECS 上。在 PVE 里面，主要运行以下的虚拟机：Gateway VM（整个 HomeLab 的网络网关）， Lab VM（运行各种 HomeLab 服务，使用 Docker 部署），Game VM（运行 Minecraft 等游戏服务器）和 Dev VM（开发环境）。其中 Gateway VM 是整个架构最重要的一部分，它不仅负责网络出口，同时还承担 DNS、反向代理、内网证书以及 Tailscale 等网络基础设施。

内网网络架构

整个 MINI PC 的网络架构如下图所示（拿 GPT 帮我画的）。

由于 MINI PC 只有一个有线网卡和一个无线网卡，于是便将有线网卡作为内部管理网络，用于连接电脑进行无网状态下的连接；有线网卡硬件直通 Gateway VM，作为整个虚拟机连接互联网的出入口。因此，PVE HOST 本身并不承担 HomeLab 的网络出口，所有的网络服务都由 Gateway 完成。这样的优点在于，我可以完全掌控整个内网的网络流动，监控管理网络服务；坏处就是一旦 Gateway VM 启动失败，则整个 MINI PC 就会失去网络连接。

Gateway 使用 Debian 作为系统，它有三张主要的网络接口：

vmbr0     192.168.17.1/24
vmbr1     10.10.0.1/24
Wi-Fi     DHCP

其中 192.168.17.0/24 这个网络主要用于管理，和 PVE HOST 相连，并可以访问其他内部的任何网络。我的电脑通过网线连接到 MINI PC 的物理网口，便可以在无网的情况下通过 SSH 访问任意一个虚拟机。这个接口不承担互联网出口，即使 Gateway VM 的 Wi-Fi 出口出现问题，我仍然可以通过这个网络访问 PVE HOST，进行故障排查。

10.10.0.0/24 作为容器的内网，内部服务之间可以直接通信，它们不需要直接暴露到物理网络，无法访问管理网段在内的其他 IP。外部访问服务统一通过 Gateway 进行反向代理或者转发（后面会进一步介绍），确保了一定的安全。

最后 MINI PC 上的无线网卡被直接通过 PCIe Passthrough 分配给 Gateway，通过 DHCP 从上游 Wi-Fi 获取地址。这样做的好处在于：无论现在连接的是手机热点还是家里的宽带，只要 Gateway 能连上 Wi-Fi，它就能自动获得新的 WAN 地址，然后通过 NAT 继续给 HomeLab 提供网络。这让整个 HomeLab 的迁移变得非常简单，换一个地方，只需要让 Gateway 换一个新的 Wi-Fi 即可（需要确认 Wi-Fi的网段不是 192.168.17.0/24，当时设计的适合没考虑到这一步😵）。

内网域名

网络搭起来之后，很快就会发现一个问题：如果每个服务都使用 IP 访问，就会变成 http://192.168.17.1:xxxx，这显然并不优雅。

于是我使用 AdGuard Home 在 Gateway 上面搭建自己的 DNS 服务器，并将包括 PVE HOST 在内的所有虚拟机的网关和 DNS 服务器设置为 Gateway 的地址，这样就可以使用类似 pve.motues 和 ad.gateway.motues 的内网域名进行访问，当然这些域名都只存在于自己的网络中。有了域名之后，自然还需要一个统一的 HTTP/HTTPS 入口，于是我在 Gateway 上运行 Nginx，并部署 Nginx-UI 提供可视化的管理面板。

现在，访问内网的服务时，DNS 服务器先将所有后缀为 .motues 的域名（按照规范应该使用 .home.arpa，这里参考了 SkyWT 的做法，选择了 .motues）全部解析到 Gateway 的地址 192.168.17.1，Nginx 再根据具体的域名将请求反向代理到对应虚拟机的端口即可。这样，之后搭建新服务的时候，只需要在 Nginx UI 里面新建一条新的反向代理规则即可，一切变得如此简洁。

内网 DNS 解决了 IP 难记的问题，但还有一个小问题：内网并不天然支持 HTTPS。这些内网域名根本不存在于公网，Let’s Encrypt 自然无法直接签发证书。所以我自己建立了一套内部 CA，然后由它签发：*.motues，*.gateway.motues等内部证书。之后只需要在自己的电脑、手机等设备上安装一次 Root CA 证书，后续所有内部服务都可以正常使用 HTTPS 访问。

使用自建 DNS 服务器的另一个好处就是支持过滤广告等高级功能，不过这需要等到之后慢慢探索了。

Tailscale 组网

前面的设计解决了内网如何访问的问题，但 HomeLab 最终不应该只在粗在与内网。我希望无论人在什么地方，手机、电脑都能够像连接内网一样访问这些服务。所以需要使用 Tailscale 建立虚拟网络。出于稳定性和访问速度的考虑，我没有选择使用官方的服务，而是在阿里云 ECS 上自建了 Headscale 作为中心服务器。

这里我没有让每个虚拟机都安装 Tailscale，而是让 Gateway 作为整个 HomeLab 的 Tailscale 节点，然后由 Gateway 把内部网络发布出去，并给予 Tailscale 网段互通其他网段的权限。同时将 Tailscale 的 DNS 服务器也设置为 Gateway，这样便可以支持内网域名的解析了。

这样做的好处也非常明显，其他所有的配置都不许要进行改动，组网便可以完成。这也符合我一直坚持的原则：基础设施应该尽量集中，而不是把配置复制到每一台机器上。

结语

在搭建 HomeLab 的博客里，SkyWT 提到：

「在今天，完成上面的一切，只是偶尔在 ChatGPT 聊聊天的结果，无需手写一行代码。我想要的一切都能够梦幻般地随着几句话而立即变为现实。」

确实如此，现在 AI 发展的速度已经快到有些不可思议。

我在搭建 HomeLab 的过程中使用的技术都是开源的，每一个几乎都有完善的解决方案。但当你一步一步把它们组合起来，变成一个完整复杂的系统后，就会开始遇到各种奇奇怪怪的问题。在没有 AI 之前，我们可能需要翻半天文档，研究配置文件，遇到问题再去搜索 Google；而现在，我们只需要把自己的需求、当前环境和错误日志丢给 AI，就可以一步一步把它搭起来。

当然，搭建 HomeLab 过程也是满满的成就感，想到在自己的小小网络里，拥有一套属于自己的网络基础设施，是一件多么酷炫的事情。

目前这个 HomeLab 的基础设施已经基本搭起来了，接下来还需要处理网络代理和内部服务搭建的问题，当然这些都是之后慢慢考虑的事情了。至于后面还能折腾出什么，就慢慢再记录吧。