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

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

Tailscale có an toàn không? Với vấn đề mà hầu hết mọi người quan tâm, câu trả lời là có: coordination server vận hành tailnet của bạn không bao giờ giữ private key dùng để mã hóa traffic, nên server này không thể đọc dữ liệu 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ị yêu cầu cung cấp dữ liệu theo lệnh pháp lý không cần đọc các packet của bạn. Server này quyết định những public key nào được các 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 bao giờ phê duyệt.

Đó là trust model trong một câu: encryption bảo vệ dữ liệu, còn control plane quyết định membership. Mỗi section 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 control để giới hạn quyền đó. Nếu bạn chưa quen với chính sản phẩm này, hãy bắt đầu bằng 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 protocol mà bạn sẽ tự cấu hình trên một WireGuard VPS tự host. Mỗi thiết bị tự tạo cặp key WireGuard trên máy đó. Bài viết cách thức hoạt động của Tailscale gọi coordination server là “một hộp chia sẻ để lưu public key” và khẳng định rằng “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 bất cứ khi nào network cho phép. Control plane là mọi thành phần còn lại: các thiết bị thuộc tailnet, public key nào thuộc về thiết bị nào, access policy, DNS settings và danh sách relay. Tailscale vận hành control plane dưới dạng hosted service. Bạn vận hành data plane trên các máy của mình.

Hãy tách riêng hai phần này để có thể trả lời từng câu hỏi bảo mật. 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 làm 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ì để thu giữ 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 lời của mình: một máy chủ độc hại có thể “dùng một node được thêm ngầm để gửi hoặc nhận traffic đến các node hiện có của bạn”, và khi đó “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 cậy một peer vì control plane thông báo rằng key đó thuộc về tailnet.

Nó có thể thay đổi những nơi 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 làm gián đoạn 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 một access control policy từ chối quyền truy cập đến tất cả node”.

Dù thế nào nó cũng thấy metadata của kết nối. Network flow log của Tailscale ghi lại sự kiện mở và đóng của mọi kết nối giữa các máy. Tài liệu nêu rõ các log này “hoàn toàn 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 liên quan đến mã hóa. Các mục còn lại liên quan đến thành viên và nội dung của policy. Vì vậy, những control bạn cần chú ý là các control quản lý việc enrolment.

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

Tailscale không có password database riêng. Tài liệu của Tailscale nêu rõ rằng không có password Tailscale; việc đăng nhập được ủy quyền cho một identity provider (IdP): Apple, Google, GitHub, Microsoft, Okta, OneLogin hoặc một OpenID Connect provider 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 đăng nhập được 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. Cơ chế xác thực đa yếu tố (MFA) của bạn là cơ chế mà IdP áp dụng. Quy trình offboarding của bạn phụ thuộc vào những gì IdP thực hiện 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; kẻ tấn công không cần tấn công WireGuard. Chúng chỉ cần thêm một device rồi được hưởng mọi quyền mà policy cấp cho user đó.

Có 2 cơ chế kiểm soát ngăn một tài khoản danh tính bị đánh cắp trở thành một device hoạt động bên trong tailnet: phê duyệt device 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ị: chưa có gì được tham gia cho đến khi có người xác nhận

Tài liệu của Tailscale mô tả 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. Mộ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 kịch bản khi 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ờ tại đó và không thể truy cập bất kỳ thứ gì. Trong admin console, 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 thông qua API.

