Tailscale có an toàn không? Hiểu về trust model

Tailscale có an toàn không? Câu trả lời ngắn gọn

Tailscale có an toàn không? Với vấn đề mà hầu hết mọi người lo ngại, câu trả lời là có: coordination server chạy tailnet của bạn không bao giờ giữ private key dùng để mã hóa traffic, nên nó không thể đọc dữ liệu mà các thiết bị gửi cho nhau. Trang security của Tailscale nêu rõ: "Private key không bao giờ rời khỏi thiết bị. Mọi traffic luôn được mã hóa end-to-end." Câu hỏi hữu ích lại là vấn đề khác. Coordination server bị breach hoặc bị cơ quan pháp luật yêu cầu cung cấp dữ liệu không cần đọc các packet của bạn. Nó quyết định các public key mà thiết bị của bạn tin cậy, nên có thể enrol một thiết bị mà bạn chưa phê duyệt.

Đó là trust model trong một câu: mã hóa bảo vệ dữ liệu, còn control plane quyết định thành viên. Mỗi phần bên dưới nêu một bên mà bạn phải tin cậy, nói rõ bên đó thực sự có thể làm gì và đưa ra biện pháp kiểm soát để giới hạn quyền của bên đó. Nếu bạn chưa quen với sản phẩm này, hãy bắt đầu từ Tailscale là gì và mesh của nó hoạt động như thế nào.

Mặt control plane và data plane là hai phần riêng biệt

Tailscale là một mesh VPN (virtual private network) xây dựng trên WireGuard, cùng giao thức mà bạn có thể tự cấu hình trên một VPS WireGuard tự host. Mỗi thiết bị tự tạo key pair WireGuard trên chính thiết bị đó. Bài viết cách hoạt động của Tailscale gọi coordination server là “một hộp thư dùng chung cho public key” và nêu rõ: “Private key không bao giờ rời khỏi node của nó.”

Data plane là lưu lượng đã mã hóa giữa các thiết bị của bạn. Lưu lượng đi trực tiếp từ thiết bị này đến thiết bị khác khi mạng cho phép. Control plane là mọi thành phần còn lại: những thiết bị nào thuộc tailnet, public key nào thuộc về thiết bị nào, access policy, thiết lập DNS và danh sách relay. Tailscale vận hành control plane dưới dạng hosted service. Bạn chạy data plane trên các máy của mình.

Hãy tách riêng hai phần này, và mọi câu hỏi bảo mật ở đây đều có thể trả lời rõ ràng. Mã hóa là thuộc tính của data plane. Membership là quyết định của control plane. Không mức độ mã hóa nào cho bạn biết ai được phép trở thành peer.

Máy chủ điều phối bị breach có thể làm gì?

Nó không thể giải mã traffic của bạn. Các key dùng để mã hóa được tạo trên thiết bị của bạn và không bao giờ được upload, nên không có gì để chiếm đoạt hoặc làm rò rỉ nhằm mở tunnel. Điều này cũng đúng với traffic được relay, sẽ được đề cập ở phần dưới.

Nó có thể enrol một node. Khi Tailscale công bố tailnet lock, công ty mô tả rủi ro bằng chính các từ của mình: một máy chủ độc hại có thể “dùng một node được thêm vào bí mật để gửi hoặc nhận traffic đến các node hiện có của bạn”, và khi đó “việc traffic được mã hóa cũng không còn quan trọng vì chính peer đó có thể là độc hại”. Thiết bị của bạn tin một peer vì control plane thông báo rằng key đó thuộc về tailnet.

Nó có thể thay đổi những gì thiết bị của bạn được phép truy cập. Access policy nằm trong control plane và được phân phối đến các node. White paper về tailnet lock của Tailscale nói rằng tailnet lock “không ngăn control plane bị breach phá vỡ kết nối trong network của bạn, chẳng hạn bằng cách không phân phối key của node mới hoặc phân phối access control policy từ chối quyền truy cập đến tất cả node”.

