Tailscale چیست و چگونه کار می‌کند؟

Tailscale چیست؟

Tailscale یک VPN است که ماشین‌های شما را مستقیماً به یکدیگر متصل می‌کند، به‌جای اینکه تمام ترافیک را از طریق یک gateway که شما مدیریت می‌کنید، عبور دهد. هر گره (node) از WireGuard استفاده می‌کند، بنابراین بسته‌ها به‌صورت رمزنگاری‌شده از یک سرور به سرور دیگر منتقل می‌شوند و هیچ‌چیز در مسیر نمی‌تواند آن‌ها را بخواند. یک سرور هماهنگ‌کننده (coordination server) میزبانی‌شده، وظیفه معرفی گره‌ها به یکدیگر را بر عهده دارد. این سرور کلیدهای عمومی را ذخیره و توزیع می‌کند و به هر گره می‌گوید که سایر گره‌ها کجا هستند. همچنین قوانین دسترسی که شما نوشته‌اید را به گره‌ها ابلاغ می‌کند.

این تفکیک، کل طراحی سیستم است. صفحه داده (data plane) به‌صورت همتا‌به‌همتا (peer to peer) و رمزنگاری‌شده بین گره‌ها عمل می‌کند. صفحه کنترل (control plane) سرویسی است که Tailscale برای شما اجرا می‌کند. هر پرسش مهمی درباره Tailscale، از جمله موارد حساس مربوط به اعتماد، از همین دو واقعیت ناشی می‌شود. اگر قبلاً یک VPN مبتنی بر WireGuard به‌صورت دستی روی یک VPS راه‌اندازی کرده‌اید، Tailscale همان تونل است با این تفاوت که توزیع کلیدها و عبور از فایروال به‌صورت خودکار برای شما انجام می‌شود.

Tailscale چگونه کار می‌کند؟

شبکه خصوصی گره‌های شما tailnet نامیده می‌شود. هنگامی که یک ماشین به این شبکه می‌پیوندد، چهار اتفاق رخ می‌دهد:

1. دیمون tailscaled اجرا می‌شود، یک جفت کلید WireGuard تولید می‌کند و وضعیت خود را در /var/lib/tailscale/tailscaled.state نگه می‌دارد. کلید خصوصی هرگز از آن ماشین خارج نمی‌شود. عبارت‌پردازی خود Tailscale صریح است: «کلید خصوصی هرگز و تحت هیچ شرایطی گره خود را ترک نمی‌کند.»
2. گره به سرور هماهنگ‌کننده (coordination server) وارد می‌شود و کلید عمومی خود را به همراه آدرس‌هایی که تصور می‌کند از طریق آن‌ها در دسترس است، آپلود می‌کند. Tailscale این سرور را «یک صندوق اشتراکی برای کلیدهای عمومی» توصیف می‌کند.
3. سرور هماهنگ‌کننده یک نقشه شبکه را بازمی‌گرداند: کلید عمومی، آدرس tailnet، نام ماشین و نقاط پایانی (endpoints) کاندید برای هر گره‌ای که این گره اجازه دسترسی به آن را دارد.
4. سپس هر جفت از گره‌ها تلاش می‌کنند یک تونل مستقیم WireGuard بین خود ایجاد کنند. هنگامی که این کار با شکست مواجه شود، بسته‌ها را از طریق یک رله (relay) ارسال می‌کنند.

هر گره یک آدرس پایدار از محدوده 100.64.0.0/10 دریافت می‌کند؛ این محدوده NAT در سطح اپراتور است که از 100.64.0.0 تا 100.127.255.255 ادامه دارد. Tailscale از این محدوده استفاده می‌کند زیرا برای زیرساخت‌های ارائه‌دهندگان رزرو شده است و به همین دلیل به‌ندرت با آدرس‌های خصوصی که سرورهای شما در حال حاضر استفاده می‌کنند، تداخل پیدا می‌کند. در لینوکس، این تونل به عنوان یک اینترفیس با نام tailscale0 ظاهر می‌شود.

