Tailscale คืออะไรและมีหลักการทำงานอย่างไร

Tailscale คืออะไร

Tailscale คือ VPN ที่เชื่อมต่อเครื่องคอมพิวเตอร์ของคุณเข้าหากันโดยตรง แทนที่จะส่งผ่านทราฟฟิกทั้งหมดผ่านเกตเวย์ที่คุณต้องดูแลเอง โหนดทุกโหนดจะรัน WireGuard ดังนั้นแพ็กเก็ตข้อมูลจะถูกเข้ารหัสจากเซิร์ฟเวอร์หนึ่งไปยังอีกเซิร์ฟเวอร์หนึ่ง และไม่มีอุปกรณ์ใดในเส้นทางที่สามารถอ่านข้อมูลเหล่านั้นได้ โดยจะมีเซิร์ฟเวอร์ประสานงาน (coordination server) ที่โฮสต์ไว้ทำหน้าที่เป็นตัวกลางในการแนะนำโหนดต่างๆ ให้รู้จักกัน ซึ่งเซิร์ฟเวอร์นี้จะจัดเก็บและแจกจ่าย public key พร้อมทั้งแจ้งให้แต่ละโหนดทราบว่าโหนดอื่นๆ อยู่ที่ใด รวมถึงส่งกฎการเข้าถึงที่คุณกำหนดไว้ลงไปยังโหนดต่างๆ ด้วย

การแบ่งส่วนการทำงานนี้คือหัวใจสำคัญของการออกแบบทั้งหมด โดย data plane จะทำงานแบบ peer-to-peer และมีการเข้ารหัสระหว่างโหนด ส่วน control plane จะเป็นบริการที่ Tailscale ดูแลให้คุณ คำถามที่น่าสนใจทุกประการเกี่ยวกับ Tailscale รวมถึงประเด็นที่ละเอียดอ่อนเรื่องความน่าเชื่อถือ ล้วนมีที่มาจากข้อเท็จจริงสองประการนี้ หากคุณเคย สร้าง WireGuard VPN ด้วยตนเองบน VPS มาก่อน Tailscale ก็คืออุโมงค์เชื่อมต่อแบบเดียวกันนั้น แต่มีการจัดการเรื่องการแจกจ่ายคีย์และการทะลุผ่านไฟร์วอลล์ให้คุณโดยอัตโนมัติ

Tailscale ทำงานอย่างไร

เครือข่ายส่วนตัวของโหนดต่างๆ ของคุณเรียกว่า tailnet เมื่อเครื่องใดเครื่องหนึ่งเข้าร่วมเครือข่าย จะมีกระบวนการ 4 อย่างเกิดขึ้นดังนี้

1. daemon ของ tailscaled จะเริ่มทำงาน สร้างคู่กุญแจ WireGuard และเก็บสถานะไว้ใน /var/lib/tailscale/tailscaled.state กุญแจส่วนตัว (private key) จะอยู่บนเครื่องนั้นเสมอ Tailscale ระบุไว้อย่างชัดเจนว่า "กุญแจส่วนตัวจะไม่ถูกส่งออกจากโหนดของมันโดยเด็ดขาด"
2. โหนดจะล็อกอินเข้าสู่ coordination server และอัปโหลดกุญแจสาธารณะ (public key) รวมถึงที่อยู่ที่โหนดเชื่อว่าสามารถติดต่อได้ Tailscale อธิบายเซิร์ฟเวอร์นั้นว่าเป็น "กล่องรับฝากกุญแจสาธารณะที่ใช้ร่วมกัน"
3. coordination server จะส่งแผนผังเครือข่ายกลับมาให้ ซึ่งประกอบด้วยกุญแจสาธารณะ, ที่อยู่ tailnet, ชื่อเครื่อง และจุดเชื่อมต่อที่เป็นไปได้ของทุกโหนดที่เครื่องนี้ได้รับอนุญาตให้ติดต่อ
4. จากนั้นโหนดแต่ละคู่จะพยายามสร้างอุโมงค์ WireGuard เชื่อมต่อกันโดยตรง หากไม่สำเร็จ พวกมันจะส่งแพ็กเก็ตผ่าน relay แทน

