Tailscale ปลอดภัยไหม? เจาะลึกรูปแบบความเชื่อมั่นของระบบ

Tailscale ปลอดภัยหรือไม่? คำตอบโดยสรุป

Tailscale ปลอดภัยหรือไม่? สำหรับส่วนที่คนส่วนใหญ่กังวล คำตอบคือใช่: coordination server ที่รัน tailnet ของคุณไม่เคยเก็บ private key ที่ใช้เข้ารหัสข้อมูลของคุณ ดังนั้นเซิร์ฟเวอร์จึงไม่สามารถอ่านสิ่งที่อุปกรณ์ของคุณส่งถึงกันได้ หน้าความปลอดภัย ของ Tailscale ระบุไว้ชัดเจนว่า: "Private keys จะไม่ถูกส่งออกจากอุปกรณ์ ข้อมูลทั้งหมดจะถูกเข้ารหัสแบบ end-to-end เสมอ" คำถามที่มีประโยชน์กว่าคือคำถามอื่น coordination server ที่ถูกบุกรุกหรือถูกบังคับด้วยคำสั่งทางกฎหมายไม่จำเป็นต้องอ่าน packet ของคุณ แต่เซิร์ฟเวอร์มีอำนาจตัดสินใจว่าอุปกรณ์ของคุณจะเชื่อถือ public key ใด ดังนั้นจึงอาจเพิ่มอุปกรณ์ที่คุณไม่เคยอนุมัติเข้ามาในเครือข่ายได้

นั่นคือรูปแบบความเชื่อมั่น (trust model) ในประโยคเดียว: การเข้ารหัสช่วยปกป้องข้อมูล และ control plane เป็นตัวกำหนดสมาชิก แต่ละส่วนด้านล่างนี้จะระบุถึงฝ่ายที่คุณต้องเชื่อถือ ระบุสิ่งที่ฝ่ายนั้นทำได้จริง และให้การควบคุมที่จำกัดอำนาจของฝ่ายนั้น หากคุณยังใหม่กับผลิตภัณฑ์นี้ ให้เริ่มต้นที่ Tailscale คืออะไรและ mesh ทำงานอย่างไร

Control plane และ data plane แยกออกจากกัน

Tailscale คือ mesh VPN (virtual private network) ที่สร้างขึ้นบนพื้นฐานของ WireGuard ซึ่งเป็นโปรโตคอลเดียวกับที่คุณต้องตั้งค่าด้วยตนเองบน VPS ที่รัน WireGuard ด้วยตัวเอง อุปกรณ์ทุกเครื่องจะสร้างคู่กุญแจ WireGuard ขึ้นมาเองในเครื่อง บทความ วิธีการทำงาน ของ Tailscale เรียก coordination server ว่าเป็น "กล่องรับฝากกุญแจสาธารณะร่วม" และระบุว่า "กุญแจส่วนตัวจะไม่ถูกส่งออกจากโหนดของตนเองโดยเด็ดขาด"

Data plane คือการรับส่งข้อมูลที่เข้ารหัสระหว่างอุปกรณ์ของคุณ ข้อมูลจะเดินทางจากอุปกรณ์เครื่องหนึ่งไปยังอีกเครื่องหนึ่งโดยตรงหากเครือข่ายเอื้ออำนวย ส่วน control plane คือส่วนประกอบอื่นทั้งหมด ได้แก่ อุปกรณ์ใดบ้างที่อยู่ใน tailnet, กุญแจสาธารณะใดเป็นของอุปกรณ์เครื่องไหน, นโยบายการเข้าถึง (access policy), การตั้งค่า DNS และรายการ relay ทั้งหมด Tailscale ดำเนินการ control plane ในรูปแบบบริการแบบ hosted ในขณะที่คุณรัน data plane บนเครื่องของคุณเอง

หากแยกสองส่วนนี้ออกจากกัน คำถามด้านความปลอดภัยทุกข้อในที่นี้จะสามารถหาคำตอบได้ การเข้ารหัสเป็นคุณสมบัติของ data plane ส่วนการเป็นสมาชิกเป็นสิ่งที่ตัดสินใจโดย control plane การเข้ารหัสไม่สามารถบอกคุณได้ว่าใครได้รับอนุญาตให้เป็น peer ในเครือข่าย

หาก coordination server ถูกบุกรุก จะเกิดอะไรขึ้นได้บ้าง?

มันไม่สามารถถอดรหัสข้อมูลของคุณได้ กุญแจที่ใช้ในการเข้ารหัสถูกสร้างขึ้นบนอุปกรณ์ของคุณและไม่มีการอัปโหลดขึ้นไป ดังนั้นจึงไม่มีข้อมูลใดให้ยึดหรือรั่วไหลที่จะทำให้ช่องทางสื่อสารเปิดออกได้ กรณีนี้รวมถึงข้อมูลที่ถูกส่งผ่าน relay ซึ่งจะอธิบายรายละเอียดเพิ่มเติมในภายหลัง

มันสามารถเพิ่มโหนด (node) เข้ามาในระบบได้ เมื่อ Tailscale ประกาศใช้ tailnet lock ทางบริษัทได้อธิบายความเสี่ยงไว้ว่า เซิร์ฟเวอร์ที่ประสงค์ร้ายอาจ "ใช้โหนดที่ถูกเพิ่มเข้ามาอย่างลับๆ เพื่อส่งหรือรับข้อมูลไปยังโหนดที่มีอยู่เดิมของคุณ" และในจุดนั้น "การที่ข้อมูลถูกเข้ารหัสไว้ก็ไม่มีความหมาย เพราะตัวโหนดปลายทางเองนั้นเป็นอันตราย" อุปกรณ์ของคุณเชื่อถือโหนดปลายทางเพราะ control plane แจ้งว่ากุญแจนั้นเป็นส่วนหนึ่งของ tailnet