پیاده‌سازی WireGuard در داخل tailscaled و در فضای کاربری (userspace) قرار دارد، نه در ماژول هسته (kernel module). به همین دلیل است که Tailscale روی مجازی‌سازی کانتینری که در آن sudo modprobe wireguard با خطای Operation not supported مواجه می‌شود، اجرا می‌گردد. این همچنین بدان معناست که سقف پهنای باند در یک ماشین مشخص، پایین‌تر از WireGuard در سطح هسته است؛ این یکی از مواردی است که در مقایسه Tailscale با WireGuard ساده به آن پرداخته شده است.

دو دستور وضعیت فعلی شما را مشخص می‌کنند.

tailscale ip -4
tailscale status

دستور tailscale status برای هر گره یک خط چاپ می‌کند و ستون آخر همان چیزی است که اهمیت دارد.

100.101.102.103  web-1      you@  linux  -
100.101.102.104  db-1       you@  linux  active; direct 198.51.100.24:41641
100.101.102.105  ci-runner  you@  linux  active; relay "fra"

خروجی direct به همراه یک آدرس و پورت به این معنی است که دو ماشین مسیری به یکدیگر پیدا کرده‌اند و ترافیک به صورت peer-to-peer است. relay "fra" به این معنی است که ترافیک از طریق یک رله Tailscale در فرانکفورت عبور می‌کند. عبارت - به این معنی است که در حال حاضر هیچ نشست فعالی با آن گره وجود ندارد که امری عادی است.

آنچه سرور هماهنگ‌کننده می‌تواند و نمی‌تواند ببیند

سرور هماهنگ‌کننده (coordination server) کلیدهای عمومی و متادیتا را نگهداری می‌کند. این سرور نام ماشین‌های شما، اینکه کدام کاربر یا تگ مالک هر گره (node) است، آدرس tailnet هر گره، آدرس‌های عمومی که گره‌های شما از طریق آن‌ها در دسترس هستند، زمان آخرین آنلاین بودن هر گره و فایل سیاستی (policy file) که نوشته‌اید را می‌داند. این اطلاعات، نقشه‌ای کامل از کل ناوگان شماست.

این سرور هیچ کلید خصوصی‌ای در اختیار ندارد، بنابراین نمی‌تواند ترافیک بین دو گره را رمزگشایی کند. رمزنگاری به‌صورت سرتاسری (end-to-end) بین همتایان WireGuard انجام می‌شود و سرور هماهنگ‌کننده یک همتا (peer) محسوب نمی‌شود.

آنچه این سرور می‌تواند انجام دهد، توزیع کلیدهاست. هر سرور هماهنگ‌کننده‌ای، چه میزبانی‌شده و چه خود-میزبان (self-run)، مورد اعتماد است تا به گره‌های شما بگوید کدام کلیدهای عمومی متعلق به tailnet هستند. این نقطه، محور اصلی مدل تهدید در ادامه است و دلیلی است که Headscale، یک سرور هماهنگ‌کننده متن‌باز که خودتان میزبانی می‌کنید وجود دارد.

نحوه ارتباط مستقیم دو سرور پشت فایروال‌های مختلف

NAT (ترجمه آدرس شبکه) قابلیتی است که به چندین دستگاه اجازه می‌دهد از یک آدرس عمومی مشترک استفاده کنند. سرور VPS شما معمولاً دارای یک آدرس عمومی اختصاصی است، اما سایر دستگاه‌هایی که می‌خواهید در tailnet قرار دهید اغلب فاقد آن هستند: مانند یک سرور خانگی، یک build runner در شبکه اداری، یا سیستمی که پشت فایروال ارائه‌دهنده خدمات قرار دارد و امکان تغییر تنظیمات آن را ندارید.