Dù thế nào, nó vẫn thấy metadata của kết nối. Network flow log của Tailscale ghi lại sự kiện mở và đóng cho mọi kết nối giữa các máy. Tài liệu nêu rõ các log này “tuyệt đối không chứa bất kỳ thông tin nào về thao tác của client hoặc nội dung của network traffic”. Vì vậy, control plane có thể biết thiết bị nào của bạn đã giao tiếp với thiết bị nào và vào thời điểm nào. Nó không biết chúng đã trao đổi nội dung gì.

Chỉ một mục trong danh sách trên liên quan đến mã hóa. Các mục còn lại liên quan đến thành viên của network và nội dung của policy. Vì vậy, các control quan trọng cần chú ý là những control chi phối việc enrol node.

Nhà cung cấp danh tính của bạn là gốc tin cậy của tailnet

Tailscale không có cơ sở dữ liệu mật khẩu riêng. Tài liệu của Tailscale nêu rõ rằng không có mật khẩu Tailscale; việc đăng nhập được ủy quyền cho một nhà cung cấp danh tính (IdP): Apple, Google, GitHub, Microsoft, Okta, OneLogin hoặc một nhà cung cấp OpenID Connect tùy chỉnh.

Hãy xem đây là một tuyên bố về bảo mật, vì đúng là như vậy. Bất kỳ ai có thể đăng nhập vào tài khoản Google hoặc Microsoft của bạn đều có thể đăng nhập vào tailnet của bạn. MFA của bạn phụ thuộc vào những gì IdP thực thi. Quy trình offboarding của bạn phụ thuộc vào cách IdP xử lý khi một người rời tổ chức. Một tài khoản IdP bị phishing cũng đồng nghĩa với một tài khoản tailnet bị chiếm quyền, và kẻ tấn công không cần tấn công WireGuard: họ chỉ cần thêm một thiết bị rồi thừa hưởng mọi quyền mà policy cấp cho người dùng đó.

Có 2 cơ chế kiểm soát ngăn một tài khoản danh tính bị đánh cắp biến thành một thiết bị hoạt động bên trong tailnet: phê duyệt thiết bị và thời hạn key. Tailnet lock là cơ chế thứ ba, tập trung vào control plane thay vì tài khoản.

Phê duyệt thiết bị: không thiết bị nào tham gia cho đến khi có người xác nhận

Tài liệu Tailscale mô tả tính năng phê duyệt thiết bị là tính năng “cho phép quản trị viên mạng Tailscale xem xét và phê duyệt thiết bị mới trước khi chúng có thể tham gia mạng Tailscale của bạn”. Owner, Admin hoặc IT admin có thể phê duyệt. Thiết bị mới sẽ hiển thị badge “Needs approval” trên trang Machines cho đến khi có người xử lý.

Bật tính năng này sẽ thay đổi tình huống tài khoản bị đánh cắp. Kẻ tấn công đăng nhập, thiết bị được đăng ký, rồi chờ ở đó và không thể truy cập gì. Trong admin console của bạn sẽ có một badge cho biết một máy bạn không nhận ra đang yêu cầu tham gia. Automation vẫn hoạt động vì khi tạo auth key, bạn có thể đánh dấu key đó là được phê duyệt trước. Thiết bị cũng có thể được phê duyệt qua API.

Auth key là một cách khác để tham gia mạng, vì vậy hãy xem chúng như credential. Tài liệu Tailscale cảnh báo rõ về loại rủi ro này: “Hãy cực kỳ cẩn thận với reusable key! Chúng có thể rất nguy hiểm nếu bị đánh cắp. Tốt nhất nên lưu chúng trong một sản phẩm key vault được thiết kế riêng cho mục đích này.” Tính đến August 2026, thời hạn hết hạn được tài liệu hóa của key là từ 1 đến 90 ngày. Nếu không chỉ định thời hạn, key sẽ mặc định hết hạn sau 90 ngày. Ưu tiên dùng one-off key. Đánh dấu key là ephemeral cho các máy thường xuyên tham gia rồi rời mạng. Lưu mọi reusable key trong Ansible Vault được mã hóa hoặc secrets manager, thay vì đặt trong shell script.