มันสามารถเปลี่ยนแปลงสิทธิ์การเข้าถึงของอุปกรณ์คุณได้ นโยบายการเข้าถึง (access policy) ถูกจัดเก็บไว้ใน control plane และถูกแจกจ่ายไปยังโหนดต่างๆ เอกสาร white paper ของ tailnet lock ระบุว่า tailnet lock "ไม่ได้ป้องกันไม่ให้ control plane ที่ถูกบุกรุกทำลายการเชื่อมต่อในเครือข่ายของคุณ เช่น การไม่แจกจ่ายกุญแจโหนดใหม่ หรือการแจกจ่ายนโยบายการควบคุมการเข้าถึงที่ปฏิเสธการเชื่อมต่อกับทุกโหนด"

มันสามารถเห็นข้อมูล metadata ของการเชื่อมต่อได้เสมอ บันทึกการไหลของข้อมูลเครือข่าย (network flow logs) ของ Tailscale จะบันทึกเหตุการณ์การเปิดและปิดการเชื่อมต่อระหว่างเครื่องต่อเครื่อง เอกสารระบุว่าบันทึกเหล่านั้น "ไม่มีข้อมูลเกี่ยวกับการทำงานของไคลเอนต์หรือเนื้อหาของการรับส่งข้อมูลเครือข่ายโดยเด็ดขาด" ดังนั้น control plane สามารถทราบได้ว่าอุปกรณ์ใดของคุณติดต่อกับอุปกรณ์ใดและเมื่อใด แต่ไม่ทราบว่าอุปกรณ์เหล่านั้นสื่อสารอะไรกัน

มีเพียงรายการเดียวในรายการข้างต้นที่เกี่ยวข้องกับการเข้ารหัส ส่วนรายการอื่นเกี่ยวข้องกับสถานะสมาชิกและนโยบาย ซึ่งเป็นเหตุผลว่าทำไมการควบคุมที่คุณควรให้ความสำคัญคือส่วนที่กำกับดูแลการลงทะเบียนโหนด (enrolment)

Identity provider ของคุณคือรากฐานความน่าเชื่อถือของ tailnet

Tailscale ไม่ได้เก็บฐานข้อมูลรหัสผ่านของตนเอง เอกสารระบุไว้อย่างชัดเจนว่าไม่มีรหัสผ่านของ Tailscale โดยการลงชื่อเข้าใช้จะถูกมอบหมายไปยัง identity provider (IdP) ได้แก่ Apple, Google, GitHub, Microsoft, Okta, OneLogin หรือผู้ให้บริการ OpenID Connect อื่นๆ

โปรดทำความเข้าใจว่านี่คือข้อกำหนดด้านความปลอดภัย ผู้ใดก็ตามที่สามารถลงชื่อเข้าใช้บัญชี Google หรือ Microsoft ของคุณได้ ก็สามารถลงชื่อเข้าใช้ tailnet ของคุณได้เช่นกัน การยืนยันตัวตนแบบหลายปัจจัย (MFA) ของคุณจะเป็นไปตามที่ IdP กำหนด และการยกเลิกสิทธิ์การเข้าถึงจะเป็นไปตามกระบวนการของ IdP เมื่อบุคคลนั้นพ้นสภาพ หากบัญชี IdP ถูกฟิชชิง (phished) บัญชี tailnet ก็จะถูกบุกรุกไปด้วย โดยที่ผู้โจมตีไม่จำเป็นต้องโจมตี WireGuard เลย เพียงแค่เพิ่มอุปกรณ์เข้ามาในระบบ ก็จะได้รับสิทธิ์ตามนโยบายที่คุณกำหนดไว้ให้กับผู้ใช้นั้นทันที

มีกลไกควบคุม 2 อย่างที่ขวางกั้นระหว่างบัญชีที่ถูกขโมยกับอุปกรณ์ที่ใช้งานได้จริงภายใน tailnet ของคุณ ได้แก่ การอนุมัติอุปกรณ์ (device approval) และการหมดอายุของคีย์ (key expiry) ส่วน Tailnet lock เป็นกลไกที่ 3 ซึ่งมุ่งเน้นไปที่ control plane แทนที่จะเป็นตัวบัญชีผู้ใช้โดยตรง

การอนุมัติอุปกรณ์: จะไม่มีสิ่งใดเข้าร่วมเครือข่ายจนกว่าจะมีคนยืนยัน

เอกสารของ Tailscale อธิบายว่าการอนุมัติอุปกรณ์เป็นฟีเจอร์ที่ "ช่วยให้ผู้ดูแลเครือข่าย Tailscale สามารถตรวจสอบและอนุมัติอุปกรณ์ใหม่ก่อนที่จะเข้าร่วมเครือข่าย Tailscale ของคุณได้" โดยผู้ที่เป็น Owner, Admin หรือ IT admin จะสามารถเป็นผู้อนุมัติได้ อุปกรณ์ใหม่จะแสดงป้าย "Needs approval" ในหน้า Machines จนกว่าจะมีคนดำเนินการกับอุปกรณ์นั้น

เมื่อเปิดใช้งานฟีเจอร์นี้ สถานการณ์กรณีบัญชีถูกขโมยจะเปลี่ยนไป ผู้โจมตีจะล็อกอินและลงทะเบียนอุปกรณ์ได้สำเร็จ แต่จากนั้นอุปกรณ์จะรอค้างอยู่โดยไม่สามารถเข้าถึงสิ่งใดได้ พร้อมกับมีป้ายแจ้งเตือนในคอนโซลผู้ดูแลระบบของคุณว่ามีเครื่องที่คุณไม่รู้จักกำลังขอเข้าร่วมเครือข่าย ระบบอัตโนมัติยังคงทำงานได้ตามปกติเนื่องจาก auth key สามารถตั้งค่าให้เป็นแบบ pre-approved ได้ในขณะที่คุณสร้างคีย์ และอุปกรณ์ยังสามารถถูกอนุมัติผ่านทาง API ได้เช่นกัน

