علت کندی Tailscale: تفاوت اتصال مستقیم و Relay

چرا Tailscale کند است: استفاده از relay به‌جای اتصال مستقیم

زمانی که اتصال از طریق relay برقرار می‌شود، Tailscale کند عمل می‌کند؛ اما در صورت برقراری اتصال مستقیم، سرعت آن به حد نهایی پهنای باند می‌رسد. یک اتصال مستقیم، بسته‌های رمزنگاری‌شده WireGuard را مستقیماً از یک ماشین به ماشین دیگر منتقل می‌کند، بنابراین سرعت آن معادل ظرفیت لینک‌های اینترنت دو طرف است. در مقابل، اتصال relayed ابتدا هر بسته را از طریق یک ماشین سوم ارسال می‌کند، بنابراین تأخیر (latency) آن ماشین و سهمی از پهنای باند آن را به ارث می‌برد. صفحه عملکرد Tailscale این موضوع را در یک جمله خلاصه کرده است: «اتصالات مستقیم تقریباً همیشه منجر به تأخیر کمتر و توان عملیاتی (throughput) بالاتر می‌شوند.»

هیچ بخشی از برنامه شما تفاوت این دو را نشان نمی‌دهد. کپی فایل فقط کند است و نشست SSH فقط دارای تأخیر است. بنابراین اولین وظیفه، تشخیص نوع اتصالی است که در حال حاضر دارید. دو دستور در کمتر از یک دقیقه پاسخ این پرسش را می‌دهند و هر اقدامی پس از آن، برای رفع دلیل کندی است. دانستن بخش راه‌اندازی پیش از شروع کار مفید است، زیرا سرور هماهنگ‌کننده و صفحه داده WireGuard سیستم‌های مجزایی هستند و تنها صفحه داده است که بایت‌های شما را جابه‌جا می‌کند.

دو دستوری که تفاوت اتصال مستقیم و رله‌شده را مشخص می‌کنند

پیش از اندازه‌گیری هر چیزی، مقداری ترافیک به سمت peer بفرستید. Tailscale مسیر را بر اساس تقاضا ایجاد می‌کند؛ بنابراین اگر امروز با یک peer ارتباط نداشته‌اید، ممکن است هنوز مسیری مذاکره نشده باشد و شما در حال خواندن یک پاسخ قدیمی باشید. یک ping یا یک curl به آدرس tailnet آن 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 (مخفف designated encrypted relay for packets) است که یکی از ماشین‌های رله Tailscale محسوب می‌شود و تمام بسته‌های ارسالی به آن peer از طریق آن عبور می‌کنند. مقدار سوم، یعنی peer-relay، در بخش بعدی بررسی می‌شود.

tailscale ping device-b

یک اتصال سالم ابتدا به‌صورت رله‌شده شروع شده و سپس تغییر وضعیت می‌دهد. اولین بسته‌ها از طریق نزدیک‌ترین سرور DERP عبور می‌کنند تا دو ماشین با یکدیگر مذاکره کنند، سپس مسیر در حین کار تغییر می‌کند:

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) که قرار بود ارسال کند را فرستاده و هرگز به یک مسیر مستقیم دست نیافته است. برای اینکه به جای توقف در اولین مسیر مستقیم، همچنان مسیر رله‌شده را زیر نظر داشته باشید، tailscale ping --until-direct=false -c 20 device-b را اجرا کنید و پراکندگی تأخیر (latency spread) را بخوانید. یک مسیر رله‌شده معمولاً اعداد بالاتر و نوسان بیشتری نشان می‌دهد، زیرا از دو مسیر اینترنتی تشکیل شده که در ماشینی که شما کنترلی روی آن ندارید، به هم متصل شده‌اند.

عبارت peer-relay در وضعیت Tailscale به چه معناست؟

