Tailscale tailnet lock 到底能防護什麼？

Tailnet lock 的防護範圍

Tailnet lock 是 Tailscale 的功能，可阻止 Tailscale 自有的協調伺服器將裝置加入您的 tailnet。啟用後，您的節點會拒絕任何未經您已信任之電腦所持有的金鑰簽署的 node key。因此，控制平面仍可分發金鑰，但無法再建立成員。這項保證的範圍刻意設得很小。Tailnet lock 只保護裝置加入的時刻，對於金鑰已遭竊取的裝置則不起作用。

在一般 tailnet 中，每個節點都會自行產生 WireGuard 金鑰，且不會將私密金鑰部分傳送到任何地方。協調伺服器是所有用戶端都會連線的控制平面，負責分發公開金鑰，並告知每個節點哪些裝置屬於 tailnet。這就是 Tailscale 的協調伺服器與金鑰分發 所依據的設計，也正是 Tailscale 絕不持有用來加密流量的金鑰 的原因。這也表示控制平面會自行決定成員資格。控制該平面的攻擊者可以將一個額外的 node key 發布到您的 tailnet，而您的節點會對其進行加密，因為通訊協定沒有提供任何機制，讓節點分辨遭注入的金鑰與真正的金鑰。

精確陳述威脅模型

tailnet lock 所回答的攻擊者模型，是能控制 coordination server 的一方。這包括 Tailscale 基礎架構遭到入侵、其中的惡意內部人員，以及迫使 Tailscale 採取行動的命令。針對這類攻擊者，也只有這類攻擊者，tailnet lock 會把答案從「攻擊者可以新增節點」改為「攻擊者不能新增節點，而且這次嘗試會被發現」。

其運作機制是由您掌握的簽章鏈。每個簽章節點都會在本機產生 tailnet lock key (TLK)，並將其保留在該裝置上。您的 tailnet 會取得一份只能追加的權限更新日誌，也就是 tailnet key authority (TKA)；每個節點都會保留這份日誌的副本。若節點金鑰未附有目前受信任 TLK 的有效簽章，系統就會拒絕該金鑰，因此對等節點不會取得連線，並會顯示為 locked out。Tailscale 的白皮書明確說明結果：啟用 tailnet lock 後，Tailscale 基礎架構無法將未經授權的節點新增至 tailnet，而且任何此類嘗試都能被偵測及阻擋。

以下 4 件事不在其防護範圍內。對大多數 tailnet 而言，這 4 件事的重要性都高於它能防護的情況。

• 遭竊的裝置。 簽章只能記錄受信任的管理員曾在某個時間點核准該節點金鑰。它無法說明目前持有該筆電的人是誰。
• 遭入侵的簽章節點。 Tailscale 自己的限制清單直接指出：tailnet lock keys 儲存在裝置上，因此取得該裝置的攻擊者也能取得金鑰。簽章節點應採用與保存 root SSH key 的機器相同的保護標準，也就是 產生、儲存及輪替 SSH 金鑰 中說明的做法。
• 阻斷服務。 白皮書明確指出，tailnet lock 防護的是未經授權的節點，而不是阻斷服務。惡意的 control plane 仍可停止分發更新並中斷您的連線，但無法成為 tailnet 成員。
• 最初的 5 分鐘。 請參閱下一節，因為這正是人們常略過的部分。

為何 tailnet lock 採用首次使用時信任

啟用 tailnet lock 時，初始的受信任金鑰集合會經由 control plane 傳送到各節點，而 control plane 正是你要移除信任的對象。每個節點第一次會接受收到的內容，之後便依此強制執行。Tailscale 的白皮書將這個缺口稱為：tailnet lock 首次啟用時，每個節點都會依賴 control plane 傳送給它的 tailnet lock 初始狀態。若 control plane 在當時已遭入侵，攻擊者就能植入包含其金鑰的金鑰集合，之後的每個簽章都會通過驗證。

這就是首次使用時信任（TOFU），採用的模型與你在首次 SSH 連線時接受主機金鑰指紋相同。沒有外部權威可供比對，因此必須由你手動執行檢查。

tailscale lock status

啟用後，請在多個節點上執行該命令。將每個節點回報的受信任 tlpub: 值，與實際由簽署節點輸出的金鑰進行比對。請透過不依賴 tailnet 的管道進行比對，因為植入惡意金鑰集合的 control plane 也能查看你用來檢查的聊天內容。這是一次性工作，只需十分鐘，也是你與「保護空無一物的鎖」之間唯一的防線。

啟用前請先確認這些事項

