เปรียบเทียบ 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 นั้นสามารถเข้าถึงได้ การเพิ่มเครื่องหนึ่งเครื่องเข้าไปในเครือข่ายที่มีอยู่สิบเครื่อง หมายถึงการแก้ไขไฟล์คอนฟิกถึงสิบไฟล์ เพราะแต่ละฝั่งจำเป็นต้องมี key ของอีกฝั่ง นี่คือเหตุผลที่การตั้งค่า WireGuard แบบ self-hosted เกือบทั้งหมดเป็นรูปแบบ hub and spoke คือมีเซิร์ฟเวอร์หนึ่งเครื่องที่มี public IP และมีไคลเอนต์ที่ติดต่อกับเซิร์ฟเวอร์นั้นเพียงอย่างเดียว

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

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

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

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

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

ต้นทุนของ control plane

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

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

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

เมื่อการใช้ WireGuard แบบปกติเป็นคำตอบที่เหมาะสม

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

นอกจากนี้ยังเป็นตัวเลือกที่เหมาะสมเมื่อคุณต้องการทำความเข้าใจเลเยอร์พื้นฐานที่เทคโนโลยีอื่นสร้างทับลงไป การทำ Self-hosting VPN ด้วย WireGuard บน VPS จะอธิบายขั้นตอนการสร้าง key, wg0.conf, การทำ IP forwarding, NAT รวมถึงปัญหา handshake ล้มเหลว ซึ่งกลไกเหล่านี้ยังคงทำงานอยู่เบื้องหลัง tailnet หากคุณยังคงพิจารณาตัวเลือกแบบเก่า 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 สามารถทำงานได้บนเครือข่ายที่คุณไม่สามารถควบคุม firewall ได้เลย

การตั้งค่าสองอย่างต่อไปนี้จะช่วยจัดการงานส่วนใหญ่หลังจากนั้น 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 จะส่งทราฟฟิกทั้งหมดของไคลเอนต์ผ่านเครื่องเดียว ซึ่งเป็นพฤติกรรมการทำ full tunnel ที่ผู้คนมักหมายถึงเมื่อพูดถึง "VPN":

sudo tailscale set --advertise-exit-node

การใช้ flag ดังกล่าวเป็นเพียงส่วนที่ง่ายที่สุด และ การเปลี่ยน 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 ไม่ได้มาพร้อมกับเครือข่าย relay ทั่วโลกเหมือนของ Tailscale ในกรณีที่ peer สองตัวไม่สามารถเชื่อมต่อกันโดยตรงได้ คุณจะต้องเปิดใช้งาน relay ที่ฝังมาในตัวบนเซิร์ฟเวอร์ของคุณเอง หรือกำหนดค่าให้ชี้ไปยังเซิร์ฟเวอร์อื่น ซึ่ง relay ดังกล่าวจะเป็นเพียงเครื่องเดียวในภูมิภาคเดียว ไม่ใช่เครือข่ายขนาดใหญ่ที่กระจายอยู่ทั่วโลก ทำให้ peer ที่อยู่ห่างไกลกันคนละซีกโลกจะรู้สึกถึงความแตกต่างนี้ได้ หากคุณไม่ต้องการประกอบส่วนประกอบเหล่านี้ด้วยตนเอง การ self-host NetBird เป็นอีกทางเลือกหนึ่งในการเก็บ control plane ไว้ภายในองค์กร เนื่องจากชุด quickstart ของ NetBird จะทำการติดตั้งบริการจัดการ (management), บริการส่งสัญญาณ (signal) และบริการ relay ขึ้นมาพร้อมกันบน VPS เครื่องเดียว

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

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

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

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

คุณสามารถเปลี่ยนใจได้โดยมีค่าใช้จ่ายต่ำ เนื่องจาก data plane ใช้โปรโตคอลเดียวกันทั้ง 3 รูปแบบ การย้ายจาก WireGuard ปกติไปสู่ coordinated mesh จึงเป็นเพียงการติดตั้ง client เพิ่มเติมแทนที่จะต้องออกแบบระบบใหม่ และการย้ายจาก Tailscale ไปยัง Headscale ก็เป็นเพียงการลงทะเบียน node ใหม่กับ 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 หรือไม่ก็ตาม