Headscale - โอเพนซอร์สสำหรับโฮสต์เองที่นำคอนโทรลเซิร์ฟเวอร์ของ Tailscale มาใช้งาน

• Headscale เป็นโปรเจกต์ที่นำคอนโทรลเซิร์ฟเวอร์ของ Tailscale มาใช้งานในรูปแบบโอเพนซอร์สและโฮสต์เองได้ โดยมุ่งเป้าไปที่ self-hoster และสภาพแวดล้อมโปรเจกต์/แล็บของนักพัฒนาสายงานอดิเรก
• Tailscale เป็น VPN สมัยใหม่ที่ใช้ WireGuard เป็นพื้นฐาน และทำงานเหมือนเครือข่าย overlay ระหว่างคอมพิวเตอร์ในเครือข่ายด้วยการใช้ NAT traversal
• คอนโทรลเซิร์ฟเวอร์ของ Tailscale รับผิดชอบการ แลกเปลี่ยน public key ของ WireGuard ของโหนด, การจัดสรร IP ให้ไคลเอนต์, การสร้างขอบเขตผู้ใช้, การแชร์เครื่องระหว่างผู้ใช้ และการเปิดเผย route ที่โหนดประกาศไว้
• Headscale มีขอบเขตแคบ โดยให้การใช้งาน เครือข่าย Tailscale เดียว (tailnet) ที่เหมาะกับการใช้งานส่วนบุคคลหรือองค์กรโอเพนซอร์สขนาดเล็ก
• โปรเจกต์นี้ไม่เกี่ยวข้องกับ Tailscale Inc. และการรัน Headscale ไม่รองรับหรือไม่แนะนำให้ใช้ reverse proxy และคอนเทนเนอร์

---

จุดประสงค์และขอบเขตของ Headscale

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

บทบาทของ Tailscale และคอนโทรลเซิร์ฟเวอร์

• Tailscale เป็น VPN สมัยใหม่ ที่สร้างอยู่บน WireGuard
• Tailscale ทำงานเหมือน เครือข่าย overlay ระหว่างคอมพิวเตอร์ในเครือข่าย และใช้ NAT traversal
• ใน Tailscale องค์ประกอบทั้งหมดเป็นโอเพนซอร์ส ยกเว้นบางส่วนของ GUI client และคอนโทรลเซิร์ฟเวอร์
  • GUI client ที่ระบุเป็นข้อยกเว้นคือไคลเอนต์สำหรับระบบปฏิบัติการ proprietary เช่น Windows และ macOS/iOS
• คอนโทรลเซิร์ฟเวอร์ ทำหน้าที่เป็นจุดแลกเปลี่ยน public key ของ WireGuard ระหว่างโหนดในเครือข่าย Tailscale
  • จัดสรรที่อยู่ IP ให้ไคลเอนต์
  • สร้างขอบเขตระหว่างผู้ใช้
  • ทำให้แชร์เครื่องระหว่างผู้ใช้ได้
  • เปิดเผย route ที่โหนดประกาศไว้
• เครือข่าย Tailscale หรือ tailnet คือเครือข่ายส่วนตัวที่ Tailscale จัดสรรให้ผู้ใช้รายบุคคลหรือองค์กร

เอกสารและข้อควรระวังเรื่องเวอร์ชัน

• หากต้องการดูตัวอย่างการตั้งค่าที่ตรงกับเวอร์ชัน release ที่ใช้อยู่ ต้องเลือก GitHub tag เดียวกันเสมอ
• branch main อาจมีการเปลี่ยนแปลงที่ยังไม่ถูก release อยู่
• เอกสารมีทั้งเวอร์ชันเสถียรและเวอร์ชันพัฒนา
  • Documentation for the stable version
  • Documentation for the development version
• แนะนำให้ดูรายการฟีเจอร์ได้ที่ เอกสาร Features
• แนะนำให้ดูขอบเขตการรองรับไคลเอนต์และระบบปฏิบัติการได้ที่ เอกสาร Client and operating system support

การรันและการ build