โหนดแต่ละโหนดจะได้รับที่อยู่ที่เสถียรจากช่วง 100.64.0.0/10 ซึ่งเป็นช่วง carrier-grade NAT ที่ครอบคลุมตั้งแต่ 100.64.0.0 ถึง 100.127.255.255 Tailscale ใช้ช่วงนี้เพราะถูกสงวนไว้สำหรับโครงสร้างพื้นฐานของผู้ให้บริการ จึงแทบจะไม่เกิดการซ้ำซ้อนกับที่อยู่ส่วนตัวที่เซิร์ฟเวอร์ของคุณใช้งานอยู่แล้ว บน Linux อุโมงค์นี้จะปรากฏเป็นอินเทอร์เฟซชื่อ tailscale0

การทำงานของ WireGuard จะอยู่ใน tailscaled ในระดับ userspace ไม่ใช่ kernel module นี่คือเหตุผลที่ Tailscale เริ่มทำงานบน container virtualisation ได้ในขณะที่ sudo modprobe wireguard ล้มเหลวด้วย Operation not supported นอกจากนี้ยังหมายความว่าขีดจำกัดของ throughput บนเครื่องนั้นๆ จะต่ำกว่าการใช้ kernel WireGuard ซึ่งเป็นหนึ่งในข้อแลกเปลี่ยนที่ Tailscale เปรียบเทียบกับ WireGuard แบบปกติ ได้อธิบายไว้

มีคำสั่ง 2 คำสั่งที่บอกสถานะการเชื่อมต่อของคุณ

tailscale ip -4
tailscale status

tailscale status จะแสดงผลลัพธ์บรรทัดละหนึ่งโหนด โดยคอลัมน์สุดท้ายคือส่วนที่สำคัญที่สุด

100.101.102.103  web-1      you@  linux  -
100.101.102.104  db-1       you@  linux  active; direct 198.51.100.24:41641
100.101.102.105  ci-runner  you@  linux  active; relay "fra"

direct ตามด้วยที่อยู่และพอร์ต หมายความว่าเครื่องทั้งสองพบเส้นทางถึงกันและรับส่งข้อมูลแบบ peer to peer ส่วน relay "fra" หมายความว่าข้อมูลกำลังผ่าน Tailscale relay ใน Frankfurt และ - หมายความว่าขณะนี้ไม่มีเซสชันที่ใช้งานอยู่กับโหนดนั้น ซึ่งเป็นเรื่องปกติ

สิ่งที่ coordination server สามารถมองเห็นและไม่สามารถมองเห็นได้

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

เซิร์ฟเวอร์ไม่มี private key จึงไม่สามารถถอดรหัสข้อมูลที่รับส่งระหว่างโหนดสองโหนดได้ การเข้ารหัสจะเป็นแบบ end-to-end ระหว่าง WireGuard peer และ coordination server ไม่ได้เป็นส่วนหนึ่งของ peer เหล่านั้น

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

วิธีที่เซิร์ฟเวอร์สองเครื่องซึ่งอยู่หลังไฟร์วอลล์ต่างกันจะสื่อสารกันโดยตรง

NAT (network address translation) คือสิ่งที่ทำให้เครื่องคอมพิวเตอร์จำนวนมากสามารถใช้ที่อยู่สาธารณะร่วมกันได้ โดยปกติแล้ว VPS ของคุณจะมีที่อยู่สาธารณะเป็นของตัวเอง แต่เครื่องอื่นๆ ที่คุณต้องการให้เข้ามาอยู่ใน tailnet มักจะไม่มี เช่น เซิร์ฟเวอร์ที่บ้าน, build runner ในเครือข่ายสำนักงาน หรือเครื่องที่อยู่หลังไฟร์วอลล์ของผู้ให้บริการที่คุณไม่สามารถแก้ไขได้

