Tailscale 架构

Tailscale 在 WireGuard 之上提供设备身份、密钥分发、访问策略、地址与 DNS 管理，以及自动寻找可用传输路径的能力。理解它最直接的方法，是跟踪“笔记本访问公司服务器的 HTTPS 服务”：先知道对方是谁、是否允许连接，再决定加密包如何到达，最后才是应用认证与业务操作。

控制平面与数据平面

协调服务把登录身份、节点公钥和网络配置关联起来，向客户端分发所需信息。业务包的正常转发不需要逐包询问协调服务；客户端依据获得的状态进行加密、选路与过滤。集中协调与点对点通信并不矛盾。

数据传输有三类路径：节点间直接 UDP、DERP 中继、tailnet 内的 Peer Relay。它们都可以承载节点之间的 WireGuard 密文，因此“用户数据不经过协调服务”成立，但不能进一步写成“用户数据绝不会经过任何中心服务器”。连接类型

Mesh 表示节点能够按策略建立彼此的覆盖网络连接，并不要求所有设备开机就持续维护所有两两活跃会话。100 台设备有 4,950 对潜在组合；若只有每台客户端访问两台服务端，实际活跃关系由业务决定。公钥分发、路径发现和业务流量也不是同一种开销。

身份：登录凭据不等于隧道私钥

加入网络时，设备在本地生成密钥；用户通过身份提供方登录，或使用 auth key 完成非交互注册。控制面将身份与设备、节点公钥关联，再按配置分发信息。节点私钥留在端点，不应发送给其他 peer 或管理服务器。Tailscale identity

带标签的服务器以标签身份参与策略；不能简单认为给服务器打标签只是给用户名加一个显示备注。标签授予权本身也要管理，否则能给设备贴上高权限标签，就可能改变它能访问的资源。身份与标签

端到端加密仍依赖“拿到的公钥确实属于应该信任的节点”。Tailnet Lock 把节点公钥接受条件增加为由受信节点签名，降低控制面擅自插入节点的风险；它不解决端点已被入侵、应用权限过大或所有可用网络路径被阻断的问题。Tailnet Lock 白皮书

路径建立：先有可用路径，再持续争取直连

常见的建立过程是先通过 DERP 获得可用的中继通道，同时交换发现信息和探测候选地址；直连成功后切换到直接 UDP。若直连无法成立，具备条件的客户端可使用可用 Peer Relay，否则继续使用 DERP。这里要区分“期望的路径优先级”和“首包实际经过的路径”，不能把中继写成所有探测彻底结束后才出现的最后一步。连接建立时序

NAT 穿透需要同时满足地址映射和入口过滤条件。STUN 帮助观察外部映射，并不会替本机创建任意开放的入口；两端探测能促使网关建立允许返回流量的状态，但复杂 NAT、多层网关和 UDP 限制仍可能使直连失败。端口映射协议提供帮助也不等于设备获得了一个不受防火墙约束的公网 IP。基础机制见端口与 NAT。

DERP 除了传输加密业务包，也承载 DISCO 发现消息；因此“访问了 DERP”本身不能证明当前所有业务都经中继。客户端保存 DERP map，并选择合适的中继区域，区域距离和链路条件影响实际表现。DERP servers

Peer Relay 是 tailnet 中被配置为中继的设备，需要适用的客户端版本、可达的中继 UDP 端口和对应使用权限。仅有一台位于公网的普通节点，不会自动让所有 peer 将它当作中继。Peer Relays

中继延迟怎么估算

假设 A 到 B 的直接单向传播为 20 ms，经 R 时 A→R 为 15 ms、R→B 为 35 ms，回程对称且忽略排队：直连 RTT 为 40 ms，中继为 100 ms。这是给定路径的教学预算，不是 DERP 或 Peer Relay 的固定性能。真实吞吐还受丢包、拥塞、CPU、带宽和外层传输影响。

nodes = 100
assert nodes * (nodes - 1) // 2 == 4950
paths_ms = {'direct': [20], 'relay': [15, 35]}
rtt_ms = {name: 2 * sum(hops) for name, hops in paths_ms.items()}
assert rtt_ms == {'direct': 40, 'relay': 100}
# 串行的三个请求往返；不包含握手、计算、排队或传输大对象。
assert 3 * (rtt_ms['relay'] - rtt_ms['direct']) == 180
print('潜在连接数及给定路径延迟预算通过')

授权：网络连通与业务许可分开理解

