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

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

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

هیچ بخشی از برنامهٔ شما تفاوت این دو را نشان نمی‌دهد. کپی فایل فقط کند است و نشست SSH فقط دارای تأخیر است. بنابراین اولین وظیفه، تشخیص نوع اتصالی است که در حال حاضر دارید. دو دستور در کمتر از یک دقیقه پاسخ این پرسش را می‌دهند و هر اقدامی پس از آن، برای رفع دلیل کندی است. دانستن بخش راه‌اندازی پیش از شروع کار ضروری است، زیرا سرور هماهنگ‌کننده (coordination server) و صفحه داده (data plane) پروتکل 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 servers) Tailscale ارسال کند. مستندات CLI خودِ Tailscale می‌گوید در این حالت «بعید است Tailscale بتواند اتصالات نقطه-به-نقطه برقرار کند.» در نتیجه، ترافیک از طریق DERP و روی پورت TCP 443 منتقل می‌شود. همین fallback باعث می‌شود دستگاه کاملاً سالم به نظر برسد: متصل است، در دسترس است و تمام بایت‌ها در حال relay شدن هستند. netcheck وضعیت شبکه را توصیف می‌کند، نه یک اتصال خاص؛ بنابراین پیش از تغییر قوانین، مسیری که یک peer واقعاً از آن استفاده می‌کند را با tailscale status یا tailscale ping تأیید کنید.

دو قانون خروجی مستند شده‌اند. «اجازه دهید دستگاه‌های داخلی ترافیک 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 روی آن گوش می‌دهد بپذیرد، peerهایی که پشت روترهای خانگیِ دشوار قرار دارند می‌توانند بدون هیچ ترفندی به آن متصل شوند. پورتی که واقعاً در حال استفاده است را پیدا کنید:

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 سخت قابل‌حل است. اگر سمت دیگر یک endpoint عمومی پایدار داشته باشد، ماشینی که پشت NAT سخت قرار دارد همچنان می‌تواند ارتباط برقرار کند و مسیر شکل می‌گیرد. وجود دو NAT سخت به‌طور همزمان حالتی است که با شکست مواجه می‌شود، زیرا هیچ‌کدام از طرفین نمی‌توانند پورتی که طرف مقابل از آن ظاهر می‌شود را پیش‌بینی کنند.

در یک VPS با آدرس IPv4 عمومی، این فیلد معمولاً باید false باشد. داشتن آدرس عمومی همیشه به این معنی نیست که هیچ ترجمه‌ای صورت نمی‌گیرد: برای مثال، AWS مستند کرده است که gateway اینترنت آن، یک NAT یک‌به‌یک بین آدرس IPv4 عمومی یک instance و آدرس خصوصی آن انجام می‌دهد. یک نگاشت ایستا و یک‌به‌یک از این نوع، پورت را برای هر کسی که با او صحبت می‌کنید ثابت نگه می‌دارد، بنابراین این NAT سخت نیست و فیلد همچنان false را نشان می‌دهد. اگر در سروری که اجاره کرده‌اید مقدار true نمایش داده می‌شود، چیزی در شبکه ارائه‌دهنده در حال اختصاص پورت‌های متفاوت برای مقاصد مختلف است و هیچ قانون فایروالی در داخل ماشین این وضعیت را تغییر نخواهد داد. گزینه‌های شما این است که یک peer relay روی ماشینی که دارای یک endpoint عمومی مناسب است قرار دهید، یا workload را منتقل کنید. این همان حالتی است که تبلیغ محدوده‌های خصوصی از طریق یک 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، تا پایان اجرای دستور فقط pongهای DERP چاپ می‌شوند و در نهایت با direct connection not established خاتمه می‌یابد. ابتدا مقداری ترافیک به سمت peer بفرستید، زیرا Tailscale مسیر را فقط در صورت نیاز ایجاد می‌کند.

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

دستور tailscale netcheck را روی VPS اجرا کنید. اگر خروجی آن UDP: false باشد، یعنی ترافیک خروجی UDP مسدود شده است که معمولاً به دلیل فایروال egress رخ می‌دهد؛ در این حالت Tailscale اعلام می‌کند که برقراری اتصال point-to-point بعید است. با استفاده از tailscale status یا tailscale ping تأیید کنید که peer روی DERP قرار دارد؛ 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 که خودتان می‌سازید حدود چهل خط تنظیمات نیاز دارد و مبادله‌ای که انجام می‌دهید در مقایسه این دو رویکرد پوشش داده شده است.