Auth key เป็นอีกช่องทางหนึ่งในการเข้าถึงระบบ ดังนั้นให้ปฏิบัติต่อคีย์เหล่านี้เสมือนเป็นข้อมูลรับรอง (credentials) เอกสารของ Tailscale ระบุไว้อย่างชัดเจนเกี่ยวกับความเสี่ยงของคีย์ประเภทนี้ว่า: "โปรดใช้ความระมัดระวังอย่างยิ่งกับคีย์ที่ใช้ซ้ำได้! คีย์เหล่านี้อาจเป็นอันตรายอย่างมากหากถูกขโมย ควรเก็บไว้ในผลิตภัณฑ์ประเภท key vault ที่ออกแบบมาเพื่อวัตถุประสงค์นี้โดยเฉพาะ" ณ เดือนสิงหาคม 2026 ช่วงเวลาหมดอายุของคีย์ที่ระบุไว้ในเอกสารคือ 1 ถึง 90 วัน และหากไม่ได้ระบุวันหมดอายุ ระบบจะตั้งค่าเริ่มต้นไว้ที่สูงสุดคือ 90 วัน ควรเลือกใช้คีย์แบบใช้ครั้งเดียว (one-off keys) ทำเครื่องหมายว่าเป็น ephemeral สำหรับเครื่องที่เข้าออกเครือข่ายบ่อย และเก็บคีย์ที่ใช้ซ้ำได้ทุกรายการไว้โดย เข้ารหัสด้วย Ansible Vault หรือเก็บไว้ใน secrets manager แทนการใส่ไว้ใน shell script

การหมดอายุของคีย์: ตัวจับเวลาที่จำกัดความผิดพลาดอื่นทั้งหมด

คีย์ของโหนดมีวันหมดอายุ ซึ่งเป็นสิ่งที่เปลี่ยนอุปกรณ์ที่ถูกขโมยหรือถูกลืมให้กลายเป็นปัญหาเพียงชั่วคราว เอกสารของ Tailscale ระบุว่า "โดยค่าเริ่มต้น โดเมนใหม่จะถูกตั้งค่าให้มีระยะเวลาหมดอายุ 180 วัน" และ "หากไม่มีการยืนยันตัวตนใหม่ คีย์จะหมดอายุและการเชื่อมต่อจาก/ไปยังปลายทางดังกล่าวจะหยุดทำงาน" คุณสามารถยืนยันตัวตนอุปกรณ์ใหม่ด้วยตนเองได้ดังนี้:

tailscale up --force-reauth

เอกสารเตือนว่าการดำเนินการนี้ "อาจทำให้การเชื่อมต่อ tailnet หยุดชะงัก ดังนั้นจึงไม่ควรทำจากระยะไกลผ่าน SSH หรือ RDP หากไม่มีช่องทางอื่นในการเข้าสู่ระบบในกรณีที่การเชื่อมต่อขาดหายไป" ให้รันคำสั่งนี้โดยเปิดหน้าต่างคอนโซลไว้ หรือทำผ่านเส้นทางอื่นที่เข้าถึงเครื่องได้ เพราะคุณกำลังจะขัดจังหวะเครือข่ายที่คุณใช้งานอยู่

เซิร์ฟเวอร์คือจุดที่การควบคุมนี้มักถูกปรับเปลี่ยน เครื่องที่ต้องยืนยันตัวตนใหม่ทุก 180 วันจะหลุดออกจาก tailnet ตอนตี 3 ในเวลาที่ไม่มีใครเฝ้าดู ดังนั้นผู้ดูแลระบบจึงปิดการหมดอายุของคีย์บนเครื่องเหล่านั้น ซึ่งเป็นการเอาตัวจับเวลาที่จะตัดคีย์ที่ถูกขโมยออกไปในที่สุดออกไป อุปกรณ์ที่ติดแท็ก (tagged device) เป็นคำตอบที่ดีกว่าสำหรับเซิร์ฟเวอร์ เพราะแท็กเป็นเจ้าของเครื่องแทนบุคคล ดังนั้นเครื่องจะยังคงอยู่แม้บุคคลนั้นจะลาออกจากบริษัทไปแล้ว ไม่ว่าคุณจะตัดสินใจอย่างไร ให้ทำรายการเครื่องที่ปิดการหมดอายุของคีย์ไว้เสมอ: คีย์เหล่านั้นจะยังคงใช้งานได้จนกว่าคุณจะลบอุปกรณ์นั้นทิ้ง

Tailnet lock: การนำ coordination server ออกจากห่วงโซ่ความเชื่อถือ

Tailnet lock แก้ปัญหาเรื่องการลงทะเบียนโดยตรง เอกสาร tailnet lock documentation ของ Tailscale อธิบายกลไกไว้ว่า: "เมื่อโหนดใหม่เข้าร่วม tailnet กุญแจสาธารณะของโหนดนั้นจำเป็นต้องได้รับลายเซ็นจากกุญแจ Tailnet Lock เสียก่อน จากนั้น coordination server จะแจกจ่ายกุญแจสาธารณะที่ลงนามแล้วไปยังโหนดอื่นๆ ในเครือข่าย" อุปกรณ์เดิมของคุณจะตรวจสอบลายเซ็นนั้นก่อนที่จะยอมรับโหนดคู่สนทนา ดังนั้นกุญแจโหนดที่ control plane สร้างขึ้นเองโดยพลการจะถูกปฏิเสธ

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

