Tailscale 深度拆解：基于 WireGuard 的零配置 mesh VPN

核心判断

Tailscale 的本质是把"VPN 配置管理"从命令行/IPSec PSK/证书系统升级为 OAuth 身份层。它把 WireGuard 当作"传输层"，自己构建"控制面"（coordination server / login server）+ 身份层（Google/Microsoft/GitHub OAuth）。结果是：开发者不需要管理 PSK、CA、不需要懂 NAT 穿透原理、不需要暴露公网端口。这正是它能从 2020 年起步迅速获得大量 DevOps/SRE/远程工作用户的原因。

项目坐标

Tailscale 不是传统 VPN

传统 VPN（IPSec、OpenVPN、WireGuard 手动配置）的几个痛点：

1. 公网 IP/端口暴露：必须有一台有公网 IP 的机器做接入点
2. NAT 穿透问题：家用宽带、移动网络几乎都是 CGNAT，公网 IP 没有
3. 证书/PSK 管理：每加一台设备都要同步密钥
4. 拓扑僵硬：星型拓扑（所有流量走中心），不适合现代分布式团队
5. 配置复杂：IPSec IKEv2 配置语法复杂到"配置 1 天，能用 1 小时"

Tailscale 用三个手段解决这些问题：

• DERP（自研中继协议）：所有节点通过 HTTPS/HTTP/3 与 DERP 服务器通信，做 NAT 穿透的中转
• 控制面分离：用户登录身份（OAuth）由 login server 管理，节点之间不直接信任 IP，而是信任"经过 OAuth 认证的设备 ID"
• 节点间直连：在能直连的情况下建立 WireGuard 直连（STUN/ICE 风格 NAT 穿透），不能直连时降级到 DERP 中继

架构：控制面 / 数据面分离

Tailscale 是典型的"control plane + data plane"分离架构：

                Control Plane (Tailscale coordination server)
                - 设备身份（OAuth → node key）
                - ACL 规则（基于 tag、user、group）
                - 网络拓扑图
                            ▲
                            │ HTTPS (443) + Noise protocol
                            │
        ┌───────────────────┴───────────────────┐
        │                                       │
    Node A                              Node B
    tailscaled daemon                   tailscaled daemon
    - WireGuard interface               - WireGuard interface
    - 与对端建立 WG 隧道                - 接收来自 A 的握手
    - 直连失败 → DERP 中继               - 直连失败 → DERP 中继

• 控制面：所有节点定期（每几分钟）与 coordination server 同步：网络映射（netmap）、ACL 策略、节点公钥轮换等
• 数据面：节点之间直接用 WireGuard 协议通信（UDP 51820 默认端口），控制面只用于密钥协商与策略下发

这个分离让"策略"与"流量"解耦：ACL 修改不需要重启连接、新节点加入立即生效。

WireGuard 是数据面

WireGuard 是 Jason Donenfeld 设计的现代 VPN 协议，使用：

• Curve25519 密钥交换
• ChaCha20 对称加密
• BLAKE2s 哈希
• Keyed BLAKE2s 消息认证

WireGuard 的特点是：

• 代码极少（Linux 内核模块约 4000 行），攻击面小
• 加密套件固定，没有"算法协商"环节（避免配置错误）
• 内核态运行（Linux），性能接近物理网络

Tailscale 直接复用 WireGuard 作为加密层。它没自己实现 IPsec 风格的加密，纯粹站在 WireGuard 之上做身份编排。

NAT 穿透：MagicDNS + STUN/ICE 风格

Tailscale 的 NAT 穿透流程：

1. 节点 A、B 都上线，向 control plane 注册自己的公网端点（IP:port，由 STUN 检测）
2. A 想 ping 100.x.x.x（B 的 Tailscale IP）
3. A 先用 B 的公网端点尝试直连 WireGuard
4. 直连成功 → 流量永远走直连
5. 直连失败（双方都在 NAT 后）→ A 通过 DERP 服务器中继（每个 Tailscale 节点自动接入最近的 DERP）

DERP 不只是兜底：Tailscale 全球自建了 100+ DERP 中继节点（截至 2025 年），用户也可以自建 DERP 提高合规性。Tailscale 客户端会自动选择延迟最低的 DERP。

一个本地起步案例

# 1. 在 macOS/Linux/Windows 上安装 tailscale
# macOS: brew install tailscale
# Linux: curl -fsSL https://tailscale.com/install.sh | sh

# 2. 登录（OAuth）
sudo tailscale up
# 浏览器跳转到 Google/Microsoft/GitHub 登录
# 登录后自动获得 100.x.x.x 的 Tailscale IP

# 3. 在另一台机器上重复，得到另一台 100.y.y.y
# 现在两台机器可以互访

跨平台覆盖：

• Linux：用户态 tun（用 wireguard-go 或 Linux 内核 WireGuard）
• macOS / Windows：用户态 tun（utun/wintun）
• iOS / Android：原生 SDK，UI 在系统层
• Synology NAS：通过包管理器安装
• AWS / GCP / Azure 虚拟机：标准 Linux 安装

ACL：身份驱动的策略

Tailscale 的 ACL 是 JSON 格式的：

