1 คะแนน โดย GN⁺ 2026-01-09 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • ใน Tailscale v1.92.5 ฟีเจอร์ การเข้ารหัสไฟล์สถานะ (state file encryption) และ คีย์ยืนยันตัวตนด้วยฮาร์ดแวร์ ของไคลเอนต์ Linux และ Windows ถูกปิดใช้งานเป็นค่าเริ่มต้น
  • แม้อุปกรณ์ TPM จะถูกรีเซ็ตหรือเปลี่ยนใหม่ ไคลเอนต์ก็ยังเริ่มทำงานได้ตามปกติ และความล้มเหลวในการโหลดคีย์ยืนยันตัวตนด้วยฮาร์ดแวร์จะไม่ขัดขวางการทำงาน
  • ใน อิมเมจคอนเทนเนอร์ของ Tailscale คีย์ยืนยันตัวตนด้วยฮาร์ดแวร์จะไม่ถูกเพิ่มเข้าไปใน Kubernetes state Secrets อีกต่อไป ทำให้สามารถย้ายคอนเทนเนอร์ไปยังโหนดอื่นได้
  • Tailscale Kubernetes Operator จะไม่ใช้วิธีสั่งซื้อ ARI เป็นค่าเริ่มต้นเมื่อทำการต่ออายุใบรับรอง และจะไม่เก็บคีย์ยืนยันตัวตนด้วยฮาร์ดแวร์ไว้ใน Secrets
  • การเปลี่ยนแปลงครั้งนี้เป็นอัปเดตที่ทำให้วิธีตั้งค่าฟีเจอร์ด้านความปลอดภัยของ Tailscale เรียบง่ายขึ้น และเพิ่มความยืดหยุ่นในการดีพลอยในสภาพแวดล้อมที่หลากหลาย

อัปเดต Tailscale v1.92.5

  • ไคลเอนต์ Linux และ Windows

    • ในฟีเจอร์ที่เกี่ยวข้องกับ Secure node state storage นั้น การเข้ารหัสไฟล์สถานะ และ คีย์ยืนยันตัวตนด้วยฮาร์ดแวร์ ถูกปิดใช้งานเป็นค่าเริ่มต้น
    • แม้อุปกรณ์ TPM (Trusted Platform Module) จะถูกรีเซ็ตหรือเปลี่ยนใหม่ ก็จะไม่ขัดขวางการเริ่มต้นของไคลเอนต์
  • อิมเมจคอนเทนเนอร์ของ Tailscale

    • เวอร์ชันใหม่พร้อมใช้งานบน Docker Hub และ GitHub Packages
    • คีย์ยืนยันตัวตนด้วยฮาร์ดแวร์จะไม่ถูกเพิ่มเข้าไปใน Kubernetes state Secrets ทำให้สามารถย้ายคอนเทนเนอร์ Tailscale ไปยัง Kubernetes node อื่นได้
  • Tailscale Kubernetes Operator

    • เวอร์ชันใหม่สามารถดีพลอยได้ตาม คู่มือการติดตั้ง
    • เมื่อทำการต่ออายุใบรับรอง จะไม่ใช้ วิธีสั่งซื้อ ARI เป็นค่าเริ่มต้น เพื่อป้องกันความล้มเหลวในการต่ออายุที่อาจเกิดขึ้นเมื่อมีการสร้าง ACME account key ขึ้นใหม่
    • คีย์ยืนยันตัวตนด้วยฮาร์ดแวร์จะไม่ถูกเพิ่มเข้าไปใน Kubernetes state Secrets ทำให้สามารถย้าย Operator ไปยังโหนดอื่นได้
  • Tailscale tsrecorder

    • เวอร์ชันใหม่พร้อมใช้งานบน Docker Hub
    • รีลีสนี้ มีเพียงการอัปเดตไลบรารีเท่านั้น ไม่มีการเปลี่ยนแปลงฟีเจอร์

5 มกราคม 2026 — Workload Identity Federation API

23 ธันวาคม 2025 — GitHub Action v4.1.1

  • Tailscale GitHub Action ได้รับการแก้ไขให้ใช้สถาปัตยกรรมที่ถูกต้องเมื่อจัดเก็บและดึงแคชบน GitHub Runner ที่ทำงานบน macOS

2 ความคิดเห็น

 
joyfui 2026-01-09