• 每個需要持續運作的節點都必須使用 Tailscale v1.46.1 或更新版本。這是 Tailscale 文件針對 tailnet lock 列出的最低版本。請在每個節點上執行 tailscale version，包括曾經註冊後便被遺忘的路由器或設備。
• 您至少必須選取 2 個簽署節點。原因不在於形式，而是簽署金鑰儲存在這些設備上。因此，只有 1 個簽署節點時，只要磁碟故障，就可能導致整個 tailnet 永遠無法再加入新機器。
• Android 設備無法作為簽署節點，因為它無法執行簽署作業。
• Tailnet lock 與設備核准是互斥功能。如果您的 tailnet 已要求手動核准設備，便必須在兩者之間擇一，無法同時啟用。
• 截至 September 2026，Tailscale 文件將 tailnet lock 列在 Personal 和 Enterprise 方案中。因此，在安全性審查中承諾提供此控制項前，請先確認您的方案。

如何啟用 tailnet lock

管理主控台會產生命令，您必須在機器上執行該命令。兩個步驟缺一不可。

1. 在管理主控台中開啟 Device management 頁面，選擇啟用 tailnet lock。
2. 選取您要信任其 tailnet lock 金鑰的節點。至少選擇 2 個節點，並確保可以實際接觸這些硬體。
3. 決定是否將 1 組停用密鑰傳送給 Tailscale 支援團隊。回答前請先閱讀下一節。
4. 複製主控台產生的 tailscale lock init 命令。您選取的每個簽署節點都會對應 1 個 tlpub: 引數。
5. 在其中 1 個簽署節點上執行該命令。

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"

簽署者會隨時間變更，以下 2 個命令可處理這些變更。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 會顯示最近的授權歷程。當節點遭鎖定且沒有人記得曾變更設定時，請查看這項資訊。

10 組停用密鑰，以及它們為何是高風險部分

tailscale lock init 會列印 10 組停用密鑰。這些密鑰只會在初始化時顯示一次，之後不會再次顯示。只要其中任意一組，就能關閉整個 tailnet 的 tailnet lock：

tailscale lock disable "DISABLEMENT_SECRET"

Tailscale 的文件直接說明了後果：如果遺失所有停用密鑰，且沒有將其中一組提供給 Tailscale support，就無法復原該 tailnet。實際情況可能是這樣：兩個簽署節點分別是一台已清除資料的筆記型電腦，以及一台已刪除的 VPS。沒有人能簽署新的節點金鑰、加入簽署節點，或關閉鎖定。現有成員仍可繼續使用 tailnet，但永久無法加入新成員。唯一的解決方式，是建立新的 tailnet，並重新註冊所有項目。

因此，請像保存復原碼一樣保存這些密鑰。至少保留兩份副本，存放在不會同時依賴 tailnet 可連線性的不同位置，並讓其中一份保持離線。只存放在必須透過 tailnet 連線才能存取的伺服器上的副本，不能算是真正的備份。

是否使用支援選項，應該經過實際評估，不要直接採用預設做法。將一組密鑰提供給 Tailscale support，代表 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 repository 的 Issue 15266 於 March 2025 提出，目前仍未關閉。該問題指出，Terraform 並行執行 tailscale lock sign 時，可能會收到空白的已簽署金鑰，因此部分節點會在鎖定狀態下啟動，其他節點則正常運作。回報者的因應方式是一次只簽署一個金鑰，並在呼叫之間短暫停頓。請讓自動化流程確認命令回傳的是非空白金鑰，再將其儲存。

第二，已簽署的 auth key 會留下狀態。簽署會將金鑰加入 authority；即使使用該金鑰建立的節點已刪除，金鑰仍會保留。July 2025 的 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，讓金鑰數量是你掌握的資訊，而不是事後才發現的問題。

Ephemeral 與 CI 節點需要規劃

Ephemeral 節點會在登出時從 tailnet 中移除，但它們仍然是節點，因此仍需要簽章才能與其他項目通訊。加入 tailnet 以執行部署的 CI 工作，同樣需要預先簽署的 auth key，就像長期執行的伺服器一樣。金鑰累積問題在 CI 環境中最嚴重，因為 CI 會建立並銷毀最多節點。

可行的做法是在 CI secret store 中保存一個已簽署、可重複使用的 ephemeral auth key，依選定的排程輪替，而不是每次工作執行時都輪替。每次輪替都會在 authority 中消耗一個金鑰，這個數量可以預先納入規劃。每個工作各自簽署金鑰，才會產生 552 個金鑰。

同樣的考量也適用於承載其他機器網路流量的伺服器。從 VPS 廣告私有範圍的 subnet router 代表其後方的每個位址通訊，因此位於該位置的遭注入節點可觸及遠多於一台主機的範圍。這些伺服器應使用已簽署的金鑰進行佈建，並排除在完全自動化的流程之外。

兩個脫離機制及其作用

tailscale lock disable <disablement-secret> 會關閉整個 tailnet 的 tailnet lock。它需要 10 組 secret 其中之一。當問題出在授權機制本身時，應使用這個指令。

