Tailnet lock của Tailscale bảo vệ gì?

Tailnet lock bảo vệ gì

Tailnet lock là tính năng của Tailscale ngăn coordination server của chính Tailscale thêm thiết bị vào tailnet của bạn. Khi bật tính năng này, các node của bạn sẽ từ chối mọi node key chưa được ký bằng key lưu trên một máy mà bạn đã tin cậy. Vì vậy, control plane vẫn phân phối key nhưng không thể tự tạo thêm member. Phạm vi bảo vệ này cố ý được giới hạn như vậy. Tailnet lock bảo vệ thời điểm một thiết bị tham gia, nhưng không có tác dụng với thiết bị có key đã bị đánh cắp.

Trong một tailnet thông thường, mỗi node tự tạo WireGuard key và không bao giờ gửi private key đi đâu. Coordination server, tức control plane mà mọi client đều kết nối đến, phân phối public key và cho mỗi node biết những ai thuộc tailnet. Đây là thiết kế mà coordination server và phân phối key của Tailscale dựa trên, đồng thời giải thích vì sao Tailscale không bao giờ giữ các key dùng để mã hóa traffic của bạn. Điều đó cũng có nghĩa là control plane tự quyết định membership. Người kiểm soát được nó có thể đưa thêm một node key vào tailnet của bạn, và các node của bạn sẽ mã hóa traffic gửi đến node đó, vì protocol không cung cấp cách để một node phân biệt key bị chèn với key hợp lệ.

Mô hình mối đe dọa, phát biểu chính xác

Tailnet lock giải quyết mối đe dọa từ một bên kiểm soát coordination server. Trường hợp này bao gồm hạ tầng của Tailscale bị compromise, insider độc hại tại đó và lệnh buộc Tailscale phải hành động. Trước kẻ tấn công này, và chỉ kẻ tấn công này, tailnet lock thay đổi kết luận từ “họ có thể thêm một node” thành “họ không thể thêm node, và nỗ lực đó sẽ bị phát hiện”.

Cơ chế này là một chuỗi chữ ký do bạn kiểm soát. Mỗi signing node tạo một tailnet lock key (TLK) cục bộ và giữ key đó trên thiết bị. Tailnet của bạn có một log chỉ được ghi thêm về các cập nhật quyền hạn, gọi là tailnet key authority (TKA), và mỗi node giữ một bản sao riêng của log đó. Node key không có chữ ký hợp lệ từ một TLK hiện đang được tin cậy sẽ bị từ chối. Vì vậy peer không có kết nối và hiển thị là bị khóa. White paper của Tailscale nêu rõ kết quả: hạ tầng Tailscale không thể thêm node trái phép vào tailnet đã bật tailnet lock, và mọi nỗ lực như vậy đều có thể bị phát hiện và chặn.

Có 4 vấn đề mà tính năng này không giải quyết. Với hầu hết tailnet, cả 4 vấn đề đều quan trọng hơn vấn đề mà tính năng này giải quyết.

• Thiết bị bị đánh cắp. Chữ ký chỉ ghi nhận rằng một admin được tin cậy đã phê duyệt node key đó vào một thời điểm nào đó. Chữ ký không cho biết hiện ai đang giữ laptop.
• Signing node bị compromise. Danh sách giới hạn của chính Tailscale nêu rõ điều này: tailnet lock key được lưu trên thiết bị, nên kẻ tấn công chiếm được thiết bị cũng có thể lấy key. Hãy bảo vệ signing node như cách bạn bảo vệ một máy đang giữ root SSH key. Đây cũng là quy trình được đề cập trong tạo, lưu trữ và xoay vòng SSH key.
• Từ chối dịch vụ. White paper nói rõ rằng tailnet lock bảo vệ trước node trái phép, không bảo vệ trước tấn công từ chối dịch vụ. Control plane độc hại vẫn có thể ngừng phân phối các bản cập nhật và làm hỏng kết nối của bạn. Nó chỉ không thể trở thành một thành viên.
• 5 phút đầu tiên. Hãy xem section tiếp theo, vì đây là phần mọi người thường bỏ qua.

Vì sao tailnet lock dùng mô hình trust on first use