เอ๊ะ เหมือนเมื่อไม่นานมานี้ผมน่าจะเห็นโพสต์ของคนที่แจกยูทิลิตี้เกี่ยวกับเรื่องนี้อยู่นะ...

 
GN⁺ 2026-01-09
ความเห็นบน Hacker News
  • ผมคือวิศวกรที่เป็นคนเริ่มทำฟีเจอร์ node state encryption ใน Tailscale เป็นคนแรก (@awly บน Github) และครั้งนี้ก็ตัดสินใจปิดค่าเริ่มต้นของมันในเวอร์ชัน 1.92.5
    อย่างที่มีคนคาดไว้ในคอมเมนต์อื่น ฟีเจอร์นี้มี ภาระด้านการซัพพอร์ตสูงเกินไป เดิมทีเราออกแบบให้ถ้า TPM ถูกรีเซ็ตหรือถูกเปลี่ยน จะถือว่าเป็นการงัดแงะทันทีและให้ไคลเอนต์ปฏิเสธการทำงาน แต่ในความเป็นจริง TPM มักมีความไม่เสถียรด้วยเหตุผลที่ไม่ได้มีเจตนาร้าย
    ตัวอย่างเช่น issue 17654, issue 18288, issue 18302
    TPM เป็นเครื่องมือที่ยอดเยี่ยมเมื่อองค์กรควบคุมอุปกรณ์ได้ดี แต่สำหรับบริการอย่าง Tailscale ที่ต้องรองรับ อุปกรณ์จากสภาพแวดล้อมที่หลากหลาย มันซับซ้อนเกินไป เลยตัดสินใจให้ผู้ใช้หรือผู้ดูแลระบบที่ใส่ใจเรื่องความปลอดภัยมาเปิดเองตอนนี้ เราน่าจะใส่บริบทแบบนี้ไว้ใน changelog มากกว่านี้ ตรงนั้นต้องขออภัยด้วย
    • พอได้อ่าน issue ที่ลิงก์ไว้ก็รู้สึกแปลกใจเหมือนกัน ผมนึกว่าปัญหา TPM จะเกิดแค่กับเครื่องเก่าหรือสภาพแวดล้อมเฉพาะทาง แต่กลับเกิดบน Dell XPS และ VM หลายตัวด้วย
      ผมรัน Tailscale ส่วนใหญ่บน VM และคอนเทนเนอร์ และที่มี TPM encryption ใช้งานได้จริงมีแค่บนพีซีหลัก, iPhone และโฮสต์ของ Linux server เท่านั้น บน VM หรือคอนเทนเนอร์ใช้ไม่ได้เลย และโน้ตบุ๊กก็น่าจะเก่าเกินกว่าจะรองรับ
    • ผมคิดว่านโยบายนี้สมเหตุสมผลมาก ขอบคุณที่อธิบาย
    • ใน issue 17654 มีผู้ใช้คนหนึ่งบอกว่าแม้ตั้งค่า “TS_ENCRYPT_STATE=false” ก็ยังไม่หาย แต่หลังจากนั้นในเวอร์ชัน 1.92.1 ปัญหาก็หายไป
      กรณีแบบนี้อยากรู้ว่าจริง ๆ แล้วเป็นปัญหาจาก state encryption หรือมีสาเหตุอื่นกันแน่ พอจะอธิบายเพิ่มได้ไหม
    • ผมก็เคยเชื่อใจ TPM เหมือนกัน แต่ BIOS update ครั้งเดียวทำให้ TPM ถูกล้างค่าไปหมดเลย หลังจากนั้นผมก็เลิกพึ่ง TPM อีก
    • ขอบคุณที่อธิบายอย่างตรงไปตรงมา อยากเห็นเบื้องหลังแบบนี้อยู่ใน changelog บ้าง
      ถ้าเรื่องมันซับซ้อน การเขียน blog post สั้น ๆ แยกออกมาต่างหากก็น่ายินดีเช่นกัน
  • ฟีเจอร์นี้ตั้งแต่แรกก็ ไม่ควรเปิดเป็นค่าเริ่มต้น ผู้ดูแลระบบควรต้องเลือกเองอย่างชัดเจนว่าจะใช้ TPM
    ตามที่ระบุใน changelog ถ้า TPM ถูกรีเซ็ตหรือถูกเปลี่ยน จะเกิดปัญหาที่โหลด hardware auth key ไม่ได้จนไคลเอนต์เริ่มทำงานไม่ได้
    ในหลายสภาพแวดล้อมการติดตั้ง ฟีเจอร์นี้จำเป็นมาก แต่เพราะ Tailscale ทำงานบน OS และอุปกรณ์ที่หลากหลายมาก จึงมี ความขัดข้องที่คาดเดาไม่ได้ มากเกินไป
    • ทุกครั้งที่พยายามใช้ TPM เพื่อการเข้ารหัส สุดท้ายก็มักจะต้องมี รหัสผ่านกู้คืนหรือ backup key อยู่ดี ซึ่งทำให้จุดประสงค์ของ TPM เองแทบหมดความหมาย
      ความผิดพลาดเล็กน้อยแค่ครั้งเดียวก็อาจทำให้คีย์ของผู้ใช้หายถาวรได้ เลยรู้สึกว่าในทางปฏิบัติมันใช้งานยาก
    • โดยปกติ Windows ไม่ได้ใช้ TPM อยู่แล้วหรือ? ถ้าใช่ ผู้ใช้ Windows หลายล้านคนน่าจะเจอปัญหาไปแล้วสิ
      เลยรู้สึกว่านี่ดูเป็นการ ตอบสนองเกินเหตุ นิดหน่อย น่าเสียดายที่ปิดทั้งฟีเจอร์ไปเพราะเคสยกเว้นบางอย่างของ TPM
      น่าจะมีทางสายกลางอยู่บ้าง เช่น เปิดใช้แบบเลือกเอง
    • ถ้า TPM ถูกรีเซ็ตหรือถูกเปลี่ยนแล้วต้องบล็อก แบบนั้นไม่ใช่พฤติกรรมที่ ถูกต้องในแง่การป้องกันการโจมตีทางกายภาพ อยู่แล้วหรือ
  • ใน PR นี้ มีอธิบายเหตุผลของการปิดไว้
    เขาบอกว่าคุณภาพของ TPM แปรปรวนมากเกินไป จนทำให้เกิดปัญหาหลากหลาย
  • ดูจาก changelog แล้วน่าจะเป็นเพราะปัญหาที่เกิดจากการเปิดเป็นค่าเริ่มต้น (ผมไม่มีข้อมูลวงใน)
    แต่ก็สงสัยว่าถ้าแก้ปัญหานี้ได้แล้ว มีแผนจะกลับมาเปิดเป็นค่าเริ่มต้นอีกไหม
    ผมเชื่อใจทีม Tailscale แต่ในช่วงเวลาที่ความกังวลเรื่อง การเฝ้าระวัง เพิ่มขึ้นแบบทุกวันนี้ ก็อยากได้เหตุผลที่ชัดเจนว่าไม่ใช่การเปลี่ยนแปลงเพราะแรงกดดันจากภาครัฐ
    • ผมมองว่าต้นเหตุของปัญหาไม่ใช่ Tailscale แต่เป็น ความไม่เสถียรของฮาร์ดแวร์ TPM เอง
      ดังนั้นฟีเจอร์นี้ก็ควรใช้แบบเลือกเปิดในสภาพแวดล้อมที่ควบคุมได้เท่านั้น
  • บนเครื่อง NixOS ที่เป็นฮาร์ดแวร์เก่า Tailscale แครช อยู่เรื่อย ๆ โดยไม่รู้สาเหตุ แต่การเปลี่ยนแปลงครั้งนี้ทำให้ผมรู้แล้วว่าต้นเหตุมาจาก TPM encryption
  • เดาว่าคงปิดไปเพราะมี คำขอซัพพอร์ตเยอะเกินไป
  • ตลอดเดือนที่ผ่านมา Tailscale พังอยู่ตลอด แต่แพตช์ที่ออกวันนี้แก้ปัญหานั้นได้
    สาเหตุคือ BIOS update และหลังจากนั้น Tailscale ก็ค้างอยู่ที่สถานะ “Starting” โดยไม่แสดง error ใด ๆ
  • ผมใช้ Linux ที่ติดตั้งบน USB สลับบูตระหว่างเดสก์ท็อปกับโน้ตบุ๊ก และวันหนึ่ง Tailscale ก็หยุดทำงานกะทันหัน
    ผมนึกว่าเป็นเคสแปลกเฉพาะตัวเอง แต่ตอนนี้ได้รู้แล้วว่าการเข้ารหัสแบบอิง TPM ก็ล้มเหลวได้จากเหตุผลอื่นเหมือนกัน
  • บน Linux ดูเหมือนว่าสามารถเพิ่ม FLAGS="--encrypt-state" ใน /etc/default/tailscaled ได้
    ใน log มีข้อความ "migrated ... to TPM-sealed format" ขึ้นมา เลยดูเหมือนว่าจะทำงานได้ปกติ
  • ด้วยเหตุผลแบบนี้ ฟีเจอร์ที่มีโอกาสพังแม้แค่ 1% ก็เอามาเปิดเป็นค่าปริยายสำหรับตลาดมวลชนไม่ได้
    สุดท้ายก็ต้องยึดตามตัวหารร่วมที่ต่ำที่สุด และเลือก เสถียรภาพมาก่อน ความปลอดภัยที่สมบูรณ์แบบ
    ถ้าผมเป็นคนดูแล Tailscale ผมอาจจะบอกว่า “ใครที่ TPM พังก็ไปแก้กันเอง เราจะคงความปลอดภัยไว้เป็นค่าเริ่มต้น”
    แต่ผมก็เข้าใจว่า Avery ต้องมีเหตุผลของเขาในการตัดสินใจ