Tailscale ช้าเพราะ relay หรือ direct ตรวจสอบและแก้ไข

Tailscale ช้าเมื่อการเชื่อมต่อถูกส่งต่อผ่าน relay และทำความเร็วได้ใกล้เคียงกับความเร็วของลิงก์เมื่อการเชื่อมต่อเป็นแบบ direct การเชื่อมต่อแบบ direct จะส่งแพ็กเก็ต WireGuard ที่เข้ารหัสจากเครื่องหนึ่งไปยังอีกเครื่องหนึ่งโดยตรง จึงทำความเร็วได้ตามขีดความสามารถของลิงก์อินเทอร์เน็ตทั้งสองฝั่ง การเชื่อมต่อแบบ relay จะส่งทุกแพ็กเก็ตผ่านเครื่องที่สามก่อน จึงมี latency ตามเครื่องนั้น และใช้ bandwidth ได้ตามสัดส่วนที่เครื่องนั้นจัดสรรให้ Tailscale ระบุไว้ในหน้าข้อมูลประสิทธิภาพอย่างชัดเจนว่า: "Direct connections nearly always result in lower latency and higher throughput."

ภายในแอปพลิเคชันจะไม่แสดงความแตกต่างนี้ การคัดลอกไฟล์จะช้า และเซสชัน SSH จะตอบสนองล่าช้า ดังนั้นขั้นตอนแรกคือตรวจสอบว่าขณะนี้ใช้การเชื่อมต่อประเภทใด คำสั่ง 2 คำสั่งจะตอบคำถามนี้ได้ภายในเวลาไม่ถึง 1 นาที และขั้นตอนที่เหลือคือการแก้สาเหตุ ควรทำความเข้าใจส่วนการตั้งค่าก่อนเริ่ม เพราะ coordination server และ WireGuard data plane เป็นระบบแยกจากกัน และมีเพียง data plane เท่านั้นที่ส่งข้อมูลของคุณ

คำสั่ง 2 รายการที่ใช้แยกการเชื่อมต่อโดยตรงออกจากการส่งต่อ

ส่ง network traffic ไปยัง peer ก่อนวัดผลใด ๆ Tailscale จะสร้าง path เมื่อมีการใช้งาน ดังนั้น peer ที่คุณยังไม่ได้ติดต่อในวันนี้อาจยังไม่ได้เจรจา path และค่าที่อ่านได้อาจไม่ใช่ข้อมูลปัจจุบัน การส่ง ping หรือ curl ไปยัง tailnet address ของ peer เพียง 1 ครั้งก็เพียงพอ

tailscale status

คำตอบอยู่ท้ายบรรทัดของ peer แต่ละรายการ

100.113.160.82 device-a  tagged-devices linux   active; offers exit node; direct 203.0.113.9:41641
100.104.93.78  device-b  you@           android active; relay "tor"

direct ตามด้วย address และ port หมายความว่า packet กำลังส่งตรงไปยัง address นั้น ส่วน relay "tor" ระบุ DERP server (designated encrypted relay for packets) ซึ่งเป็นเครื่อง relay ของ Tailscale และ packet ทุกตัวที่ส่งไปยัง peer นั้นจะผ่านเครื่องดังกล่าว ค่าแบบที่ 3 คือ peer-relay ซึ่งจะอธิบายในหัวข้อถัดไป

tailscale ping device-b

การเชื่อมต่อที่ทำงานปกติจะเริ่มจากการส่งต่อ แล้วเปลี่ยนเป็นการเชื่อมต่อโดยตรง packet แรกจะผ่าน DERP server ที่อยู่ใกล้ที่สุดระหว่างที่เครื่องทั้ง 2 เครื่องกำลังเจรจา จากนั้น path จะเปลี่ยนเป็นดังนี้:

pong from device-b (100.113.160.82) via DERP(tor) in 51ms
pong from device-b (100.113.160.82) via DERP(tor) in 48ms
pong from device-b (100.113.160.82) via 203.0.113.9:41641 in 35ms