Tailscale จะค้นหาเส้นทางโดยใช้เทคนิคที่สร้างขึ้นบนมาตรฐาน STUN (session traversal utilities for NAT) และ ICE โดยแต่ละโหนดจะส่งแพ็กเก็ต UDP ขนาดเล็กไปยังเซิร์ฟเวอร์ STUN เพื่อเรียนรู้ที่อยู่สาธารณะและพอร์ตที่เร้าเตอร์ของมันกำหนดให้กับซ็อกเก็ตนั้น ทั้งสองโหนดจะรายงาน candidate เหล่านั้นไปยังเซิร์ฟเวอร์ประสานงาน (coordination server) ซึ่งจะส่งข้อมูลต่อไปยังอีกฝั่ง จากนั้นทั้งสองโหนดจะเริ่มส่งแพ็กเก็ตหากันในเวลาเดียวกัน เร้าเตอร์ของแต่ละฝั่งจะเห็นแพ็กเก็ตขาออกก่อน จึงสร้างการจับคู่ (mapping) และยอมรับการตอบกลับที่มาจากที่อยู่เดียวกันนั้น ทำให้ไม่มีฝั่งใดจำเป็นต้องตั้งค่ากฎไฟร์วอลล์ขาเข้าเลย

พอร์ตที่ใช้มีความเฉพาะเจาะจง อุโมงค์ WireGuard แบบตรงจะใช้ UDP โดยมีพอร์ตต้นทางเป็น 41641 ตามค่าเริ่มต้น ส่วน STUN จะทำงานผ่าน UDP 3478 ไปยังเซิร์ฟเวอร์ relay ของ Tailscale สำหรับการเชื่อมต่อควบคุมและข้อมูลที่ถูกส่งผ่าน relay จะใช้ HTTPS บน TCP 443 โดยส่วนใหญ่แล้วคุณไม่จำเป็นต้องเปิดพอร์ตขาเข้าใดๆ แต่ในเครือข่ายที่มี NAT ที่ซับซ้อน การอนุญาตให้ UDP 41641 เข้ามาได้จะช่วยให้การเชื่อมต่อโดยตรงมีโอกาสสำเร็จมากขึ้น

tailscale netcheck

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

เมื่อ Tailscale ใช้ DERP relay แทน

DERP (designated encrypted relay for packets) เป็นกลไกสำรอง Tailscale มี relay ให้บริการในหลายภูมิภาคซึ่งเข้าถึงได้ผ่าน TCP 443 หากโหนดไม่สามารถสร้างเส้นทางเชื่อมต่อโดยตรงได้ โหนดนั้นจะส่งแพ็กเก็ต WireGuard ผ่าน relay เหล่านี้แทน

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

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

tailscale ping db-1

การตอบกลับชุดแรกจะแสดงผล via DERP(fra) จากนั้นบรรทัดถัดมาจะรายงานผลในลักษณะ via 198.51.100.24:41641 การเปลี่ยนแปลงนี้คือการอัปเกรดไปสู่การเชื่อมต่อแบบ direct tunnel หากสถานะไม่เปลี่ยนแปลง ให้รันคำสั่ง tailscale netcheck ที่โหนดทั้งสองฝั่ง เส้นทางที่ผ่าน relay ยังคงใช้งานได้ตามปกติ แต่จะมีค่า latency เพิ่มขึ้นเนื่องจากทุกแพ็กเก็ตต้องอ้อมผ่านเครื่องที่สาม

การเชื่อมต่อ VPS เข้ากับ tailnet ของคุณ

สคริปต์ติดตั้งรองรับ Ubuntu และ Debian

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

sudo tailscale up จะแสดง URL ขึ้นมา ให้เปิด URL นั้นแล้วยืนยันตัวตน จากนั้นโหนดจะปรากฏใน admin console ของคุณ จากนั้นให้ตรวจสอบว่า daemon กลับมาทำงานใหม่หลังจากรีบูตเครื่องหรือไม่ เพราะนี่คือขั้นตอนที่ผู้ใช้มักจะข้ามไป

sudo systemctl is-enabled tailscaled
tailscale status

is-enabled ควรแสดงผลเป็น enabled และ tailscale status ควรแสดงรายการโหนดใหม่พร้อมที่อยู่ 100.x สำหรับเซิร์ฟเวอร์ที่สร้างจากสคริปต์ การใช้ URL แบบโต้ตอบนั้นไม่สะดวก ให้สร้าง auth key ใน admin console แล้วส่งค่าดังกล่าวพร้อมกับ tag ที่ระบุประเภทของเครื่องนี้