Hết hạn key: bộ hẹn giờ giới hạn mọi sai sót khác

Key của node sẽ hết hạn. Đây là cơ chế biến một thiết bị bị đánh cắp hoặc bị bỏ quên thành một vấn đề tạm thời. Tài liệu Tailscale nêu rằng “Theo mặc định, các domain mới được đặt thời hạn 180 ngày”, và “Nếu không reauthenticate, key sẽ hết hạn và các kết nối đến/từ endpoint đó sẽ ngừng hoạt động.” Bạn có thể tự reauthenticate cho thiết bị:

tailscale up --force-reauth

Tài liệu cảnh báo rằng thao tác này “có thể làm gián đoạn kết nối tailnet, vì vậy không nên thực hiện từ xa qua SSH hoặc RDP nếu không có cách đăng nhập thay thế khi kết nối bị mất.” Hãy mở sẵn quyền truy cập console hoặc dùng một đường truy cập thứ hai vào máy, vì bạn sắp làm gián đoạn chính network đang sử dụng.

Server là nơi cơ chế này thường bị vô hiệu hóa. Một máy phải reauthenticate mỗi 180 ngày sẽ rời khỏi tailnet lúc 3 giờ sáng khi không có ai theo dõi, nên administrator thường tắt key expiry trên máy đó. Việc này loại bỏ bộ hẹn giờ có thể ngắt quyền sử dụng của một key bị đánh cắp. Với server, tagged device là lựa chọn phù hợp hơn, vì tag sở hữu máy thay cho một cá nhân, nên máy vẫn hoạt động khi người đó rời công ty. Dù chọn cách nào, hãy lập danh sách các máy đã tắt expiry: những key đó vẫn hợp lệ cho đến khi bạn xóa thiết bị.

Tailnet lock: đưa coordination server ra khỏi chuỗi tin cậy

Tailnet lock xử lý trực tiếp vấn đề enrolment. Tài liệu tailnet lock của Tailscale giải thích cơ chế này: “Khi một node mới tham gia tailnet, public node key của node đó phải có chữ ký từ một Tailnet Lock key. Coordination server phân phối public node key đã được ký đến các peer node.” Các thiết bị hiện có sẽ xác minh chữ ký đó trước khi chấp nhận một peer, vì vậy node key do control plane tự tạo sẽ bị từ chối.

tailscale lock status
tailscale lock sign nodekey:1abddef1 tlpub:abcdef12

tailscale lock init bật tính năng này và bạn chỉ định các signing node ngay lúc đó. Tailscale yêu cầu tối thiểu 2 signing node khi khởi tạo và cho phép tối đa 20 signing node trong một tailnet. Sau đó, mọi thiết bị mới đều cần chữ ký từ một trong các node này. Đây là một chi phí vận hành thực tế: thêm một điện thoại nghĩa là phải chạy một command trên laptop.

Các giới hạn này được ghi rõ trong tài liệu và quan trọng hơn phần mô tả tính năng:

• Nếu làm mất disablement secret thì không có cách khôi phục. Tài liệu nêu rõ: “Nếu bạn làm mất các disablement secret và không cung cấp một secret nào cho bộ phận hỗ trợ Tailscale, tailnet sẽ không thể khôi phục.”
• Signing key nằm trên thiết bị do bạn sở hữu nên chịu cùng mức bảo mật với thiết bị đó. Tài liệu nói rõ: “Nếu thiết bị bị breach, key có thể bị lấy.”
• Bạn không thể chạy đồng thời cả hai cơ chế kiểm soát. Tailscale xác nhận tailnet lock và device approval loại trừ lẫn nhau, nên bật một cơ chế đồng nghĩa với việc bỏ cơ chế còn lại.
• Đây là trust on first use (TOFU). Thiết lập ban đầu vẫn đi qua control plane. Chỉ sau bước đầu tiên đó, điểm neo tin cậy mới được chuyển vào network của bạn.

