เปรียบเทียบ WireGuard vs Tailscale vs Headscale

WireGuard กับ Tailscale: คำตอบโดยสรุป

การเลือกระหว่าง WireGuard กับ Tailscale ไม่ใช่การเลือกโปรโตคอลสองชนิด เพราะ Tailscale คือ WireGuard โดย Tailscale ใช้การเข้ารหัสและอุโมงค์เชื่อมต่อแบบเดียวกัน แต่เพิ่มส่วนควบคุม (control plane) เข้ามา ได้แก่ เซิร์ฟเวอร์ประสานงานที่ทำหน้าที่แลกเปลี่ยน public key, แจกจ่ายที่อยู่ IP, เจาะทะลุ NAT (network address translation) และบังคับใช้นโยบายการเข้าถึง ดังนั้น คุณกำลังเลือกว่าต้องการจัดการส่วนการประสานงานเหล่านี้ด้วยตนเองมากน้อยเพียงใด

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

สิ่งที่ control plane มอบให้คุณอย่างแท้จริง

WireGuard แบบปกติไม่มีระบบค้นหา peer โดยอัตโนมัติ ทุก peer คือข้อความที่คุณต้องเขียนขึ้นเองด้วยมือ ประกอบด้วย public key, บรรทัด AllowedIPs และ Endpoint หาก peer นั้นสามารถเข้าถึงได้ การเพิ่มเครื่องหนึ่งเครื่องเข้าไปในเครือข่ายที่มีอยู่สิบเครื่อง หมายถึงการต้องแก้ไขไฟล์ config ถึงสิบไฟล์ เพราะแต่ละฝั่งจำเป็นต้องมี key ของอีกฝั่ง นี่คือเหตุผลที่การตั้งค่า WireGuard แบบ self-hosted เกือบทั้งหมดเป็นรูปแบบ hub and spoke คือมีเซิร์ฟเวอร์หนึ่งเครื่องที่มี public IP และมี client ที่ติดต่อได้เฉพาะเซิร์ฟเวอร์นั้นเท่านั้น

Control plane ช่วยลดภาระการแก้ไขไฟล์เหล่านี้ แต่ละ node จะลงทะเบียนเพียงครั้งเดียว ได้รับที่อยู่จากช่วง 100.64.0.0/10 CGNAT (carrier grade NAT) และได้รับข้อมูล public key ของ node อื่นๆ ที่ได้รับอนุญาตให้ติดต่อได้ การเชื่อมต่ออุโมงค์ข้อมูลยังคงเป็น WireGuard โดยตรงระหว่าง peer สองฝั่ง และ traffic ของคุณจะไม่ผ่านเซิร์ฟเวอร์ประสานงาน สิ่งที่เซิร์ฟเวอร์จัดการคือ metadata ได้แก่ ใครมีตัวตนอยู่บ้าง, key ของแต่ละคนคืออะไร และใครได้รับอนุญาตให้คุยกับใคร

ผลลัพธ์ที่เป็นรูปธรรมสามประการจากระบบนี้มีดังนี้

NAT traversal. แล็ปท็อปสองเครื่องที่อยู่หลัง home router สองตัวต่างไม่มี public IP เป็นของตัวเอง Tailscale ใช้ STUN (session traversal utilities for NAT) เพื่อค้นหาที่อยู่และพอร์ตภายนอกของแต่ละฝั่ง จากนั้นทั้งสองฝั่งจะส่งแพ็กเก็ตออกไปพร้อมกันเพื่อให้ router ของแต่ละฝั่งมองเห็นการไหลของข้อมูลขาออกก่อนและยอมรับการตอบกลับ เมื่อวิธีนี้ล้มเหลว traffic จะเปลี่ยนไปใช้ DERP relay ซึ่งเป็น relay ที่เข้ารหัสซึ่งดำเนินการโดย Tailscale ข้อมูลของคุณจะยังคงถูกเข้ารหัสแบบ end-to-end ผ่าน relay เพราะ relay ไม่เคยถือครองกุญแจถอดรหัส เมื่อรัน tailscale status บรรทัดของแต่ละ peer จะแสดง direct หรือ relay และเมื่อรัน tailscale netcheck คุณจะเห็นว่า relay ใดอยู่ใกล้ที่สุดและเครือข่ายของคุณอนุญาตให้ใช้ UDP ได้หรือไม่