Tailscale با استفاده از تکنیک‌های مبتنی بر استانداردهای STUN (ابزارهای پیمایش نشست برای NAT) و ICE، مسیری را پیدا می‌کند. هر گره یک بسته UDP کوچک به یک سرور STUN ارسال می‌کند و آدرس عمومی و پورتی که روتر به آن سوکت اختصاص داده است را شناسایی می‌کند. هر دو گره این کاندیداها را به سرور هماهنگ‌کننده گزارش می‌دهند و سرور آن‌ها را به طرف مقابل منتقل می‌کند. سپس هر دو گره به‌طور هم‌زمان شروع به ارسال بسته به یکدیگر می‌کنند. هر روتر ابتدا یک بسته خروجی را مشاهده می‌کند، بنابراین یک نگاشت (mapping) ایجاد کرده و پاسخ دریافتی از همان آدرس را می‌پذیرد. در این حالت، هیچ‌کدام از طرفین نیازی به ایجاد قانون فایروال ورودی (inbound) ندارند.

پورت‌ها مشخص هستند. تونل‌های مستقیم WireGuard از پروتکل UDP با پورت مبدأ پیش‌فرض 41641 استفاده می‌کنند. STUN روی پورت UDP 3478 با سرورهای رله Tailscale ارتباط برقرار می‌کند. اتصال کنترل و هرگونه داده رله‌شده از HTTPS روی پورت TCP 443 استفاده می‌کنند. در بیشتر مواقع نیازی به باز کردن هیچ پورت ورودی ندارید، اگرچه در شبکه‌هایی با NAT پیچیده، اجازه دادن به ترافیک ورودی UDP 41641 احتمال برقراری اتصال مستقیم را افزایش می‌دهد.

tailscale netcheck

دو خط از آن گزارش را بخوانید. UDP: true به این معنی است که ترافیک UDP از دستگاه خارج می‌شود و UDP: false به این معنی است که تمام اتصالات از این گره رله (relayed) خواهند شد. MappingVariesByDestIP: true به این معنی است که روتر برای هر مقصد یک پورت عمومی متفاوت اختصاص می‌دهد، بنابراین پیش‌بینی آدرس که در بالا ذکر شد کارساز نیست و آن گره‌ها معمولاً در حالت رله باقی می‌مانند.

زمانی که Tailscale از یک DERP relay استفاده می‌کند

DERP (مخفف designated encrypted relay for packets) راهکار جایگزین (fallback) است. Tailscale در مناطق بسیاری رله‌هایی را اجرا می‌کند که از طریق پورت TCP 443 در دسترس هستند؛ هر گره‌ای که نتواند مسیر مستقیمی پیدا کند، بسته‌های WireGuard خود را از طریق یکی از این رله‌ها ارسال می‌کند.

بسته‌ها همچنان رمزگذاری‌شده باقی می‌مانند. Tailscale این موضوع را به‌صراحت بیان می‌کند: «هیچ راهی برای سرور DERP جهت رمزگشایی ترافیک شما وجود ندارد. این سرور صرفاً ترافیکِ از پیش رمزگذاری‌شده را به‌صورت کورکورانه از یک گره به گره دیگر هدایت می‌کند.» رله فقط متن رمزگذاری‌شده (ciphertext) را می‌بیند و متوجه می‌شود که کدام گره با کدام گره در حال تبادل اطلاعات است.

رله‌ها همچنین اولین بسته‌های اکثر اتصالات را منتقل می‌کنند. یافتن مسیر مستقیم لحظاتی زمان می‌برد، بنابراین یک نشست اغلب به‌صورت رله‌شده آغاز می‌شود و پس از آنکه دو گره یکدیگر را پیدا کردند، به مسیر مستقیم ارتقا می‌یابد. شما می‌توانید این فرآیند را مشاهده کنید.

tailscale ping db-1

اولین پاسخ‌ها با via DERP(fra) برمی‌گردند، سپس خط بعدی چیزی شبیه به via 198.51.100.24:41641 را گزارش می‌دهد. این تغییر، همان ارتقا به تونل مستقیم است. اگر این وضعیت هرگز تغییر نکرد، دستور tailscale netcheck را در هر دو سمت اجرا کنید. مسیر رله‌شده همچنان کار می‌کند. این کار باعث افزایش تأخیر (latency) می‌شود، زیرا هر بسته مسیر اضافه‌ای را از طریق یک ماشین سوم طی می‌کند. اگر آنچه متوجه شده‌اید انتقال کند داده‌هاست و نه قطع بودن اتصال، دلیل کندتر بودن اتصال رله‌شده Tailscale نسبت به اتصال مستقیم این اختلاف را اندازه‌گیری کرده و نشان می‌دهد که چگونه می‌توان یک VPS را در مسیر مستقیم قرار داد.

