你自己的控制服务器。
值得握在手里的，是那份地图。

面对「我想让我的机器之间私密互访」这个诉求，有三个诚实的答案，本指南只是其中一个。纯 WireGuard 是最小的一种：一个内核模块、每个对等节点一份配置文件、除了接口本身没有别的守护进程，除了操作系统之外没什么需要保持更新。如果你的设备都是地址固定的服务器，而且一只手就数得过来，那就不必往下看了，去读WireGuard 指南就够了。你最终会得到更少的软件，以及一份更短的「可能出问题的清单」。

Tailscale 是三者中规模最大的：底层同样是 WireGuard，再加上一套协调服务、几乎能穿透任何环境的 NAT 穿透能力、遍布多个大洲的中继网络、网页控制台、单点登录和支持合同。它确实是优秀的软件，免费套餐足以轻松满足一个家庭的需求。代价不是金钱——而是你名下每台设备的地图，以及每台设备每次连接来源的记录，都存放在一家公司的数据库里。

Headscale 是第三种答案，也是三者中最克制的一种：它是协调服务器的开源重新实现，由你自己运行，与同一个官方客户端对话。你保留了自动化和 NAT 穿透能力；换来的是一个需要自己运维的小型服务、一套不完整的功能，以及需要认真阅读说明的升级。没人应该假装这是免费的。它换来的只有一件事，却正是这个网站在乎的那件事：地图不在别人手里。

还有一件事最好现在就决定，而不要拖到以后，因为它会影响你安装的内容：这个网络是只给你自己用，还是会有别人加入。只有一个人使用的 tailnet，内部完全开放也不会出什么问题。而只要有同事、承包商或家人加入，从第一周起就需要写明白的访问规则——也就是步骤 05——而且需要每个人都有独立的用户，而不是所有人共用一个登录账号。提前决定好，只要花一段文字的功夫；事后再补救，则要搭上一个下午。

只有 Headscale 和 Caddy，再无其他。Headscale 在 Docker 网络内部监听普通 HTTP；Caddy 负责终结 TLS，首次启动时申请证书，并在无需提醒的情况下自动续期。指标监听端口只对 localhost 开放，因为那是内部调试接口，不是对外的公开接口。

在写这个文件之前，先定一条规矩：把镜像锁定到确切的版本号。Headscale 是尚未到 1.0 版本的软件，配置项和 CLI 子命令在历次次要版本里都不止一次改过名字。用浮动标签，会让一次再普通不过的容器重启，变成一次事故——而这项服务的职责，恰恰是让你能连上其他一切东西。

/srv/headscale/docker-compose.yml

services:
  headscale:
    image: docker.io/headscale/headscale:0.26            # pin it; never :latest
    container_name: headscale
    command: serve
    volumes:
      - ./config:/etc/headscale
      - ./data:/var/lib/headscale
    ports:
      - "3478:3478/udp"                                  # STUN, for your own DERP
    restart: unless-stopped

  caddy:
    image: caddy:2-alpine
    container_name: caddy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
    restart: unless-stopped

volumes:
  caddy_data:

/srv/headscale/Caddyfile

vpn.example.com {
    reverse_proxy headscale:8080
}

这就是完整的代理配置了。Caddy 支持 HTTP/2，也会自动升级长连接而无需特别告知，这一点在这里很重要，因为每个客户端都会保持一条长连接来接收地图更新。拿你锁定版本时自带的示例配置文件来改，而不要从零开始写——这个文件很长，大部分都是合理的默认值，真正要关心的配置项是这几个：

/srv/headscale/config/config.yaml — the lines that matter

server_url: https://vpn.example.com          # exactly what clients will dial
listen_addr: 0.0.0.0:8080                    # inside the Docker network only
metrics_listen_addr: 127.0.0.1:9090          # debug surface, keep it local

prefixes:
  v4: 100.64.0.0/10
  v6: fd7a:115c:a1e0::/48

noise:
  private_key_path: /var/lib/headscale/noise_private.key

database:
  type: sqlite                               # postgres for a large fleet
  sqlite:
    path: /var/lib/headscale/db.sqlite

