SSD Nodes Learn Hosting plans →
คู่มือ Matt Connorโดย Matt Connor · อัปเดตเมื่อ 2026-10-15

Tailscale ช้าเพราะใช้ DERP relay หรือไม่ ตรวจสอบอย่างไร

Tailscale ผ่าน DERP relay มักช้ากว่าการเชื่อมต่อโดยตรง ใช้คำสั่ง 2 รายการตรวจสอบ พร้อมวิธีแก้เมื่อ UDP ถูกบล็อกและ VPS อยู่หลัง NAT แบบเข้มงวด

เหตุใด Tailscale จึงช้า: ใช้การเชื่อมต่อแบบ relay แทนการเชื่อมต่อโดยตรง

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

ไม่มีสิ่งใดภายในแอปพลิเคชันของคุณที่แสดงความแตกต่างนี้ การคัดลอกไฟล์จะช้า และเซสชัน SSH จะมีอาการหน่วง ดังนั้นขั้นตอนแรกคือตรวจสอบว่าขณะนี้คุณใช้การเชื่อมต่อประเภทใด คำสั่ง 2 รายการจะตอบเรื่องนี้ได้ภายในเวลาไม่ถึง 1 นาที และขั้นตอนทั้งหมดหลังจากนั้นคือการแก้สาเหตุ ควรทำความเข้าใจส่วนการตั้งค่าก่อนเริ่มดำเนินการ เพราะ เซิร์ฟเวอร์ประสานงานและ data plane ของ WireGuard เป็นระบบแยกจากกัน และมีเพียง 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 ระบุสาเหตุที่การเชื่อมต่อยังคงถูกส่งผ่าน 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 ได้ และคู่มือ CLI ของ Tailscale ระบุว่าในกรณีนี้ "ไม่น่าเป็นไปได้ที่ Tailscale จะสามารถสร้างการเชื่อมต่อแบบ point-to-point ได้" จากนั้นทราฟฟิกจะวิ่งผ่าน DERP บน TCP พอร์ต 443 การสำรองข้อมูล (fallback) นี้เองที่เป็นเหตุผลว่าทำไมเครื่องยังคงดูปกติสมบูรณ์: มันเชื่อมต่อได้ เข้าถึงได้ และทุกไบต์ข้อมูลกำลังถูกส่งผ่าน relay netcheck อธิบายถึงลักษณะเครือข่ายโดยรวมมากกว่าการเชื่อมต่อใดการเชื่อมต่อหนึ่ง ดังนั้นให้ยืนยันเส้นทางที่ peer ใช้งานจริงด้วย tailscale status หรือ tailscale ping ก่อนที่คุณจะเริ่มเปลี่ยนกฎใดๆ

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

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

sudo ufw status verbose
sudo nft list ruleset

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

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

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

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

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

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

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

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

เหตุใด 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 ของฉันเป็นแบบ direct หรือ relayed?

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

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

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

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

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

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

ไม่ การตั้งค่านี้ระบุไว้สำหรับเครื่อง Linux ที่ทำหน้าที่ส่งต่อข้อมูลให้เครื่องอื่น เช่น 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 ที่คุณสร้างเอง จะใช้ config ประมาณ 40 บรรทัด และสิ่งที่คุณต้องแลกเปลี่ยนนั้นได้อธิบายไว้ใน การเปรียบเทียบระหว่างสองแนวทางนี้

บทความนี้มีประโยชน์หรือไม่

#tailscale#networking#performance#nat#wireguard