1 điểm bởi GN⁺ 2026-01-09 | 2 bình luận | Chia sẻ qua WhatsApp
  • Trong Tailscale v1.92.5, các tính năng mã hóa tệp trạng thái (state file encryption)khóa xác thực phần cứng trên client Linux và Windows đã bị tắt theo mặc định
  • Ngay cả khi thiết bị TPM bị đặt lại hoặc thay thế, client vẫn khởi động bình thường và việc tải khóa xác thực phần cứng thất bại sẽ không cản trở quá trình chạy
  • Trong image container Tailscale, khóa xác thực phần cứng không còn được thêm vào Secrets trạng thái của Kubernetes, nên có thể di chuyển container sang node khác
  • Tailscale Kubernetes Operator không còn mặc định dùng phương thức đặt hàng ARI khi gia hạn chứng chỉ, đồng thời không lưu khóa xác thực phần cứng vào Secrets
  • Thay đổi lần này là bản cập nhật nhằm đơn giản hóa cách cấu hình các tính năng bảo mật của Tailscale và tăng tính linh hoạt khi triển khai trong nhiều môi trường khác nhau

Cập nhật Tailscale v1.92.5

  • Client Linux và Windows

    • Trong các tính năng liên quan đến Secure node state storage, mã hóa tệp trạng tháikhóa xác thực phần cứng đã bị tắt theo mặc định
    • Ngay cả khi thiết bị TPM (Trusted Platform Module) bị đặt lại hoặc thay thế, việc khởi động client sẽ không bị chặn
  • Image container Tailscale

    • Phiên bản mới đã có trên Docker HubGitHub Packages
    • Khóa xác thực phần cứng không được thêm vào Secrets trạng thái của Kubernetes, nên có thể chuyển container Tailscale sang node Kubernetes khác
  • Tailscale Kubernetes Operator

    • Có thể triển khai phiên bản mới theo hướng dẫn cài đặt
    • Khi gia hạn chứng chỉ, phương thức đặt hàng ARI không còn được dùng theo mặc định, giúp tránh lỗi gia hạn có thể xảy ra khi khóa tài khoản ACME được tạo lại
    • Khóa xác thực phần cứng không được thêm vào Secrets trạng thái của Kubernetes, nên có thể chuyển Operator sang node khác
  • Tailscale tsrecorder

    • Phiên bản mới có trên Docker Hub
    • Bản phát hành này chỉ bao gồm cập nhật thư viện, không có thay đổi về tính năng

5 tháng 1 năm 2026 — API Workload Identity Federation

23 tháng 12 năm 2025 — GitHub Action v4.1.1

  • Tailscale GitHub Action đã được sửa để sử dụng đúng kiến trúc khi lưu và truy xuất bộ nhớ đệm trên GitHub Runner chạy trên macOS

2 bình luận

 
joyfui 2026-01-09

