Tailscale Peer Relays: รีเลย์ความเร็วสูงเพื่อเครือข่ายที่ปลอดภัยและยืดหยุ่น

 (tailscale.com)
3 คะแนน โดย GN⁺ 2025-10-31 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Tailscale Peer Relays เป็นความสามารถรีเลย์ทราฟฟิกแบบใหม่ที่มาแทน เซิร์ฟเวอร์ DERP แบบเดิม โดยเป็นโครงสร้างที่ผู้ใช้สามารถนำไปติดตั้งและดูแลจัดการเองได้
  • แต่ละโหนดสามารถทำหน้าที่เป็นรีเลย์ได้ด้วยการ เปิดเพียงพอร์ต UDP เดียว และ มีอยู่ในไคลเอนต์ Tailscale ในตัว จึงเปิดใช้งานได้อย่างง่ายดาย
  • รองรับการเชื่อมต่อ ความเร็วสูงและปริมาณงานสูง ทำให้ได้ ประสิทธิภาพใกล้เคียงการเชื่อมต่อโดยตรง แม้อยู่หลัง Cloud NAT หรือไฟร์วอลล์
  • ทราฟฟิกทั้งหมดคงไว้ซึ่ง การเข้ารหัสแบบ end-to-end บนพื้นฐาน WireGuard® พร้อมรองรับ fallback อัตโนมัติ ไปยัง DERP และ Custom DERP
  • ขณะนี้เปิดให้ใช้งานในสถานะ Public Beta และทุกแพ็กเกจสามารถใช้ Peer Relay ฟรีได้สูงสุด 2 ตัว

ภาพรวมของ Tailscale Peer Relays

  • Tailscale Peer Relays เป็น กลไกรีเลย์ทราฟฟิกที่ผู้ใช้ดูแลเอง ซึ่งสามารถใช้แทน เซิร์ฟเวอร์ DERP แบบจัดการโดย Tailscale ได้
    • โหนด Tailscale ใด ๆ ก็สามารถตั้งค่าให้เป็นรีเลย์ได้ และทำหน้าที่ส่งต่อทราฟฟิกระหว่างโหนดภายใน tailnet เดียวกัน
    • รีเลย์จะส่งต่อได้เฉพาะโหนดที่อยู่ใน tailnet เดียวกับตัวเองเท่านั้น
  • เนื่องจากลูกค้าดูแลจัดการเอง จึงมี ข้อจำกัดด้านปริมาณงานน้อยกว่า DERP และให้ประสิทธิภาพสูงได้แม้ใน โครงสร้างพื้นฐานคลาวด์แบบปิดหรือสภาพแวดล้อมที่มีไฟร์วอลล์
  • ในการทดสอบกับพาร์ตเนอร์ระยะแรก พบว่าให้ ปริมาณงานใกล้เคียงการเชื่อมต่อโดยตรง และยืนยันประสิทธิภาพที่ เร็วกว่า DERP เดิมหลายสิบเท่า

รับมือกับสภาพแวดล้อม Hard NAT

  • Tailscale ใช้เทคนิค NAT traversal ที่ปรับปรุงมาเพื่อรักษา การเชื่อมต่อโดยตรง (มากกว่า 90%) ให้ได้มากที่สุดแม้อยู่ในสภาพแวดล้อม NAT
  • อย่างไรก็ตาม ใน สภาพแวดล้อมคลาวด์ บางแห่ง การเชื่อมต่อโดยตรงอาจทำไม่ได้หรือไม่มีประสิทธิภาพ
  • DERP แบบเดิมให้การเชื่อมต่อที่เสถียร แต่มีข้อจำกัดด้าน QoS และเพดานประสิทธิภาพ ทำให้เกิดความท้าทายในบางสภาพแวดล้อมการติดตั้ง
  • Peer Relays ถูกออกแบบมาเป็น เครื่องมือเชื่อมต่อที่เน้นประสิทธิภาพ โดยใช้ การสื่อสารแบบหน่วงต่ำบน UDP และมี โครงสร้างที่ฝังอยู่ในไคลเอนต์ จึงติดตั้งใช้งานได้ง่าย
  • ลูกค้าสามารถวางรีเลย์เองเพื่อสร้าง เครือข่ายที่มีสมรรถนะสูงและยืดหยุ่นสูง ได้

