Tailscale tailnet lock 到底能防什么

Tailnet lock 的防护范围

Tailnet lock 是 Tailscale 提供的功能，可阻止 Tailscale 自己的协调服务器向您的 tailnet 添加设备。启用后，您的节点会拒绝任何未由受信任机器上保存的密钥签名的节点密钥。因此，控制平面仍会分发密钥，但无法再创建成员。这个功能的保护范围有意保持有限。Tailnet lock 保护的是设备加入 tailnet 的时刻，对密钥已经被窃取的设备不起作用。

在普通 tailnet 中，每个节点都会生成自己的 WireGuard 密钥，并且不会将私钥发送到任何地方。协调服务器是所有客户端都会连接的控制平面，负责分发公钥，并告知每个节点哪些设备属于该 tailnet。Tailscale 的协调服务器和密钥分发正是基于这一设计，Tailscale 从不持有用于加密您流量的密钥也是如此。这也意味着控制平面可以自行决定成员关系。控制该控制平面的人员可以将一个额外的节点密钥发布到您的 tailnet 中，而您的节点会向该节点加密发送流量，因为协议没有提供任何机制，让节点区分注入的密钥和真实密钥。

精确定义威胁模型

tailnet lock 防范的攻击者，是能够控制协调服务器的一方。这包括 Tailscale 基础设施遭到入侵、Tailscale 内部人员恶意操作，以及迫使 Tailscale 执行某项操作的命令。仅针对这一类攻击者，tailnet lock 才会将结果从“攻击者可以添加节点”改为“攻击者无法添加节点，且该尝试可被发现”。

其机制是一条由您控制的签名链。每个签名节点都会在本地生成 tailnet lock 密钥（TLK），并将其保存在该设备上。您的 tailnet 会获得一个仅可追加的权限更新日志，即 tailnet 密钥授权机构（TKA）；每个节点都保存该日志的副本。没有当前受信任 TLK 的有效签名的节点密钥会被拒绝，因此对端无法建立连接，并会显示为被锁定。Tailscale 白皮书明确说明了结果：在启用 tailnet lock 的情况下，Tailscale 基础设施无法向 tailnet 添加未经授权的节点，任何此类尝试都可以被检测并阻止。

它无法覆盖以下四种情况，而对大多数 tailnet 而言，这四种风险都比它能够覆盖的风险更重要。

• 设备被盗。 签名只能记录某个受信任的管理员曾在某个时间批准了该节点密钥。它无法说明当前持有笔记本电脑的人是谁。
• 签名节点遭到入侵。 Tailscale 自己的限制说明直接指出：tailnet lock 密钥保存在设备上，因此取得该设备的攻击者也能取得该密钥。签名节点应按保存 root SSH 密钥的机器进行保护，这与生成、存储和轮换 SSH 密钥中介绍的做法相同。
• 拒绝服务。 白皮书明确指出，tailnet lock 防护的是未经授权的节点，而不是拒绝服务。恶意控制平面仍可停止分发更新并中断您的连接。它只是无法成为 tailnet 的成员。
• 最初的 5 分钟。 请参阅下一节，因为这是人们最容易跳过的部分。

为什么 tailnet lock 属于首次使用时信任

启用 tailnet lock 后，初始受信任密钥集合会通过控制平面发送到各个节点，而控制平面正是您试图取消信任的一方。每个节点首次都会接受收到的内容，之后始终按该内容执行。Tailscale 白皮书将这一缺口称为：首次启用 tailnet lock 时，每个节点都依赖控制平面发送给它的 tailnet lock 初始状态。如果控制平面当时已经遭到入侵，攻击者就可以植入包含其密钥的密钥集合，之后的每个签名都会通过验证。

这就是首次使用时信任（TOFU），其模型与您首次连接 SSH 时接受主机密钥指纹相同。没有外部权威可供核对，因此必须手动检查，而且需要由您执行。

tailscale lock status

启用后，在多个节点上运行该命令。将每个节点报告的受信任 tlpub: 值，与实际打印这些密钥的签名节点提供的值进行比较。请通过不依赖 tailnet 的渠道进行比较，因为植入恶意密钥集合的受攻击控制平面也可能看到您用于核对的聊天内容。这项工作只需执行一次，大约需要十分钟，也是保护您免受无效锁影响的唯一措施。

