วิธีเช็ค Tailscale ทำไมช้า: การเชื่อมต่อ Relay vs Direct

เหตุผลที่ Tailscale ทำงานช้า: การส่งผ่าน relay แทนการเชื่อมต่อโดยตรง

Tailscale จะทำงานช้าเมื่อการเชื่อมต่อถูกส่งผ่าน relay แต่จะมีความเร็วใกล้เคียงกับขีดจำกัดของเครือข่ายเมื่อเป็นการเชื่อมต่อโดยตรง การเชื่อมต่อโดยตรงจะส่งแพ็กเก็ต WireGuard ที่เข้ารหัสจากเครื่องหนึ่งไปยังอีกเครื่องหนึ่งโดยตรง จึงทำงานได้เต็มประสิทธิภาพตามความเร็วของอินเทอร์เน็ตทั้งสองฝั่ง ส่วนการเชื่อมต่อแบบ relay จะส่งทุกแพ็กเก็ตผ่านเครื่องที่สามก่อน จึงได้รับผลกระทบจากค่า latency และส่วนแบ่งแบนด์วิดท์ของเครื่องนั้นๆ หน้าประสิทธิภาพของ Tailscale ระบุไว้ชัดเจนว่า "การเชื่อมต่อโดยตรงมักให้ค่า latency ที่ต่ำกว่าและ throughput ที่สูงกว่าเสมอ"

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

คำสั่งสองชุดที่ใช้แยกแยะการเชื่อมต่อแบบตรงและแบบผ่านตัวกลาง

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

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 ตามด้วยที่อยู่และพอร์ต หมายความว่าแพ็กเก็ตกำลังส่งตรงไปยังที่อยู่นั้น ส่วน relay "tor" คือชื่อของ DERP server (designated encrypted relay for packets) ซึ่งเป็นหนึ่งในเครื่อง relay ของ Tailscale และแพ็กเก็ตทุกชุดที่ส่งไปยัง peer นั้นกำลังผ่านเครื่องดังกล่าวอยู่ สำหรับค่าที่สามคือ peer-relay จะอธิบายในหัวข้อถัดไป

tailscale ping device-b

การเชื่อมต่อที่ปกติจะเริ่มต้นด้วยการ relay แล้วจึงเปลี่ยนสถานะ แพ็กเก็ตชุดแรกจะผ่าน DERP server ที่ใกล้ที่สุดในขณะที่เครื่องทั้งสองเจรจากัน จากนั้นเส้นทางจะเปลี่ยนไปโดยอัตโนมัติ:

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 ทุกชุดที่กำหนดไว้แล้วแต่ไม่พบเส้นทางตรง หากต้องการเฝ้าดูเส้นทางแบบ relay ต่อไปแทนที่จะหยุดเมื่อพบเส้นทางตรงชุดแรก ให้รัน tailscale ping --until-direct=false -c 20 device-b แล้วสังเกตค่าความหน่วง (latency) เส้นทางแบบ relay มักจะแสดงตัวเลขที่สูงกว่าและมีความผันผวนมากกว่า เนื่องจากเป็นการเชื่อมต่อผ่านเส้นทางอินเทอร์เน็ตสองเส้นที่มาบรรจบกันที่เครื่องที่คุณไม่สามารถควบคุมได้

What does peer-relay mean in tailscale status?

A peer relay is a machine in your own tailnet that relays traffic for other members when a direct connection is impossible. It listens on a UDP port you choose, and the daemon uses it in preference to DERP. tailscale status marks such a connection peer-relay, and tailscale ping prints the relay's endpoint:

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

Read that carefully. It is still not a direct connection, so the run still ends with direct connection not established. What changed is who is relaying. A VPS with a public IP address and a generous bandwidth allowance is a much better relay for your own traffic than a shared DERP node, which is why this matters to anyone renting a server. Enable it on the machine that has the clean public endpoint:

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

A port of 0 picks a random unused port, and an empty string disables the relay server. Then grant the client devices permission to use it, with the tailscale.com/cap/relay capability in your tailnet policy file:

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

Both the relay device and the client devices need Tailscale 1.86 or later, so check with tailscale version on each before you spend an hour on the policy file. The order the daemon tries is worth memorising. It attempts a direct connection first. If that fails it looks for a peer relay it is allowed to use. If there is none, it falls back to DERP. DERP is never fully out of the picture, because it is also the channel over which the two machines negotiate in the first place.

สาเหตุที่ 1: ไฟร์วอลล์ขาออกบล็อก UDP

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

tailscale netcheck

รายงานจะถูกตัดทอนในส่วนนี้ และฟิลด์ด้านบนสุดคือตัวตัดสินทุกอย่าง:

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

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