วิธีการทำงาน

  • Peer Relay ใช้ พอร์ต UDP เดียว ที่ทั้งสองฝั่งของโหนดสามารถเข้าถึงได้
  • สามารถเปิดใช้งานได้ง่ายด้วยคำสั่ง CLI tailscale set --relay-server-port
  • หากไม่สามารถเชื่อมต่อโดยตรงได้ ระบบจะ fallback อัตโนมัติตามลำดับ Peer Relay → DERP (แบบจัดการหรือแบบกำหนดเอง)
  • การเชื่อมต่อทั้งหมดได้รับการปกป้องด้วย การเข้ารหัส WireGuard®
  • สามารถตั้งค่าให้ อนุญาตเฉพาะทราฟฟิกภายใน tailnet ได้ พร้อมลดข้อยกเว้นบนไฟร์วอลล์ให้เหลือน้อยที่สุด
  • รองรับทั้งการขยายข้ามภูมิภาค ความทนทานต่อความขัดข้องของเครือข่าย และความสามารถในการ fallback ไปยัง DERP โดยอัตโนมัติ

กรณีใช้งานที่หลากหลาย

  • รีเลย์ทราฟฟิกที่ไม่สามารถเชื่อมต่อโดยตรงได้ด้วยความเร็วสูงใน สภาพแวดล้อม Cloud NAT (เช่น AWS Managed NAT Gateway)
  • ใน สภาพแวดล้อมไฟร์วอลล์ที่เข้มงวด สามารถเปิดเพียงพอร์ต UDP เดียวเพื่อลดขั้นตอนการอนุมัติ
  • ช่วย ลดภาระของเครือข่าย DERP และ ไม่จำเป็นต้องดูแลรักษา Custom DERP
  • เมื่อต้อง เข้าถึงเครือข่ายลูกค้าแบบปิด สามารถเปิดเพียงพอร์ตขั้นต่ำผ่านเอนด์พอยต์ที่คาดเดาได้
  • ลูกค้าจริงได้นำ Peer Relay ไปใช้เพื่อทำ การเข้าถึงเครือข่ายที่ไม่ได้จัดการ, ควบคุมเส้นทางการเชื่อมต่อกับพาร์ตเนอร์ และ ออกแบบเครือข่ายแบบละเอียดด้วย VPC peering เป็นต้น