启用前请检查这些事项

• 要继续正常运行的每个节点都需要 Tailscale v1.46.1 或更高版本。这是 Tailscale 文档为 tailnet lock 指定的最低版本。在每个节点上运行 tailscale version，包括曾经注册过但后来被遗忘的路由器或设备。
• 必须至少选择两个签名节点。这不是形式要求：签名密钥存储在这些设备上。只有一个签名节点时，只要该设备的磁盘损坏，整个 tailnet 就可能永远无法添加新设备。
• Android 设备不能充当签名节点，因为它无法执行签名操作。
• Tailnet lock 与设备审批是互斥功能。如果您的 tailnet 已要求手动审批设备，您必须在两者之间选择，不能同时启用。
• 截至 2026 年 9 月，Tailscale 文档将 tailnet lock 列在 Personal 和 Enterprise 计划中。因此，在安全评审中承诺提供此控制措施前，请先确认您的计划。

如何启用 tailnet lock

管理控制台会生成命令，您需要在一台机器上运行该命令。两部分缺一不可。

1. 在管理控制台中打开 Device management 页面，然后选择启用 tailnet lock。
2. 选择要信任其 tailnet lock 密钥的节点。至少选择两个节点，并确保可以实际接触到这些节点所在的硬件。
3. 决定是否向 Tailscale 支持团队发送一个禁用密钥。在作出决定前，请阅读下一节。
4. 复制控制台生成的 tailscale lock init 命令。该命令会为您选择的每个签名节点包含一个 tlpub: 参数。
5. 在其中一个签名节点上运行该命令。

tailscale lock init "tlpub:SIGNING_NODE_1_KEY" "tlpub:SIGNING_NODE_2_KEY"

tailnet 中已有的每个节点都会在初始化期间由受信任密钥签名，因此现有功能不会中断。变化发生在新节点上。加入已锁定 tailnet 的机器会带有未签名的节点密钥，该机器上的 tailscale lock status 会显示这一点：

This node is LOCKED OUT by tailnet-lock, and action is required to establish connectivity.

管理控制台会将相同状态显示为 Locked out 徽标，machines-list 筛选器 property:locked-out 可以一次找到所有此类节点。被锁定节点的状态输出还会打印用于修复该问题的确切命令。复制该行，并在签名节点上运行：

tailscale lock sign "nodekey:NODE_KEY" "tlpub:ROTATION_KEY"

签名节点会随时间变化，以下两个命令用于管理这些变化。tailscale lock add tlpub:<key> 用于信任新的签名节点。tailscale lock remove tlpub:<key> 用于停用某个签名节点；默认情况下，该命令会重新签名由已停用密钥签名的节点，使这些节点继续工作。使用 --re-sign=false 可以禁止此行为。如果签名节点是被盗而不是正常停用，应改用 tailscale lock revoke-keys tlpub:<key>。该命令会使用 --cosign 在其余签名节点之间分阶段执行，然后使用 --finish。tailscale lock log --limit 20 用于输出最近的权限历史记录。节点被锁定且无人记得进行过任何更改时，应查看此记录。

十个解除锁定密钥，以及它们为何是风险所在

tailscale lock init 会输出十个解除锁定密钥。它们只会在初始化时显示一次，之后不再显示。其中任何一个都可以关闭整个 tailnet 的 tailnet lock：

tailscale lock disable "DISABLEMENT_SECRET"

Tailscale 文档明确说明了后果：如果您丢失了所有解除锁定密钥，且没有向 Tailscale 支持团队提供其中一个密钥，就无法恢复该 tailnet。设想一下实际情况：您的两个签名节点分别是一台已被清除数据的笔记本电脑和一台已删除的 VPS。任何人都无法为新节点签名，无法添加签名节点，也无法关闭锁定。现有成员仍可继续使用该 tailnet，但它将永久拒绝新成员。唯一的解决办法是创建新的 tailnet，并重新注册所有设备。

因此，请像保存恢复代码一样保存这些密钥。至少保留两份副本，并将它们存放在两个不同时依赖 tailnet 可访问性的地点，其中一份应保持离线。若某份副本只存放在必须通过 tailnet 访问的服务器上，它就不能算作备份。