sudo tailscale up --auth-key=tskey-auth-REPLACE-ME --advertise-tags=tag:server

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

มีการตั้งค่าสองอย่างที่สำคัญสำหรับการจัดการเครื่องจำนวนมาก โดยปกติแล้ว node key จะหมดอายุหลังจาก 180 วัน (ข้อมูล ณ เดือนสิงหาคม 2026) และเมื่อ key หมดอายุ "การเชื่อมต่อจาก/ไปยัง endpoint นั้นจะหยุดทำงาน" จนกว่าจะมีคนล็อกอินใหม่อีกครั้ง ดังนั้นให้เปิดแถวของเครื่องใน admin console แล้วเลือก Disable Key Expiry สำหรับเซิร์ฟเวอร์ที่ไม่มีผู้ดูแล ส่วน MagicDNS ซึ่งเปิดใช้งานเป็นค่าเริ่มต้นสำหรับ tailnet ที่สร้างขึ้นในหรือหลังวันที่ 20 ตุลาคม 2022 จะกำหนดชื่อให้กับแต่ละโหนด เช่น db-1.yak-bebop.ts.net ซึ่งจะถูก resolve โดย stub resolver ที่ 100.100.100.100 ให้ใช้ชื่อแทนการใช้ที่อยู่ IP เพราะเมื่อสร้างโหนดใหม่ โหนดนั้นจะได้ที่อยู่ IP ใหม่แต่ยังคงใช้ชื่อเดิมได้

หากการติดตั้งล้มเหลวที่ apt หรือที่ repository คุณสามารถดูวิธีแก้ไขได้ที่ ข้อผิดพลาดทั่วไปในการติดตั้ง Tailscale บน Ubuntu

การเข้าถึงบริการที่ผูกไว้กับ localhost

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

ss -tlnp | grep 3000

หากคำสั่งดังกล่าวแสดงผลเป็น 127.0.0.1:3000 หมายความว่า socket ยอมรับเฉพาะแพ็กเกจที่มีปลายทางเป็น 127.0.0.1 เท่านั้น คำขอจากโหนดอื่นที่ส่งเข้ามายังที่อยู่ 100.x ของโหนดนี้จะถูก kernel ปฏิเสธเนื่องจากไม่มีบริการใดรอรับการเชื่อมต่ออยู่ และ kernel จะตอบกลับด้วย TCP reset ส่งผลให้ฝั่งไคลเอนต์รายงานข้อผิดพลาด Connection refused ในกรณีนี้ tunnel ทำงานได้ปกติ แต่ปัญหาอยู่ที่ตัว listener

แนวทางการแก้ไขที่ถูกต้องมีสองวิธี วิธีแรกคือการผูกบริการเข้ากับที่อยู่ tailnet ของโหนดโดยตรง ซึ่งจะช่วยให้บริการไม่ถูกเปิดเผยบน public interface และไม่มี proxy มาคั่นกลาง โดยให้ระบุ --bind 100.101.102.104 หรือตัวเลือกที่เทียบเท่ากันในไฟล์ config ของคุณ สำหรับ container ให้ publish พอร์ตเป็น -p 100.101.102.104:3000:3000 วิธีที่สองคือปล่อยให้บริการทำงานบน loopback ตามเดิมแล้วใช้ Tailscale วางไว้ด้านหน้า

tailscale serve 3000

วิธีนี้จะทำหน้าที่ proxy คำขอไปยัง http://127.0.0.1:3000 และให้บริการภายใน tailnet ของคุณผ่านชื่อ ts.net ด้วยโปรโตคอล HTTPS เมื่อมีการเปิดใช้งานใบรับรอง HTTPS สำหรับ tailnet แล้ว บริการจะยังคงเป็นส่วนตัวสำหรับโหนดของคุณเท่านั้น สำหรับแนวคิดเดียวกันในเวอร์ชันสาธารณะคือ Funnel ซึ่งคุณสามารถอ่านรายละเอียดว่าแบบใดที่เหมาะสมกับความต้องการของคุณได้ที่ Tailscale serve กับ funnel