Ủa, hình như cách đây không lâu tôi đã thấy một bài viết của ai đó phát hành tiện ích liên quan đến vụ này...

 
GN⁺ 2026-01-09
Ý kiến trên Hacker News
  • Tôi là kỹ sư đã triển khai tính năng mã hóa trạng thái nút đầu tiên ở Tailscale (@awly trên Github). Lần này chúng tôi đã quyết định tắt mặc định trong phiên bản 1.92.5
    Như một bình luận khác đã suy đoán, tính năng này có gánh nặng hỗ trợ quá lớn. Ban đầu nó được thiết kế để nếu TPM bị reset hoặc thay thế thì luôn bị coi là can thiệp trái phép và client sẽ từ chối chạy. Nhưng trên thực tế, TPM thường không ổn định vì nhiều lý do không mang tính ác ý
    Ví dụ có issue 17654, issue 18288, issue 18302.
    TPM là công cụ tuyệt vời khi tổ chức có thể kiểm soát thiết bị tốt, nhưng với một dịch vụ phải hỗ trợ thiết bị trong nhiều môi trường khác nhau như Tailscale thì nó quá phức tạp. Vì vậy hiện tại chúng tôi để cho người dùng hoặc quản trị viên nhạy cảm về bảo mật tự kích hoạt. Đáng lẽ changelog nên đưa thêm bối cảnh này, và tôi thấy có lỗi về điều đó
    • Đọc các issue được liên kết xong tôi khá ngạc nhiên. Tôi cứ nghĩ vấn đề TPM chỉ xảy ra trên phần cứng cũ hoặc môi trường đặc biệt, nhưng nó cũng xuất hiện trên Dell XPS và nhiều VM.
      Tôi chạy hầu hết các instance Tailscale trên VM và container, và thực tế TPM encryption chỉ được áp dụng trên PC chính, iPhone và host của máy chủ Linux. Trên VM hay container thì hoàn toàn không hoạt động, còn laptop thì có lẽ quá cũ nên không được hỗ trợ
    • Tôi thấy chính sách này rất hợp lý. Cảm ơn vì đã giải thích
    • Trong issue 17654, có người dùng nói rằng ngay cả với cấu hình “TS_ENCRYPT_STATE=false” thì cũng không giải quyết được, nhưng đến phiên bản 1.92.1 thì vấn đề lại biến mất.
      Tôi muốn biết trong trường hợp như vậy đây có thực sự là vấn đề state encryption hay là do nguyên nhân khác, nếu có thể giải thích thêm
    • Tôi cũng từng tin tưởng TPM, nhưng chỉ một lần cập nhật BIOS đã khiến TPM bị khởi tạo lại hoàn toàn. Từ đó về sau tôi quyết định không phụ thuộc vào TPM nữa
    • Cảm ơn vì đã giải thích thẳng thắn như vậy. Sẽ tốt hơn nếu changelog có thêm dù chỉ một chút bối cảnh này.
      Nếu tình hình phức tạp thì một bài blog ngắn tổng hợp riêng cũng rất đáng hoan nghênh
  • Tính năng này ngay từ đầu không nên được bật mặc định. Quản trị viên phải là người chủ động chọn dùng TPM
    Như changelog đã nói, nếu TPM bị reset hoặc thay thế thì sẽ không thể tải khóa xác thực phần cứng, khiến client không khởi động được.
    Trong nhiều môi trường triển khai tính năng này thực sự cần thiết, nhưng vì Tailscale chạy trên quá nhiều OS và thiết bị nên có quá nhiều xung đột khó lường
    • Mỗi lần tôi định dùng TPM cho mục đích mã hóa thì cuối cùng lại cần mật khẩu khôi phục hoặc khóa dự phòng. Nhưng như vậy lại làm mất ý nghĩa của chính TPM.
      Chỉ một sai sót nhỏ cũng có thể khiến khóa của người dùng biến mất hoàn toàn, nên trên thực tế tôi thấy rất khó dùng
    • Windows chẳng phải mặc định đã dùng TPM sao? Nếu vậy thì hàng triệu người dùng Windows lẽ ra phải gặp vấn đề.
      Vì thế chuyện này có vẻ hơi phản ứng quá mức. Thật đáng tiếc khi tắt toàn bộ tính năng chỉ vì một số trường hợp TPM ngoại lệ.
      Giá như có một bước trung gian (ví dụ: kích hoạt tùy chọn) thì có lẽ tốt hơn
    • Nếu TPM bị reset hoặc thay thế thì việc chặn lại chẳng phải mới là hành vi đúng về mặt phòng thủ trước tấn công vật lý hay sao, tôi có chút thắc mắc
  • PR này có giải thích lý do vô hiệu hóa.
    Họ nói rằng độ chênh lệch chất lượng của TPM quá lớn nên gây ra đủ loại vấn đề
  • Nhìn changelog thì có vẻ nguyên nhân là các vấn đề do bật mặc định gây ra (tôi không có thông tin nội bộ).
    Tuy vậy, tôi vẫn tò mò liệu nếu xử lý xong vấn đề này thì họ có kế hoạch bật mặc định lại hay không.
    Tôi tin tưởng đội ngũ Tailscale, nhưng trong thời điểm như hiện nay khi lo ngại bị giám sát ngày càng lớn, tôi muốn nghe một lý do rõ ràng rằng thay đổi này không phải vì yêu cầu từ chính phủ
    • Tôi nghĩ nguyên nhân không phải do Tailscale mà là do sự bất ổn của chính phần cứng TPM.
      Vì vậy tính năng này chỉ nên được dùng có chọn lọc trong môi trường được kiểm soát
  • Tailscale liên tục crash trên máy NixOS dùng phần cứng cũ và tôi không hiểu vì sao, nhưng nhờ thay đổi lần này tôi mới biết nguyên nhân. Là do TPM encryption
  • Tôi đoán có lẽ họ đã vô hiệu hóa vì yêu cầu hỗ trợ quá nhiều
  • Suốt một tháng qua Tailscale của tôi liên tục hỏng, và bản vá ra hôm nay đã giải quyết được vấn đề đó.
    Nguyên nhân là cập nhật BIOS, sau đó Tailscale chỉ đứng ở trạng thái “Starting” mà không hiển thị bất kỳ lỗi nào
  • Tôi boot Linux cài trên USB luân phiên giữa desktop và laptop, rồi một ngày Tailscale đột nhiên ngừng hoạt động.
    Tôi tưởng chỉ trường hợp của mình là lạ, nhưng giờ mới biết mã hóa dựa trên TPM còn có thể thất bại vì nhiều lý do khác
  • Trên Linux, có vẻ chỉ cần thêm FLAGS="--encrypt-state" vào /etc/default/tailscaled.
    Trong log có hiện thông báo "migrated ... to TPM-sealed format", nên có vẻ hoạt động tốt
  • Vì những lý do như vậy nên ở thị trường đại chúng, không thể đưa một tính năng hỏng dù chỉ 1% vào mặc định.
    Cuối cùng vẫn phải hạ xuống mẫu số chung thấp nhất, và buộc phải ưu tiên độ ổn định hơn bảo mật hoàn hảo.
    Nếu tôi là người vận hành Tailscale, có lẽ tôi sẽ nói “ai bị TPM lỗi thì tự sửa đi, còn chúng tôi sẽ giữ bảo mật mặc định”.
    Nhưng tôi hiểu là Avery có lý do để đưa ra quyết định đó