Auth key là một cách khác để truy cập, vì vậy hãy xử lý chúng như credential. Tài liệu của Tailscale cảnh báo rõ về loại có rủi ro: “Hãy hết sức cẩn thận với reusable key! Nếu bị đánh cắp, chúng có thể rất nguy hiểm. 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, khoảng thời gian hết hạn được ghi trong tài liệu 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 one-off key. Đánh dấu key là ephemeral cho các máy thường xuyên tham gia và rời khỏi mạng. Lưu 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 sự cố tạm thời. Tài liệu Tailscale nêu rằng “Theo mặc định, 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 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 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 3am 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ể cắt quyền sử dụng của key bị đánh cắp. Với server, dùng tagged device là lựa chọn tốt hơn, vì tag gắn quyền sở hữu với máy thay vì một người, 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 device.

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 đã ký đến các peer node." Các thiết bị hiện có của bạn sẽ xác minh chữ ký đó trước khi chấp nhận một peer. Vì vậy, public 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à tại thời điểm đó bạn chỉ định các signing node. Tailscale yêu cầu ít nhất 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 có 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 mất disablement secret thì không có cách khôi phục. Tài liệu ghi rõ: "Nếu bạn mất các disablement secret và chưa cung cấp một secret cho bộ phận hỗ trợ của Tailscale, tailnet không thể được khôi phục."
• Signing key nằm trên một thiết bị do bạn sở hữu, nên kế thừa mức bảo mật của 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ả 2 cơ chế kiểm soát. Tailscale nêu rằng tailnet lock và device approval loại trừ lẫn nhau. Bật một cơ chế đồng nghĩa với việc từ 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. Anchor của trust chỉ được chuyển vào network của bạn sau bước đầu tiên đó.

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

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

Không. Khi hai 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õ: “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 phép quan sát metadata: hai endpoint đã 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 thực sự đang dùng:

tailscale status
tailscale netcheck

tailscale status đánh dấu mỗi peer là direct, hiển thị dưới dạng direct 203.0.113.10:41641, hoặc relayed, hiển thị dưới dạng relay kèm tên relay và các bộ đếm byte phía sau. Nếu một peer luôn dùng relay, nghĩa là hai đầu không thể thiết lập đường kết nối trực tiếp. Nguyên nhân thường là UDP bị chặn ở đâu đó hoặc cả hai phía đều nằm sau NAT (network address translation) nghiêm ngặt. tailscale netcheck cho biết UDP có hoạt động từ máy đó 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 giúp xác định nguyên nhân nào trong hai nguyên nhân trên đang xảy ra.

Một exit node chuyển điểm egress của bạn, nhưng không loại bỏ điểm egress

Exit node định tuyến toàn bộ lưu lượng Internet public 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 trước khi client có thể sử dụng nó. Cả hai bước đều là cơ chế có chủ đích: một máy chưa được phê duyệt không thể âm thầm trở thành đường ra cho toàn bộ tailnet.

Tiếp theo là vấn đề trust. Lưu lượng được mã hóa từ laptop của bạn đến exit node. Sau đó, lưu lượng rời máy đó dưới dạng traffic Internet thông thường và mang IP 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à upstream network của họ cũng nhìn thấy chúng. Bạn chỉ chuyển điểm quan sát sang nơi khác, chứ không xóa nó. Đây là một đánh đổi hợp lý khi bạn kiểm soát đầu bên kia. Đó là lý do để tự chạy exit node trên một VPS. Ngược lại, đây là lựa chọn kém an toàn khi bạn không kiểm soát đầu bên kia.

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

Tailnet mới được tạo có chính sách cho phép rộng. Tài liệu kiểm soát truy cập của Tailscale cho biết file policy mặc định “cho phép các thiết bị trong tailnet liên lạc 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. Đây là mạng phẳng. Bạn đã đưa mạng đó 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 list (ACL) hoặc grants mới hơn. Cả hai đều được viết bằng một phương ngữ 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 bằng cách không khai báo rule tương ứng. Tailscale liệt kê những target của rule 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 tag hoặc autogroup. Bạn cũng có thể 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 như điện thoại cá nhân, tailscale set --shields-up sẽ chặn các kết nối đó ngay trên 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 xác định 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 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 gây trở ngại, NetBird là mesh còn lại có control plane có thể tự host, và chạy NetBird server trên VPS của bạn sẽ chuyển quyết định enrolment tương tự sang phần cứng do bạn sở hữu.