งานที่เกี่ยวข้องอีกสองประเภทมีหน้าเอกสารแยกต่างหาก สำหรับการเข้าถึงเครือข่ายส่วนตัวทั้งหมดที่ไม่ได้ติดตั้ง Tailscale ไว้ จำเป็นต้องใช้ subnet router บน VPS และสำหรับการส่ง traffic อินเทอร์เน็ตขาออกของโหนดผ่านโหนดอื่น จำเป็นต้องใช้ exit node

การปิดพอร์ตที่ไม่จำเป็นอีกต่อไป

เมื่อผู้ดูแลระบบสามารถเข้าถึงเซิร์ฟเวอร์ผ่าน tailnet ได้แล้ว พอร์ต 22 แบบสาธารณะก็ไม่มีความจำเป็นอีกต่อไป นี่คือผลลัพธ์ที่สำคัญในทางปฏิบัติ พอร์ตที่ปิดอยู่จะไม่สามารถถูกโจมตีแบบ brute force ได้ และ log ของคุณจะไม่เต็มไปด้วยความพยายามในการเข้าถึงที่ไม่พึงประสงค์อีกต่อไป

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

sudo ufw allow in on tailscale0
sudo ufw status verbose

หลังจากนั้น ให้ลบกฎ SSH แบบสาธารณะออกและเชื่อมต่อใหม่โดยใช้ชื่อ MagicDNS โปรดสังเกตว่า ufw allow in on tailscale0 ทำงานอย่างไรในความเป็นจริง มันจะเชื่อถือทุกสิ่งที่ส่งผ่าน tunnel ดังนั้นไฟล์นโยบายของ Tailscale จึงกลายเป็นตัวควบคุมการเข้าถึงแทนที่ ufw คุณควรเขียนนโยบายโดยคำนึงถึงเรื่องนี้

คำเตือนสำหรับผู้ที่รันคอนเทนเนอร์ พอร์ตของ Docker ที่ถูกเผยแพร่ (published port) จะติดตั้งกฎ NAT ของตัวเองและข้ามการทำงานของ ufw ดังนั้นการใช้ ufw deny จึงไม่สามารถปิดพอร์ตเหล่านั้นได้ พอร์ตของ Docker ที่เผยแพร่จะข้ามการทำงานของ ufw อธิบายกลไกดังกล่าวไว้ การเผยแพร่พอร์ตไปยังที่อยู่ของ tailnet ตามที่ระบุไว้ข้างต้นจะช่วยหลีกเลี่ยงปัญหานี้ได้

สิ่งที่ Tailscale ป้องกันและสิ่งที่ไม่ป้องกัน

ควรระบุให้ชัดเจน เนื่องจากคำโฆษณามักทำให้ประเด็นนี้คลุมเครือ

สิ่งที่ได้รับการป้องกัน: การรับส่งข้อมูลระหว่างสองโหนดจะถูกเข้ารหัสแบบ end-to-end ด้วย WireGuard และไม่มี relay ใดที่อยู่ตรงกลางสามารถอ่านข้อมูลได้ private key จะไม่ถูกส่งออกจากเครื่องที่สร้างมันขึ้นมา โหนดไม่จำเป็นต้องเปิดพอร์ตขาเข้าสู่สาธารณะ ดังนั้นจึงไม่มีพอร์ตอย่าง 22 หรือ 5432 ให้ Internet สแกนพบ การเข้าถึงระหว่างโหนดถูกกำหนดโดยไฟล์นโยบาย (policy file) แทนที่จะขึ้นอยู่กับว่าใครทราบที่อยู่ของโหนดนั้น