Tailnet lock bảo vệ membership. Nó không bảo vệ availability, và white paper cũng nói rõ điều đó.

Kết nối relay có làm lộ lưu lượng của tôi không?

Không. Khi 2 thiết bị không thể kết nối trực tiếp với nhau, lưu lượng sẽ chuyển qua máy chủ DERP (Designated Encrypted Relay for Packets). Tài liệu của Tailscale nêu rõ điều này: “Vì private key của Tailscale không bao giờ rời khỏi thiết bị cục bộ đã tạo ra chúng, máy chủ DERP không thể giải mã lưu lượng của bạn. Máy chủ DERP chỉ chuyển tiếp một cách mù quáng lưu lượng đã được mã hóa từ thiết bị này sang thiết bị khác.”

Relay vẫn làm giảm tốc độ và cho máy chủ đó thấy metadata: 2 endpoint đã được mã hóa, cùng thời điểm và dung lượng dữ liệu truyền giữa chúng. Hãy kiểm tra loại kết nối bạn đang thực sự dùng:

tailscale status
tailscale netcheck

tailscale status đánh dấu mỗi peer là direct, hiển thị bằng direct 203.0.113.10:41641, hoặc relayed, hiển thị bằng relay kèm theo tên relay và các bộ đếm byte phía sau. Nếu một peer vẫn dùng relay, nghĩa là hai đầu không thể thiết lập đường truyền direct. Nguyên nhân thường là UDP bị chặn ở đâu đó hoặc cả hai phía đều nằm sau NAT nghiêm ngặt (network address translation). tailscale netcheck cho biết máy đó có hoạt động được với UDP hay không, NAT ánh xạ các port như thế nào và độ trễ đến các relay gần nhất. Các thông tin này cho biết bạn đang gặp nguyên nhân nào trong hai nguyên nhân trên. Nếu peer đã direct nhưng throughput vẫn thấp hơn mong đợi, relay không phải là nguyên nhân. MTU của đường truyền không khớp thường là nguyên nhân khiến WireGuard chậm.

Một exit node chuyển điểm thoát của bạn, không xóa điểm thoát

Exit node định tuyến toàn bộ traffic Internet công khai của một thiết bị qua một thiết bị khác trong tailnet, bằng các default route 0.0.0.0/0 và ::/0. Trên Linux, máy cung cấp dịch vụ sẽ quảng bá exit node, còn mỗi client phải chủ động bật sử dụng:

sudo tailscale set --advertise-exit-node
sudo tailscale set --exit-node=100.101.102.103
sudo tailscale set --exit-node=100.101.102.103 --exit-node-allow-lan-access=true
sudo tailscale set --exit-node=

Exit node phải được Owner, Admin hoặc Network admin phê duyệt trong admin console. Policy của bạn cũng phải cấp quyền autogroup:internet thì client mới được sử dụng. Cả hai bước đều là cơ chế kiểm soát có chủ đích: một máy chưa được phê duyệt không thể âm thầm trở thành đường thoát cho toàn bộ tailnet. Cơ chế phê duyệt tương tự cũng áp dụng cho subnet route. Vì vậy, máy quảng bá một private range sẽ không hoạt động cho đến khi admin chấp thuận. Đây là bước kiểm tra đầu tiên khi quảng bá một private network lên tailnet từ VPS.

Bây giờ xét vấn đề trust. Traffic được mã hóa từ laptop của bạn đến exit node. Sau đó, traffic rời máy đó dưới dạng traffic Internet thông thường và mang IP address của máy đó. Vì vậy, operator của exit node nhìn thấy các đích truy cập của bạn. Hosting provider của máy đó và network upstream của họ cũng nhìn thấy các đích này. Bạn chỉ chuyển điểm bị quan sát sang nơi khác, chứ không loại bỏ nó. Đây là lựa chọn hợp lý khi bạn kiểm soát đầu bên kia, cũng là lý do để chạy exit node của riêng bạn trên VPS. Ngược lại, đây là lựa chọn kém phù hợp khi bạn không kiểm soát đầu bên kia.