tailscale lock init เป็นคำสั่งเปิดใช้งานฟีเจอร์นี้ โดยคุณต้องระบุโหนดที่จะทำหน้าที่ลงนามในขณะนั้น Tailscale กำหนดให้ต้องมีโหนดลงนามอย่างน้อย 2 โหนดในการเริ่มต้น และอนุญาตให้มีได้สูงสุด 20 โหนดในหนึ่ง tailnet หลังจากนั้น อุปกรณ์ใหม่ทุกเครื่องจำเป็นต้องได้รับลายเซ็นจากหนึ่งในโหนดเหล่านั้น ซึ่งถือเป็นภาระในการปฏิบัติงานจริง: การเพิ่มโทรศัพท์หนึ่งเครื่องหมายถึงคุณต้องรันคำสั่งบนแล็ปท็อป

ข้อจำกัดต่างๆ ได้รับการระบุไว้ในเอกสาร และมีความสำคัญมากกว่าคำอธิบายฟีเจอร์:

• หากทำ disablement secret หาย จะไม่มีทางกู้คืนได้ เอกสารระบุว่า "หากคุณทำ disablement secret หาย และไม่ได้มอบสำเนาให้ฝ่ายสนับสนุนของ Tailscale ไว้ tailnet จะไม่สามารถกู้คืนได้"
• กุญแจสำหรับลงนามจะอยู่ในอุปกรณ์ที่คุณเป็นเจ้าของ ดังนั้นความปลอดภัยของกุญแจจึงขึ้นอยู่กับความปลอดภัยของอุปกรณ์นั้น เอกสารระบุไว้อย่างชัดเจนว่า: "หากอุปกรณ์ถูกบุกรุก กุญแจอาจถูกขโมยไปได้"
• คุณไม่สามารถใช้งานทั้งสองระบบพร้อมกันได้ Tailscale ระบุว่า tailnet lock และ device approval ไม่สามารถใช้งานร่วมกันได้ ดังนั้นการเปิดใช้งานอย่างหนึ่งหมายถึงต้องยกเลิกอีกอย่างหนึ่ง
• เป็นระบบความเชื่อถือเมื่อใช้งานครั้งแรก (TOFU) การตั้งค่าเริ่มต้นยังคงต้องผ่าน control plane และจุดยึดเหนี่ยวของความเชื่อถือจะย้ายมาอยู่ในเครือข่ายของคุณเองหลังจากขั้นตอนแรกนั้นเสร็จสิ้น

Tailnet lock ปกป้องสถานะการเป็นสมาชิก แต่ไม่ได้ปกป้องความพร้อมใช้งานของระบบ ซึ่งระบุไว้ชัดเจนในเอกสารทางเทคนิค (white paper)

การเชื่อมต่อผ่าน relay ทำให้ข้อมูลของฉันถูกเปิดเผยหรือไม่?

ไม่ การเชื่อมต่อจะไม่ถูกเปิดเผย เมื่ออุปกรณ์สองเครื่องไม่สามารถเชื่อมต่อกันโดยตรงได้ ข้อมูลจะเปลี่ยนไปใช้ DERP server (Designated Encrypted Relay for Packets) แทน เอกสารของ Tailscale ระบุคุณสมบัตินี้ไว้อย่างชัดเจนว่า: "เนื่องจาก private key ของ Tailscale จะไม่ถูกส่งออกจากอุปกรณ์ต้นทางที่สร้างมันขึ้นมา DERP server จึงไม่สามารถถอดรหัสข้อมูลของคุณได้ DERP server จะทำหน้าที่เพียงส่งต่อข้อมูลที่ถูกเข้ารหัสไว้แล้วจากอุปกรณ์หนึ่งไปยังอีกอุปกรณ์หนึ่งโดยไม่ทราบเนื้อหาภายใน"

อย่างไรก็ตาม การใช้ relay จะทำให้ความเร็วลดลง และ relay สามารถสังเกตเห็น metadata ได้ ได้แก่ ปลายทางที่เข้ารหัสทั้งสองฝั่ง รวมถึงเวลาและปริมาณข้อมูลที่รับส่งระหว่างกัน คุณสามารถตรวจสอบประเภทการเชื่อมต่อที่คุณใช้งานอยู่ได้ดังนี้:

tailscale status
tailscale netcheck

tailscale status จะระบุสถานะของ peer แต่ละตัวว่าเป็นแบบ direct ซึ่งแสดงผลเป็น direct 203.0.113.10:41641 หรือแบบ relayed ซึ่งแสดงผลเป็น relay ตามด้วยชื่อของ relay และตัวนับจำนวนไบต์ หาก peer ยังคงสถานะเป็น relay แสดงว่าอุปกรณ์ทั้งสองฝั่งไม่สามารถสร้างเส้นทางเชื่อมต่อโดยตรงได้ ซึ่งมักเกิดจากการที่ UDP ถูกบล็อกในบางจุด หรือทั้งสองฝั่งอยู่หลัง NAT (network address translation) ที่เข้มงวด tailscale netcheck จะรายงานว่า UDP สามารถใช้งานได้จากเครื่องนั้นหรือไม่, NAT ของคุณมีการแมปพอร์ตอย่างไร และค่า latency ไปยัง relay ที่ใกล้ที่สุด ซึ่งจะช่วยให้คุณทราบสาเหตุของปัญหา หาก peer เชื่อมต่อแบบ direct อยู่แล้วแต่ความเร็วยังไม่เป็นที่น่าพอใจ แสดงว่าปัญหาไม่ได้เกิดจาก relay และ ปัญหา path MTU ไม่ตรงกันมักเป็นสาเหตุหลักที่ทำให้ WireGuard ทำงานช้า

Exit node เป็นเพียงการย้ายจุดออกสู่เครือข่าย ไม่ใช่การลบจุดออก