การหมุนเวียนกุญแจพร้อมวันหมดอายุ. กุญแจของ WireGuard ไม่มีวันหมดอายุ กุญแจที่คุณออกให้เมื่อสามปีก่อนจะใช้งานได้ตลอดไปจนกว่าคุณจะลบ peer block นั้นออกด้วยมือ Tailscale จึงเปลี่ยนมาใช้วันหมดอายุสำหรับ node key แทน โดย ณ เดือนตุลาคม 2026 ระยะเวลาหมดอายุเริ่มต้นบน tailnet ใหม่คือ 180 วัน เครื่องที่ไม่ได้ยืนยันตัวตนใหม่จะหยุดการเชื่อมต่อ คุณสามารถปิดการหมดอายุแยกรายอุปกรณ์สำหรับเซิร์ฟเวอร์หรือ subnet router ที่ไม่มีใครคอยล็อกอินเข้าใช้งานได้

นโยบายแทนการกำหนดเส้นทาง. ใน WireGuard ปกติ AllowedIPs ทำหน้าที่เป็นทั้งตาราง routing และรายการควบคุมการเข้าถึง (access control list) ในเวลาเดียวกัน ดังนั้นการกำหนดว่า "alice สามารถเข้าถึงฐานข้อมูลได้" จึงต้องระบุเป็นช่วง IP Tailscale แยกไฟล์นโยบายออกมาต่างหาก โดยกฎจะอ้างอิงถึงผู้ใช้ กลุ่ม และแท็ก กฎสามารถกำหนดได้ว่า tag:laptop สามารถเข้าถึง tag:db ได้ที่พอร์ต 5432 และห้ามเข้าถึงส่วนอื่น และกฎนั้นจะยังคงมีผลแม้เครื่องปลายทางจะได้รับที่อยู่ใหม่ก็ตาม

ต้นทุนของการใช้ control plane

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

ยังมีต้นทุนอีกประการหนึ่งที่มักถูกมองข้าม Tailscale เป็น daemon ที่ต้องรันบนทุกเครื่อง ดังนั้นคุณจึงต้องคอยอัปเดตแพตช์ซอฟต์แวร์นี้บนทุกเครื่องด้วยตนเอง ในขณะที่การใช้ WireGuard แบบปกติบน Ubuntu 24.04 จะเป็น kernel module ที่มาพร้อมกับ distribution และได้รับการอัปเดตไปพร้อมกับ kernel โดยอัตโนมัติ

ต้นทุนประการที่สามคือค่าใช้จ่าย ณ เดือนตุลาคม 2026 แผน Personal เปิดให้ใช้งานฟรีสำหรับอุปกรณ์ของผู้ใช้ไม่จำกัดจำนวนสำหรับผู้ใช้สูงสุด 6 คน ส่วนแผน Standard มีค่าใช้จ่าย 8 ดอลลาร์ต่อผู้ใช้ต่อเดือน และแผน Premium มีค่าใช้จ่าย 18 ดอลลาร์ต่อผู้ใช้ต่อเดือน สำหรับการใช้งานในครัวเรือนยังคงฟรี แต่สำหรับทีมที่มีสมาชิก 10 คนจะไม่ฟรีอีกต่อไป การตัดสินใจว่าคุณจะเกินขีดจำกัดหรือไม่นั้นขึ้นอยู่กับจำนวนผู้ใช้งานเป็นหลัก แต่มีข้อยกเว้นคือ เซิร์ฟเวอร์และอุปกรณ์ที่ติดแท็ก (tagged devices) จะมีโควตาแยกต่างหาก ทุกแผนจะรวมโควตาสำหรับทรัพยากรที่ติดแท็กไว้ 50 รายการ และ ณ เดือนตุลาคม 2026 หน้าเพจราคาได้ระบุค่าใช้จ่ายไว้ที่ 1 ดอลลาร์ต่อเดือนสำหรับแต่ละรายการที่เกินจากนั้น สิ่งที่แผนฟรีครอบคลุมจริง ๆ เป็นข้อมูลที่ควรตรวจสอบก่อนที่คุณจะเชิญผู้ใช้คนที่ 7 หรือติดแท็กเซิร์ฟเวอร์ตัวที่ 51