สิ่งที่ไม่ได้ป้องกัน: coordination server จะเห็นแผนผังอุปกรณ์ (device graph) ของคุณ ข้อมูล metadata เหล่านี้มีความละเอียดอ่อนในตัวมันเอง เนื่องจากชื่อเครื่อง, เจ้าของ, ที่อยู่ และเวลาที่ออนไลน์สามารถบ่งบอกถึงโครงสร้างพื้นฐานของคุณได้ นอกจากนี้ server ยังทำหน้าที่แจกจ่ายกุญแจซึ่งเป็นความเสี่ยงที่สำคัญกว่า Tailscale ระบุไว้โดยตรงว่า "หาก Tailscale มีเจตนาร้ายและแอบเพิ่มโหนดใหม่เข้าไปในเครือข่ายของคุณ Tailscale จะสามารถส่งหรือรับข้อมูลไปยังโหนดที่มีอยู่ของคุณในรูปแบบ plaintext ได้" ผู้ให้บริการ single sign-on ของคุณก็อยู่ในเส้นทางความเชื่อถือเดียวกัน เพราะใครก็ตามที่สามารถสร้างตัวตนในระบบนั้นได้ ก็สามารถเพิ่มโหนดใหม่ได้เช่นกัน และหากโหนดใดถูกบุกรุก (compromised) โหนดนั้นก็จะเป็น peer ภายใน tailnet ซึ่งจะสามารถเข้าถึงสิ่งใดก็ตามที่นโยบายของคุณอนุญาต ความเสี่ยงนี้จะยอมรับได้หรือไม่นั้นขึ้นอยู่กับว่าคุณกำลังป้องกันจากใคร และ รูปแบบความเชื่อถือฉบับเต็ม จะอธิบายแต่ละกรณีไว้ รวมถึงสิ่งที่บัญชีตัวตนที่ถูกขโมยไปสามารถทำได้จริง

มีคำตอบสองประการสำหรับความเสี่ยงในการแจกจ่ายกุญแจ ประการแรกคือ tailnet lock ซึ่งกำหนดให้โหนดที่เชื่อถือได้ที่มีอยู่ต้องลงนามทาง cryptographic ให้กับโหนดใหม่ก่อนที่โหนดอื่นของคุณจะยอมรับมัน control plane ใดที่เพิ่มโหนดโดยไม่มีลายเซ็นที่ถูกต้องจะถูกเพิกเฉย admin console จะสร้างบรรทัด tailscale lock init ที่ถูกต้องสำหรับโหนดที่ทำหน้าที่ลงนามของคุณ และทุกโหนดสามารถตรวจสอบสิ่งที่มันเห็นได้

tailscale lock status

โหนดทั้งหมดควรรายงานชุดกุญแจลงนามที่เชื่อถือได้ชุดเดียวกัน คำตอบประการที่สองคือการรัน control plane ด้วยตนเอง Headscale coordination server ที่โฮสต์เอง ใช้โปรโตคอลเดียวกันกับ client ชุดเดียวกัน ซึ่งจะย้ายแผนผังอุปกรณ์และการแจกจ่ายกุญแจมาไว้บนฮาร์ดแวร์ที่คุณเป็นเจ้าของเอง คุณจะต้องรับผิดชอบเรื่อง uptime ของ server นั้นด้วย หากคุณยังคงเปรียบเทียบ control plane ที่โฮสต์เองอยู่แทนที่จะตัดสินใจเลือกตัวนี้ NetBird เป็น mesh VPN อีกตัวหนึ่งที่คุณสามารถรัน server ได้เองทั้งหมดบน VPS เครื่องเดียว

ค่าเริ่มต้นหนึ่งอย่างที่ควรแก้ไขตั้งแต่วันแรก: tailnet ใหม่ที่เพิ่งสร้างจะถูกตั้งค่าแบบอนุญาตไว้ก่อน (permissive): "นโยบายเริ่มต้นของ tailnet จะอนุญาตให้ทุกอุปกรณ์ภายใน tailnet สื่อสารกันได้" ทันทีที่คุณเพิ่มส่วน acls เข้าไป รูปแบบความปลอดภัยจะเปลี่ยนเป็นปฏิเสธโดยค่าเริ่มต้น (deny by default) และจะมีเพียงกฎที่คุณกำหนดเท่านั้นที่ผ่านได้