• การรัน Headscale ไม่รองรับหรือไม่แนะนำให้ใช้ reverse proxy และคอนเทนเนอร์
• แนะนำให้ดูวิธีรันได้จาก เอกสารทางการ
• โมดูลสำหรับผู้ใช้ NixOS อยู่ในไดเรกทอรี nix/
• development build ของ branch main มีให้ในรูปแบบ container image และ binary
  • ดูรายละเอียดได้ที่ เอกสาร development builds

ความสัมพันธ์ของโปรเจกต์และการมีส่วนร่วม

• โปรเจกต์นี้ ไม่เกี่ยวข้องกับ Tailscale Inc.
• หนึ่งใน main maintainer ที่ยังทำงานอยู่ของ Headscale ได้รับการจ้างงานโดย Tailscale และสามารถมีส่วนร่วมกับโปรเจกต์ในเวลางานได้
  • การมีส่วนร่วมของ maintainer รายดังกล่าวจะถูก review โดย maintainer คนอื่น
• maintainer ร่วมกันกำหนดทิศทางโปรเจกต์ภายใต้หลักการสร้างโปรเจกต์ที่ยั่งยืน พร้อมสนับสนุนชุมชน self-hoster, ผู้ใช้ที่กระตือรือร้น และนักพัฒนาสายงานอดิเรก
• ผู้มีส่วนร่วมควรอ่าน CONTRIBUTING.md

สภาพแวดล้อมการพัฒนาและ workflow

• การมีส่วนร่วมต้องใช้ Go และ Buf เวอร์ชันล่าสุด
  • Buf ใช้เป็นตัวสร้าง Protobuf
• แนะนำให้ใช้ Nix ในการตั้งค่าสภาพแวดล้อมการพัฒนา
  • เมื่อรัน nix develop ระบบจะติดตั้งเครื่องมือที่จำเป็นและให้ shell พร้อมใช้งาน
  • วิธีนี้รับประกันสภาพแวดล้อมการพัฒนาแบบเดียวกับ maintainer ของ Headscale
• โค้ด Go lint ด้วย golangci-lint และ format ด้วย golines, gofumpt
  • ความกว้างของ golines ตั้งไว้ที่ 88
  • แนะนำให้รัน make lint และ make fmt ก่อน commit
• โค้ด Proto lint ด้วย buf และ format ด้วย clang-format
• เอกสาร format ด้วย mdformat ส่วนไฟล์ที่เหลือ เช่น Markdown และ YAML format ด้วย prettier
• เมื่อเปลี่ยนแปลง proto/ ต้องสร้างโค้ด Go จาก Protobuf ใหม่
  • คำสั่งคือ make generate
  • แนะนำให้ใส่การเปลี่ยนแปลงใน gen/ เป็น commit แยกต่างหากเพื่อให้ review ง่ายขึ้น
• การทดสอบและการ build รันด้วย make test และ make build ตามลำดับ
• workflow ที่แนะนำคือหลังจาก nix develop ให้รัน make test และ make build
  • หากจัดการ dependency เอง สามารถใช้ Make ได้โดยตรง
  • Makefile จะเตือนหากไม่มีเครื่องมือที่จำเป็น และแนะนำให้รัน nix develop
  • ดู target ที่ใช้ได้ด้วย make help

[GN⁺]

ความคิดเห็นจาก Hacker News