{
  "acls": [
    {"action": "accept", "src": ["group:dev"], "dst": ["tag:web:80,443"]},
    {"action": "accept", "src": ["autogroup:members"], "dst": ["*:*"]},
    {"action": "accept", "src": ["autogroup:internet"], "dst": ["*:*"]}
  ],
  "groups": {
    "group:dev": ["user1@example.com", "user2@example.com"]
  },
  "tagOwners": {
    "tag:web": ["autogroup:admin"]
  }
}

策略关键概念：

• users / groups：从 OAuth 身份拉取（不是用户自己声明）
• tags：节点自定义标签（如 tag:prod-db），用于节点角色识别
• autogroup：预定义组（autogroup:members = 所有成员；autogroup:internet = 出口节点）

策略推送到所有节点后，由客户端本地执行——不需要中心网关。

与 ZeroTier、Cloudflare Tunnel 的取舍

决策建议：

• 开发者/SRE 个人/小团队 → Tailscale（上手最快）
• 大规模企业 / 自建合规 → Headscale（自托管控制面）
• 只暴露内网服务给公网，不做 mesh → Cloudflare Tunnel
• 要协议兼容既有 ZeroTier 节点 → ZeroTier

MagicDNS：Tailscale 自带的内网 DNS

装好 Tailscale 后，你不仅可以用 IP 访问对端，还能直接用 hostname：

# 默认配置
ping my-macbook              # 100.100.100.101

# 自定义 hostname
ssh pi4                       # 你的 Raspberry Pi 的 hostname
curl http://nas.local:8080    # 局域网服务

MagicDNS 把"设备 hostname → Tailscale IP"的映射自动同步，不需要你维护 /etc/hosts。它也支持 split DNS：让特定的域名走指定 DNS 服务器（比如公司内网域名走内网 DNS）。

共享节点 / 出口节点 / 子网路由

Tailscale 的几个关键共享能力：

1. 共享节点：节点 A 标记为"共享给 user B"，B 可以连接 A 上的服务（但看不到 A 内部其它流量）
2. 出口节点（Exit Node）：节点 A 标记为 exit node，其它节点的流量通过 A 转发（相当于"用 A 的网络出口"）
3. 子网路由（Subnet Router）：节点 A 暴露它所在的局域网段（如 192.168.1.0/24），让其它 Tailscale 节点能访问 A 背后的 LAN

这让 Tailscale 不只是"个人 VPN"，也能做"跨云内网互通"——比如把 AWS VPC 和办公网络通过一台 Subnet Router 接通。

自托管 Headscale

Tailscale 公司提供商业 SaaS，但也开源了大部分客户端代码。如果你需要自托管控制面（合规要求、数据主权）：

# 启动 Headscale（兼容 Tailscale 客户端的控制面）
docker run -d --name headscale \
  -v /var/lib/headscale:/etc/headscale \
  -p 8080:8080 -p 9090:9090 \
  headscale/headscale:latest serve

客户端配置：

sudo tailscale up --login-server=https://headscale.example.com

Headscale 是社区维护的 Tailscale 兼容控制面，UI 较弱（没有商业版控制台的"设备分组可视化"），但 API 完整。

常见坑

1. DERP 中继带宽限制

DERP 是 Tailscale 自建的中继，免费版没明确带宽上限但单节点吞吐 ~50Mbps。如果有跨洲大流量需求，自建 DERP 或用商业版。

2. ACL 配置错误导致全员锁死

{"action": "drop", "src": ["*"], "dst": ["*"]}

如果手抖写了这条 push，所有节点立刻无法互通。Tailscale 的"测试 ACL"功能会在 push 前模拟规则，让你看到影响范围。

3. MagicDNS 与内网 DNS 冲突

MagicDNS 强制接管 100.100.100.100 作为 DNS 服务器。如果你的内网已经有 DNS 推送，要配置 split DNS：

{
  "dns": {
    "routes": {
      "internal.corp": ["10.0.0.53"]
    },
    "magicDNS": true
  }
}

何时用 / 何时不用

适合：

• 远程办公 / 分布式团队
• 跨云 VPC 互通（AWS + GCP + Azure + 自建机房）
• 调试时需要"家里电脑 / 公司电脑 / 服务器"互通
• IoT 设备远程接入（用 Raspberry Pi + Tailscale）
• 给客户共享测试环境（用共享节点）

不适合：

• 大规模企业生产流量（流量大、合规严）——直接用 WireGuard 自建或 Cisco/Arista 商用方案
• 需要客户端在用户设备上无感安装——Tailscale 是显式安装
• 已经深度绑定 ZeroTier / WireGuard 自建的场景——切换成本

阅读路径

1. 官方文档 tailscale.com/kb——先看 “How Tailscale works”
2. 源码 cmd/tailscaled/——理解 daemon 启动流程
3. 协议：DERP 协议在仓库 derp/，WireGuard 是外部依赖
4. Headscale 文档 headscale.net——如果要自托管

参考资源

• 仓库：https://github.com/tailscale/tailscale
• 自托管控制面：https://github.com/juanfont/headscale
• 官方博客 “How Tailscale works” 系列：https://tailscale.com/blog/how-tailscale-works/
• WireGuard 论文 / 协议：https://www.wireguard.com/protocol/