اتصال یک VPS به tailnet

اسکریپت نصب، توزیع‌های Ubuntu و Debian را پوشش می‌دهد.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

sudo tailscale up یک URL چاپ می‌کند. آن را باز کرده و احراز هویت کنید تا node در کنسول مدیریتی شما ظاهر شود. سپس اطمینان حاصل کنید که daemon پس از reboot دوباره بالا می‌آید، زیرا این مرحله‌ای است که کاربران اغلب فراموش می‌کنند.

sudo systemctl is-enabled tailscaled
tailscale status

is-enabled باید enabled را چاپ کند و tailscale status باید node جدید را به همراه آدرس 100.x آن فهرست نماید. برای سروری که با اسکریپت ساخته شده، URL تعاملی کاربردی ندارد. یک auth key در کنسول مدیریتی ایجاد کنید و آن را به همراه یک tag که نوع ماشین را مشخص می‌کند، ارسال نمایید.

sudo tailscale up --auth-key=tskey-auth-REPLACE-ME --advertise-tags=tag:server

یک node برچسب‌گذاری شده (tagged) متعلق به آن tag است، نه شخصی که دستور را اجرا کرده است؛ بنابراین پس از حذف حساب کاربری آن شخص، همچنان به کار خود ادامه می‌دهد. این tag باید ابتدا در فایل policy شما تحت tagOwners تعریف شده باشد، در غیر این صورت دستور رد می‌شود. برچسب‌گذاری همچنین نحوه محاسبه تعداد ماشین‌ها در طرح اشتراکی شما را تغییر می‌دهد، زیرا منابع برچسب‌گذاری شده جدا از دستگاه‌های شخصی محاسبه می‌شوند و آنچه طرح رایگان واقعاً پوشش می‌دهد محدودیت‌های مربوطه را مشخص می‌کند.

دو تنظیم برای مدیریت ناوگان سرورها اهمیت دارد. کلیدهای node به‌صورت پیش‌فرض پس از 180 روز منقضی می‌شوند (از اوت 2026)، و هنگامی که کلیدی منقضی شود، «اتصالات به/از آن endpoint متوقف خواهد شد» تا زمانی که شخصی دوباره لاگین کند؛ بنابراین ردیف مربوط به ماشین را در کنسول مدیریتی باز کرده و گزینه Disable Key Expiry را برای سرورهای بدون نظارت (unattended) انتخاب کنید. قابلیت MagicDNS که به‌صورت پیش‌فرض برای tailnetهای ایجاد شده در تاریخ 20 اکتبر 2022 یا پس از آن فعال است، به هر node نامی مانند db-1.yak-bebop.ts.net می‌دهد که توسط یک stub resolver در 100.100.100.100 ترجمه (resolve) می‌شود. از نام‌ها به جای آدرس‌ها استفاده کنید، زیرا node بازسازی‌شده آدرس جدیدی می‌گیرد اما نام خود را حفظ می‌کند.

اگر فرآیند نصب در مرحله apt یا مخازن با خطا مواجه شد، خطاهای رایج نصب Tailscale در Ubuntu راه‌حل‌های مربوطه را پوشش می‌دهد.

دسترسی به سرویسی که روی localhost محدود شده است

اینجاست که tailnet مفید واقع می‌شود و جایی است که کاربران معمولاً با مشکل مواجه می‌شوند. پیوستن به tailnet باعث نمی‌شود سرویسی که روی loopback قرار دارد، قابل دسترس شود.

ss -tlnp | grep 3000

اگر این دستور 127.0.0.1:3000 را چاپ کند، یعنی سوکت فقط بسته‌هایی را می‌پذیرد که مقصد آن‌ها 127.0.0.1 باشد. درخواستی که از یک گره (node) دیگر می‌رسد، با آدرس 100.x این گره خطاب شده است؛ بنابراین هسته سیستم‌عامل هیچ گوش‌دهنده‌ای برای آن ندارد و با یک TCP reset پاسخ می‌دهد. کلاینت پیام Connection refused را گزارش می‌کند. تونل سالم است، اما listener مشکل دارد.