• ทุก ๆ ไม่กี่เดือน ผมจะกลับมาดู repository นี้ว่า Tailnet lock ใช้งานได้ในที่สุดหรือยัง และระหว่างนั้นมีใครทำ security audit แล้วหรือไม่
  น่าเสียดายที่ทั้งสองอย่างดูเหมือนยังไม่มีความคืบหน้า เลยทำให้ยิ่งไม่แน่ใจว่าผมจะเชื่อใจสิ่งนี้ให้เป็นองค์ประกอบหลักของโครงสร้างพื้นฐานของผมได้แค่ไหน
  หลักคิดของ Tailscale SaaS คือการสร้าง tunnel ที่อ้อมผ่าน firewall และให้ผู้ใช้ควบคุมได้ว่าจะ route อะไรผ่าน tunnel นั้น ด้วยวิธีที่เข้าใจง่ายและรวมศูนย์
  Headscale ดูเหมือนจะทำเรื่องการอ้อมผ่าน firewall และ NAT traversal ขั้นสูงได้ดี แต่ยังน่าสงสัยว่ามันให้ความปลอดภัยของตัวเองได้เพียงพอที่จะชดเชยความปลอดภัยที่เพิ่งอ้อมผ่านไปหรือไม่
  ถ้าผู้ใช้ไม่มีทางเข้าใจหรือปฏิเสธได้ว่า control server สั่งให้ client ทำอะไร และไม่มีการ audit ความปลอดภัยของโค้ด server เลย ก็ดูเป็นตัวเลือกที่ค่อนข้างกล้าเสี่ยง

  • Tailnet lock ดูจะสำคัญกับ Headscale น้อยกว่าใน Tailscale มาก เพราะคุณควบคุม โครงสร้างพื้นฐาน Headscale เอง
  • สงสัยว่า Headscale implement ฟีเจอร์พวกนั้นเองจริง ๆ หรือเปล่า
    ผมเคยคิดว่านี่เป็น control layer ที่วางอยู่บนบริการ backend พื้นฐานของ Tailscale แล้วมันทำหน้าที่เป็นตัวกลางเชื่อมต่อด้วยวิธีใหม่หรือ?
    ผมใช้ ZeroTier ค่อนข้างบ่อย แต่ไม่คุ้นกับ Tailscale คำถามนี้อาจจะพื้น ๆ ก็ได้
  • หนึ่งใน maintainer ตอนนี้ทำงานอยู่ที่ Tailscale
  • ดูที่เกี่ยวข้องได้ที่ https://github.com/juanfont/headscale/issues/2416

• ถ้าสนใจ orchestration server แบบ self-hosted ก็น่าดู Netbird เช่นกัน
  เป็นเครื่องมือคล้าย ๆ กัน แต่ server ก็เปิดเป็น open source ด้วย และ control server แบบ self-hosted มาพร้อม GUI ที่ใช้ได้ดีและฟีเจอร์จากเวอร์ชันเสียเงิน
  https://netbird.io/knowledge-hub/tailscale-vs-netbird

  • เมื่อเทียบกับ Headscale แล้ว Netbird มีชิ้นส่วนที่ต้องดูแลเยอะมาก
    ดูแข็งแรง ทรงพลัง และมีฟีเจอร์เยอะ แต่ Headscale แบบ self-hosted นั้นเรียบง่ายกว่าและต้องการสิ่งต่าง ๆ น้อยกว่ามาก
  • กำลังค่อย ๆ ย้ายจาก Tailscale ไป Netbird อยู่ และมันทำงานได้ดีมาก ยกเว้นพฤติกรรมแปลก ๆ ของ Tailscale ที่ยึด เส้นทาง CGNAT ทั้งหมด ไป
    ตอนนี้ยังรัน Tailscale อยู่ด้วย แต่ค่อย ๆ เข้าใกล้การเลิกใช้แล้วเปลี่ยนไป Netbird ทั้งหมดมากขึ้น
  • อยากใช้ Netbird แต่ยังไม่มีฟีเจอร์ที่ฝังใน Go binary ได้เหมือน tsnet ของ Tailscale
    issue ที่เกี่ยวข้องใน GitHub อยู่ที่นี่
    https://github.com/netbirdio/netbird/issues/1103
  • การไม่มี IPv6 เป็นข้อเสียร้ายแรงจริง ๆ: https://github.com/netbirdio/netbird/issues/46
  • สงสัยว่า Netbird ทำ NAT traversal ที่ละเอียดประณีตเหมือน Tailscale ด้วยหรือเปล่า

• น่าจะใส่ชื่อโปรเจกต์ Headscale ไว้ในหัวข้อด้วย
  Headscale เป็นโปรเจกต์ที่เคยขึ้น HN มาหลายครั้งแล้ว

• ถ้า Headscale รองรับ peering/federation ระหว่าง instance ได้คงเจ๋งมาก อาจจะหลังจากปรับ ACL ใหม่แล้วก็ได้
  หนึ่งในปัญหาหลักคือ address collision
  ข้อเสนอคือ: กำหนดให้เป็น overlay network เฉพาะ IPv6 ในช่วง Unique Local Address (ULA) แล้วแบ่ง 121 บิตที่เหลือเป็น 20 บิตล่างสำหรับ address ของอุปกรณ์ (ประมาณ 1 ล้านเครื่อง) และ 101 บิตบนเป็น hash ของ public key ของ server
  เพิ่ม public key ของ instance อื่นเพื่อทำ federation แล้วจัดการการสื่อสารระหว่าง node ด้วย policy และ ACL
  ผมคิดว่าเป็นไอเดียที่ดี แต่ตอนเสนอในปี 2023 maintainer ชื่อ kradalby บอกว่าอยู่นอก scope: https://github.com/juanfont/headscale/issues/1370