เมื่อ WireGuard แบบปกติคือคำตอบที่เหมาะสม

เลือกใช้ WireGuard แบบปกติเมื่อโทโพโลยีเป็นแบบ hub and spoke อย่างแท้จริง เช่น มี VPS หนึ่งเครื่องที่มี public IP และมีอุปกรณ์อีก 3-4 เครื่องเชื่อมต่อเข้ามา โดยไม่มีความจำเป็นที่อุปกรณ์เหล่านั้นจะต้องติดต่อสื่อสารกันเอง การตั้งค่าจะสั้นพอที่จะแสดงผลบนหน้าจอเดียว ไม่ต้องคอยอัปเดต daemon ไม่มีบัญชีผู้ใช้ที่อาจสูญหาย และไม่มีบริการภายนอกใดๆ มาคั่นกลางระหว่างคุณกับเซิร์ฟเวอร์

นอกจากนี้ยังเป็นคำตอบที่เหมาะสมเมื่อคุณต้องการทำความเข้าใจเลเยอร์พื้นฐานที่บริการอื่นสร้างทับขึ้นมา การทำ Self-hosting VPN ด้วย WireGuard บน VPS จะอธิบายขั้นตอนการสร้าง key, wg0.conf, การทำ IP forwarding, NAT และความล้มเหลวในการทำ handshake ทั้งนี้ key และ handshake ยังคงทำงานอยู่เบื้องหลังทุก tailnet และ IP forwarding จะกลับมามีความสำคัญทันทีเมื่อโหนดใน tailnet ทำหน้าที่เป็น subnet router หรือ exit node หากคุณยังคงพิจารณาตัวเลือกแบบเดิม WireGuard เทียบกับ OpenVPN จะครอบคลุม 4 กรณีที่ OpenVPN ยังคงมีความได้เปรียบอยู่

ขั้นตอนการติดตั้งนั้นสั้นมาก:

sudo apt update && sudo apt install -y wireguard
sudo modprobe wireguard && echo ok

จุดที่ WireGuard แบบปกติเริ่มใช้งานไม่สะดวกคือเมื่อทุกอุปกรณ์จำเป็นต้องติดต่อสื่อสารกันเองทั้งหมด (full mesh) การทำ full mesh ของโหนดจำนวน N โหนด จำเป็นต้องมี peer block จำนวน N คูณด้วย N ลบหนึ่ง หากมีอุปกรณ์ 6 เครื่อง คุณจะต้องดูแล block ถึง 30 ชุดด้วยตนเอง และหากมีการระบุค่า AllowedIPs ซ้ำกัน ระบบจะดึง traffic ไปจาก peer ที่ใช้งานก่อนหน้าโดยไม่มีการแจ้งเตือนข้อผิดพลาดใดๆ ปรากฏขึ้นเลย

เมื่อ Tailscale คือคำตอบที่เหมาะสม

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

การติดตั้งไคลเอนต์ทำได้ด้วยคำสั่งเดียวจากตัวติดตั้งอย่างเป็นทางการ:

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

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

การตั้งค่าสองอย่างต่อไปนี้จะช่วยจัดการงานส่วนใหญ่หลังจากนั้น subnet router จะประกาศเครือข่าย LAN ทั้งวงเข้าสู่เครือข่าย เพื่อที่คุณจะได้ไม่ต้องติดตั้งไคลเอนต์บนทุกอุปกรณ์:

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
sudo tailscale set --advertise-routes=192.0.2.0/24

เส้นทาง (route) จะยังไม่ทำงานจนกว่าคุณจะอนุมัติใน admin console ซึ่งเป็นสิ่งที่ตั้งใจไว้ เพื่อป้องกันไม่ให้โหนดใดโหนดหนึ่งแทรกเส้นทางเข้าสู่เครือข่ายของคุณได้เอง ไคลเอนต์ Linux ยังจำเป็นต้องใช้ sudo tailscale set --accept-routes เนื่องจากโดยปกติแล้ว Linux จะไม่ยอมรับเส้นทางที่ประกาศมา ดังนั้นเส้นทางที่ดูเหมือนได้รับการอนุมัติบนฝั่งเซิร์ฟเวอร์จะยังไม่มีผลบนแล็ปท็อป Linux จนกว่าคุณจะตั้งค่าส่วนนี้ หากนี่คือรูปแบบที่คุณต้องการ การรัน subnet router บน VPS จะอธิบายขั้นตอนการอนุมัติและการตั้งค่าการส่งต่อข้อมูล (forwarding) ตามลำดับเพื่อหลีกเลี่ยงปัญหาเส้นทางทำงานไม่สมบูรณ์