การทำงานหยุดที่จุดนั้นเนื่องจาก --until-direct มีค่าเริ่มต้นเป็น true การเชื่อมต่อที่ไม่สามารถเปลี่ยนเป็นการเชื่อมต่อโดยตรงจะมีลักษณะดังนี้ และจบด้วยประโยคแทนที่จะเป็น pong:

pong from device-b (100.104.93.78) via DERP(tor) in 53ms
pong from device-b (100.104.93.78) via DERP(tor) in 60ms
direct connection not established

บรรทัดสุดท้ายคือผลการตรวจสอบ หมายความว่า Tailscale ส่ง probe ที่จะส่งทั้งหมดแล้ว แต่ไม่เคยได้ path โดยตรง หากต้องการเฝ้าดู path ที่มีการส่งต่อแทนการหยุดเมื่อพบ path โดยตรงครั้งแรก ให้เรียกใช้ tailscale ping --until-direct=false -c 20 device-b และอ่านช่วงค่าความหน่วง path ที่มีการส่งต่อมักแสดงทั้งค่าที่สูงกว่าและความผันผวนที่มากกว่า เนื่องจากเป็นการเชื่อมต่อ internet 2 เส้นทางเข้าด้วยกันผ่านเครื่องที่คุณไม่ได้ควบคุม

peer-relay ใน tailscale status หมายถึงอะไร

peer relay คือเครื่องใน tailnet ของคุณเองที่ทำหน้าที่ relay traffic ให้สมาชิกอื่น เมื่อไม่สามารถเชื่อมต่อโดยตรงได้ เครื่องนี้จะรับฟังบน UDP port ที่คุณเลือก และ daemon จะเลือกใช้ก่อน DERP tailscale status ใช้ระบุการเชื่อมต่อประเภทนี้ peer-relay และ tailscale ping แสดง endpoint ของ relay:

pong from device-b (100.97.143.93) via peer-relay(203.0.113.42:40000:vni:1) in 4ms
direct connection not established

อ่านผลลัพธ์นี้อย่างละเอียด การเชื่อมต่อยังไม่ใช่การเชื่อมต่อโดยตรง ดังนั้นการทำงานจึงยังลงท้ายด้วย direct connection not established สิ่งที่เปลี่ยนไปคือเครื่องใดทำหน้าที่ relay VPS ที่มี public IP address และ bandwidth allowance สูง เหมาะสำหรับ relay traffic ของคุณเองมากกว่า DERP node ที่ใช้งานร่วมกัน นี่จึงมีความสำคัญสำหรับผู้ที่เช่าเซิร์ฟเวอร์ ให้เปิดใช้งานบนเครื่องที่มี public endpoint ที่เข้าถึงได้โดยตรง:

sudo tailscale set --relay-server-port=40000

การกำหนด port เป็น 0 จะเลือก port ที่ยังไม่ได้ใช้งานแบบสุ่ม ส่วน empty string จะปิด relay server จากนั้นอนุญาตให้ client device ใช้งาน relay นี้ โดยเพิ่มความสามารถ tailscale.com/cap/relay ในไฟล์ tailnet policy:

{
  "grants": [
    {
      "src": ["tag:us-east-vpc"],
      "dst": ["tag:us-east-relays"],
      "app": {
        "tailscale.com/cap/relay": []
      }
    }
  ]
}

ทั้ง relay device และ client device ต้องใช้ Tailscale 1.86 หรือใหม่กว่า ดังนั้นให้ตรวจสอบด้วย tailscale version บนอุปกรณ์แต่ละเครื่องก่อนใช้เวลานานกับไฟล์ policy ลำดับที่ daemon พยายามใช้งานควรจดจำไว้ daemon จะพยายามเชื่อมต่อโดยตรงก่อน หากไม่สำเร็จ จะค้นหา peer relay ที่ได้รับอนุญาตให้ใช้งาน หากไม่มี จะ fallback ไปใช้ DERP DERP ไม่ได้หายไปจากกระบวนการทั้งหมด เพราะยังเป็นช่องทางที่เครื่องทั้งสองใช้ negotiate กันตั้งแต่แรก

สาเหตุที่ 1: egress firewall ที่บล็อก UDP