tailscale lock local-disable

tailscale lock local-disable 是單一節點的脫離機制，但其適用範圍經常被誤解。它會讓執行該指令的節點停止強制執行 tailnet lock，因此該節點會接受金鑰未經簽署的對等節點。它不會讓其他節點接受該節點未經簽署的金鑰。對遭拒於系統之外的伺服器執行 local-disable，不會因此讓其他節點能連線到該伺服器。這也是 Tailscale 文件說明要在每個節點上執行該指令，才能讓整個 tailnet 實際上忽略 tailnet lock 的原因。請將此視為暫時解除單一節點強制執行的緊急措施，待該節點目前無法簽署的問題排除後，正確簽署該節點，並停止關閉強制執行。

誰應啟用 tailnet lock，誰不應啟用

如果節點核准機制必須在有人離職後仍能維持，請啟用它。未啟用 lock 時，任何具有主控台管理權限的人都能新增機器。啟用 lock 後，新增機器還需要持有受信任簽署金鑰的裝置，因此即使忘記撤銷離職管理員的主控台存取權限，該管理員仍無法加入節點。如果客戶的第三方風險問卷要求說明如何防止 VPN 廠商加入您的網路，也請啟用它，因為這項控制能以實際機制回答，而不是只提出承諾。

對於只有一個人使用，且包含一台筆記型電腦、一支手機和一台 VPS 的 tailnet，請不要啟用它。這類 tailnet 面臨的實際威脅是您失去存取權，而不是 Tailscale 遭到入侵。tailnet lock 會新增十個您必須永久正確保存的 secret；一旦遺失便無法復原。因此，為了降低您不會面臨的風險，反而提高了您實際面臨的風險。對於沒有清楚記錄各個簽署裝置持有者的小型團隊，理由也相同。請先做好這項管理，因為 tailnet lock 本質上就是附帶永久故障模式的管理工作。

Headscale 以不同方式回答相同問題

如果疑慮在於由第三方決定誰能加入您的網路，則有兩種解法。Tailnet lock 保留 Tailscale 的協調伺服器，但移除其新增成員的權限。執行您自行託管的開放原始碼協調伺服器 Headscale 則是移除該伺服器，並由您同時承擔控制權與維運工作，包括修補、備份，以及凌晨 2 點必須由您處理的服務中斷。兩者在抽象層面上都沒有比較安全。請根據您較願意承擔哪一種故障來選擇：受您限制的託管控制平面，或由您自行運作的控制平面。

FAQ

tailnet lock 實際上會阻止什麼？

它會阻止 Tailscale 的 coordination server 將節點加入您的 tailnet。啟用 tailnet lock 後，只有在您控制的 signing node 使用其 tailnet lock key 簽署 node key 後，該 node key 才會被接受。因此，即使 control plane 遭到入侵並散布金鑰，也無法加入新的成員。它不會額外加密任何內容，因為節點之間的流量本來就已使用 WireGuard key 進行端對端加密，而 coordination server 從未持有這些 key。它也無法防範遭竊的裝置、遭入侵的 signing node，或只是停止提供您的 tailnet 服務的 control plane。

如果我遺失全部 ten 個 disablement secret，會發生什麼事？

tailscale lock init 執行時會顯示這些 secret，之後不會再次顯示。如果您遺失全部 secret，且未將其中一個傳送給 Tailscale support，文件指出該 tailnet 將無法復原。實務上，如果您也失去所有 signing node，就無法再簽署任何 node key，也無法關閉 lock，因此唯一可行的方式是建立新的 tailnet，並重新註冊所有裝置。請將兩份副本保存於不會同時依賴 tailnet 運作的位置，並讓其中一份保持離線。

我必須手動簽署每個新裝置嗎？

不必。請改為簽署 auth key，而不是節點。在 signing node 上匯出該 key，然後執行 tailscale lock sign $AUTH_KEY，再將該命令顯示的 signed value 傳給映像檔或佈建工具中的 tailscale up --auth-key。以這種方式建立的節點會以已簽署狀態加入。請簽署少量可重複使用的 key，而不是每台機器各簽署一個，因為每個 signed key 都會在節點移除後，繼續為 authority 增加一個 key；而 authority 最多只能有 512 個 key，實務上的自動化流程已曾達到這項上限。

tailnet lock 和 device approval 相同嗎？

不相同，而且兩者無法同時執行，因為它們是互斥的功能。device approval 是 admin console 中的政策檢查：管理員必須先勾選選項，新裝置才能取得存取權，而 coordination server 會強制執行該決定。tailnet lock 則是由您自己的節點執行的密碼編譯檢查，使用保存在您自有硬體上的 key，因此即使 coordination server 具有惡意，也仍然有效。device approval 是管理使用者時較輕量的控制機制。tailnet lock 則是用來回答與供應商相關問題的機制。