dns:
  magic_dns: true
  base_domain: ts.example.com                # NOT a parent or child of server_url
  nameservers:
    global:
      - 1.1.1.1                              # replaced by your own in step 05

启动它，然后去看日志，而不是靠猜。如果首次启动时无法获取证书，或者因为 DNS 后缀与服务器主机名重叠而被拒绝，日志会说得清清楚楚，然后停下来。

docker compose up -d
docker compose logs -f headscale

# From your laptop — a control server that is up answers this:
curl -s https://vpn.example.com/health

首次启动会在 /srv/headscale/data 中生成私钥材料。现在就把它复制到安全的地方——趁着还没有任何一台设备注册，等第一批设备注册完之后再复制一次：一旦丢失这把密钥，所有设备都会拒绝它们一直信任的服务器，唯一的补救办法就是手工把所有设备重新注册一遍。步骤 06 会把这次复制变成一份真正的备份。

一个所有设备都能互相访问的 tailnet 已经很有用了。再加三样东西，它才会从一堆隧道变成真正的网络，而这三样东西都有一个容易让人栽跟头的共同点：客户端负责广播能力，服务器必须批准它。一条只广播、未获批准的路由，就等于根本不存在，而且不会有任何提示——症状就是你能 ping 通路由器本身，却连不上它后面的任何设备。

子网路由器——把整个局域网接入 tailnet。 家庭或办公网络里的一台机器广播该网络的地址范围；其余所有设备就能访问它背后的打印机、NAS 和管理界面，而不需要在那些设备上另外安装任何东西。记得先在内核里开启转发功能，否则数据包会在路由器处悄无声息地止步，不会有任何错误提示。

# On the machine that sits inside the LAN:
echo 'net.ipv4.ip_forward = 1'          | sudo tee /etc/sysctl.d/99-ts.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-ts.conf
sudo sysctl -p /etc/sysctl.d/99-ts.conf

sudo tailscale up --login-server https://vpn.example.com \
  --advertise-routes=192.168.1.0/24 --accept-routes

# On the control server — approve it, or it does not exist.
# The subcommand moved between releases; check `hs nodes --help` first.
hs nodes list
hs nodes approve-routes --identifier 3 --routes 192.168.1.0/24

出口节点——把所有流量都经由 VPS 转发出去。 同一套机制，只是路由范围更大：一台把自己广播为出口节点的设备，愿意承载另一台设备的整条互联网连接。在不受信任的咖啡馆或酒店网络里，这正是你想要的，也是本指南里最接近「个人 VPN」的东西。

# On the VPS that will do the exiting (forwarding must be on, as above):
sudo tailscale up --login-server https://vpn.example.com --advertise-exit-node

# Approve it on the control server, then on the laptop:
tailscale set --exit-node=100.64.0.1 --exit-node-allow-lan-access
tailscale set --exit-node=                    # turn it off again

出口节点不是商业 VPN，也别把它当成商业 VPN 来说服自己。它的地址只属于你一个人，而且是固定的——这一点在对付咖啡馆 Wi-Fi 时非常好用，在对抗跨站点的长期关联分析时却毫无用处，这个取舍在旗舰指南里说得很清楚。另外提醒一句：你完全可以把出口节点放在另一台更便宜的 VPS 上，让控制服务器彻底不承担任何转发流量。

访问规则——在第二个人加入之前先写好。 默认策略是「全部放行」，对只有一个人的 tailnet 来说这没问题，但只要多一个人加入就错了。策略是一份小小的 HuJSON 文档：用户分组、机器标签，以及一份规则列表，写明哪些来源可以在哪些端口上访问哪些目标。把配置指向这个文件，用版本控制管理它，每次修改后重新加载。

{
  "groups": {
    "group:admin":     ["alice"],
    "group:contractor":["bob"]
  },
  "tagOwners": {
    "tag:server": ["group:admin"],
    "tag:exit":   ["group:admin"]
  },
  "acls": [
    // Admins reach everything.
    { "action": "accept", "src": ["group:admin"], "dst": ["*:*"] },

    // The contractor reaches one machine, on two ports, and nothing else.
    { "action": "accept", "src": ["group:contractor"],
      "dst": ["tag:server:22,443"] }
  ],
  "autoApprovers": {
    "routes":   { "192.168.1.0/24": ["tag:server"] },
    "exitNode": ["tag:exit"]
  }
}