دو راه حل اصولی وجود دارد. سرویس را روی آدرس tailnet گره bind کنید؛ این کار باعث می‌شود سرویس بدون نیاز به پروکسی، از رابط عمومی (public interface) دور بماند: مقدار --bind 100.101.102.104 یا گزینه معادل آن را در پیکربندی خود وارد کنید و برای کانتینر، پورت را به صورت -p 100.101.102.104:3000:3000 منتشر کنید. یا سرویس را روی loopback باقی بگذارید و Tailscale را جلوی آن قرار دهید.

tailscale serve 3000

این کار درخواست‌ها را به http://127.0.0.1:3000 پروکسی می‌کند و پس از فعال‌سازی گواهی‌های HTTPS برای tailnet، آن‌ها را در شبکه داخلی شما با نام ts.net و از طریق HTTPS ارائه می‌دهد. این سرویس برای گره‌های شما خصوصی باقی می‌ماند. نسخه عمومی همین ایده، Funnel است و Tailscale serve در مقابل funnel توضیح می‌دهد که کدام‌یک برای نیاز شما مناسب‌تر است.

دو وظیفه مرتبط دیگر صفحات خاص خود را دارند. دسترسی به یک شبکه خصوصی کامل که Tailscale روی آن نصب نیست، نیازمند یک subnet router روی یک VPS است و هدایت ترافیک اینترنت خروجی یک گره از طریق گره‌ای دیگر، نیازمند یک exit node است.

بستن پورت‌هایی که دیگر به آن‌ها نیاز ندارید

هنگامی که هر مدیر سیستم از طریق tailnet به سرور دسترسی پیدا می‌کند، پورت عمومی 22 دیگر کاربردی ندارد. این همان مزیت عملی است: پورتی که بسته باشد، هدف حملات brute force قرار نمی‌گیرد و لاگ‌های شما دیگر با تلاش‌های ورود پر نمی‌شوند.

ترتیب کار مهم است. ابتدا دسترسی tailnet را اضافه کنید، از یک نشست (session) دوم مطمئن شوید که می‌توانید از طریق آن وارد شوید و تنها پس از آن، قانون عمومی (public rule) را حذف کنید.

sudo ufw allow in on tailscale0
sudo ufw status verbose

پس از آن، قانون عمومی SSH را حذف کرده و با استفاده از نام MagicDNS دوباره متصل شوید. توجه داشته باشید که ufw allow in on tailscale0 در واقع چه کاری انجام می‌دهد: این دستور به هر چیزی که از طریق تونل وارد شود اعتماد می‌کند، بنابراین فایل سیاست (policy file) در Tailscale به جای ufw به ابزار کنترل دسترسی شما تبدیل می‌شود. سیاست خود را با در نظر گرفتن این موضوع بنویسید.

یک هشدار برای کسانی که از کانتینرها استفاده می‌کنند: پورت منتشرشده (published port) در Docker، قوانین NAT مخصوص به خود را نصب کرده و ufw را دور می‌زند، بنابراین یک ufw deny آن را نمی‌بندد. پورت‌های منتشرشده Docker که ufw را دور می‌زنند این مکانیزم را توضیح می‌دهد. انتشار روی آدرس tailnet، همان‌طور که در بالا گفته شد، این مشکل را برطرف می‌کند. اگر برنامه تحت Docker Compose اجرا می‌شود، یک sidecar در Tailscale در استک Compose یک گام فراتر می‌رود و پورت منتشرشده را به‌طور کامل حذف می‌کند، به‌طوری که کانتینر فقط از طریق نام tailnet آن قابل دسترسی باشد.

آنچه Tailscale محافظت می‌کند و آنچه محافظت نمی‌کند

بیان صریح این موضوع ضروری است، زیرا نسخه‌های بازاریابی مرزهای آن را مبهم می‌کنند.