Tailscale ระบุสาเหตุ 2 ประการที่ทำให้การเชื่อมต่อยังใช้ relay และสาเหตุแรกคือ UDP ถูกบล็อก ให้ตรวจสอบจากเครื่องโดยตรง:

tailscale netcheck

รายงานถูกตัดไว้ตรงนี้ และ field แรกคือค่าที่ใช้ตัดสินทั้งหมด:

Report:
  * UDP: true
  * IPv4: yes, 203.0.113.9:41641
  * IPv6: no
  * MappingVariesByDestIP: false
  * PortMapping:
  * Nearest DERP: Dallas

UDP: false คือคำตอบทั้งหมดเมื่อพบค่านี้ เครื่องไม่สามารถส่งแพ็กเก็ต UDP ออกไปยัง probe server ของ Tailscale ได้ จึงไม่สามารถสร้างเส้นทางโดยตรง และ daemon จะเปลี่ยนไปใช้ DERP ผ่าน TCP port 443 การ fallback นี้ทำให้เครื่องยังดูเหมือนทำงานปกติ เพราะเครื่องยังเชื่อมต่อได้ ยังเข้าถึงได้ และทุกไบต์ยังถูกส่งผ่าน relay

มี outbound rule ที่ต้องกำหนด 2 รายการ ได้แก่ “อนุญาตให้อุปกรณ์ภายในเริ่มส่ง UDP จาก :41641 ไปยัง *:*” ซึ่งเป็น traffic ของ WireGuard โดยตรง และ “อนุญาตให้อุปกรณ์ภายในเริ่มส่ง UDP ไปยัง *:3478” ซึ่งเป็น STUN (session traversal utilities for NAT) หรือ protocol ที่เครื่องใช้ตรวจสอบ public address และ port ของตนเอง ให้ใช้ wildcard สำหรับปลายทาง Tailscale เพิ่ม relay server อยู่ตลอดเวลา ดังนั้นรายการ address ที่เขียนกำหนดเองจะไม่ถูกต้องภายใน 1 ปี

บนเซิร์ฟเวอร์ที่เช่ามา สาเหตุที่พบบ่อยมักเป็น egress policy ที่เข้มงวดเกินไป ไม่ว่าจะเป็น policy ที่ติดมากับ hardened image หรือ policy ที่ provider บังคับใช้ upstream ให้ตรวจสอบ outgoing policy เริ่มต้นก่อน:

sudo ufw status verbose
sudo nft list ruleset

Default: deny (incoming), allow (outgoing) ใช้งานได้ตามปกติและไม่ใช่ปัญหา ค่า outgoing default เป็น deny พร้อม allow list สั้น ๆ ที่อนุญาตเฉพาะ TCP 443 และ DNS มีลักษณะตรงกับกรณีที่ทำให้เซิร์ฟเวอร์ใช้ relay ตลอดเวลา เพราะเส้นทาง DERP ผ่าน TCP 443 สามารถผ่าน rule นี้ได้ แต่เส้นทางโดยตรงไม่สามารถผ่านได้ ตำแหน่งที่ rule เหล่านี้ถูกใช้งานจริงขึ้นอยู่กับว่า เครื่องใช้ iptables หรือ nftables อยู่เบื้องหลัง และการแก้ไขผิดชุดเป็นสาเหตุทั่วไปที่ทำให้ไม่มีอะไรเปลี่ยนแปลง

ฝั่ง inbound ก็สำคัญเช่นกัน เพราะ VPS มี public IP address จึงอาจเป็นฝั่งที่เชื่อมต่อได้ง่ายของคู่การเชื่อมต่อ หาก firewall ยอมรับ inbound UDP บน port ที่ tailscaled ใช้รับฟังอยู่ peer ที่อยู่หลัง home router ซึ่งมีข้อจำกัดมากสามารถเชื่อมต่อมายังเครื่องได้โดยไม่ต้องใช้วิธีพิเศษ ให้ค้นหา port ที่กำลังใช้งานจริง:

sudo ss -lunp | grep tailscaled
sudo ufw allow 41641/udp