มีการระบุถึงกฎขาออกไว้สองข้อ "อนุญาตให้อุปกรณ์ภายในเริ่มการเชื่อมต่อ UDP จาก :41641 ไปยัง *:*" ซึ่งเป็นทราฟฟิกของ WireGuard เอง และ "อนุญาตให้อุปกรณ์ภายในเริ่มการเชื่อมต่อ UDP ไปยัง *:3478" ซึ่งเป็น STUN (session traversal utilities for NAT) ซึ่งเป็นโปรโตคอลที่เครื่องใช้เพื่อเรียนรู้ที่อยู่ IP และพอร์ตสาธารณะของตนเอง ให้ใช้ wildcard สำหรับปลายทาง เนื่องจาก Tailscale มีการเพิ่มเซิร์ฟเวอร์ relay อยู่เรื่อยๆ การเขียนรายการที่อยู่ด้วยมือจะทำให้ข้อมูลผิดพลาดภายในหนึ่งปี

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

sudo ufw status verbose
sudo nft list ruleset

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

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

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

41641 คือพอร์ตคงที่ค่าเริ่มต้น หาก tailnet ของคุณเปิดการตั้งค่า randomizeClientPort ไว้ ไคลเอนต์จะเลือกพอร์ตแบบสุ่มแทน ในกรณีนี้ให้ใช้หมายเลขจริงจากผลลัพธ์ของ ss แทนที่จะใช้ค่าจากหน้านี้ จากนั้นให้ตรวจสอบแผงควบคุมของผู้ให้บริการของคุณ โฮสต์ส่วนใหญ่รันไฟร์วอลล์เครือข่ายที่แยกต่างหากจากไฟร์วอลล์ภายในเซิร์ฟเวอร์ และกฎที่คุณเพิ่มด้วย ufw จะไม่มีผลใดๆ กับไฟร์วอลล์ภายนอกนั้น

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

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

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

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

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

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

ให้วัดผลทั้งสองส่วนแยกกัน ปิดการใช้งาน exit node แล้วทดสอบเฉพาะตัว tunnel เทียบกับที่อยู่ tailnet ของ VPS:

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

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

CPU คืออีกปัจจัยที่จำกัดประสิทธิภาพของ exit node คำแนะนำของ Tailscale คือให้เลือก CPU รุ่นใหม่ที่มีความเร็วสัญญาณนาฬิกาสูงกว่าการเน้นจำนวนคอร์ที่มากกว่า ดังนั้นแผนบริการที่มี vCPU จำนวนมากจึงไม่ได้หมายความว่าจะเร็วกว่าเสมอไป บนโฮสต์แบบแชร์ที่มีการใช้งานหนาแน่น CPU ที่คุณได้รับจริงอาจไม่ใช่ CPU ที่ระบุไว้ในแผน และ steal time จากเพื่อนบ้านที่ใช้งานหนัก จะแสดงออกมาเป็นค่า throughput ที่ผันผวนตามช่วงเวลาโดยที่คุณไม่ได้เปลี่ยนแปลงการตั้งค่าใดๆ เลย

ตัวแปรปรับแต่งเพียงหนึ่งเดียว: rx-udp-gro-forwarding

Tailscale ระบุการตั้งค่า Linux เพียงรายการเดียว ซึ่งมีผลกับเครื่องที่ทำหน้าที่ส่งต่อทราฟฟิก (forwarding) ได้แก่ exit nodes และ subnet routers ส่วนไคลเอนต์ทั่วไปจะไม่ได้รับประโยชน์จากการตั้งค่านี้ โดยจำเป็นต้องใช้ Tailscale เวอร์ชัน 1.54 ขึ้นไป และ Linux kernel เวอร์ชัน 6.2 ขึ้นไป ดังนั้นควรตรวจสอบทั้งสองส่วนก่อนดำเนินการเปลี่ยนแปลงใดๆ:

tailscale version
uname -r

เมื่อตรวจสอบเรียบร้อยแล้ว ให้เปิดใช้งาน UDP GRO (generic receive offload) forwarding บนอินเทอร์เฟซที่เชื่อมต่อกับอินเทอร์เน็ต:

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 เหตุผลที่การตั้งค่านี้ช่วยเพิ่มประสิทธิภาพคือทราฟฟิกของ Tailscale เป็นรูปแบบ UDP การปล่อยให้เคอร์เนลรวมแพ็กเก็ต UDP ขนาดเล็กเข้าด้วยกันตลอดเส้นทางการส่งต่อ (forwarding path) จะช่วยให้ daemon จัดการกับเซกเมนต์ที่มีขนาดใหญ่ขึ้นในจำนวนที่น้อยลงสำหรับปริมาณข้อมูลเท่าเดิม ทั้งนี้ ethtool -K จะไม่คงอยู่หลังการรีบูต ดังนั้นต้องตั้งค่าให้คงอยู่ถาวร สำหรับระบบที่ใช้ 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