Khi bật tailnet lock, tập key tin cậy ban đầu được gửi đến các node qua control plane, chính bên mà bạn đang cố loại khỏi mô hình tin cậy. Mỗi node chấp nhận thông tin nhận được trong lần đầu và thực thi thông tin đó từ thời điểm này trở đi. White paper của Tailscale gọi tên lỗ hổng này: khi tailnet lock được bật lần đầu, mỗi node dựa vào trạng thái tailnet lock ban đầu do control plane gửi đến. Nếu control plane đã bị breach vào thời điểm đó, kẻ tấn công có thể đưa vào một tập key chứa key của chúng, và mọi chữ ký về sau đều được xác thực thành công.

Đây là trust on first use (TOFU), cùng mô hình với fingerprint của SSH host key mà bạn chấp nhận trong lần kết nối đầu tiên. Không có authority bên ngoài để đối chiếu, nên bạn phải tự kiểm tra thủ công.

tailscale lock status

Sau khi bật, hãy chạy lệnh đó trên một số node. Đối chiếu các giá trị tlpub: tin cậy mà từng node báo cáo với các key mà các node ký thực tế đã in ra. Hãy thực hiện việc đối chiếu qua một kênh không phụ thuộc vào tailnet, vì control plane đã bị breach và đưa vào một tập key xấu cũng có thể xem cuộc trò chuyện bạn dùng để kiểm tra. Đây là việc chỉ cần làm một lần, mất mười phút, và là rào chắn duy nhất giữa bạn với một lock không bảo vệ được gì.

Kiểm tra các mục này trước khi bật

• Mọi node bạn muốn tiếp tục hoạt động phải chạy Tailscale v1.46.1 trở lên. Đây là phiên bản tối thiểu được tài liệu Tailscale nêu cho tailnet lock. Chạy tailscale version trên từng node, bao gồm cả router hoặc appliance mà bạn đã đăng ký một lần rồi quên mất.
• Bạn phải chọn ít nhất 2 signing node. Đây không phải yêu cầu mang tính hình thức: signing key nằm trên các thiết bị đó, nên chỉ có một signing node đồng nghĩa với việc chỉ cần ổ đĩa hỏng là bạn có thể không bao giờ thêm được máy vào tailnet nữa.
• Thiết bị Android không thể làm signing node vì không thể thực hiện thao tác signing.
• Tailnet lock và device approval là hai tính năng loại trừ lẫn nhau. Nếu tailnet của bạn đã yêu cầu phê duyệt thiết bị thủ công, bạn phải chọn một trong hai, không thể dùng đồng thời.
• Tính đến tháng 9 năm 2026, tài liệu Tailscale liệt kê tailnet lock trong các gói Personal và Enterprise. Vì vậy, hãy xác nhận plan của bạn trước khi cam kết hỗ trợ control này trong security review.

Cách bật tailnet lock

Admin console tạo command và bạn chạy command đó trên một máy. Mỗi phần riêng lẻ đều không hoạt động.

1. Trong admin console, mở trang Device management và chọn bật tailnet lock.
2. Chọn các node có tailnet lock key mà bạn muốn trust. Chọn ít nhất 2 node trên phần cứng mà bạn có thể tiếp cận trực tiếp.
3. Quyết định có gửi một disablement secret cho Tailscale support hay không. Đọc phần tiếp theo trước khi trả lời.
4. Copy command tailscale lock init do console tạo. Command này chứa một argument tlpub: cho mỗi signing node bạn đã chọn.
5. Chạy command đó trên một trong các signing node.

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

Mọi node đã có trong tailnet đều được các trusted key ký trong quá trình khởi tạo, nên các node đang hoạt động vẫn tiếp tục hoạt động. Thay đổi nằm ở các node mới. Một máy tham gia locked tailnet sẽ có node key chưa được ký. tailscale lock status trên máy đó sẽ hiển thị trạng thái này:

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

Admin console hiển thị cùng trạng thái dưới dạng badge Locked out, còn bộ lọc machines-list property:locked-out sẽ tìm tất cả các node đó cùng lúc. Output status trên node bị lock out cũng in chính xác command dùng để khắc phục. Copy dòng đó và chạy trên một signing node:

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