关于这个文件，有两点要说明。策略语言是 Tailscale 定义的，Headscale 实现的是它的一个庞大且不断扩充的子集，而不是全部——在依赖某条冷门规则之前，先查一下你这个版本的文档。另外，策略文件存放的位置也变过：较旧的版本在顶层配置里直接指定一个路径，较新的版本则把它归到一个策略小节下，还多了一种可以把规则直接存进数据库的模式。两种方式都有文档说明；真正要紧的是你锁定的那个版本采用的是哪一种。

MagicDNS——短名称，以及无处不在的自有解析器。 开启 MagicDNS 后，每台设备都会响应步骤 02 中所选后缀下的一个短名称，所以 ssh nas 在任何地方都能直接用，不需要 hosts 文件。更有意思的是后半部分：控制服务器还会把一份域名服务器列表推送给每个客户端，这意味着你在私有 DNS 解析器指南中搭建的解析器，可以在移动数据网络下为你的手机提供服务——过滤、缓存，且不记录任何日志——同时它监听的地址还是一个完全无法从公网访问的 tailnet 地址。

dns:
  magic_dns: true
  base_domain: ts.example.com
  override_local_dns: true          # beat whatever DHCP handed the device
  nameservers:
    global:
      - 100.64.0.5                  # your resolver, on the tailnet

自建控制平面是一项真实而具体的改善，而不是一场变戏法。就算以上这些全部做到位，仍有五件事不会改变，弄清楚它们，才是「真正的防线」和「自我安慰的说辞」之间的差别。

控制服务器是一个公开的、有名字的端点。 每台设备都要拨打它，所以它必须有一个主机名，而这个主机名一旦签发证书，就会立刻被记录进证书透明度日志。哪怕你从未在任何地方链接过它，它依然是可以被发现的，而它的地址正是你所有设备唯一共有的常量。用一个你已经公开使用的域名下的子域名，而不要用一个能看出用途的名字。

Headscale 是一个重新实现的项目，而且它自己也这么说。 它不是 Tailscale 构建或支持的产品，从设计上就注定功能不会完全对等，托管版产品所卖的一些东西——网页控制台、公共中继网络、打磨精致的单点登录流程——在这里要么不存在，要么只是一个没人审计过的第三方项目。在把某个功能纳入计划之前，先去查项目文档确认它是否存在，并且要把升级当成一项任务来对待，而不是放任它在后台自动发生。

默认的中继，依然是别人的。 在你启用内嵌 DERP 服务器之前，任何无法直连的连接都会退回到公共中继网络。载荷依然是端到端加密的，没有人能读取它——但「你的两台设备正在通信、通信量有多少」这件事本身，会经过一套不属于你的基础设施。这正是大多数人第一天下午最容易漏掉的那部分信任链。

出口节点是一个稳定的地址，而不是一群人。 把流量经由你自己的 VPS 转发，能骗过咖啡馆的网络和 ISP 的画像分析。但它挡不住关联分析，因为这个地址只属于你一个人，而且从不改变。商业 VPN 的共享地址在其他各方面都更差，唯独在这个特定威胁上更胜一筹。

机器依然放在一栋建筑物里。 租来的服务器运行在有门禁、有工作人员的数据中心的硬件上。改变的是：没有产品层面对你设备的索引、没有公司数据库记录每台设备的连接来源、也没有一份可能下个季度就被悄悄修改的隐私政策。不变的是：硬盘依然是实体的，而且不在你家里。

你实际买到的东西，精确地说是这样：你名下每一台机器的清单、每一台的连接来源记录，以及添加新设备的权限，如今全都保存在一台你以匿名方式租用的机器上。这是一个有限的主张，但也是一个真实的主张。它值不值这个价钱，取决于步骤 06 有没有做到位——一个没有经过实测还原的自建控制平面，算不上什么隐私上的改善，只是一个包装得更好看的单点故障。