Exit node จะทำหน้าที่ส่งผ่านทราฟฟิกอินเทอร์เน็ตสาธารณะทั้งหมดของอุปกรณ์ผ่านอุปกรณ์อีกเครื่องหนึ่งบน tailnet โดยใช้เส้นทางเริ่มต้น 0.0.0.0/0 และ ::/0 สำหรับบน Linux เครื่องที่ให้บริการจะเป็นผู้ประกาศ (advertise) บริการนี้ และไคลเอนต์แต่ละเครื่องจะเป็นผู้เลือกใช้งานเอง:

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 จะต้องได้รับการอนุมัติจาก Owner, Admin หรือ Network admin ใน admin console และนโยบายของคุณจะต้องอนุญาต autogroup:internet ก่อนที่ไคลเอนต์จะใช้งานได้ ทั้งสองขั้นตอนเป็นสิ่งที่ต้องตั้งใจทำ: เครื่องที่ยังไม่ได้รับอนุมัติจะไม่สามารถกลายเป็นทางออกสำหรับทั้ง tailnet ของคุณได้โดยพลการ ประตูการอนุมัติเดียวกันนี้ยังครอบคลุมถึง subnet routes ดังนั้นเครื่องที่ประกาศช่วงเครือข่ายส่วนตัวจะยังคงสถานะไม่ทำงานจนกว่าผู้ดูแลระบบจะยอมรับ ซึ่งเป็นอุปสรรคแรกใน การประกาศเครือข่ายส่วนตัวไปยัง tailnet ของคุณจาก VPS

ทีนี้มาถึงคำถามเรื่องความเชื่อใจ ทราฟฟิกจะถูกเข้ารหัสจากแล็ปท็อปของคุณไปยัง exit node จากนั้นทราฟฟิกจะออกจากเครื่องนั้นในฐานะทราฟฟิกอินเทอร์เน็ตปกติ โดยใช้ที่อยู่ IP ของเครื่องนั้น ดังนั้นผู้ดูแล exit node จะเห็นปลายทางที่คุณเข้าถึง รวมถึงผู้ให้บริการโฮสติ้งของเครื่องนั้นและเครือข่ายต้นทางด้วย คุณเพียงแค่ย้ายจุดที่ถูกเฝ้าสังเกต ไม่ใช่การกำจัดจุดนั้นทิ้ง ซึ่งถือเป็นการแลกเปลี่ยนที่คุ้มค่าเมื่อคุณเป็นผู้ควบคุมปลายทางนั้นเอง ซึ่งเป็นเหตุผลสนับสนุนการ รัน exit node ของคุณเองบน VPS แต่จะเป็นการแลกเปลี่ยนที่ไม่ดีหากคุณไม่ได้เป็นผู้ควบคุมเครื่องนั้น

นโยบายเริ่มต้นคือเครือข่ายแบบแบน (flat network)

Tailnet ใหม่ที่เพิ่งเปิดใช้งานจะมาพร้อมกับการตั้งค่าที่อนุญาตให้เข้าถึงได้กว้าง เอกสารการควบคุมการเข้าถึงของ Tailscale ระบุว่าไฟล์นโยบายเริ่มต้น "เปิดใช้งานการสื่อสารระหว่างอุปกรณ์ทุกเครื่องภายใน tailnet" อุปกรณ์ทุกเครื่องสามารถเข้าถึงอุปกรณ์อื่นได้ทุกเครื่องผ่านทุกพอร์ต นี่คือลักษณะของเครือข่ายแบบแบน คุณได้ย้ายมันเข้ามาไว้ภายใน tunnel แล้ว ซึ่งช่วยป้องกันผู้บุกรุกจากภายนอกได้ แต่ไม่ได้ช่วยป้องกันแล็ปท็อปที่ติดมัลแวร์แต่อย่างใด

คุณควรจำกัดสิทธิ์ในไฟล์นโยบายของ tailnet ซึ่งรองรับรายการควบคุมการเข้าถึง (ACLs) หรือระบบ grants แบบใหม่ ทั้งสองแบบเขียนด้วยภาษา JSON ที่อนุญาตให้ใส่คำอธิบายได้:

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

นโยบายดังกล่าวอนุญาตให้กลุ่มหนึ่งเข้าถึง SSH บนเซิร์ฟเวอร์ที่ใช้งานจริง (production) อนุญาตให้สมาชิกใช้ exit node และปฏิเสธการเข้าถึงอื่นทั้งหมดโดยปริยาย Tailscale มีรายการระบุว่าเป้าหมายของกฎใดบ้างที่สามารถใช้งานได้ในแต่ละแผนบริการ ดังนั้นควรตรวจสอบข้อมูลดังกล่าวก่อนที่คุณจะออกแบบโดยใช้ tags หรือ autogroups และดู สิ่งที่แผนบริการฟรีครอบคลุมจริง สำหรับอุปกรณ์ที่ไม่ควรยอมรับการเชื่อมต่อขาเข้าเลย เช่น โทรศัพท์ส่วนตัว tailscale set --shields-up จะทำหน้าที่บล็อกการเชื่อมต่อเหล่านั้นที่ตัวไคลเอนต์เอง

การเปลี่ยนมา self-host control plane ด้วย Headscale มีผลอย่างไร

Headscale คือ "การนำ control server ของ Tailscale มาทำ self-hosted ในรูปแบบ open source" ไฟล์ README ของโครงการระบุขอบเขตไว้อย่างชัดเจนว่า "รองรับขอบเขตที่จำกัด โดยรองรับ Tailscale network (tailnet) เพียง หนึ่ง เครือข่าย ซึ่งเหมาะสำหรับการใช้งานส่วนตัวหรือองค์กร open source ขนาดเล็ก" รายการฟีเจอร์ครอบคลุมถึง ACL และ grants, subnet routers, exit nodes, DERP server ในตัว, Tailscale SSH และ Taildrop หากข้อจำกัดด้านขอบเขตนี้เป็นประเด็นสำคัญ NetBird เป็นอีกหนึ่ง mesh ที่มี control plane แบบ self-hostable ให้ใช้งาน และการ รัน NetBird server บน VPS ของคุณเอง จะเปลี่ยนการตัดสินใจเรื่องการลงทะเบียนอุปกรณ์มาอยู่บนฮาร์ดแวร์ที่คุณเป็นเจ้าของแทน