{
  "tagOwners": {
    "tag:server": ["autogroup:admin"]
  },
  "acls": [
    {"action": "accept", "src": ["autogroup:member"], "dst": ["tag:server:22"]}
  ]
}

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

รูปแบบความล้มเหลวและข้อความที่คุณจะพบ

tailscale status แจ้งว่า relay เสมอ โหนดทั้งสองไม่สามารถสร้างเส้นทางเชื่อมต่อโดยตรงได้ ให้รันคำสั่ง tailscale netcheck ที่ทั้งสองฝั่ง หากพบ UDP: false แสดงว่า UDP ถูกบล็อกขาออก ทำให้ใช้งานได้ผ่าน relay เท่านั้น หากพบ MappingVariesByDestIP: true แสดงว่ามี hard NAT ขวางอยู่ การอนุญาตให้ UDP พอร์ต 41641 ขาเข้าในฝั่งที่คุณควบคุมมักจะช่วยแก้ไขปัญหานี้ได้

โหนดที่เคยใช้งานได้ปกติหลายเดือนหายไป node key ของโหนดนั้นหมดอายุตามค่าเริ่มต้นที่ 180 วัน เครื่องจะแสดงสถานะว่าหมดอายุใน admin console และการรัน sudo tailscale up บนเครื่องนั้นจะทำให้กลับมาใช้งานได้อีกครั้ง ควรปิดการตั้งค่า key expiry บนเซิร์ฟเวอร์เพื่อป้องกันไม่ให้เกิดเหตุการณ์นี้ซ้ำ

รายชื่อ peer ปรากฏขึ้นแต่การเชื่อมต่อหมดเวลา (timeout) การเชื่อมต่อเครือข่ายทำงานปกติแต่ policy ปฏิเสธทราฟฟิกดังกล่าว ให้ตรวจสอบส่วน acls เพื่อหาว่ามีกฎที่ครอบคลุม source, destination และ port นี้หรือไม่ แพ็กเก็ตที่ถูกปฏิเสธจะถูกทิ้ง (drop) แทนที่จะได้รับคำตอบกลับ จึงเป็นสาเหตุว่าทำไมคุณถึงได้รับข้อผิดพลาด timeout แทนที่จะเป็น Connection refused

ชื่อ MagicDNS ไม่สามารถ resolve ได้ ping db-1 ล้มเหลวในขณะที่ ping 100.101.102.104 ทำงานได้ปกติ มีบางอย่างเข้ามาแทนที่ /etc/resolv.conf ทำให้การสอบถามข้อมูลไม่เคยไปถึง stub resolver ที่ 100.100.100.100 ให้ตรวจสอบ cat /etc/resolv.conf เพื่อหา 100.100.100.100 และตรวจสอบว่ามีโปรเซสอื่นใดบนเครื่องที่เขียนทับไฟล์นั้นอยู่หรือไม่ ปัญหานี้เป็นประเภทเดียวกับ DNS ขัดข้องภายในอุโมงค์ WireGuard

tailscale up ปฏิเสธ tag ของคุณ tag ดังกล่าวยังไม่ได้ถูกประกาศไว้ภายใต้ tagOwners ในไฟล์ policy ให้เพิ่ม tag นั้นเข้าไปแล้วรันคำสั่งอีกครั้ง

FAQ

Tailscale เป็น VPN หรือ mesh network?

ทั้งสองคำมีความถูกต้องและอธิบายคนละเลเยอร์กัน อุโมงค์เชื่อมต่อใช้โปรโตคอล WireGuard ซึ่งทำให้มันเป็น VPN ส่วนโทโพโลยีเป็นแบบ mesh เพราะแต่ละโหนดจะสร้างอุโมงค์เชื่อมต่อโดยตรงไปยังโหนดอื่นที่สื่อสารด้วย แทนที่จะส่งแพ็กเก็ตทั้งหมดผ่านเซิร์ฟเวอร์กลางเพียงจุดเดียว เซิร์ฟเวอร์ประสานงาน (coordination server) จะอยู่ในเส้นทางการควบคุม (control path) ไม่ใช่เส้นทางข้อมูล (data path) ดังนั้นหากเซิร์ฟเวอร์ดังกล่าวไม่สามารถเข้าถึงได้ อุโมงค์ที่มีอยู่เดิมจะยังคงรับส่งข้อมูลได้ตามปกติ สิ่งที่จะหยุดทำงานระหว่างที่ระบบขัดข้องคือการเพิ่มโหนดใหม่ และการปรับปรุงคีย์หรือนโยบายใหม่