exit node จะส่งทราฟฟิกอินเทอร์เน็ตทั่วไปของไคลเอนต์ ซึ่งหมายถึงทุกอย่างที่ไม่ได้มุ่งหน้าไปยังอุปกรณ์อื่นใน tailnet หรือเส้นทาง subnet ที่ได้รับอนุมัติ ให้ผ่านเครื่องหนึ่งเครื่อง ซึ่งเป็นพฤติกรรมการทำ tunnel เต็มรูปแบบที่ผู้คนมักหมายถึงเมื่อพูดว่า "VPN" บน Linux จำเป็นต้องมีการตั้งค่า IP forwarding แบบเดียวกับที่แสดงไว้ข้างต้นก่อนที่คุณจะประกาศใช้งาน:

sudo tailscale set --advertise-exit-node

แฟล็กดังกล่าวเป็นเพียงส่วนที่ง่าย และ การเปลี่ยน VPS ให้เป็น exit node จะครอบคลุมถึงสิ่งที่ต้องทำหลังจากนั้น ได้แก่ การอนุมัติเส้นทางใน admin console จากนั้นจึงแก้ไขพฤติกรรม DNS และ IPv6 ที่อาจทำให้ทราฟฟิกออกไปผิดทาง หากสิ่งที่คุณต้องการเข้าถึงคือเว็บเซอร์วิสเพียงอย่างเดียวแทนที่จะเป็นทั้งเครือข่าย serve และ funnel จะช่วยวาง HTTPS ไว้หน้าพอร์ตภายในพอร์ตเดียวแทน โดยสามารถเลือกได้ว่าจะให้เข้าถึงได้เฉพาะใน tailnet หรือเปิดให้สาธารณะเข้าถึงได้ผ่านอินเทอร์เน็ต

เมื่อ Headscale เป็นคำตอบที่เหมาะสม

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

sudo tailscale up --login-server https://headscale.example.com

เส้นทางการรับส่งข้อมูลทุกอย่างยังคงเหมือนเดิม คือยังคงใช้โปรโตคอล WireGuard และเป็นการเชื่อมต่อโดยตรงระหว่าง peer หากเครือข่ายเอื้ออำนวย สิ่งที่เปลี่ยนไปคือรายการโหนด (node list), คีย์ (keys) และนโยบาย (policy) จะถูกจัดเก็บอยู่ในไฟล์ SQLite บนดิสก์ของคุณเอง ไม่มีบุคคลภายนอกสามารถมองเห็นโครงสร้างเครือข่ายของคุณ ปิดการใช้งานบัญชีของคุณ หรือเรียกเก็บเงินคุณตามจำนวนผู้ใช้งานได้

สิ่งที่ต้องแลกมาคือภาระงานจริง คุณจะต้องรันบริการ HTTPS แบบสาธารณะ ซึ่งหมายถึงการต้องมีชื่อ DNS, ใบรับรอง (certificate) และ reverse proxy ที่สามารถส่งผ่าน WebSocket upgrades ได้อย่างถูกต้อง คุณต้องรับผิดชอบเรื่อง uptime ของระบบเอง และหาก coordination server ล่ม โหนดใหม่จะไม่สามารถลงทะเบียนได้ และโหนดที่มีอยู่เดิมจะไม่สามารถรับทราบการเปลี่ยนแปลงใดๆ ได้ นอกจากนี้ Headscale ยังอยู่ในเวอร์ชันต่ำกว่า 1.0 และการอัปเดตเวอร์ชันย่อยมักมีการเปลี่ยนแปลงที่ส่งผลกระทบต่อการใช้งานเดิม (breaking changes) ดังนั้นโปรดอ่าน changelog ก่อนการอัปเกรดทุกครั้ง การรัน Headscale เพื่อเป็น Tailscale control server ของคุณเอง จะครอบคลุมเนื้อหาเกี่ยวกับการติดตั้ง, config.yaml, preauth keys และพอร์ตที่ต้องเปิดใช้งาน