محافظت‌شده: ترافیک بین دو گره (node) به‌صورت سرتاسری با WireGuard رمزنگاری می‌شود و هیچ رله‌ای در میانه مسیر نمی‌تواند آن را بخواند. کلیدهای خصوصی هرگز ماشینی که آن‌ها را تولید کرده است، ترک نمی‌کنند. گره‌ها نیازی به پورت ورودی عمومی ندارند، بنابراین هیچ چیزی روی پورت‌های 22 یا 5432 برای اسکن توسط اینترنت وجود ندارد. دسترسی بین گره‌ها به‌جای کسی که آدرس را می‌داند، توسط یک فایل سیاست (policy file) تعیین می‌شود.

محافظت‌نشده: سرور هماهنگ‌کننده (coordination server) نمودار دستگاه‌های شما را می‌بیند. این متادیتا به‌خودی‌خود حساس است، زیرا نام ماشین‌ها، مالکان، آدرس‌ها و زمان‌های آنلاین بودن، زیرساخت شما را توصیف می‌کنند. این سرور همچنین کلیدها را توزیع می‌کند که ریسک جدی‌تری است. Tailscale مستقیماً می‌گوید: «اگر Tailscale مخرب باشد و به‌طور پنهانی گره‌های جدیدی را به شبکه شما وارد کند، می‌تواند ترافیک را به گره‌های موجود شما ارسال یا از آن‌ها دریافت کند.» ارائه‌دهنده Single Sign-On شما در همان مسیر اعتماد قرار دارد، زیرا هر کسی که بتواند در آنجا هویت جعل کند، می‌تواند یک گره اضافه کند. همچنین یک گرهِ آسیب‌دیده، یک همتا (peer) در داخل tailnet است، بنابراین آنچه در ادامه به آن دسترسی پیدا می‌کند، هر چیزی است که سیاست شما اجازه می‌دهد. اینکه آیا این موارد ریسک قابل قبولی را تشکیل می‌دهند یا خیر، به این بستگی دارد که در برابر چه کسی دفاع می‌کنید و مدل اعتماد کامل هر یک از این موارد را بررسی می‌کند، از جمله اینکه یک حساب کاربری سرقت‌شده واقعاً چه کاری می‌تواند انجام دهد.

دو پاسخ برای ریسک توزیع کلید وجود دارد. اولی tailnet lock است که مستلزم آن است که گره‌های مورد اعتماد موجود، یک گره جدید را به‌صورت رمزنگاری امضا کنند تا سایر گره‌های شما آن را بپذیرند. کنترل پلنی که بدون امضای معتبر، گره‌ای اضافه کند، نادیده گرفته می‌شود. کنسول مدیریت، خط tailscale lock init دقیق را برای گره‌های امضاکننده شما تولید می‌کند و هر گره می‌تواند آنچه را که می‌بیند تأیید کند.

tailscale lock status

همه گره‌ها باید مجموعه یکسانی از کلیدهای امضای مورد اعتماد را گزارش کنند. پاسخ دوم، اجرای کنترل پلن توسط خودتان است. یک سرور هماهنگ‌کننده Headscale که خودتان میزبانی می‌کنید، همان پروتکل را با همان کلاینت‌ها صحبت می‌کند و نمودار دستگاه و توزیع کلید را به سخت‌افزاری که مالک آن هستید منتقل می‌کند. در این صورت، شما مالک پایداری (uptime) آن سرور نیز خواهید بود. اگر هنوز در حال مقایسه کنترل پلن‌های خود-میزبانی‌شده هستید و به این مورد نرسیده‌اید، NetBird یک VPN مش جداگانه است که سرور آن را به‌طور کامل روی یک VPS اجرا می‌کنید.

یک پیش‌فرض که باید در همان روز اول اصلاح شود. یک tailnet جدید به‌صورت سهل‌گیرانه عرضه می‌شود: «سیاست پیش‌فرض tailnet، ارتباط بین تمام دستگاه‌های داخل tailnet را فعال می‌کند.» به‌محض اینکه یک بخش acls اضافه کنید، مدل به «رد پیش‌فرض» تغییر می‌یابد و فقط قوانین شما اجازه عبور می‌یابند.