Chính sách mặc định là network phẳng

Tailnet mới tạo có chính sách cho phép rộng. Tài liệu access control của Tailscale cho biết file policy mặc định “cho phép các thiết bị trong tailnet giao tiếp với nhau”. Mỗi thiết bị có thể truy cập mọi thiết bị khác trên mọi port. Đó là một network phẳng. Bạn đã đưa network này vào trong tunnel, việc này giúp chống truy cập từ bên ngoài nhưng không ngăn được một laptop bị nhiễm mã độc.

Hãy siết chặt chính sách trong file policy của tailnet. File này hỗ trợ access control lists (ACL) hoặc grants mới hơn; cả hai đều được viết bằng một dialect JSON cho phép dùng comment:

{
  "acls": [
    {"action": "accept", "src": ["group:eng"], "dst": ["tag:prod:22"]},
    {"action": "accept", "src": ["autogroup:member"], "dst": ["autogroup:internet:*"]}
  ]
}

Policy này cho phép một group truy cập SSH trên các production server, cho phép thành viên dùng exit node và từ chối mọi truy cập khác do không khai báo rule tương ứng. Tailscale liệt kê các rule target khả dụng trên từng plan, vì vậy hãy kiểm tra thông tin đó trước khi thiết kế dựa trên tags hoặc autogroups, đồng thời xem free plan thực sự bao gồm những gì. Với thiết bị không bao giờ được nhận kết nối đến, chẳng hạn personal phone, tailscale set --shields-up sẽ chặn các kết nối đó tại client.

Headscale thay đổi gì khi bạn tự host control plane

Headscale là “Một triển khai mã nguồn mở, tự host của control server Tailscale.” README của dự án nêu rõ phạm vi: “Nó chỉ triển khai một phạm vi hẹp, một mạng Tailscale duy nhất (tailnet), phù hợp cho mục đích cá nhân hoặc một tổ chức mã nguồn mở nhỏ.” Danh sách tính năng gồm ACL và grants, subnet router, exit node, DERP server tích hợp, Tailscale SSH và Taildrop. Nếu phạm vi hẹp này là điểm vướng, NetBird là mesh khác có control plane có thể tự host, và chạy NetBird server trên VPS của bạn sẽ chuyển cùng quyết định về việc cho thiết bị tham gia sang phần cứng do bạn sở hữu.

Điều thay đổi là danh tính của bên có thể cho một node giả mạo tham gia mạng. Với Headscale, thư mục key và policy nằm trên server của bạn. Không bên thứ ba nào nắm danh sách public key của thiết bị của bạn, và không bên thứ ba nào có thể bị buộc phải giao một key hoặc ký xác nhận cho một key.

Điều không thay đổi là data plane. Đây vẫn là WireGuard với cùng cơ chế mã hóa end-to-end và cùng cơ chế fallback qua relay khi không thể thiết lập đường truyền trực tiếp. Bạn cũng phải tự đảm nhận các công việc mà Tailscale từng thực hiện: theo dõi uptime, patching, backup và bảo đảm an ninh vật lý cho máy chủ. Nếu máy chủ đó là một VPS thuê, yếu tố cuối cùng phụ thuộc vào cam kết của bên khác thay vì quyền kiểm soát của bạn, vì hypervisor có thể đọc memory của guest và cả thư mục chứa key, trừ khi phần cứng hỗ trợ memory được mã hóa và có thể attestation. Một Headscale host bị breach cho phép attacker làm đúng những gì một coordination server bị breach cho phép: enrol một node và phân phối policy. Tailnet lock không nằm trong danh sách tính năng của Headscale, nên biện pháp kiểm soát bù trừ cho rủi ro cụ thể này không có sẵn ở đó. Chi phí cũng khiến một số tailnet chọn hướng này, vì Tailscale tính phí theo user thay vì theo device và phép tính đó thay đổi ngay khi một team nhỏ vượt quá free plan. Nếu câu hỏi về quyền sở hữu là yếu tố quyết định lựa chọn của bạn, tự host control plane bằng Headscale sẽ hướng dẫn cách thiết lập.