Các signer có thể thay đổi theo thời gian, và có 2 command để xử lý việc này. tailscale lock add tlpub:<key> trust một signing node mới. tailscale lock remove tlpub:<key> loại bỏ một signer. Theo mặc định, command này sẽ ký lại các node mà key đã loại bỏ từng ký, để chúng tiếp tục hoạt động. Dùng --re-sign=false để tắt hành vi đó. Nếu signing node bị đánh cắp thay vì được loại bỏ, hãy dùng tailscale lock revoke-keys tlpub:<key>. Command này chạy theo từng giai đoạn trên các signer còn lại bằng --cosign rồi --finish. tailscale lock log --limit 20 in lịch sử authority gần đây. Đây là nơi cần kiểm tra khi một node bị lock out nhưng không ai nhớ đã thay đổi gì.

Mười bí mật vô hiệu hóa và vì sao đây là phần rủi ro

tailscale lock init in ra mười bí mật vô hiệu hóa. Các bí mật này chỉ được hiển thị một lần khi khởi tạo và không bao giờ hiển thị lại. Chỉ cần một bí mật bất kỳ là có thể tắt tailnet lock cho toàn bộ tailnet:

tailscale lock disable "DISABLEMENT_SECRET"

Tài liệu của Tailscale nêu rõ hậu quả, không giảm nhẹ: nếu bạn mất các bí mật vô hiệu hóa và không cung cấp một bí mật cho bộ phận hỗ trợ của Tailscale, tailnet không thể được khôi phục. Hãy hình dung tình huống thực tế. Hai signing node của bạn là một laptop đã bị xóa dữ liệu và một VPS đã bị xóa. Không ai có thể ký node key mới, thêm signing node hoặc tắt lock. Tailnet vẫn hoạt động cho các member hiện tại nhưng vĩnh viễn không chấp nhận member mới. Cách duy nhất là tạo tailnet mới và đăng ký lại mọi thiết bị.

Vì vậy, hãy lưu các bí mật này như recovery code. Giữ ít nhất 2 bản sao ở những nơi không cùng phụ thuộc vào khả năng truy cập tailnet, đồng thời giữ 1 bản offline. Một bản sao chỉ nằm trên server mà bạn truy cập thông qua tailnet thì không phải là backup.

Tùy chọn hỗ trợ cần được quyết định rõ ràng thay vì dùng mặc định. Gửi 1 bí mật cho bộ phận hỗ trợ của Tailscale nghĩa là Tailscale có thể tắt tailnet lock của bạn. Điều đó trao lại một phần bảo đảm cho chính bên mà tính năng này được tạo ra để hạn chế. Tuy nhiên, nó cũng có nghĩa là việc mất binder sẽ không làm tailnet của bạn ngừng hoạt động. Nếu bạn bật tailnet lock vì một đợt đánh giá rủi ro bên thứ ba yêu cầu xác định điều gì xảy ra khi VPN vendor bị breach, đừng gửi bí mật đó. Nếu bạn bật tính năng này vì các admin thường thay đổi và muốn việc cho phép node tham gia phải gắn với thiết bị, hãy gửi bí mật và yên tâm hơn.

Vì sao provisioning không giám sát bị lỗi và cách khắc phục

Đây là hậu quả mà các team thường gặp trong vòng một tuần. Trong một tailnet bị khóa, máy khởi động và chạy tailscale up bằng auth key thông thường sẽ tham gia ở trạng thái bị khóa. Automation báo thành công, node xuất hiện trong console, nhưng không có gì có thể truy cập node đó. Việc signing phải diễn ra trước khi node tồn tại, không phải sau đó. Điều này có nghĩa là phải signing auth key.

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

Chạy lệnh đó trên một signing node. Lệnh in ra phiên bản đã signed của auth key. Giá trị đã signed này là giá trị mà image, file cloud-init hoặc biến Terraform truyền cho tailscale up --auth-key. Mọi node được tạo bằng giá trị này sẽ tham gia ở trạng thái đã signed và có thể truy cập ngay.

Có 2 dạng lỗi cần biết trước khi gặp phải. Thứ nhất, signing không xử lý tốt concurrency. Issue 15266 trong repository tailscale/tailscale, được mở vào tháng 3 năm 2025 và vẫn chưa được đóng, ghi nhận các lần chạy Terraform trong đó các lệnh gọi tailscale lock sign đồng thời trả về signed key rỗng. Vì vậy, một số node khởi động ở trạng thái bị khóa, còn các node khác hoạt động bình thường. Cách khắc phục của người báo lỗi là signing từng key một, với khoảng dừng ngắn giữa các lần gọi. Automation của bạn phải kiểm tra lệnh có trả về key không rỗng trước khi lưu key đó.