{
  "tagOwners": {
    "tag:server": ["autogroup:admin"]
  },
  "acls": [
    {"action": "accept", "src": ["autogroup:member"], "dst": ["tag:server:22"]}
  ]
}

آن سیاست به اعضای tailnet اجازه می‌دهد فقط به SSH روی سرورهای برچسب‌دار (tagged) دسترسی داشته باشند و نه هیچ چیز دیگر. به‌جای باقی گذاشتن wildcard، برای هر سرویس یک قانون اضافه کنید، زیرا wildcard به این معنی است که یک کلید لپ‌تاپ سرقت‌شده می‌تواند به دیتابیس شما دسترسی پیدا کند.

حالت‌های شکست و رشته‌هایی که مشاهده خواهید کرد

tailscale status همیشه relay را نمایش می‌دهد. دو گره (node) هرگز مسیر مستقیمی ایجاد نکردند. دستور tailscale netcheck را در هر دو سمت اجرا کنید. UDP: false به این معناست که ترافیک UDP در خروجی مسدود شده است، بنابراین فقط از طریق relay امکان برقراری ارتباط وجود دارد. MappingVariesByDestIP: true نشان‌دهنده وجود یک NAT سخت در مسیر است؛ باز کردن پورت UDP 41641 در سمت ورودی (سمتی که کنترل آن را در اختیار دارید) معمولاً این مشکل را حل می‌کند.

گره‌ای که ماه‌ها کار می‌کرد، ناپدید شده است. کلید گره (node key) در بازه پیش‌فرض 180 روزه منقضی شده است. وضعیت دستگاه در کنسول مدیریتی به صورت expired نمایش داده می‌شود و اجرای sudo tailscale up روی آن دستگاه، وضعیت را بازیابی می‌کند. برای جلوگیری از تکرار این اتفاق، انقضای کلید را روی سرورها غیرفعال کنید.

همتایان (peers) لیست شده‌اند اما اتصالات با timeout مواجه می‌شوند. اتصال شبکه برقرار است اما سیاست‌های امنیتی (policy) ترافیک را مسدود می‌کنند. بخش acls را برای یافتن قانونی که این مبدأ، مقصد و پورت را پوشش می‌دهد، بررسی کنید. بسته مسدود شده به جای دریافت پاسخ، دور ریخته می‌شود؛ به همین دلیل به جای Connection refused، با timeout مواجه می‌شوید.

نام‌های MagicDNS ترجمه (resolve) نمی‌شوند. دستور ping db-1 شکست می‌خورد در حالی که ping 100.101.102.104 به درستی کار می‌کند. چیزی فایل /etc/resolv.conf را جایگزین کرده است، بنابراین پرس‌وجوها هرگز به stub resolver در 100.100.100.100 نمی‌رسند. فایل cat /etc/resolv.conf را برای وجود 100.100.100.100 بررسی کنید و ببینید چه فرآیند دیگری روی سیستم، این فایل را بازنویسی می‌کند. این مشکل از همان دسته‌بندی اختلال DNS در تونل WireGuard است.

tailscale up تگ شما را نمی‌پذیرد. تگ مورد نظر در بخش tagOwners در فایل سیاست‌ها (policy file) تعریف نشده است. آن را اضافه کنید و سپس دستور را دوباره اجرا کنید.

FAQ

آیا Tailscale یک VPN است یا یک شبکه مش (mesh)؟

هر دو واژه دقیق هستند و لایه‌های متفاوتی را توصیف می‌کنند. تونل‌ها از پروتکل WireGuard استفاده می‌کنند که آن را به یک VPN تبدیل می‌کند. توپولوژی شبکه از نوع مش است، زیرا هر گره به‌جای ارسال تمام بسته‌ها از طریق یک سرور مرکزی، مستقیماً با گره‌ای که با آن در ارتباط است تونل برقرار می‌کند. سرور هماهنگ‌کننده (coordination server) در مسیر کنترل قرار دارد، نه در مسیر داده؛ بنابراین اگر این سرور از دسترس خارج شود، تونل‌های موجود همچنان ترافیک را منتقل می‌کنند. آنچه در زمان قطعی متوقف می‌شود، پیوستن گره‌های جدید و اعمال تغییرات در کلیدها یا سیاست‌های شبکه است.