• ใช้ Headscale มาได้ครึ่งปีแล้วและใช้งานได้ดี
  ชอบมาก จนถึงขั้นไม่รู้ว่าเมื่อก่อนใช้ชีวิตโดยไม่มี เครือข่าย Tailscale ได้อย่างไร
  มีแพ็กเกจบน OpenBSD และผมใช้แพ็กเกจนั้นเป็น server อยู่

• ชอบ Headscale และเพิ่งเอาขึ้น production ซึ่งทำงานได้ดีมาก

  • ใช้งาน Headscale มา 2.5 ปีแล้ว และถือว่าค่อนข้างดี
    ใช้โดเมน Gmail สำหรับ login ซึ่งมีข้อดีใหญ่คือผู้ใช้ลงทะเบียนอุปกรณ์ของตัวเองได้เอง
    สมัยใช้ OpenVPN ทีมปฏิบัติการต้องส่ง certificate และ config ให้เอง
    ข้อเสียอย่างเดียวคือบางครั้งผู้ใช้เผลอไปเชื่อมต่อกับ login server ของ Tailscale แทนที่จะเป็น server ของเราเอง แล้วงงว่าทำไมเข้า service ไม่ได้
    กำลังตั้งค่า service ที่เข้าถึงได้ตาม user group
    ยังใช้ Headscale เวอร์ชันเก่าอยู่ เพราะมี integration ที่ต้อง port ไปยัง control plane ใหม่
    ตาม headscale node list | wc มี node ประมาณ 250 ตัว และส่วนใหญ่เป็น server
    ไม่ค่อยชอบที่ Tailscale ไปแตะ routing table กับ firewall rule แบบเหมือนเวทมนตร์ แต่โดยรวมแล้วไม่ค่อยเป็นปัญหาและทำงานได้ค่อนข้างดี
  • สงสัยว่าหมายถึง deploy เป็น internal service สำหรับทั้งบริษัทหรือเปล่า