Tailscale สามารถอ่านข้อมูลการรับส่งข้อมูลของฉันได้หรือไม่?

ไม่สามารถอ่านเนื้อหาได้ ข้อมูลจะถูกเข้ารหัสแบบ end-to-end ระหว่างโหนดด้วย WireGuard โดย private key จะไม่ถูกส่งออกจากโหนด และ DERP relay จะทำหน้าที่ส่งต่อแพ็กเก็ตโดยไม่มีวิธีถอดรหัสข้อมูลเหล่านั้น อย่างไรก็ตาม Tailscale จะเห็นข้อมูลเมตา (metadata) เช่น ชื่อเครื่อง, เจ้าของ, public key, ที่อยู่ปลายทาง และสถานะออนไลน์ของแต่ละโหนด นอกจากนี้ยังทำหน้าที่แจกจ่ายคีย์ ดังนั้นหากเซิร์ฟเวอร์ประสานงานถูกบุกรุก ผู้โจมตีอาจพยายามแทรกโหนดที่เครือข่ายของคุณจะเชื่อถือได้ ฟีเจอร์ tailnet lock จะป้องกันปัญหานี้โดยกำหนดให้ต้องมีการลงนามจากโหนดที่คุณเชื่อถือเอง และการใช้ Headscale จะช่วยตัดปัญหาเรื่องการพึ่งพา control plane ของผู้ให้บริการภายนอกออกไป

ฉันจำเป็นต้องเปิดพอร์ตไฟร์วอลล์สำหรับ Tailscale หรือไม่?

แทบไม่จำเป็นต้องเปิดพอร์ตขาเข้าเลย คำแนะนำของ Tailscale ระบุว่า "โดยส่วนใหญ่แล้ว คุณไม่จำเป็นต้องเปิดพอร์ตไฟร์วอลล์ใดๆ" สำหรับขาออก โหนดจำเป็นต้องใช้ TCP 443 เพื่อเชื่อมต่อไปยังเซิร์ฟเวอร์ประสานงานและ relay รวมถึง UDP 3478 สำหรับ STUN อุโมงค์เชื่อมต่อโดยตรงจะใช้ UDP โดยมีพอร์ตต้นทางเริ่มต้นที่ 41641 การอนุญาตให้ UDP 41641 ขาเข้าเป็นทางเลือกเสริม ซึ่งจะช่วยให้การเชื่อมต่อโดยตรงสำเร็จได้ง่ายขึ้นบนเครือข่ายที่มีข้อจำกัด

ทำไมโหนดอื่นถึงไม่สามารถเข้าถึงบริการของฉันที่พอร์ต 3000 ได้?

ให้ตรวจสอบ bind address ก่อนด้วย ss -tlnp หาก listener ทำงานอยู่ที่ 127.0.0.1:3000 ระบบจะปฏิเสธการเชื่อมต่อที่ส่งมายังที่อยู่ 100.x ของ tailnet เนื่องจาก socket นั้นยอมรับเฉพาะการเชื่อมต่อที่ส่งไปยัง loopback เท่านั้น และไคลเอนต์จะได้รับข้อความ Connection refused ให้ตั้งค่าบริการให้ bind กับที่อยู่ของ tailnet หรือใช้ tailscale serve 3000 เพื่อทำ proxy หาก listener ทำงานที่ 0.0.0.0 อยู่แล้วแต่การเชื่อมต่อหมดเวลา (timeout) แทนที่จะถูกปฏิเสธ สาเหตุอาจมาจากกฎนโยบายหรือไฟร์วอลล์ของโฮสต์ ไม่ใช่ที่ bind address

ฉันควรใช้ Headscale แทนเซิร์ฟเวอร์ประสานงานของ Tailscale หรือไม่?

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