是否使用支持选项，需要认真决策，而不应直接采用默认设置。将一个密钥发送给 Tailscale 支持团队，意味着 Tailscale 可以关闭您的 tailnet lock，也意味着您将部分保障交还给该功能正是为了约束的对象。同时，这也意味着即使您丢失了保存密钥的文件夹，tailnet 仍不会因此失效。如果您启用 tailnet lock，是因为第三方风险评估要求您说明 VPN 供应商遭到入侵时会发生什么，就不要发送该密钥。如果您启用它，是因为管理员会更替，而您希望节点加入权限与设备绑定，那么可以发送该密钥，从而更安心。

无人值守配置为何会失败，以及如何修复

这是团队通常会在一周内遇到的问题。在受限的 tailnet 中，一台启动后运行 tailscale up 的机器如果使用普通 auth key 加入，就会被锁定在外。自动化流程报告成功，节点也会出现在控制台中，但没有任何连接可以到达它。必须在节点存在之前完成签名，而不是事后签名。因此，需要对 auth key 进行签名。

AUTH_KEY="tskey-auth-xxxxxxxxxxxxxxxx"
tailscale lock sign $AUTH_KEY

在签名节点上运行该命令。它会输出 auth key 的签名版本。镜像、cloud-init 文件或 Terraform 变量将该签名值传递给 tailscale up --auth-key。使用该值创建的节点会以已签名状态加入，并且可以访问。

在遇到以下问题之前，应先了解两种失败模式。首先，签名不适合并发执行。tailscale/tailscale 仓库中的 Issue 15266 于 2025 年 3 月提交，目前仍未关闭。该问题报告称，Terraform 并发调用 tailscale lock sign 时会返回空的签名密钥，导致部分节点启动后被锁定在外，而其他节点正常运行。报告者的解决方法是一次只签名一个密钥，并在调用之间短暂暂停。自动化流程应检查命令是否返回非空密钥，然后再保存该密钥。

其次，签名的 auth key 会留下状态数据。签名会向 authority 添加密钥。即使由该密钥创建的节点已被删除，该密钥仍会保留。2025 年 7 月的 Issue 16607 描述了这样一种自动化流程：每次部署都为新密钥签名，直到 authority 达到上限：

network-lock modify failed: modify network-lock keys: generating checkpoint: generated update was invalid: checkpoint state: too many keys (552, max 512)

此时，tailnet 既无法添加密钥，也无法删除多余密钥，因为删除操作本身也是一次 authority 更新，并且必须生成有效的 checkpoint。应少量签名密钥并重复使用，而不是为每台机器分别签名；还应定期检查 tailscale lock log，确保密钥数量处于已知状态，而不是等到达到上限后才发现。

临时节点和 CI 节点需要规划

临时节点在注销时会从 tailnet 中移除，但它们仍然是节点，因此仍需要签名才能与其他对象通信。加入 tailnet 执行部署的 CI 任务，同样需要预先签名的身份验证密钥，就像长期运行的服务器一样。上述密钥累积问题在 CI 中尤其严重，因为 CI 创建和销毁的节点最多。

可行的做法是：在 CI 密钥存储中保存一个已签名、可重复使用的临时身份验证密钥，并按您选择的计划轮换，而不是在每次任务运行时轮换。每次轮换都会在授权方消耗一个密钥，因此可以提前规划这个数量。按每个任务签名才会产生 552 个密钥。

同样的原则也适用于承载其他机器流量的服务器。从 VPS 广播私有地址段的子网路由器会代表其后方的每个地址通信，因此位于该位置的注入节点可以访问远超单台主机的资源。这些服务器应使用已签名的密钥进行配置，并排除在完全自动化流程之外。

两个紧急解锁方式及其作用

tailscale lock disable <disablement-secret> 会为整个 tailnet 关闭 tailnet lock。它需要 10 个密钥中的一个；当问题出在授权机构本身时，应使用此方式。

tailscale lock local-disable

tailscale lock local-disable 是针对单个节点的解锁方式，其作用范围经常被误解。它会让执行该命令的节点停止强制执行 tailnet lock，因此该节点会接受密钥未签名的对等节点。它不会让其他节点接受该节点未签名的密钥。在被锁定而无法访问的服务器上执行 local-disable，不会使其他节点因此能够访问该服务器。这就是为什么 Tailscale 文档要求在每个节点上执行该命令，才能让整个 tailnet 实际上忽略 tailnet lock。对于当前无法完成签名的节点，应将其视为紧急解锁措施；随后应正确签名该节点，并停止关闭强制执行。