آیا Tailscale می‌تواند ترافیک من را بخواند؟

محتوای ترافیک خیر. ترافیک بین گره‌ها با استفاده از WireGuard به‌صورت سرتاسری (end-to-end) رمزنگاری می‌شود، کلیدهای خصوصی هرگز گره‌ها را ترک نمی‌کنند و رله‌های DERP بسته‌هایی را منتقل می‌کنند که راهی برای رمزگشایی آن‌ها ندارند. Tailscale به متادیتا دسترسی دارد: نام ماشین‌ها، مالکان، کلیدهای عمومی، آدرس‌های endpoint و زمان آنلاین بودن هر گره. این سرویس همچنین کلیدها را توزیع می‌کند، بنابراین یک سرور هماهنگ‌کننده نفوذپذیر می‌تواند سعی کند گره‌ای را وارد شبکه کند که ناوگان شما به آن اعتماد کند. قابلیت tailnet lock با الزام به امضای دیجیتال از سوی گره‌های مورد اعتماد خودتان، جلوی این کار را می‌گیرد و Headscale نیز کنترل‌کننده میزبانی‌شده (hosted control plane) را از چرخه حذف می‌کند.

آیا نیاز است پورت‌های فایروال را برای Tailscale باز کنم؟

تقریباً هرگز برای ترافیک ورودی (inbound) نیازی نیست. راهنمای رسمی Tailscale بیان می‌کند که «در بیشتر مواقع، نیازی به باز کردن هیچ پورت فایروالی ندارید.» برای ترافیک خروجی (outbound)، یک گره به پورت TCP 443 برای ارتباط با سرور هماهنگ‌کننده و رله‌ها، و همچنین پورت UDP 3478 برای STUN نیاز دارد. تونل‌های مستقیم از پروتکل UDP با پورت مبدأ پیش‌فرض 41641 استفاده می‌کنند. باز کردن پورت UDP 41641 برای ترافیک ورودی اختیاری است و فقط به موفقیت اتصالات مستقیم در شبکه‌های محدود کمک می‌کند.

چرا سایر گره‌ها نمی‌توانند به سرویس من روی پورت 3000 دسترسی پیدا کنند؟

ابتدا آدرس bind را با دستور ss -tlnp بررسی کنید. سرویسی که روی 127.0.0.1:3000 گوش می‌دهد، اتصالات ورودی به آدرس 100.x (آدرس tailnet گره) را رد می‌کند، زیرا آن سوکت فقط مقصدهای loopback را می‌پذیرد و کلاینت با خطای Connection refused مواجه می‌شود. سرویس را روی آدرس tailnet تنظیم کنید یا از tailscale serve 3000 برای پروکسی کردن آن استفاده کنید. اگر سرویس از قبل روی 0.0.0.0 گوش می‌دهد و اتصال به‌جای رد شدن (refuse)، با timeout مواجه می‌شود، علت آن یک قانون در سیاست‌های شبکه یا فایروال میزبان است، نه آدرس bind.

آیا باید به‌جای سرور هماهنگ‌کننده Tailscale از Headscale استفاده کنم؟

زمانی از Headscale استفاده کنید که نمودار دستگاه‌ها یا توزیع کلیدها باید روی زیرساختی باشد که خودتان کنترل می‌کنید، یا زمانی که tailnet باید بدون وابستگی به هیچ سرویس خارجی کار کند. کلاینت‌ها و پروتکل در هر دو حالت یکسان هستند. هزینه این کار این است که اکنون شما مسئولیت نگهداری سرور هماهنگ‌کننده را بر عهده دارید و قطعی آن باعث می‌شود گره‌های جدید نتوانند به شبکه بپیوندند و تغییرات سیاست‌ها اعمال نشود. برای ناوگان‌های کوچک، استفاده از کنترل‌کننده میزبانی‌شده (hosted control plane) به همراه فعال‌سازی tailnet lock معمولاً گزینه بهتری است.