41641 คือ static port เริ่มต้น tailnet ที่เปิดใช้การตั้งค่า randomizeClientPort จะทำให้ client เลือก port แบบสุ่มแทน ในกรณีนี้ให้ใช้หมายเลขจริงจากผลลัพธ์ของ ss ไม่ใช่หมายเลขจากหน้านี้ จากนั้นตรวจสอบ control panel ของ provider ด้วย ผู้ให้บริการส่วนใหญ่มี network firewall ที่แยกจาก firewall ภายในเซิร์ฟเวอร์ และ rule ที่คุณเพิ่มด้วย ufw จะไม่มีผลกับ firewall ดังกล่าว

สาเหตุที่ 2: hard NAT ที่ปลายทางด้านใดด้านหนึ่งหรือทั้งสองด้าน

สาเหตุที่มีการบันทึกไว้เป็นอันดับที่ 2 คือ hard NAT โดย NAT (network address translation) คือการทำงานของเราเตอร์ที่แปลง private address ของคุณเป็น public address เราเตอร์ที่เป็นมิตรจะใช้ public port เดิมสำหรับ socket ภายในหนึ่งรายการ ไม่ว่าคุณจะสื่อสารกับใคร ลักษณะนี้เรียกว่า endpoint independent mapping ส่วน hard NAT จะจัดสรร public port ต่างกันตามปลายทาง ดังนั้น address ที่เครื่องเรียนรู้จาก STUN server จึงไม่ใช่ address ที่ peer จะใช้เชื่อมต่อได้ Tailscale รายงานสถานะนี้ใน netcheck เป็น MappingVariesByDestIP: true

หากมี hard NAT เพียงด้านเดียว ระบบยังทำงานได้ หากอีกด้านมี public endpoint ที่คงที่ เครื่องที่อยู่หลัง hard NAT ยังสามารถเชื่อมต่อเข้าหาอีกด้านได้ และเส้นทางจะถูกสร้างขึ้น กรณีที่ล้มเหลวคือมี hard NAT ทั้งสองด้านพร้อมกัน เพราะแต่ละฝ่ายไม่สามารถคาดเดา port ที่อีกฝ่ายจะปรากฏให้เห็นได้

บน VPS ที่มี public IPv4 address ฟิลด์นี้ควรแสดงค่า false เนื่องจากไม่มีสิ่งใดแปลง address ดังกล่าว หากแสดงค่า true บนเซิร์ฟเวอร์ที่คุณเช่ามา แสดงว่า address กำลังถูกแปลงอยู่ที่ใดที่หนึ่งในเครือข่ายของผู้ให้บริการ และไม่มีกฎ firewall ภายในเครื่องที่จะเปลี่ยนแปลงเรื่องนี้ได้ ทางเลือกคือวาง peer relay บนเครื่องที่มี public endpoint ที่เชื่อมต่อได้โดยตรง หรือย้าย workload กรณีนี้เป็นอีกกรณีที่ การประกาศ private ranges จาก subnet router มีประโยชน์ เพราะคุณต้องมีเส้นทางที่ใช้งานได้ดีเข้าสู่เครือข่ายเพียง 1 เส้นทาง แทนที่จะต้องมีเส้นทางที่ใช้งานได้ดีไปยังอุปกรณ์ทุกเครื่องในเครือข่ายนั้น

เหตุใด exit node จึงทำให้ Tailscale ดูช้ากว่าความเป็นจริง

exit node คือการส่งผ่านอีกหนึ่ง hop และผู้อ่านมักโทษ tunnel เมื่อเลือกใช้ exit node คำขอจะออกจาก laptop ของคุณ วิ่งผ่าน tunnel ไปยัง VPS จากนั้นออกจาก VPS ไปยัง public internet แล้วการตอบกลับจะย้อนกลับมาทางเดิม แม้การเชื่อมต่อไปยัง VPS โดยตรงจะทำงานได้สมบูรณ์ ก็ไม่สามารถทำให้เวลารวมเร็วกว่า uplink ของ VPS เองได้ และระยะทางที่เพิ่มขึ้นจะแสดงให้เห็นในการโหลดทุกหน้า