当前 Tailscale 文档以 grants 描述网络层与应用层能力，ACL 仍受支持。网络层授权可表达“工程组能连接 web 标签设备的 TCP 443”；它不会自动让该用户成为 Web 应用管理员。Grants、ACL

以下是一个独立的最小策略示例，用户名要替换为真实 tailnet 成员；假设目的设备已合法获得 tag:web。在已有策略中追加时，其他宽泛允许项仍会生效，不能把这一条理解成覆盖或撤销已有权限。

{
  "groups": {"group:engineering": ["alice@example.com"]},
  "tagOwners": {"tag:web": ["autogroup:admin"]},
  "grants": [
    {
      "src": ["group:engineering"],
      "dst": ["tag:web"],
      "ip": ["tcp:443"]
    }
  ]
}

这个示例允许匹配主体发起指定连接，返回流量按已允许连接处理；它没有授权服务器任意向客户端新建连接，也没有授予 TCP 22。tagOwners 管理谁可以赋予标签，不是允许谁连接这些设备。Grants 语法

应用层 app 能力需要相应应用集成识别；任意传统 Web 服务不会因为策略文件里出现一个能力名，就自动实施该业务权限。

地址、MagicDNS 与路由是三件事

设备的 Tailscale 地址是覆盖网络中的地址，不是它当前 Wi-Fi 出口的公网地址。换网络时，外层 endpoint 可以变化；应用继续使用同一节点名称或覆盖地址，能减少对底层位置的依赖，但仍受节点注册和地址生命周期约束。

MagicDNS 为 tailnet 设备生成名称，使用户可以用设备名访问。名称解析回答“目标地址是什么”，路由回答“交给哪个接口或网关”，访问策略回答“是否允许”。把传统子网加入 tailnet 后，其已有内部域名也不必然由 MagicDNS 自动注册；通常还需要内部 DNS 与 split DNS 配置。MagicDNS、Subnet routers

子网路由、出口与中继：看谁终止 WireGuard

访问传统服务器时，子网路由器解出内层 IP 包，再把它送入目标网络。如果应用使用 HTTPS，应用层 TLS 可以继续保护到服务器；如果发送明文 HTTP，后半程不会因为前半程有 WireGuard 而自动加密。

Linux 的 kernel routing 与 userspace netstack routing 描述的是解密后如何转发。前者由内核转发内层包；后者在用户态处理连接。不能由“kernel mode”推断 Tailscale 一定把 WireGuard 加解密交给 wireguard.ko。Kernel vs. netstack

子网可访问通常要同时满足路由发布与批准、客户端采用相应路由、策略允许以及转发/回程成立。默认 SNAT 让传统服务器看到路由器地址，简化回程；关闭 SNAT 后，目标网络必须知道如何返回原始来源。保留源 IP 与免配回程路由不是可以同时免费获得的两个效果。子网 SNAT

协调服务离线：已有通信与管理变更的命运不同

客户端缓存密钥和过滤规则，因此控制面不可达时，已有节点间通信可能继续。它不是永久自治：密钥过期、端点变化、缓存不足或所有中继不可达都可能影响连接；新设备加入、刷新密钥、传播新策略和撤销不能按正常流程完成。协调服务故障

这也解释了一个容易忽略的现象：控制面中断时，旧业务继续运行是可用性优势，但管理员希望立即收紧访问时，旧策略仍在执行就成为变更传播问题。故障处理要同时观察连通性和策略的新鲜程度。

控制面断开，哪一种操作先失效？

保持有效缓存和直连，只断开协调服务，蓝色业务路径仍存在；但控制刷新已经不可用。继续撤掉直连，可观察中继是否还能承载；再失去有效状态或所有路径，才触及这里的数据面前提。

从证据定位，而不是看到 relay 就改配置

以下命令供手动诊断；ping 与 netcheck 会发起网络探测。

tailscale status
tailscale ping <peer-name>
tailscale netcheck

status 中的 direct、relay、peer-relay 描述当前观察到的路径，路径可以随时间变化。默认 tailscale ping 用于 Tailscale 层发现/连通检查，与普通 ICMP 或访问业务 TCP 端口不是同一测试；一次成功不能证明 HTTPS 证书有效或 API 授权正确。Ping 类型

排查一次失败访问，可依次记录：名称解析出的地址、客户端选路与节点状态、实际传输路径、目标端口可达性、TLS/应用错误。若只有大响应失败，应继续检查 MTU 与丢包；若经 relay 可用而 direct 不成立，应观察 UDP 可达性与 NAT 条件；若已收到 HTTP 403，就应回到应用认证授权证据，而不是重复调整穿透端口。