Tailscale bảo vệ trước những gì

• Cổng lắng nghe public. Một service bind vào địa chỉ tailnet sẽ không thể truy cập từ internet, nên các scanner quét mọi VPS trên port 22 sẽ không thấy service đó. Ngoại lệ là trường hợp bạn tự bật, vì Funnel cố ý publish một service trong tailnet ra internet mở. Vì vậy, bạn nên biết serve kết thúc ở đâu và funnel bắt đầu từ đâu trước khi chạy một trong hai command. Vẫn giữ host firewall, vì port Docker được publish sẽ tự ghi rule riêng và bypass ufw trên public interface.
• Đoán password vào các login bị expose. Không có gì để thử hàng loạt khi port chỉ trả lời bên trong tunnel. Đây là trạng thái an toàn hơn so với việc rate limiting một port đang mở, dù fail2ban trên Ubuntu 24.04 vẫn đáng chạy trên mọi máy buộc phải public.
• Network không đáng tin trên đường truyền. Traffic giữa các máy được mã hóa end-to-end qua network của quán cà phê hoặc LAN dùng chung của nhà cung cấp, và vẫn được mã hóa khi đi qua relay.
• Phân phối key thủ công. Mỗi peer được thêm thủ công vào cấu hình WireGuard là một cơ hội dùng trùng địa chỉ hoặc dán nhầm key. Mesh tự xử lý việc quản lý đó, và đây là phần lớn khác biệt trong thực tế giữa WireGuard và Tailscale.

Tailscale không bảo vệ khỏi những gì

• Endpoint đã bị xâm phạm. Tailnet tin cậy các thiết bị. Malware trên laptop đã được phê duyệt sẽ có tunnel, địa chỉ tailnet và mọi quyền mà policy cấp cho user đó. Đây là khoảng trống lớn nhất, và không VPN nào có thể loại bỏ.
• Administrator độc hại hoặc bất cẩn. Bất kỳ ai có thể chỉnh sửa file policy đều có thể tự cấp quyền truy cập cho mình vào mọi thứ. Người chiếm được tài khoản danh tính của Owner cũng có thể làm tương tự. Hãy review các thay đổi policy như khi review code.
• Phân tích traffic. ISP (internet service provider) của bạn thấy các gói UDP đã mã hóa đi đến một endpoint, cùng thời điểm và lưu lượng. Flow log của Tailscale cho biết peer nào đã trao đổi traffic và vào thời điểm nào. Cả hai không thấy nội dung, nhưng việc có kết nối vẫn không bị ẩn. Vì vậy, hãy đọc cách Tor và VPN khác nhau trước khi chọn công cụ cho mục đích đó.
• Thiết bị bạn đã mất quyền kiểm soát. Key expiry là biện pháp dự phòng chậm, với mặc định 180 day. Xóa thiết bị trong admin console là biện pháp nhanh, vì vậy hãy biết nút đó ở đâu trước khi cần dùng.

Kiểm tra tailnet của bạn

1. Chạy tailscale status trên một thiết bị và đọc danh sách peer. Một máy mà bạn không thể xác định danh tính chính là tình huống mà tính năng phê duyệt thiết bị được thiết kế để ngăn chặn.
2. Chạy tailscale lock status để xem tailnet lock có được bật hay không, rồi quyết định liệu việc ký mọi thiết bị mới có đáng với tailnet của bạn hay không.
3. Mở admin console và ghi lại mọi máy đã tắt key expiry, cùng mọi auth key có thể dùng lại vẫn còn tồn tại. Cả hai đều là credential không có thời hạn.
4. Đọc policy file của bạn. Nếu file vẫn dùng cấu hình mặc định, mọi thiết bị đều có thể truy cập mọi thiết bị khác trên mọi port, và một laptop bị nhiễm mã độc có thể truy cập tất cả các thiết bị đó.