มีข้อจำกัดประการหนึ่งที่ผู้ใช้มักพบเมื่อใช้งานไปแล้วระยะหนึ่ง Headscale ไม่ได้มาพร้อม global relay network ของ Tailscale เมื่อ peer 2 รายไม่สามารถเชื่อมต่อกันโดยตรง คุณต้องเปิดใช้ relay ที่ฝังมาในระบบบนเซิร์ฟเวอร์ของคุณเอง หรือกำหนดค่าให้ชี้ไปยัง relay อื่น relay ดังกล่าวเป็นเซิร์ฟเวอร์เครื่องเดียวใน region เดียว ไม่ใช่ fleet ที่กระจายอยู่ทั่วโลก peer ที่อยู่คนละฝั่งของโลกจะได้รับผลกระทบจากความแตกต่างนี้อย่างชัดเจน หากไม่ต้องการประกอบส่วนนี้เอง การ self-hosting NetBird ก็เป็นอีกทางเลือกสำหรับการเก็บ control plane ไว้ภายในองค์กร เพราะ quickstart ของ NetBird จะเริ่มบริการ management, signal และ relay พร้อมกันบน VPS 1 เครื่อง อย่างไรก็ตาม NetBird ไม่ใช่ Tailscale server ที่นำมาแทนกันได้ทันทีแบบ Headscale เพราะ NetBird ออก client และ policy model ของตนเอง ดังนั้นควรอ่าน ความแตกต่างระหว่าง NetBird กับ Tailscale ด้าน access rules และ relay ก่อนเลือกใช้ NetBird แทน Headscale

วิธีตัดสินใจในขั้นตอนเดียว

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

ให้ถามว่าเครื่องเหล่านั้นมี public address ที่เสถียรหรือไม่ หากเครื่องส่วนใหญ่อยู่หลัง NAT ที่คุณควบคุมไม่ได้ คุณควรใช้ control plane เพราะการทำ hole punching เป็นส่วนที่ยากและไม่คุ้มค่าที่จะสร้างขึ้นใหม่เอง

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

คุณสามารถเปลี่ยนใจได้โดยมีค่าใช้จ่ายต่ำ เนื่องจาก data plane ใช้โปรโตคอลเดียวกันทั้งสามแบบ การย้ายจาก WireGuard ปกติไปสู่ coordinated mesh จึงเป็นเพียงการติดตั้งไคลเอนต์ใหม่แทนที่จะต้องออกแบบระบบใหม่ทั้งหมด และการย้ายจาก Tailscale ไปยัง Headscale ก็เป็นเพียงการลงทะเบียนโหนดใหม่กับ login server ตัวใหม่เท่านั้น

สิ่งที่ทั้งสามอย่างนี้ไม่ได้มอบให้คุณ

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

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

FAQ

Tailscale เป็นเพียง WireGuard ที่เพิ่มขั้นตอนเข้ามาใช่หรือไม่?

Tailscale ใช้โปรโตคอล WireGuard สำหรับเส้นทางข้อมูล ดังนั้นการเข้ารหัสและอุโมงค์เชื่อมต่อจึงเหมือนกัน สิ่งที่เพิ่มเข้ามาคือการประสานงาน (coordination): การแลกเปลี่ยนกุญแจ, การกำหนดหมายเลข IP, การทำ NAT traversal ด้วย STUN และ DERP relay, การหมดอายุของกุญแจ และไฟล์นโยบายที่ระบุชื่อผู้ใช้แทนช่วง IP สิ่งเหล่านี้คือส่วนที่ WireGuard แบบปกติปล่อยให้คุณจัดการเอง และเป็นส่วนที่ทำได้ยากเมื่ออุปกรณ์มีการย้ายเครือข่ายไปมา

ทราฟฟิกของฉันผ่านเซิร์ฟเวอร์ของ Tailscale หรือไม่?