ให้วัดสองส่วนแยกกัน ปิด exit node แล้วทดสอบ tunnel เพียงอย่างเดียวกับ tailnet address ของ VPS:

sudo tailscale set --exit-node=
sudo apt install -y iperf3
iperf3 -s

เรียกใช้ iperf3 -c 100.113.160.82 จาก client ไปยัง tailnet address นั้น ค่าที่ได้คือ tunnel ของคุณ จากนั้นเปิด exit node อีกครั้งด้วย sudo tailscale set --exit-node=100.113.160.82 แล้วเรียกใช้ speed test ปกติกับ public internet ค่าที่ได้คือ tunnel รวมกับ uplink ของ VPS หากค่าตัวแรกดีแต่ค่าตัวที่สองแย่ Tailscale ไม่ใช่ปัญหา และควรตรวจสอบ เครือข่ายและการจัดสรรทรัพยากรของ exit node เป็นจุดแรก tailscale exit-node list แสดงรายการ node ที่มีให้เลือก หากไม่แน่ใจว่าเลือก node ใดอยู่

CPU เป็นอีกปัจจัยที่กำหนดขีดจำกัดของ exit node แนวทางของ Tailscale คือให้เลือก CPU รุ่นใหม่กว่าที่มี clock speed สูงกว่า แทนการเลือกจำนวน core ที่มากกว่า ดังนั้น plan ที่มี vCPU มากกว่าจึงไม่ได้เร็วกว่าโดยอัตโนมัติ ใน host ที่มีผู้ใช้งานร่วมกันหนาแน่น CPU ที่ผู้ให้บริการระบุไว้ไม่ใช่ CPU ที่คุณได้รับจริง และ steal time จากเพื่อนบ้านที่ใช้ทรัพยากรมาก จะแสดงเป็น throughput ที่เปลี่ยนแปลงไปตามชั่วโมง ทั้งที่ฝั่งของคุณไม่มีการเปลี่ยนแปลง

ค่าปรับแต่งรายการเดียว: rx-udp-gro-forwarding

Tailscale ระบุการตั้งค่า Linux ไว้เพียงรายการเดียว และใช้กับเครื่องที่ forward traffic ได้แก่ exit nodes และ subnet routers เท่านั้น client ทั่วไปจะไม่ได้ประโยชน์จากการตั้งค่านี้ ต้องใช้ Tailscale 1.54 ขึ้นไปและ Linux kernel 6.2 ขึ้นไป ดังนั้นให้ตรวจสอบทั้งสองรายการก่อนเปลี่ยนแปลง:

tailscale version
uname -r

เมื่อพร้อมแล้ว ให้เปิดใช้ UDP GRO (generic receive offload) forwarding บน interface ที่เชื่อมต่อกับอินเทอร์เน็ต:

NETDEV=$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")
sudo ethtool -K $NETDEV rx-udp-gro-forwarding on rx-gro-list off

ตรวจสอบว่าการตั้งค่ามีผล:

ethtool -k $NETDEV | grep -E 'rx-udp-gro-forwarding|rx-gro-list'

ควรเห็น rx-udp-gro-forwarding: on และ rx-gro-list: off การตั้งค่านี้ช่วยได้เพราะ traffic ของ Tailscale เป็น UDP และการให้ kernel รวม UDP packet ขนาดเล็กไว้ตลอดเส้นทางการ forward ทำให้ daemon ต้องจัดการ segment ที่มีขนาดใหญ่ขึ้นและมีจำนวนน้อยลงสำหรับข้อมูลจำนวนไบต์เท่าเดิม ethtool -K จะไม่คงอยู่หลัง reboot จึงต้องทำให้การตั้งค่าคงอยู่ หากระบบใช้ networkd-dispatcher:

printf '#!/bin/sh\n\nethtool -K %s rx-udp-gro-forwarding on rx-gro-list off \n' "$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")" | sudo tee /etc/networkd-dispatcher/routable.d/50-tailscale
sudo chmod 755 /etc/networkd-dispatcher/routable.d/50-tailscale