Thứ hai, signed auth key để lại state. Việc signing thêm một key vào authority, và key đó vẫn tồn tại sau khi node được tạo từ key bị xóa. Issue 16607 từ tháng 7 năm 2025 mô tả automation signing một key mới cho mỗi lần deployment cho đến khi authority đạt giới hạn:

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

Khi đó, tailnet không thể thêm key hoặc xóa các key thừa, vì thao tác xóa cũng là một authority update phải tạo ra checkpoint hợp lệ. Hãy signing một số ít key rồi dùng lại thay vì signing một key cho từng máy, đồng thời thỉnh thoảng kiểm tra tailscale lock log để biết chính xác số lượng thay vì chỉ phát hiện khi có lỗi.

Các node ephemeral và node CI cần có kế hoạch

Các node ephemeral, tức những node tự xóa mình khỏi tailnet khi logout, vẫn là node nên vẫn cần chữ ký để giao tiếp với bất kỳ hệ thống nào. Một CI job tham gia tailnet để chạy deployment cần auth key được ký trước, giống hệt server chạy lâu dài. CI cũng là nơi tình trạng tích lũy key nói trên ảnh hưởng nghiêm trọng nhất, vì đây là nơi bạn tạo và xóa nhiều node nhất.

Mô hình có thể triển khai được là dùng một auth key ephemeral, có chữ ký và có thể tái sử dụng, lưu trong CI secret store; chỉ xoay vòng theo lịch bạn chọn thay vì sau mỗi job. Mỗi lần xoay vòng chỉ tiêu tốn một key trong authority, nên bạn có thể lập kế hoạch dựa trên con số này. Chính việc ký cho từng job đã tạo ra 552 key.

Cách suy nghĩ tương tự cũng áp dụng cho các server chuyển tiếp traffic của những máy khác. subnet router quảng bá một dải mạng riêng từ VPS đại diện cho mọi địa chỉ phía sau nó, nên một node bị chèn vào vị trí đó có thể truy cập nhiều hơn rất nhiều so với chỉ một host. Đây là những máy cần được provision bằng key có chữ ký và không nên đưa vào quy trình hoàn toàn tự động.

Hai cơ chế bypass và chức năng của từng cơ chế

tailscale lock disable <disablement-secret> tắt tailnet lock cho toàn bộ tailnet. Lệnh này cần một trong 10 secret và được dùng khi chính authority là nguyên nhân gây sự cố.

tailscale lock local-disable

tailscale lock local-disable là cơ chế bypass theo từng node và phạm vi của nó thường bị hiểu sai. Lệnh này khiến node mà bạn chạy lệnh ngừng thực thi tailnet lock, nên node đó sẽ chấp nhận các peer có key chưa được ký. Lệnh này không khiến các node khác chấp nhận key chưa được ký của node đó. Một server bị khóa sẽ không thể truy cập được chỉ vì bạn chạy local-disable trên server đó. Vì vậy, tài liệu của Tailscale hướng dẫn chạy lệnh trên từng node để tailnet trên thực tế bỏ qua tailnet lock. Hãy xem đây là bước break-glass cho một node hiện chưa thể được ký, sau đó ký node đúng cách và không tiếp tục để cơ chế enforcement bị tắt.

Ai nên bật tailnet lock và ai không nên bật

Hãy bật nếu quyền gia nhập node phải tiếp tục được kiểm soát sau khi nhân sự rời đi. Khi chưa bật lock, bất kỳ ai có quyền admin trong console đều có thể thêm máy. Khi bật lock, việc thêm máy còn cần một device đang giữ signing key đáng tin cậy. Vì vậy, admin đã rời đi nhưng bạn quên thu hồi quyền truy cập console vẫn không thể đưa thêm node vào. Hãy bật nếu bảng câu hỏi đánh giá rủi ro từ bên thứ ba của khách hàng hỏi biện pháp nào ngăn VPN vendor tham gia network của bạn. Đây là control trả lời câu hỏi đó bằng một cơ chế cụ thể thay vì một cam kết.