สิ่งที่เปลี่ยนไปคือตัวตนของฝ่ายที่สามารถลงทะเบียนโหนดที่ไม่ได้รับอนุญาตได้ เมื่อใช้ Headscale ไดเรกทอรีของคีย์และนโยบายต่างๆ จะอยู่บนเซิร์ฟเวอร์ของคุณเอง ไม่มีบุคคลที่สามถือครองรายการ public key ของอุปกรณ์คุณ และไม่มีบุคคลที่สามรายใดที่สามารถถูกบังคับให้ส่งมอบหรือลงนามในคีย์เหล่านั้นได้

สิ่งที่ยังคงเดิมคือ data plane ซึ่งยังคงเป็น WireGuard ที่มีการเข้ารหัสแบบ end-to-end เหมือนเดิม รวมถึงการใช้ relay fallback ในกรณีที่ไม่สามารถเชื่อมต่อโดยตรงได้ นอกจากนี้ คุณยังต้องรับหน้าที่ที่เดิม Tailscale เคยดูแลให้ ได้แก่ การรักษา uptime, การแพตช์ระบบ, การสำรองข้อมูล และความปลอดภัยทางกายภาพของเครื่อง หากเครื่องนั้นเป็น VPS ที่เช่ามา ความปลอดภัยทางกายภาพจะเป็นเพียงคำสัญญาของผู้อื่น ไม่ใช่สิ่งที่คุณควบคุมได้ เนื่องจาก hypervisor สามารถอ่านหน่วยความจำของ guest และเข้าถึงไดเรกทอรีของคีย์ได้ เว้นแต่ฮาร์ดแวร์จะรองรับ encrypted memory ที่คุณสามารถตรวจสอบได้ หากโฮสต์ที่รัน Headscale ถูกบุกรุก ผู้โจมตีจะได้รับสิทธิ์เช่นเดียวกับที่ได้จากการบุกรุก coordination server ซึ่งก็คืออำนาจในการลงทะเบียนโหนดและแจกจ่ายนโยบาย ฟีเจอร์ Tailnet lock ยังไม่อยู่ในรายการฟีเจอร์ของ Headscale ดังนั้นการควบคุมเพื่อชดเชยความเสี่ยงเฉพาะส่วนนี้จึงยังไม่สามารถทำได้ ในด้านต้นทุนก็เป็นปัจจัยที่ทำให้หลาย tailnet เปลี่ยนมาใช้แนวทางนี้ เนื่องจาก Tailscale คิดค่าบริการรายผู้ใช้ไม่ใช่รายอุปกรณ์ ซึ่งตัวเลขค่าใช้จ่ายจะเปลี่ยนไปทันทีเมื่อทีมขนาดเล็กมีจำนวนสมาชิกเกินกว่าแผนฟรี หากคำถามเรื่องความเป็นเจ้าของคือปัจจัยตัดสินใจของคุณ การ self-host control plane ด้วย Headscale จะอธิบายขั้นตอนการติดตั้งไว้ให้คุณแล้ว

สิ่งที่ Tailscale ป้องกันได้

• พอร์ตที่เปิดรับการเชื่อมต่อจากสาธารณะ บริการที่ผูกอยู่กับที่อยู่ tailnet จะไม่สามารถเข้าถึงได้จากอินเทอร์เน็ต ดังนั้นเครื่องมือสแกนที่พยายามเข้าถึงทุก VPS ผ่านพอร์ต 22 จะไม่พบบริการเหล่านี้ ข้อยกเว้นคือกรณีที่คุณเปิดใช้งานด้วยตนเอง เนื่องจาก Funnel จะเผยแพร่บริการใน tailnet ออกสู่สาธารณะโดยเจตนา ซึ่งเป็นเหตุผลว่าทำไมจึงควรทำความเข้าใจ จุดสิ้นสุดของ serve และจุดเริ่มต้นของ funnel ก่อนที่จะรันคำสั่งใดคำสั่งหนึ่ง อย่างไรก็ตาม ควรเปิดใช้งาน host firewall ไว้เสมอ เพราะพอร์ตของ Docker ที่ถูกเผยแพร่จะเขียนกฎของตัวเองและ ข้ามการทำงานของ ufw บนอินเทอร์เฟซสาธารณะ
• การเดารหัสผ่านกับหน้าล็อกอินที่เปิดเผย จะไม่มีเป้าหมายให้โจมตีด้วยวิธี brute force หากพอร์ตนั้นตอบสนองเฉพาะภายในอุโมงค์เท่านั้น ซึ่งเป็นสถานะที่ปลอดภัยกว่าการจำกัดอัตราการเข้าถึง (rate limiting) บนพอร์ตที่เปิดสาธารณะ แม้ว่า fail2ban บน Ubuntu 24.04 จะยังคงเป็นสิ่งที่ควรติดตั้งไว้บนบริการใดก็ตามที่จำเป็นต้องเปิดใช้งานต่อสาธารณะ
• เครือข่ายที่ไม่น่าเชื่อถือระหว่างทาง การรับส่งข้อมูลระหว่างเครื่องของคุณจะถูกเข้ารหัสแบบ end-to-end แม้จะผ่านเครือข่าย Wi-Fi สาธารณะหรือ LAN ของผู้ให้บริการที่ใช้ร่วมกัน และข้อมูลจะยังคงถูกเข้ารหัสในขณะที่ถูกส่งผ่าน relay
• การจัดการแจกจ่ายคีย์ด้วยตนเอง ทุก peer ที่เพิ่มเข้าไปในไฟล์ config ของ WireGuard ด้วยตนเองมีความเสี่ยงที่จะเกิดการใช้ที่อยู่ซ้ำหรือการวางคีย์ผิดพลาด ระบบ mesh จะจัดการงานเอกสารเหล่านี้ให้คุณ ซึ่งเป็นความแตกต่างในทางปฏิบัติส่วนใหญ่ระหว่าง WireGuard กับ Tailscale