• ในหลายกรณีการใช้งาน เช่น การเข้าถึงจากมือถือหรือ GUI บน macOS จะใช้ Headscale ได้ก็ต่อเมื่อ ไคลเอนต์ Tailscale อย่างเป็นทางการ ยังคงมีฟีเจอร์ให้ตั้งค่าเซิร์ฟเวอร์ควบคุมได้
  ทันทีที่ Tailscale เริ่มลดคุณภาพลงอย่างหลีกเลี่ยงไม่ได้ ฟีเจอร์นี้ก็จะหายไป
  ตอนนี้ผมเป็นลูกค้าที่พอใจกับ Tailscale มาก แต่พูดจากประสบการณ์ที่เคยเจอหลายครั้งในอดีต ตอนที่บริษัทอื่น ๆ ถูกขายหรือเงินทุน VC หมด

  • ถ้าไม่นับส่วน GUI ของระบบปฏิบัติการที่ไม่ใช่โอเพนซอร์ส ไคลเอนต์ Tailscale ส่วนใหญ่ก็เป็น โอเพนซอร์ส ไม่ใช่หรือ?
  • ถ้าจำไม่ผิด ดูเหมือน Tailscale เคยพูดไว้ที่ไหนสักแห่งว่า Headscale กลับส่งผล เชิงบวกต่อรายได้
    ก็น่าจะเป็นไปได้ Headscale ส่วนใหญ่ใช้โดยผู้ใช้โฮมแล็บและผู้ใช้สายงานอดิเรกขนาดเล็ก และไม่ได้แข่งกับ Pulsesecure, Cisco Anyconnect, GlobalProtect แต่แข่งกับ OpenVPN หรือ WireGuard ที่โฮสต์เอง
    มันเป็นช่องทางแนะนำ Tailscale ให้กับคนที่ชอบเทคโนโลยีใหม่ ๆ ในเวลาว่าง แต่ไม่อยากยอมเสียการควบคุมโครงสร้างพื้นฐาน
    คนเหล่านั้นก็จะนำความเชี่ยวชาญและความกระตือรือร้นต่อ Tailscale ไปยังที่ทำงาน
    บริษัทต่าง ๆ มักไม่ค่อยอยากจัดการโครงสร้างพื้นฐาน IT เอง เว้นแต่มันจะเป็นความสามารถหลักขององค์กร
    แน่นอนว่าบางบริษัทจะเลือก Headscale แทนผลิตภัณฑ์หลักของ Tailscale แต่เมื่อดูจากขนาดบริษัทและมูลค่าเงินแล้ว น่าจะเป็นส่วนน้อย
    นั่นใกล้เคียงกับต้นทุนเพื่อสร้างรายได้ และไม่ได้ต่างจากโฆษณา Facebook หรือป้ายโฆษณาข้างถนนในซิลิคอนแวลลีย์มากนัก
  • สิ่งที่ไม่พอใจที่สุดใน Tailscale คือไคลเอนต์ โดยเฉพาะ การใช้แบตเตอรี่ของไคลเอนต์มือถือ
    เหตุผลที่ที่ทำงานใช้ Tailscale ไม่ได้คือทราฟฟิกถูกกำหนดเส้นทางผ่านเซิร์ฟเวอร์ที่เราไม่สามารถควบคุมได้
    ผมอยากใช้ Tailscale ที่ที่ทำงานจริง ๆ และมันจะช่วยแก้ปัญหาได้หลายอย่าง
    ถ้าต้องเปิดพอร์ตก็พอรับได้ แต่การทำ tunnel ทราฟฟิกผ่านพอร์ตนั้นเป็นเรื่องที่น่ากังวลมาก

• ดูน่าสนใจ อยากรู้ว่ามีมูลค่าเพิ่มอะไรเมื่อเทียบกับการตั้งค่า WireGuard + OpenWrt

  • อุปกรณ์ต่าง ๆ เชื่อมต่อกันแบบ peer-to-peer ได้โดยไม่ต้องตั้งค่าด้วยมือ แม้อยู่หลัง NAT ที่ซับซ้อน
    มันทำงานได้เลยภายใต้ข้อจำกัดของ ACL ที่จัดการจากส่วนกลาง
    บางคนลดค่าของ Tailscale ว่าเป็น “แค่ตัว orchestrate WireGuard” แต่จริง ๆ แล้วมันมีมากกว่านั้นมาก
    ในมุมมองผลิตภัณฑ์ WireGuard เป็นเพียงรายละเอียดการนำไปใช้งานเท่านั้น
  • เพราะเป็น mesh VPN เพียร์จึงสื่อสารกันโดยตรง จึงไม่มี latency เพิ่ม
    เมื่อก่อนผมเลือก Netbird เพราะรู้สึกว่า UI ของ Headscale พื้นฐานเกินไป แต่ช่วงไม่กี่ปีที่ผ่านมาอาจดีขึ้นแล้วก็ได้
  • คุณค่าที่ Tailscale เสนอคือ WireGuard ที่คนซึ่งคุ้นเคยกับเทคโนโลยีในระดับหนึ่งก็สามารถตั้งค่าและดูแลเองได้
    มันทำงานได้บนไคลเอนต์จำนวนมาก และ Apple TV ของผมก็เชื่อมต่อกับเครือข่าย Tailscale อยู่ด้วย
    ใช้เวลาตั้งค่าประมาณ 1 นาที และยังทำหน้าที่เป็นเกตเวย์ได้ด้วย
  • บางคนไม่มี IP แบบคงที่ หรือไม่อยากให้มีอะไรในเครือข่ายบ้านคอย listen อยู่
    ถ้าใช้ Tailscale หรือ Headscale ที่โฮสต์ไว้ภายนอก ก็ใช้งานแบบนั้นได้

• สงสัยว่าถ้าเซิร์ฟเวอร์ประสานงานของ Tailscale ถูกเจาะ และเปิด Tailnet lock ไว้ อุปกรณ์ของผมจะมีความเสี่ยงถูกเจาะมากแค่ไหน