یک peer-relay دستگاهی در tailnet اختصاصی شماست که وقتی برقراری اتصال مستقیم غیرممکن باشد، ترافیک را برای سایر اعضا رله می‌کند. این دستگاه روی پورت UDP انتخابی شما گوش می‌دهد و daemon به جای استفاده از DERP، آن را در اولویت قرار می‌دهد. tailscale status چنین اتصالی را علامت‌گذاری می‌کند peer-relay و tailscale ping نقطه پایانی (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

این موضوع را به‌دقت مطالعه کنید. این همچنان یک اتصال مستقیم نیست، بنابراین اجرا همچنان با direct connection not established پایان می‌یابد. آنچه تغییر کرده، هویت رله‌کننده است. یک VPS با IP عمومی و پهنای باند مناسب، رله بسیار بهتری برای ترافیک شما نسبت به یک گره اشتراکی DERP است؛ به همین دلیل این موضوع برای هر کسی که سرور اجاره می‌کند اهمیت دارد. آن را روی دستگاهی که دارای نقطه پایانی عمومی و مناسب است فعال کنید:

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

پورت 0 یک پورت تصادفیِ استفاده‌نشده را انتخاب می‌کند و یک رشته خالی، سرور رله را غیرفعال می‌کند. سپس با استفاده از قابلیت tailscale.com/cap/relay در فایل سیاست (policy file) tailnet خود، به دستگاه‌های کلاینت اجازه استفاده از آن را بدهید:

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

هم دستگاه رله و هم دستگاه‌های کلاینت به Tailscale نسخه 1.86 یا بالاتر نیاز دارند، بنابراین پیش از صرف وقت برای فایل سیاست، نسخه را با tailscale version روی هر کدام بررسی کنید. ترتیب اولویت daemon ارزش به‌خاطر سپردن دارد. ابتدا تلاش می‌کند اتصال مستقیم برقرار کند. اگر این کار با شکست مواجه شود، به دنبال یک peer-relay می‌گردد که اجازه استفاده از آن را داشته باشد. اگر چنین موردی وجود نداشته باشد، به سراغ DERP می‌رود. DERP هرگز به‌طور کامل از چرخه خارج نمی‌شود، زیرا همان کانالی است که دو دستگاه در وهله اول از طریق آن با یکدیگر مذاکره می‌کنند.

دلیل 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 را به سمت سرورهای probe شرکت Tailscale ارسال کند، بنابراین مسیر مستقیمی شکل نمی‌گیرد و daemon به ناچار به DERP روی پورت TCP 443 متوسل می‌شود. همین fallback باعث می‌شود ماشین همچنان کاملاً سالم به نظر برسد: متصل است، در دسترس است و تمام بایت‌ها در حال relay شدن هستند.

دو قانون خروجی مستند شده‌اند. «اجازه دهید دستگاه‌های داخلی شما ترافیک UDP را از :41641 به *:* آغاز کنند» که همان ترافیک WireGuard است، و «اجازه دهید دستگاه‌های داخلی شما ترافیک UDP را به *:3478 آغاز کنند» که مربوط به STUN (ابزارهای پیمایش نشست برای NAT) است؛ پروتکلی که ماشین برای یادگیری آدرس عمومی و پورت خود از آن استفاده می‌کند. برای مقاصد از wildcard استفاده کنید. Tailscale به‌مرور زمان سرورهای relay جدیدی اضافه می‌کند و لیست دستی آدرس‌ها ظرف یک سال اشتباه خواهد بود.

در سرورهای اجاره‌ای، مقصر معمولاً یک سیاست خروجی سخت‌گیرانه است؛ یا سیاستی که در یک image امنیتی (hardened) به ارث برده‌اید یا سیاستی که ارائه‌دهنده شما در لایه بالاتر اعمال کرده است. ابتدا سیاست پیش‌فرض خروجی را بررسی کنید:

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 روی آن گوش می‌دهد بپذیرد، همتایان (peers) پشت روترهای خانگیِ پیچیده می‌توانند بدون هیچ ترفندی به آن متصل شوند. پورتی که در حال حاضر استفاده می‌شود را پیدا کنید:

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

41641 پورت استاتیک پیش‌فرض است. یک tailnet با تنظیم randomizeClientPort فعال، باعث می‌شود کلاینت‌ها یک پورت تصادفی انتخاب کنند؛ در این صورت عدد واقعی را از خروجی ss بردارید، نه از این صفحه. سپس پنل کنترل ارائه‌دهنده خود را بررسی کنید. اکثر میزبان‌ها یک فایروال شبکه دارند که از فایروال داخل سرور جداست و قانونی که با ufw اضافه کرده‌اید، هیچ تأثیری بر آن ندارد.

علت 2: NAT سخت در یک یا هر دو سمت

دومین علت مستندشده، NAT سخت است. NAT (ترجمه آدرس شبکه) کاری است که روتر هنگام بازنویسی آدرس خصوصی شما به آدرس عمومی انجام می‌دهد. یک روتر منعطف، برای یک سوکت داخلی مشخص، فارغ از اینکه با چه کسی صحبت می‌کنید، همان پورت عمومی را حفظ می‌کند که به آن نگاشت مستقل از نقطه پایانی (endpoint independent mapping) گفته می‌شود. یک NAT سخت به ازای هر مقصد، یک پورت عمومی متفاوت اختصاص می‌دهد؛ بنابراین آدرسی که دستگاه از یک سرور STUN یاد گرفته است، همان آدرسی نیست که همتا (peer) بتواند از آن استفاده کند. Tailscale این وضعیت را در netcheck به صورت MappingVariesByDestIP: true گزارش می‌دهد.

وجود یک NAT سخت قابل مدیریت است. اگر سمت دیگر یک نقطه پایانی عمومی پایدار داشته باشد، دستگاه پشت NAT سخت همچنان می‌تواند به آن متصل شود و مسیر شکل می‌گیرد. وجود دو NAT سخت به‌طور همزمان باعث شکست ارتباط می‌شود، زیرا هیچ‌کدام از طرفین نمی‌توانند پورتی که طرف مقابل از طریق آن ظاهر می‌شود را پیش‌بینی کنند.

در یک VPS با آدرس IPv4 عمومی، این فیلد باید false را نشان دهد، زیرا هیچ‌چیز آن آدرس را ترجمه نمی‌کند. اگر در سروری که اجاره کرده‌اید مقدار true نمایش داده می‌شود، آدرس در جایی از شبکه ارائه‌دهنده در حال ترجمه است و هیچ قانون فایروالی در داخل دستگاه نمی‌تواند آن را تغییر دهد. گزینه‌های شما این است که یک peer relay روی دستگاهی که نقطه پایانی عمومی تمیز دارد قرار دهید یا بار کاری را منتقل کنید. این همان موردی است که تبلیغ محدوده‌های خصوصی از طریق یک subnet router در آن سودمند است، زیرا در این حالت به‌جای نیاز به یک مسیر خوب به تک‌تک دستگاه‌ها، تنها به یک مسیر مناسب به داخل شبکه نیاز دارید.

چرا استفاده از exit node باعث می‌شود Tailscale کندتر از حد واقعی به نظر برسد

یک exit node در واقع یک گام (hop) دوم است و کاربران معمولاً تونل را مقصر این کندی می‌دانند. وقتی یک exit node انتخاب می‌کنید، درخواست از لپ‌تاپ شما خارج شده، از طریق تونل به VPS می‌رسد، از VPS به اینترنت عمومی ارسال می‌شود و پاسخ نیز همین مسیر را بازمی‌گردد. حتی یک اتصال کاملاً مستقیم به آن VPS هم نمی‌تواند سرعت کل را از پهنای باند آپلینک خودِ VPS بیشتر کند و این مسافت اضافه در زمان بارگذاری هر صفحه خود را نشان می‌دهد.

این دو بخش را جداگانه اندازه‌گیری کنید. exit node را خاموش کنید و سپس تونل را به‌تنهایی با استفاده از آدرس tailnet مربوط به VPS تست کنید:

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

دستور iperf3 -c 100.113.160.82 را از سمت کلاینت روی آن آدرس tailnet اجرا کنید. عددی که به دست می‌آید، سرعت تونل شماست. حالا exit node را با sudo tailscale set --exit-node=100.113.160.82 دوباره روشن کنید و یک تست سرعت معمولی به سمت اینترنت عمومی انجام دهید. آن عدد، حاصل تونل به‌علاوه آپلینک VPS است. اگر عدد اول خوب و عدد دوم بد است، مشکل از Tailscale نیست و باید شبکه و ظرفیت خودِ exit node را بررسی کنید. دستور tailscale exit-node list نشان می‌دهد اگر مطمئن نیستید کدام نود را انتخاب کرده‌اید، چه گزینه‌هایی در دسترس هستند.

CPU نیمه دیگر محدودیت عملکرد یک exit node است. توصیه Tailscale این است که نسل‌های جدیدتر CPU با فرکانس بالاتر را به تعداد هسته‌های بیشتر ترجیح دهید؛ بنابراین، پلنی که vCPU بیشتری دارد لزوماً در اینجا سریع‌تر نیست. در یک هاست اشتراکی شلوغ، CPU که به شما وعده داده شده همان CPU واقعی نیست که دریافت می‌کنید و steal time از یک همسایه پرمصرف (noisy neighbour) به شکل نوسان در پهنای باند در ساعات مختلف، بدون هیچ تغییری از سمت شما، ظاهر می‌شود.

تنظیم کلیدی: rx-udp-gro-forwarding

Tailscale یک تنظیم واحد در لینوکس را معرفی می‌کند که برای ماشین‌هایی که ترافیک را فوروارد می‌کنند، یعنی exit nodeها و subnet routerها، کاربرد دارد. یک کلاینت معمولی از این قابلیت بهره‌ای نمی‌برد. این تنظیم به Tailscale نسخه 1.54 یا بالاتر و هسته لینوکس نسخه 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 در طول مسیر فورواردینگ، باعث می‌شود 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

اسکریپت را یک‌بار به‌صورت دستی اجرا کنید و بررسی کنید که وضعیت خروجی آن 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 که رابط اترنت گزارش می‌دهد، کمتر است. این موضوع عمدی است و یک باگ محسوب نمی‌شود. هر بسته‌ای که داخل تونل ارسال می‌کنید، بسته‌بندی (wrap) می‌شود: یک هدر IP خارجی به اندازه 20 بایت برای IPv4 یا 40 بایت برای IPv6، یک هدر UDP به اندازه 8 بایت، و فریم‌بندی WireGuard به همراه تگ احراز هویت به اندازه 32 بایت. تمام این موارد باید درون ظرفیتی جای بگیرند که مسیر واقعی قادر به حمل آن است. Tailscale مقداری را انتخاب می‌کند که به اندازه کافی کوچک باشد تا از لینک‌هایی که ظرفیت کمتر از یک بسته کامل 1500 بایتی دارند عبور کند؛ این شامل اتصالات PPPoE، برخی شبکه‌های موبایل و تونل‌های IPv6 می‌شود.

نشانه مشکل MTU خاص است، بنابراین آن را صرفاً بر اساس کندی تشخیص ندهید. SSH پاسخگو است، ping کار می‌کند، اما انتقال‌های حجیم یا صفحات بزرگ HTTPS به جای کند اجرا شدن، کاملاً متوقف می‌شوند. این الگو به این معناست که بسته‌های بیش از حد بزرگ در جایی حذف می‌شوند بدون اینکه پیام ICMP برای اطلاع‌رسانی به فرستنده بازگردد. افزایش MTU در tailscale0 به سمت 1500 وضعیت را بدتر می‌کند، زیرا بسته‌هایی که هم‌اکنون نیز جا نمی‌شوند، بزرگ‌تر خواهند شد. راه حل واقعی این است که مسیر MTU کاری را از طریق روش نصف کردن (bisection) پیدا کنید و TCP MSS را روی روتری که ترافیک را هدایت می‌کند، محدود (clamp) کنید. نوع اتصال هیچ‌کدام از این موارد را تغییر نمی‌دهد: مسیر رله‌شده (relayed) و مسیر مستقیم، از MTU رابط یکسانی استفاده می‌کنند.

FAQ

چگونه بفهمم اتصال Tailscale من مستقیم است یا از طریق relay؟

دستور tailscale status را اجرا کنید و انتهای خط مربوط به peer را بخوانید. عبارت direct 203.0.113.9:41641 به معنای اتصال مستقیم است، relay "tor" یعنی تمام بسته‌ها از طریق آن سرور DERP عبور می‌کنند و peer-relay نشان می‌دهد که بسته‌ها از طریق دستگاهی در tailnet خودتان منتقل می‌شوند. برای اطمینان بیشتر، tailscale ping <peer> را اجرا کنید: یک مسیر سالم با DERP شروع می‌شود و سپس یک pong با آدرس و پورت مشخص چاپ می‌کند، در حالی که مسیر relayed تا پایان اجرا فقط DERP pong چاپ می‌کند و در نهایت با direct connection not established تمام می‌شود. ابتدا مقداری ترافیک به سمت peer بفرستید، زیرا Tailscale مسیر را فقط در صورت نیاز ایجاد می‌کند.

چرا VPS من هرگز اتصال مستقیم برقرار نمی‌کند؟

دستور tailscale netcheck را روی VPS اجرا کنید. اگر خروجی UDP: false را نشان داد، یک فایروال خروجی (egress) در حال مسدود کردن UDP است و daemon به ناچار به DERP روی پورت TCP 443 بازگشته است؛ به همین دلیل دستگاه همچنان متصل به نظر می‌رسد. ترافیک خروجی UDP از پورت 41641 به هر مقصدی و ترافیک خروجی UDP به هر مقصدی روی پورت 3478 را مجاز کنید. فایروال شبکهٔ ارائه‌دهندهٔ خود و همچنین فایروال داخل سرور را بررسی کنید، زیرا این‌ها کنترل‌های مجزایی هستند و یک قانون ufw روی تنظیمات ارائه‌دهنده تأثیری ندارد.

آیا اتصال relayed در Tailscale نسبت به اتصال مستقیم امنیت کمتری دارد؟

خیر. سرور DERP بسته‌های WireGuard را که قادر به رمزگشایی آن‌ها نیست، فقط فوروارد می‌کند؛ زیرا کلیدهای رمزنگاری روی دستگاه‌های شما تولید می‌شوند و هرگز از آن‌ها خارج نمی‌شوند. هزینهٔ استفاده از relay، تأخیر (latency) و پهنای باند است، نه محرمانگی. آنچه سرور هماهنگ‌کننده (coordination server) کنترل می‌کند این است که کدام دستگاه‌ها از وجود یکدیگر مطلع شوند، و تفکیک بین مواد کلید و متادیتای اتصال موضوعی است که پیش از تصمیم‌گیری برای self-host کردن آن، ارزش درک کردن دارد.

آیا تنظیم rx-udp-gro-forwarding برای همهٔ دستگاه‌ها مفید است؟

خیر. این تنظیم برای ماشین‌های لینوکسی مستند شده است که ترافیک را برای دیگران فوروارد می‌کنند، یعنی exit nodeها و subnet routerها. لپ‌تاپ یا سروری که فقط با peerهای خود صحبت می‌کند، هیچ سودی از آن نمی‌برد. این تنظیم همچنین به Tailscale نسخه 1.54 یا بالاتر و هسته لینوکس 6.2 یا بالاتر نیاز دارد، بنابراین ابتدا tailscale version و uname -r را بررسی کنید و به یاد داشته باشید که ethtool -K پس از reboot بازنشانی می‌شود مگر اینکه آن را دائمی کنید.

آیا Tailscale از WireGuard معمولی کندتر است؟

هر دو از WireGuard برای رمزنگاری ترافیک شما استفاده می‌کنند. Tailscale تنظیمات اتصال را اضافه می‌کند که در WireGuard معمولی باید به‌صورت دستی انجام دهید، و همین تنظیمات است که گاهی شما را به سمت relay می‌برد. WireGuard معمولی هیچ relay ندارد: یا مستقیماً متصل می‌شود یا اصلاً متصل نمی‌شود. بنابراین موارد مشابه را با هم مقایسه کنید و Tailscale را فقط زمانی بنچمارک بگیرید که tailscale status وضعیت direct را نشان دهد. اگر برای مقایسه به نسخهٔ دستی نیاز دارید، یک سرور WireGuard که خودتان می‌سازید حدود چهل خط پیکربندی نیاز دارد و معامله‌ای که انجام می‌دهید در مقایسه این دو رویکرد پوشش داده شده است.