สิ่งที่ Tailscale ไม่สามารถป้องกันได้

• อุปกรณ์ปลายทางที่ถูกบุกรุก tailnet จะเชื่อถืออุปกรณ์ที่ได้รับอนุญาต ดังนั้นมัลแวร์ในแล็ปท็อปที่ผ่านการอนุมัติจะสามารถเข้าถึงอุโมงค์เชื่อมต่อ, หมายเลข IP ใน tailnet และสิทธิ์ทั้งหมดที่นโยบายของคุณมอบให้ผู้ใช้รายนั้น นี่คือช่องโหว่ที่ใหญ่ที่สุดซึ่งไม่มี VPN ใดสามารถปิดกั้นได้
• ผู้ดูแลระบบที่ประสงค์ร้ายหรือประมาทเลินเล่อ ใครก็ตามที่สามารถแก้ไขไฟล์นโยบายได้จะสามารถมอบสิทธิ์การเข้าถึงทุกอย่างให้ตนเอง และใครก็ตามที่สามารถยึดบัญชีผู้ใช้ระดับ Owner ได้ก็จะทำเช่นเดียวกัน คุณควรตรวจสอบการเปลี่ยนแปลงนโยบายในลักษณะเดียวกับที่คุณตรวจสอบโค้ด
• การวิเคราะห์ทราฟฟิก ISP (ผู้ให้บริการอินเทอร์เน็ต) ของคุณจะเห็นข้อมูล UDP ที่เข้ารหัสไหลไปยังปลายทาง รวมถึงเวลาและปริมาณข้อมูล ส่วน flow logs ของ Tailscale จะบันทึกว่าอุปกรณ์ใดสื่อสารกันและเมื่อใด แม้ทั้งสองฝ่ายจะไม่เห็นเนื้อหาภายใน แต่การเชื่อมต่อก็ไม่ได้ถูกซ่อนไว้ ดังนั้นโปรดอ่าน ความแตกต่างระหว่าง Tor และ VPN ก่อนเลือกเครื่องมือสำหรับงานดังกล่าว
• อุปกรณ์ที่คุณทำหายไปแล้ว การหมดอายุของคีย์ (Key expiry) เป็นมาตรการป้องกันขั้นสุดท้ายที่ค่อนข้างช้าโดยมีค่าเริ่มต้นที่ 180 วัน การลบอุปกรณ์ออกจาก admin console เป็นวิธีที่รวดเร็วกว่า ดังนั้นควรทราบตำแหน่งของปุ่มดังกล่าวไว้ก่อนที่จะจำเป็นต้องใช้งานจริง

ตรวจสอบ Tailnet ของคุณเอง

1. รัน tailscale status บนอุปกรณ์เพื่ออ่านรายการ peer อุปกรณ์ที่คุณไม่รู้จักคือสถานการณ์ที่ฟีเจอร์การอนุมัติอุปกรณ์ (device approval) มีไว้เพื่อป้องกัน
2. รัน tailscale lock status เพื่อดูว่า tailnet lock ถูกเปิดใช้งานอยู่หรือไม่ จากนั้นตัดสินใจว่าความยุ่งยากในการลงนามอุปกรณ์ใหม่ทุกครั้งนั้นคุ้มค่าสำหรับ tailnet ของคุณหรือไม่
3. เปิด admin console แล้วจดบันทึกทุกเครื่องที่ปิดการหมดอายุของคีย์ (key expiry) รวมถึง auth key แบบใช้ซ้ำได้ที่ยังคงมีอยู่ ทั้งสองอย่างนี้คือข้อมูลรับรองที่ไม่มีการจำกัดเวลา
4. อ่านไฟล์นโยบาย (policy file) ของคุณ หากยังคงเป็นค่าเริ่มต้น อุปกรณ์ทุกเครื่องจะสามารถเข้าถึงอุปกรณ์อื่นได้ทุกพอร์ต ซึ่งหมายความว่าหากแล็ปท็อปเครื่องหนึ่งติดไวรัส มันจะเข้าถึงอุปกรณ์ทั้งหมดได้

Tailscale สร้างชื่อเสียงจาก data plane ซึ่งการออกแบบไม่เปิดช่องให้ผู้ให้บริการอ่านข้อมูลการรับส่งของคุณได้ ให้ถือว่าคำกล่าวอ้างนั้นเป็นไปตามเอกสารของผู้ผลิต จากนั้นให้ตรวจสอบในส่วนที่เป็นของคุณเอง ได้แก่ บัญชีผู้ใช้งาน, การตั้งค่าการอนุมัติ, รายการการหมดอายุ และไฟล์นโยบาย หน้าความปลอดภัยของ Tailscale ระบุถึงการรับรอง SOC 2 Type II และการทำงานด้านความปลอดภัยอย่างต่อเนื่องร่วมกับ Latacora ซึ่งเป็นหลักฐานเกี่ยวกับกระบวนการของพวกเขา ไม่ใช่การยืนยันเกี่ยวกับการตั้งค่าของคุณเอง

FAQ

Tailscale สามารถอ่านทราฟฟิกของฉันได้หรือไม่?