โดยปกติแล้วไม่ผ่าน อุปกรณ์จะเชื่อมต่อกันโดยตรงเมื่อเซิร์ฟเวอร์ประสานงานแนะนำให้รู้จักกันแล้ว และ tailscale status จะแสดง direct บนบรรทัดของอุปกรณ์นั้นๆ เมื่อไม่สามารถสร้างเส้นทางตรงได้ ทราฟฟิกจะเปลี่ยนไปใช้ DERP relay และบรรทัดนั้นจะแสดงเป็น relay แม้ในกรณีดังกล่าว relay จะส่งผ่านเฉพาะแพ็กเก็ตที่เข้ารหัสไว้และไม่มีกุญแจส่วนตัว (private key) ของ WireGuard ของคุณ จึงไม่สามารถอ่านเนื้อหาภายในได้ ให้รัน tailscale netcheck เพื่อตรวจสอบว่าเครือข่ายของคุณกำลังบล็อก UDP ที่จำเป็นสำหรับการเชื่อมต่อโดยตรงหรือไม่

ฉันสามารถใช้ Headscale กับแอปอย่างเป็นทางการของ Tailscale ได้หรือไม่?

ได้ Headscale ใช้โปรโตคอลควบคุมเดียวกัน ดังนั้นไคลเอนต์อย่างเป็นทางการจึงสามารถเข้าร่วมได้ด้วย sudo tailscale up --login-server https://headscale.example.com แอปบนเดสก์ท็อปและมือถือสามารถชี้ไปยังเซิร์ฟเวอร์ล็อกอินแบบกำหนดเองได้เช่นกัน แม้ว่าการตั้งค่าจะอยู่ในตำแหน่งที่ต่างกันในแต่ละแพลตฟอร์ม และแอปบนมือถือมักจะเป็นแอปที่ต้องการเวอร์ชันเฉพาะเจาะจงมากที่สุด ควรทดสอบกับโทรศัพท์หนึ่งเครื่องก่อนที่จะย้ายเครือข่ายทั้งหมด

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

ไคลเอนต์ Tailscale ไม่จำเป็นต้องเปิดพอร์ตขาเข้า เพราะจะทำการเชื่อมต่อออกไปยังเซิร์ฟเวอร์ประสานงานและคงการเชื่อมต่อนั้นไว้ เซิร์ฟเวอร์ Headscale ที่โฮสต์เองจำเป็นต้องเปิดพอร์ตขาเข้า: พอร์ต 443 สำหรับโปรโตคอลควบคุม, พอร์ต 80 หากคุณใช้การตรวจสอบสิทธิ์แบบ HTTP-01 และพอร์ต 3478/udp เฉพาะเมื่อคุณเปิดใช้งาน relay ที่ฝังมาด้วย ส่วน WireGuard แบบปกติจำเป็นต้องเปิดพอร์ต UDP ที่ใช้รับฟัง (ปกติคือ 51820) บนเซิร์ฟเวอร์และบนไฟร์วอลล์เครือข่ายแยกต่างหากที่ผู้ให้บริการของคุณใช้งานอยู่

ทั้งสามตัวเลือกนี้ ตัวไหนเร็วที่สุด?

ปริมาณการรับส่งข้อมูล (throughput) เท่ากัน เพราะทั้งสามตัวส่งแพ็กเก็ตด้วย WireGuard ความแตกต่างจะปรากฏในการตั้งค่าการเชื่อมต่อและคุณภาพของเส้นทาง WireGuard แบบปกติที่มี Endpoint ที่ถูกต้องจะเชื่อมต่อโดยตรงได้ทุกครั้ง Tailscale และ Headscale จะเชื่อมต่อโดยตรงได้เกือบตลอดเวลาและจะเปลี่ยนไปใช้ relay เมื่อเครือข่ายบล็อกการทำ hole punching ซึ่งเส้นทางที่ผ่าน relay จะเพิ่มความหน่วง (latency) ให้วัดเส้นทางของคุณด้วย tailscale ping <node> ซึ่งจะรายงานว่าเส้นทางเป็นแบบตรงหรือผ่าน relay หรือใช้ iperf3 วัดผ่านอุโมงค์เชื่อมต่อ หากตัวเลขที่ได้ต่ำกว่าความเร็วสายของคุณมากในขณะที่เป็นเส้นทางตรง แสดงว่าตัวเลือกทั้งสามไม่ใช่สาเหตุของปัญหา และ สาเหตุทั่วไปคือการไม่ตรงกันของ path MTU ซึ่งส่งผลเหมือนกันไม่ว่าจะใช้ control plane หรือไม่ก็ตาม