Điểm thay đổi là danh tính của bên có thể enrol một node giả mạo. Với Headscale, key directory 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 các thiết bị của bạn. Không bên thứ ba nào có thể bị buộc phải giao một key hoặc ký một key.

Data plane không thay đổi. Đâ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ể tạo đường kết nối trực tiếp. Bạn cũng phải tự đảm nhiệm các công việc mà Tailscale trước đây xử lý: duy trì uptime, patch, backup và bảo đảm an ninh vật lý cho máy chủ. Nếu Headscale host bị breach, attacker sẽ có đúng những quyền mà một coordination server bị breach có thể cấp cho họ: enrol một node và phân phối policy. Tailnet lock không có trong danh sách tính năng của Headscale, nên không có compensating control cho rủi ro cụ thể này. Nếu vấn đề quyền sở hữu là yếu tố quyết định, tự host control plane bằng Headscale sẽ hướng dẫn bạn thiết lập.

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

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

Tailscale không bảo vệ được những gì

• Endpoint đã bị xâm nhập. Tailnet tin cậy các thiết bị. Malware trên một laptop đã được phê duyệt sẽ có tunnel, địa chỉ tailnet và mọi quyền mà policy cấp cho user đó. Đây là lỗ hổ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ó quyền chỉnh sửa policy file đều có thể tự cấp quyền truy cập vào mọi thứ. Người chiếm được tài khoản identity của Owner cũng làm được điều tương tự. Hãy review các thay đổi policy như cách bạn review code.
• Phân tích lưu lượng. ISP (nhà cung cấp dịch vụ Internet) 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 ghi nhận peer nào đã giao tiếp và vào lúc 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ị che giấu. 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 là 180 ngày. 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 tên chính là tình huống mà device approval được tạo ra để ngăn chặn.
2. Chạy tailscale lock status để xem tailnet lock có được bật 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 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ị có thể truy cập mọi thiết bị khác trên mọi port, và một laptop bị nhiễm có thể truy cập tất cả các thiết bị đó.

Tailscale tạo dựng uy tín ở 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 các phần thuộc về bạn: identity account, thiết lập approval, 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ó đọc đượ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 key WireGuard được tạo trên thiết bị của bạn. Trang bảo mật của Tailscale nêu rõ: "Private keys never leave the device. All traffic is end-to-end encrypted, always." Điều này cũng áp dụng cho các kết nối chuyển sang relay DERP, vì relay "blindly forwards already-encrypted traffic from one device to another" và không giữ key nào có thể dùng để giải mã. Hạ tầng Tailscale chỉ thấy metadata: những thiết bị nào tồn tại, 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 từ một node được bí mật thêm vào, node này có thể "send or receive traffic to your existing nodes". Mã hóa không giúp ích trong trường hợp đó "because the peer itself would be malicious". 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ì nó chưa từng giữ private key của các thiết bị đó.

Exit node có ẩn hoạt động duyệt web của tôi khỏi ISP không?

Nó ẩn các đích truy cập khỏi network mà bạn đang kết nối, bao gồm ISP tại nhà hoặc tại 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. Exit node sẽ thấy các đích truy cập đó. Hosting provider và upstream network của exit node cũng thấy chúng, trong khi các website bạn truy cập sẽ thấy IP address của exit node. Bạn chỉ đang chọn một bên quan sát khác, vì vậy hãy chọn bên mà bạn thực sự tin cậy.

Headscale có an toàn hơn Tailscale coordination server không?

Đây là một quyết định về trust khác, không phải lựa chọn chắc chắn an toàn hơn. Với Headscale, bạn quản lý key directory và policy, nên không bên ngoài nào có thể bị buộc phải 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 đó: patch, uptime, backup và bảo mật của chính host. Một Headscale host bị xâm nhập cho attacker quyền enrol tương tự như 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 đó phù hợp.

Tôi vẫn cần firewall trên VPS đang nằm trong tailnet không?

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