ให้เรียกใช้ script ด้วยตนเอง 1 ครั้ง และตรวจสอบว่า exit status เป็น 0 นอกจากนี้ forwarding node ต้องเปิดใช้ IP forwarding ตั้งแต่แรกด้วย ซึ่งเป็นการตั้งค่าแยกต่างหากและอาจทำให้เกิดปัญหาแยกกัน:

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

อินเทอร์เฟซ tailscale0 ของคุณใช้ MTU เท่าใด

อย่าเดาค่านี้ ให้ตรวจสอบจากเครื่องโดยตรง:

ip link show tailscale0

ค่า mtu ในผลลัพธ์นั้นคือค่าที่ tunnel ของคุณใช้จริง และมีค่าน้อยกว่า 1500 ซึ่งเป็นค่าที่อินเทอร์เฟซ Ethernet ของคุณรายงาน ค่านี้ตั้งใจให้เป็นเช่นนั้น ไม่ใช่ข้อผิดพลาด ทุก packet ที่ส่งภายใน tunnel จะถูกห่อหุ้มด้วย IP header ด้านนอกขนาด 20 bytes สำหรับ IPv4 หรือ 40 bytes สำหรับ IPv6, UDP header ขนาด 8 bytes และ WireGuard framing กับ authentication tag ขนาด 32 bytes ข้อมูลทั้งหมดต้องมีขนาดพอดีกับความจุของเส้นทางจริง Tailscale จึงเลือกค่าที่ต่ำพอให้ใช้งานได้บนลิงก์ที่รองรับ packet ขนาดไม่ถึง 1500 bytes เต็ม ซึ่งรวมถึงการเชื่อมต่อ PPPoE, เครือข่ายมือถือบางประเภท และ IPv6 tunnel

อาการของปัญหา MTU มีลักษณะเฉพาะ จึงไม่ควรวินิจฉัยจากความช้าเพียงอย่างเดียว SSH ยังตอบสนอง, ping ใช้งานได้ แต่การถ่ายโอนข้อมูลขนาดใหญ่หรือหน้า HTTPS ขนาดใหญ่กลับหยุดค้างทั้งหมด แทนที่จะทำงานช้าลง รูปแบบนี้หมายความว่า packet ที่มีขนาดใหญ่เกินไปถูกทิ้งที่จุดใดจุดหนึ่ง และไม่มี ICMP message ส่งกลับมาแจ้ง sender การเพิ่ม MTU ของ tailscale0 เข้าใกล้ 1500 จะทำให้อาการแย่ลง เพราะ packet ที่ส่งไม่พอดีอยู่แล้วจะมีขนาดใหญ่ขึ้น วิธีแก้ที่ถูกต้องคือ ค้นหา path MTU ที่ใช้งานได้ด้วยการแบ่งช่วงแบบทวิภาค และกำหนด TCP MSS บน router ที่ forward traffic ประเภทการเชื่อมต่อไม่ทำให้เรื่องนี้เปลี่ยนแปลง path ที่ relay และ path ที่เชื่อมต่อโดยตรงใช้ MTU ของอินเทอร์เฟซเดียวกัน

FAQ

ฉันจะทราบได้อย่างไรว่าการเชื่อมต่อ Tailscale เป็นการเชื่อมต่อโดยตรงหรือผ่าน relay?

เรียกใช้ tailscale status แล้วอ่านส่วนท้ายของบรรทัดของ peer ค่า direct 203.0.113.9:41641 หมายถึงการเชื่อมต่อโดยตรง ค่า relay "tor" หมายถึงทุก packet จะถูกส่งผ่านเซิร์ฟเวอร์ DERP ดังกล่าว และค่า peer-relay หมายถึง packet จะถูกส่งผ่านเครื่องใน tailnet ของคุณเอง หากต้องการตรวจสอบอีกวิธี ให้เรียกใช้ tailscale ping <peer>: path ที่ทำงานปกติจะเริ่มต้นด้วย DERP แล้วแสดง pong พร้อม address และ port แบบ plain ส่วน path ที่ผ่าน relay จะแสดง DERP pong ต่อเนื่องจนจบการทำงานด้วย direct connection not established ให้ส่ง traffic ไปยัง peer ก่อน เพราะ Tailscale จะสร้าง path เมื่อมีการใช้งานเท่านั้น