รันสคริปต์ด้วยตนเองหนึ่งครั้งและตรวจสอบว่าสถานะการทำงาน (exit status) เป็น 0 สำหรับโหนดที่ทำหน้าที่ส่งต่อทราฟฟิก จำเป็นต้องเปิดใช้งาน 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 ในผลลัพธ์ดังกล่าวคือค่าที่อุโมงค์ของคุณใช้งานจริง ซึ่งต่ำกว่าค่า 1500 ที่อินเทอร์เฟซอีเทอร์เน็ตรายงาน นี่เป็นสิ่งที่ตั้งใจให้เป็นเช่นนั้น ไม่ใช่ข้อผิดพลาด แพ็กเก็ตทุกชุดที่คุณส่งภายในอุโมงค์จะถูกห่อหุ้มไว้: ส่วนหัว IP ภายนอกขนาด 20 ไบต์สำหรับ IPv4 หรือ 40 ไบต์สำหรับ IPv6, ส่วนหัว UDP ขนาด 8 ไบต์ และส่วนการจัดรูปแบบรวมถึงแท็กการยืนยันตัวตนของ WireGuard อีก 32 ไบต์ ข้อมูลทั้งหมดนี้ต้องบรรจุลงในขนาดที่เส้นทางจริงสามารถรองรับได้ Tailscale จึงเลือกค่าที่ต่ำพอที่จะผ่านลิงก์ที่รองรับขนาดแพ็กเก็ตน้อยกว่า 1500 ไบต์ได้ ซึ่งรวมถึงการเชื่อมต่อแบบ PPPoE, เครือข่ายมือถือบางประเภท และอุโมงค์ IPv6

อาการของปัญหา MTU มีลักษณะเฉพาะ ดังนั้นอย่าเพิ่งวินิจฉัยว่าเป็นปัญหา MTU เพียงเพราะความเร็วช้า SSH ยังคงตอบสนองได้ดี ping ทำงานได้ปกติ แต่การถ่ายโอนข้อมูลขนาดใหญ่หรือหน้าเว็บ HTTPS ที่มีขนาดใหญ่กลับค้างไปเลยแทนที่จะทำงานช้าลง รูปแบบดังกล่าวหมายความว่าแพ็กเก็ตที่มีขนาดใหญ่เกินไปถูกทิ้งที่จุดใดจุดหนึ่งโดยไม่มีข้อความ ICMP ส่งกลับมาแจ้งผู้ส่ง การเพิ่มค่า MTU ของ tailscale0 ให้ใกล้เคียง 1500 จะยิ่งทำให้ปัญหาแย่ลง เนื่องจากแพ็กเก็ตที่ไม่สามารถผ่านได้อยู่แล้วจะมีขนาดใหญ่ขึ้น วิธีแก้ไขที่แท้จริงคือการ ค้นหาค่า MTU ของเส้นทางที่ใช้งานได้ด้วยวิธีแบ่งครึ่งช่วง (bisection) และทำการ clamp ค่า TCP MSS บนเราเตอร์ที่ส่งต่อทราฟฟิกนั้น ประเภทของการเชื่อมต่อไม่ได้เปลี่ยนแปลงสิ่งเหล่านี้: ทั้งเส้นทางที่ผ่าน relay และเส้นทางตรงต่างก็ใช้ค่า MTU ของอินเทอร์เฟซเดียวกัน

FAQ

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

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

ทำไม VPS ของฉันถึงไม่เคยเชื่อมต่อแบบ direct ได้เลย?

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

การเชื่อมต่อ Tailscale แบบ relayed มีความปลอดภัยน้อยกว่าแบบ direct หรือไม่?

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

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

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

Tailscale ทำงานช้ากว่า WireGuard แบบปกติหรือไม่?

ทั้งสองอย่างใช้ WireGuard ในการเข้ารหัสข้อมูลของคุณเหมือนกัน Tailscale เพิ่มขั้นตอนการตั้งค่าการเชื่อมต่อที่ WireGuard ปกติปล่อยให้คุณทำเองด้วยมือ ซึ่งขั้นตอนการตั้งค่านี้เองที่บางครั้งทำให้คุณต้องไปใช้ relay ในขณะที่ WireGuard ปกติไม่มี relay ให้ใช้งาน หากเชื่อมต่อโดยตรงไม่ได้ก็จะเชื่อมต่อไม่ได้เลย ดังนั้นควรเปรียบเทียบในสภาวะที่เท่าเทียมกัน และทำการทดสอบ benchmark Tailscale เฉพาะเมื่อ tailscale status แสดงผลเป็น direct เท่านั้น หากคุณต้องการเปรียบเทียบกับเวอร์ชันที่ตั้งค่าด้วยตนเอง การสร้างเซิร์ฟเวอร์ WireGuard ด้วยตัวเอง จะใช้การตั้งค่าประมาณ 40 บรรทัด และคุณสามารถศึกษาข้อแลกเปลี่ยนที่เกิดขึ้นได้ใน การเปรียบเทียบระหว่างสองแนวทางนี้