Không nên bật cho tailnet của một người với một laptop, một phone và một VPS. Rủi ro thực tế với tailnet đó là bạn mất quyền truy cập, không phải Tailscale bị compromised. Tailnet lock thêm 10 secret mà bạn phải lưu trữ đúng cách vĩnh viễn. Nếu mất các secret này thì không thể khôi phục. Vì vậy, nó làm tăng rủi ro thực tế bạn đang đối mặt để giảm một rủi ro không thực tế với bạn. Lập luận tương tự áp dụng cho một team nhỏ nhưng không có inventory ghi rõ ai đang giữ signing device nào. Trước hết, hãy làm đúng việc ghi chép đó. Tailnet lock chính là việc ghi chép, kèm theo một failure mode vĩnh viễn.

Headscale trả lời cùng câu hỏi theo một cách khác

Nếu phản đối là bên thứ ba quyết định ai được tham gia mạng của bạn, có hai cách trả lời. Tailnet lock vẫn giữ coordination server của Tailscale và loại bỏ quyền thêm thành viên của server đó. Tự chạy Headscale, coordination server mã nguồn mở do bạn tự host thay vào đó loại bỏ server, còn bạn giữ cả quyền kiểm soát lẫn công việc vận hành nó: áp dụng bản vá, sao lưu và xử lý sự cố gián đoạn mà bạn phải tự khắc phục lúc 2 giờ sáng. Về mặt lý thuyết, không có cách nào an toàn hơn cách còn lại. Hãy chọn dựa trên loại sự cố bạn muốn tự chịu trách nhiệm hơn: một hosted control plane mà bạn đã giới hạn quyền, hay một control plane do bạn vận hành.

FAQ

Tailnet lock thực sự ngăn chặn điều gì?

Nó ngăn coordination server của Tailscale thêm một node vào tailnet của bạn. Khi bật tailnet lock, node key chỉ được chấp nhận sau khi một signing node do bạn kiểm soát ký nó bằng tailnet lock key của tailnet. Vì vậy, control plane bị xâm nhập có thể phân phối key nhưng không thể thêm một thành viên mới. Tính năng này không mã hóa thêm dữ liệu nào, vì traffic giữa các node vốn đã được mã hóa end-to-end bằng WireGuard key mà coordination server không bao giờ nắm giữ. Nó cũng không giúp chống lại thiết bị bị đánh cắp, signing node bị xâm nhập hoặc control plane chỉ đơn giản là ngừng cung cấp tailnet của bạn.

Điều gì xảy ra nếu tôi mất cả mười disablement secret?

Các secret được in ra một lần khi tailscale lock init chạy và không bao giờ được hiển thị lại. Nếu bạn mất tất cả và chưa gửi secret nào cho Tailscale support, tài liệu cho biết tailnet không thể khôi phục. Trên thực tế, nếu bạn cũng mất các signing node, bạn sẽ không thể ký node key nào khác và cũng không thể tắt lock. Khi đó, cách duy nhất là tạo tailnet mới và đăng ký lại mọi thiết bị. Hãy giữ 2 bản sao ở những nơi không cùng phụ thuộc vào việc tailnet đang hoạt động, đồng thời giữ 1 bản offline.

Tôi có phải ký thủ công mọi thiết bị mới không?

Không. Hãy ký auth key thay vì ký node. Trên một signing node, export key rồi chạy tailscale lock sign $AUTH_KEY. Sau đó truyền giá trị đã ký mà command in ra cho tailscale up --auth-key trong image hoặc provisioning tool của bạn. Các node được tạo theo cách này sẽ xuất hiện với trạng thái đã ký. Hãy ký một số ít key có thể tái sử dụng thay vì tạo 1 key cho mỗi máy, vì mỗi signed key sẽ thêm một key vào authority và key đó vẫn tồn tại sau khi node bị xóa. Authority có giới hạn 512 key, và trong thực tế automation đã chạm đến giới hạn này.

Tailnet lock có giống device approval không?

Không. Bạn không thể bật cả 2 tính năng, vì chúng loại trừ lẫn nhau. Device approval là một policy check trong admin console: admin đánh dấu một tùy chọn trước khi thiết bị mới được cấp quyền truy cập, còn coordination server sẽ thực thi quyết định đó. Tailnet lock là một cryptographic check do chính các node của bạn thực hiện, bằng các key được giữ trên phần cứng của bạn. Vì vậy, tính năng này vẫn hoạt động nếu coordination server trở nên hostile. Device approval là cơ chế kiểm soát nhẹ hơn để quản lý người dùng. Tailnet lock là cơ chế trả lời câu hỏi về vendor.