ไม่ได้ ทราฟฟิกจะถูกเข้ารหัสด้วยคีย์ WireGuard ที่สร้างขึ้นบนอุปกรณ์ของคุณเอง และหน้าความปลอดภัยของ Tailscale ระบุว่า "Private keys จะไม่ถูกส่งออกจากอุปกรณ์ ทราฟฟิกทั้งหมดจะถูกเข้ารหัสแบบ end-to-end เสมอ" สิ่งนี้ยังรวมถึงการเชื่อมต่อที่ต้องอาศัย DERP relay เพราะ relay จะ "ส่งต่อทราฟฟิกที่เข้ารหัสไว้แล้วจากอุปกรณ์หนึ่งไปยังอีกอุปกรณ์หนึ่งโดยไม่ทราบเนื้อหา" และไม่มีคีย์ใดที่สามารถใช้ถอดรหัสได้ สิ่งที่โครงสร้างพื้นฐานของ Tailscale มองเห็นคือข้อมูลเมตา (metadata) เช่น อุปกรณ์ใดบ้างที่มีอยู่ และอุปกรณ์ใดเชื่อมต่อกับอุปกรณ์ใดในเวลาใด

หากเซิร์ฟเวอร์ coordination ของ Tailscale ถูกบุกรุก จะเกิดอะไรขึ้น?

ผู้โจมตีสามารถลงทะเบียนโหนด (node) ใหม่ได้ ประกาศเรื่อง tailnet lock ของ Tailscale อธิบายถึงความเสี่ยงของการเพิ่มโหนดอย่างลับๆ ซึ่งอาจ "ส่งหรือรับทราฟฟิกไปยังโหนดที่มีอยู่ของคุณ" โดยที่การเข้ารหัสไม่สามารถช่วยป้องกันได้ "เพราะตัวโหนดปลายทางนั้นเป็นอันตรายเอง" นอกจากนี้ หาก control plane ถูกบุกรุก ผู้โจมตีอาจแจกจ่ายนโยบายที่เปลี่ยนปลายทางที่อุปกรณ์ของคุณสามารถเข้าถึงได้ และเอกสาร white paper ของ tailnet lock ยังระบุว่าอาจทำให้การเชื่อมต่อใช้งานไม่ได้โดยการไม่แจกจ่ายคีย์โหนดใหม่ สิ่งที่ผู้โจมตีทำไม่ได้คือการถอดรหัสทราฟฟิกระหว่างอุปกรณ์ที่มีอยู่ของคุณ เพราะเซิร์ฟเวอร์ไม่เคยถือครอง private key ของอุปกรณ์เหล่านั้น

Exit node ช่วยซ่อนประวัติการท่องเว็บจาก ISP ของฉันหรือไม่?

มันช่วยซ่อนปลายทางจากเครือข่ายที่คุณใช้งานอยู่ รวมถึง ISP ที่บ้านหรือร้านกาแฟ เพราะทุกอย่างจะออกจากอุปกรณ์ของคุณในรูปแบบทราฟฟิกที่เข้ารหัสซึ่งมุ่งหน้าไปยัง exit node แต่มันไม่ได้ทำให้คุณไม่ระบุตัวตน (anonymous) เพราะ exit node จะเห็นปลายทางเหล่านั้นแทน รวมถึงผู้ให้บริการโฮสติ้งและเครือข่ายต้นทางของ exit node นั้นด้วย ในขณะที่เว็บไซต์ที่คุณเข้าชมจะเห็น IP address ของ exit node คุณเพียงแค่เปลี่ยนผู้สังเกตการณ์ ดังนั้นควรเลือกใช้ exit node ที่คุณไว้วางใจได้จริง

Headscale ปลอดภัยกว่าเซิร์ฟเวอร์ coordination ของ Tailscale หรือไม่?

เป็นการตัดสินใจเรื่องความไว้วางใจที่แตกต่างกัน ไม่ใช่ว่าปลอดภัยกว่าอย่างชัดเจน ในกรณีของ Headscale คุณเป็นผู้ถือครองไดเรกทอรีคีย์และนโยบายเอง ดังนั้นจึงไม่มีบุคคลภายนอกที่สามารถถูกบังคับให้ลงทะเบียนอุปกรณ์ใน tailnet ของคุณได้ แต่คุณต้องรับผิดชอบในการดูแลเซิร์ฟเวอร์นั้นเอง ทั้งการแพตช์, uptime, การสำรองข้อมูล และความปลอดภัยของตัวโฮสต์ หากโฮสต์ที่รัน Headscale ถูกบุกรุก ผู้โจมตีจะมีอำนาจในการลงทะเบียนโหนดเช่นเดียวกับกรณีที่ coordination server ถูกบุกรุก และเนื่องจาก tailnet lock ยังไม่อยู่ในรายการฟีเจอร์ของ Headscale คุณจึงต้องปกป้องโฮสต์นั้นให้ดี

ฉันยังจำเป็นต้องใช้ไฟร์วอลล์บน VPS ที่อยู่ใน tailnet ของฉันหรือไม่?

จำเป็น อินเทอร์เฟซเครือข่ายสาธารณะยังคงมีอยู่ และบริการใดก็ตามที่ผูกไว้กับ 0.0.0.0 จะยังคงเข้าถึงได้จากอินเทอร์เน็ตไม่ว่า Tailscale จะทำงานอยู่หรือไม่ก็ตาม คุณควรผูกบริการไว้กับที่อยู่ของ tailnet, ตั้งค่านโยบาย default deny บนอินเทอร์เฟซสาธารณะ และตรวจสอบพอร์ตของคอนเทนเนอร์ที่เปิดใช้งานอยู่ เพราะ Docker จะแทรกกฎของตนเองและอาจเปิดพอร์ตที่คุณเข้าใจว่าปิดไปแล้วได้