哪些人应启用 tailnet lock，哪些人不应启用

如果节点准入必须在人员离职后仍然安全，请启用它。未启用 tailnet lock 时，拥有控制台管理员权限的任何人都可以添加机器。启用后，添加机器还需要一台持有受信任签名密钥的设备。因此，即使您忘记撤销离职管理员的控制台访问权限，该管理员也无法引入节点。如果客户的第三方风险问卷要求说明如何阻止 VPN 供应商加入您的网络，也应启用它。这个控制通过实际机制回答了该问题，而不是停留在承诺上。

如果 tailnet 只有一个人使用，并且包含一台笔记本电脑、一部手机和一台 VPS，请不要启用它。该 tailnet 面临的实际威胁是您失去访问权限，而不是 Tailscale 被攻破。tailnet lock 会增加 10 个必须永久妥善保存的机密；一旦丢失，无法恢复。因此，它会为了降低一个并不存在的风险，增加您实际面临的风险。对于没有记录每个签名设备由谁持有的小团队，情况也一样。请先完善这份清单，因为 tailnet lock 本质上是带有永久故障模式的资产记录管理。

Headscale 以另一种方式回答同一个问题

如果你反对的是由第三方决定谁可以加入网络，那么有两种解决方案。Tailnet lock 保留 Tailscale 的协调服务器，但限制其添加成员的权限。运行由您自行托管的开源协调服务器 Headscale则会移除该服务器，您需要同时承担控制权和运维工作，包括打补丁、备份，以及在凌晨两点自行修复中断。抽象地说，这两种方案都不会更安全。应根据您更愿意承担哪种故障风险来选择：受限的托管控制平面，还是由您自行运行的控制平面。

FAQ

tailnet lock 实际会阻止什么？

它会阻止 Tailscale 的协调服务器向您的 tailnet 添加节点。启用 tailnet lock 后，只有在您控制的签名节点使用其 tailnet lock 密钥为节点密钥签名后，该节点密钥才会被接受。因此，即使控制平面已遭入侵，也只能分发密钥，无法引入新的成员。它不会额外加密任何内容，因为节点之间的流量已经使用 WireGuard 密钥进行端到端加密，而协调服务器从未持有这些密钥。它也无法防御设备被盗、签名节点遭入侵，或控制平面仅停止为您的 tailnet 提供服务的情况。

如果我丢失了全部 10 个禁用密钥，会发生什么？

tailscale lock init 运行时会显示这些密钥，之后不会再次显示。如果您丢失了全部密钥，也没有将其中一个发送给 Tailscale 支持团队，文档说明该 tailnet 无法恢复。实际上，如果您还失去了签名节点，就无法再为其他节点密钥签名，也无法关闭锁定。因此，唯一的后续方案是创建新的 tailnet，并重新注册所有设备。请将副本保存在两个不同时依赖 tailnet 正常运行的位置，并确保其中一个副本处于离线状态。

我必须手动为每台新设备签名吗？

不必。请为身份验证密钥签名，而不是为节点签名。在签名节点上导出密钥并运行 tailscale lock sign $AUTH_KEY，然后将该命令输出的已签名值传递给镜像或配置工具中的 tailscale up --auth-key。通过这种方式创建的节点会自动处于已签名状态。请为少量可重复使用的密钥签名，而不是为每台机器分别创建一个密钥，因为每个已签名密钥都会向授权机构添加一个密钥，即使节点已删除，该密钥仍会保留；此外，授权机构最多支持 512 个密钥，实际自动化部署中曾达到这一上限。

tailnet lock 与设备审批相同吗？

不相同，而且两者不能同时运行，因为它们是互斥功能。设备审批是管理控制台中的策略检查：管理员在新设备获得访问权限前选中一个复选框，协调服务器负责执行该决定。tailnet lock 是由您自己的节点执行的加密检查，使用存储在您自有硬件上的密钥，因此即使协调服务器具有恶意行为，它仍然有效。设备审批是管理用户时更轻量的控制措施。tailnet lock 则用于回答有关供应商的信任问题。