Tailscale có danh tiếng nhờ data plane, nơi thiết kế không cho operator cách đọc traffic của bạn. Hãy tiếp nhận tuyên bố đó theo tài liệu của vendor, sau đó audit những phần thuộc về bạn: identity account, thiết lập phê duyệt, danh sách expiry và policy file. Trang bảo mật của Tailscale nêu chứng nhận SOC 2 Type II và hoạt động bảo mật liên tục với Latacora. Đây là bằng chứng về quy trình của họ, không phải tuyên bố về cấu hình của bạn.

FAQ

Tailscale có thể đọc lưu lượng của tôi không?

Không. Lưu lượng được mã hóa bằng các WireGuard key được tạo trên thiết bị của bạn. Trang bảo mật của Tailscale nêu rõ: “Private key không bao giờ rời khỏi thiết bị. Mọi lưu lượng luôn được mã hóa đầu cuối.” Điều này cũng áp dụng cho các kết nối chuyển tiếp qua relay DERP, vì relay “chỉ chuyển tiếp mù lưu lượng đã được mã hóa từ thiết bị này sang thiết bị khác” và không giữ key nào có thể dùng để giải mã. Hạ tầng Tailscale chỉ thấy metadata: có những thiết bị nào, thiết bị nào kết nối với thiết bị nào và vào thời điểm nào.

Một Tailscale coordination server bị xâm nhập thực sự có thể làm gì?

Nó có thể enrol một node. Thông báo về tailnet lock của Tailscale mô tả rủi ro một node được bí mật thêm vào có thể “gửi hoặc nhận lưu lượng với các node hiện có”, trong đó việc mã hóa không giúp ích vì “bản thân peer có thể là một tác nhân độc hại”. Một control plane bị xâm nhập cũng có thể phân phối policy thay đổi phạm vi truy cập của các thiết bị, và white paper về tailnet lock lưu ý rằng nó có thể làm gián đoạn kết nối bằng cách không phân phối key của node mới. Nó không thể giải mã lưu lượng giữa các thiết bị hiện có, vì chưa bao giờ giữ private key của chúng.

Exit node có che giấu hoạt động duyệt web của tôi với ISP không?

Nó che giấu đích truy cập khỏi mạng mà bạn đang sử dụng, bao gồm ISP tại nhà hoặc quán cà phê, vì mọi thứ rời thiết bị của bạn dưới dạng lưu lượng được mã hóa và gửi đến exit node. Nó không làm bạn ẩn danh. Thay vào đó, exit node thấy các đích truy cập đó. Nhà cung cấp hosting và mạng upstream của exit node cũng thấy chúng, còn các website bạn truy cập sẽ thấy IP của exit node. Bạn chỉ thay đổi bên quan sát, nên hãy chọn một bên mà bạn thực sự tin cậy.

Headscale có bảo mật hơn Tailscale coordination server không?

Đây là một quyết định về bên được tin cậy khác, không phải lựa chọn chắc chắn an toàn hơn. Với Headscale, bạn tự quản lý thư mục key và policy, nên không có bên bên ngoài nào có thể bị ép enrol một thiết bị vào tailnet của bạn. Bạn cũng phải tự vận hành server đó: cập nhật bản vá, duy trì uptime, sao lưu và bảo vệ chính host. Một Headscale host bị xâm nhập cho attacker quyền enrol giống như một coordination server bị xâm nhập. Tailnet lock không nằm trong danh sách tính năng của Headscale, vì vậy hãy bảo vệ host đó tương ứng.

VPS đã nằm trong tailnet thì tôi vẫn cần firewall không?

Có. Network interface public vẫn tồn tại. Mọi service bind vào 0.0.0.0 vẫn có thể được truy cập từ Internet, dù Tailscale có đang chạy hay không. Hãy bind service vào địa chỉ của tailnet, đặt policy mặc định deny trên interface public và kiểm tra các container port đã publish, vì Docker tự chèn rule riêng và có thể expose một port mà bạn tưởng đã được đóng.