เหตุใด VPS ของฉันจึงไม่เคยเชื่อมต่อโดยตรง?

เรียกใช้ tailscale netcheck บน VPS หากผลลัพธ์เป็น UDP: false แสดงว่า egress firewall กำลังทิ้ง outbound UDP และ daemon ได้เปลี่ยนไปใช้ DERP ผ่าน TCP 443 จึงทำให้เครื่องยังดูเหมือนเชื่อมต่ออยู่ อนุญาต outbound UDP จาก port 41641 ไปยังปลายทางใดก็ได้ และอนุญาต outbound UDP ไปยังปลายทางใดก็ได้ที่ port 3478 ตรวจสอบ network firewall ของ provider รวมถึง firewall ภายในเซิร์ฟเวอร์ด้วย เพราะเป็นการควบคุมคนละส่วนกัน และกฎ ufw จะไม่มีผลต่อ firewall ของ provider

การเชื่อมต่อ Tailscale ผ่าน relay มีความปลอดภัยน้อยกว่าการเชื่อมต่อโดยตรงหรือไม่?

ไม่ เซิร์ฟเวอร์ DERP ทำหน้าที่ส่งต่อ packet ของ WireGuard ที่ไม่สามารถถอดรหัสได้ เพราะ cryptographic key ถูกสร้างบนอุปกรณ์ของคุณและไม่เคยออกจากอุปกรณ์เหล่านั้น ต้นทุนของ relay คือ latency และ throughput ไม่ใช่การสูญเสียความลับ สิ่งที่ coordination server ควบคุมคืออุปกรณ์ใดจะรับรู้ข้อมูลของกันและกัน และควรทำความเข้าใจ ความแตกต่างระหว่าง key material กับ connection metadata ก่อนตัดสินใจว่าจะ self-host ส่วนใดมากน้อยเพียงใด

การตั้งค่า rx-udp-gro-forwarding ช่วยเครื่องทุกประเภทหรือไม่?

ไม่ การตั้งค่านี้มีเอกสารระบุไว้สำหรับเครื่อง Linux ที่ forward traffic ให้เครื่องอื่น ซึ่งหมายถึง exit node และ subnet router laptop หรือเซิร์ฟเวอร์ที่สื่อสารกับ peer ของตนเองเท่านั้นจะไม่ได้รับประโยชน์จากการตั้งค่านี้ นอกจากนี้ยังต้องใช้ Tailscale 1.54 ขึ้นไปและ Linux kernel 6.2 ขึ้นไป ดังนั้นให้ตรวจสอบ tailscale version และ uname -r ก่อน และโปรดจำไว้ว่า ethtool -K จะถูก reset เมื่อ reboot หากไม่ได้ทำให้ค่าคงอยู่ถาวร

Tailscale ช้ากว่า WireGuard แบบ plain หรือไม่?

ทั้งสองใช้ WireGuard เพื่อเข้ารหัส traffic ของคุณ Tailscale เพิ่มขั้นตอนการตั้งค่าการเชื่อมต่อที่ WireGuard แบบ plain ให้คุณจัดการเอง และขั้นตอนนี้เป็นสาเหตุที่บางครั้งการเชื่อมต่อไปลงที่ relay WireGuard แบบ plain ไม่มี relay ให้ไปลง จึงเชื่อมต่อโดยตรงหรือไม่สามารถเชื่อมต่อได้เลย ดังนั้นให้เปรียบเทียบสิ่งที่มีเงื่อนไขเหมือนกัน และทำ benchmark Tailscale เฉพาะเมื่อ tailscale status ระบุว่า direct หากต้องการรุ่นที่ตั้งค่าด้วยตนเองเพื่อใช้เปรียบเทียบ WireGuard server ที่คุณสร้างเอง ใช้ config ประมาณ 40 บรรทัด และรายละเอียดของข้อแลกเปลี่ยนนี้อธิบายไว้ใน การเปรียบเทียบแนวทางทั้งสองแบบ