Public Beta และนโยบายการให้บริการ

  • Tailscale Peer Relays เปิดให้ใช้งานได้ทันทีในเวอร์ชัน Public Beta
  • ขณะนี้กำลังดำเนินการปรับปรุงบางส่วนด้าน การมองเห็นระบบและการดีบัก
  • พาร์ตเนอร์ระยะแรกยืนยันแล้วถึง ความง่ายในการติดตั้งและประสิทธิภาพที่เสถียร
  • ทุกแพ็กเกจ (รวมถึงแพ็กเกจฟรี) ได้รับ Peer Relay ฟรีสูงสุด 2 ตัว และสามารถขยายเพิ่มได้สำหรับรีเลย์เพิ่มเติม
  • หากต้องการรีเลย์เพิ่มเติม สามารถขยายได้โดย ติดต่อทีมขายของ Tailscale

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-10-31
ความคิดเห็นจาก Hacker News

  • คิดว่าฟีเจอร์นี้ สมเหตุสมผล มาก
    ใช้โหนดกลางเฉพาะตอนที่เชื่อมต่อโดยตรงไม่ได้ และทราฟฟิกก็ยังเป็น การเข้ารหัสแบบ end-to-end
    คล้ายกับการรัน derp server เอง แต่ไม่ต้องเปิดพอร์ต และยังช่วยลดการใช้รีเลย์ของ Tailscale เลยประหยัดค่าแบนด์วิดท์ได้ด้วย
    แต่อยากรู้ว่าทำไมถ้าใช้รีเลย์มากกว่าสองตัวถึงต้องเสียเงิน

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

  • เมื่อก่อน tinc ก็แก้ปัญหานี้ได้อยู่แล้ว
    ทุกโหนดสามารถทำหน้าที่เป็นรีเลย์ได้ และทำงานเป็น mesh network จริง ๆ โดยไม่มีเซิร์ฟเวอร์กลาง
    แทนที่จะสร้างใหม่ ผมว่าพอร์ตมันขึ้นมาใหม่บนพื้นฐาน wireguard ด้วยภาษาแบบ memory-safe จะดีกว่า

    • ผมเองก็ดูแลเครือข่าย Tinc 30 โหนดอยู่ แต่โฮสต์ที่อยู่หลัง NAT มักหลุดเส้นทางบ่อย
      บางครั้งเพิ่ง SSH ติดได้ไม่นาน เส้นทางก็หายไปแล้ว
      เพราะทราฟฟิกถูกถอดรหัสแล้วเข้ารหัสใหม่ที่โหนดรีเลย์ ถ้าจะให้เป็น การเข้ารหัสแบบ end-to-end ต้องใช้โปรโตคอลแบบ experimental
      อยากเขียนใหม่บนพื้นฐานโปรโตคอล cjdns เหมือนกัน แต่ไม่ง่ายเลย
    • ทำฟีเจอร์แบบเดียวกันนี้ด้วย Wireguard ก็ได้

  • ฟีเจอร์ Peer Relay ใหม่ของ Tailscale ดูคล้ายกับสิ่งที่ ZeroTier เคยทำมาก่อน
    จะบอกว่าเป็น “ฟีเจอร์เฉพาะของ Tailscale” ก็ดูฝืนไปหน่อย และรู้สึกว่าการคิดเงินเพิ่มนอกเหนือจากค่าบริการต่อผู้ใช้นั้นแรงเกินไป

    • เคยใช้ ZeroTier มาก่อน แต่ไม่มีฟีเจอร์แบบนี้
      ปัญหากลับเป็นเรื่องวิธีเข้ารหัสของตัวเอง, ประสิทธิภาพ single-thread ที่ตกลง, และความเร็วในการพัฒนาที่ช้า
      ลองมาหลายทางเลือกแล้ว แต่ตอนนี้ก็ยังไม่มีตัวไหนที่ได้ทั้งฟีเจอร์และประสิทธิภาพเท่า Tailscale
      รู้สึกเหมือนการเปรียบเทียบแนว ๆ “มี FTP แล้วจะใช้ Dropbox ไปทำไม”

  • อยากรู้ว่าสามารถระบุ ที่อยู่ IPv4/IPv6 ภายนอก ได้โดยตรงหรือไม่
    เพราะบางทีทราฟฟิกขาเข้าและขาออกใช้อีกคนละที่อยู่ หรือจากหลายที่อยู่อินเทอร์เน็ตมีแค่บางตัวที่ไฟร์วอลล์อนุญาต

  • สัปดาห์ก่อนเพิ่งตั้งค่า headscale กับ split horizon SSL ไป สุดท้ายก็พบว่า ใช้ได้แค่ DERP
    เลยคิดว่าการเปิด UDP port บนเครือข่ายโลคัลโดยตรงน่าจะดีกว่า
    ถ้าความปลอดภัยของไคลเอนต์ Wireguard ถูกพิสูจน์มาดีพอ แบบนั้นก็สะดวกกว่า

    • อยากรู้ว่า “ใช้ได้แค่ DERP” หมายถึงอะไร
      คือพยายามเปิดพอร์ตของ Wireguard ตรง ๆ หรือว่าหมายถึงพอร์ตของ Tailscale กันแน่

  • ถ้าใช้ฟีเจอร์นี้แทน DERP จะใช้ในเบราว์เซอร์ไม่ได้
    เพราะมันอิงกับ native UDP
    เลยสงสัยว่าในอนาคตจะทำผ่าน WebTransport ได้ไหม

    • (Tailscalar) ผมเองก็คาดหวังกับ WebTransport มาก
      แต่ก็ยังแก้ปัญหา NAT traversal ไม่ได้
      ก็กำลังตามดูความคืบหน้าของ QAD จาก Iroh อย่างใกล้ชิด
      ถ้าทุกอย่างลงตัวก็น่าจะได้เครือข่ายที่ เหมือนเวทมนตร์ มากขึ้นอีก

  • คิดว่าขั้นต่อไป ถ้าให้ไคลเอนต์ tailscale ทุกตัวรับ คำขอ forwarding อัตโนมัติ แล้วทำให้ mesh network ซ่อมตัวเองได้แบบไร้รอยต่อก็น่าสนใจ

    • แต่ถ้า hop เพิ่มขึ้น latency ก็จะสูงขึ้น เลยมองว่าปล่อยให้คำขอล้มเหลวเพื่อให้เห็นปัญหาชัด ๆ อาจดีกว่า
    • การขยายแนวนี้เป็นเรื่องที่ถกกันบ่อยใน overlay network
      แต่ประเด็นสำคัญคือจะยอมให้มี การรีเลย์ทราฟฟิก ของคนอื่นหรือไม่

  • Tailscale ทำให้บริการต่าง ๆ เชื่อมต่อกันได้ แต่ก็สงสัยว่าถ้า Tailscale ล่ม บริการของผมจะคุยกันเองไม่ได้ไปด้วยไหม

    • ตอนที่เซิร์ฟเวอร์ล็อกอินล่มจริง ๆ เครือข่ายโลคัลก็ถูกตัดไปทั้งหมด
      ต่อ tailscale ไม่ได้ เลยเชื่อมใหม่ก็ไม่ได้
      เพราะงั้นตอนนี้เลยจะตั้ง headscale เอง
      ที่อุปกรณ์ใน LAN เดียวกันยังคุยกันไม่ได้ก็ดูน่าหงุดหงิดพอสมควร

  • สุดสัปดาห์ที่ผ่านมาเพิ่งทำโซลูชันชั่วคราวสำหรับ Kubernetes Operator อยู่ทั้งวัน แต่ตอนนี้ด้วยฟีเจอร์นี้น่าจะรื้อทิ้งได้หมดแล้ว
    Bravo จริง ๆ

    • K8s คือฝันร้ายของผมเลย 555 เห็นด้วยสุด ๆ

  • ก่อนหน้านี้สงสัยว่า use case ของฟีเจอร์นี้คืออะไร
    เหมือนจะเหมาะกับกรณีที่ผลิตภัณฑ์ SaaS ต้องการข้อมูลจากระบบของลูกค้า แล้วให้ฝั่งลูกค้าเปิดข้อมูลผ่านรีเลย์เพื่อทำ integration
    แต่ถึงอย่างนั้นก็น่าจะยังต้องมีซอฟต์แวร์สำหรับ authentication, logging ฯลฯ อยู่ดี

    • นี่คือทางเลือกแทน DERP server ที่ tailscale ดูแลให้นั่นเอง
      เพราะหลายครั้งเจาะ NAT ไม่ผ่าน เลยต้องใช้ DERP บ่อย ซึ่งมันช้า
      ตอนนี้สามารถกำหนด peer ที่เชื่อมต่อดีภายในเครือข่ายให้เป็นรีเลย์เพื่อให้เร็วขึ้นได้
      มันไม่ใช่ use case ใหม่ แต่เป็น เวอร์ชันปรับปรุงประสิทธิภาพ ของ DERP เดิมมากกว่า
    • โดยพื้นฐานแล้ว Tailscale คือ แพลตฟอร์ม VPN ที่ปลอดภัย
      แทนที่จะใช้โครงสร้าง hub-and-spoke แบบดั้งเดิม มันมุ่งไปที่ สถาปัตยกรรม P2P ที่ให้ทุกโหนดเชื่อมต่อกันตรง ๆ ผ่าน UDP/IP ให้ได้มากที่สุด
      แต่เพราะ NAT และไฟร์วอลล์ ทำให้หลายกรณีเชื่อมต่อกันตรง ๆ ไม่ได้ DERP จึงทำหน้าที่รีเลย์ให้
      DERP นั้นช้าและผู้ใช้ก็ไม่มีทางปรับปรุงประสิทธิภาพเองได้ แต่ด้วย Peer Relay ครั้งนี้ ผู้ใช้สามารถรันรีเลย์เองได้แล้ว
      ถ้าวางตำแหน่งดี ๆ ก็ช่วยลด latency ได้
      แน่นอนว่าไม่ใช่ฟีเจอร์ที่ผู้ใช้ทุกคนจำเป็นต้องมี