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

Tailscale چیست؟

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

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

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 در سطح اپراتور (carrier-grade NAT) است که از 100.64.0.0 تا 100.127.255.255 را شامل می‌شود. Tailscale از این محدوده استفاده می‌کند زیرا برای زیرساخت‌های ارائه‌دهنده رزرو شده است و به همین دلیل به‌ندرت با آدرس‌های خصوصی که سرورهای شما در حال حاضر استفاده می‌کنند، تداخل پیدا می‌کند. در لینوکس، این تونل به عنوان یک اینترفیس با نام tailscale0 ظاهر می‌شود.

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

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

سرور هماهنگ‌کننده کلیدهای عمومی و متادیتای شما را نگهداری می‌کند. این سرور نام ماشین‌های شما، کاربری یا تگی که مالک هر گره است، آدرس tailnet هر گره، آدرس‌های عمومی که گره‌های شما از طریق آن‌ها در دسترس هستند، زمان آخرین آنلاین بودن هر گره و فایل سیاستی که نوشته‌اید را می‌داند. این اطلاعات، نقشه‌ای کامل از ناوگان گره‌های شماست.

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

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

اتصال یک 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 باید گره جدید را با آدرس 100.x آن فهرست نماید. برای سروری که با اسکریپت ساخته شده، URL تعاملی کاربردی ندارد. یک auth key در کنسول مدیریت ایجاد کنید و آن را به همراه یک tag که نوع ماشین را مشخص می‌کند، ارسال نمایید.

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

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

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

اگر خودِ عملیات نصب در apt یا مخزن (repository) با خطا مواجه شد، خطاهای رایج نصب Tailscale در Ubuntu راه‌حل‌ها را پوشش می‌دهد.

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

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

ss -tlnp | grep 3000

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

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

tailscale serve 3000

این کار درخواست‌ها را به http://127.0.0.1:3000 پروکسی می‌کند و آن‌ها را در داخل tailnet شما روی یک نام ts.net و از طریق HTTPS ارائه می‌دهد، به شرطی که گواهی‌های HTTPS برای tailnet فعال شده باشند. این سرویس برای گره‌های شما خصوصی باقی می‌ماند. نسخه عمومی همین ایده، 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، همان‌طور که در بالا گفته شد، این مشکل را برطرف می‌کند.

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

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

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

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

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

tailscale lock status

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

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

{
  "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 سخت (hard NAT) در مسیر است؛ باز کردن پورت UDP 41641 در سمت ورودی (inbound) برای طرفی که کنترل آن را در دست دارید، معمولاً این مشکل را حل می‌کند.

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

همتایان (peers) لیست می‌شوند اما اتصالات با timeout مواجه می‌شوند. اتصال شبکه برقرار است اما سیاست‌های امنیتی (policy) ترافیک را رد می‌کنند. بخش acls را برای یافتن قانونی که این مبدأ، مقصد و پورت را پوشش می‌دهد، بررسی کنید. بسته‌ای که رد (deny) شود، به جای دریافت پاسخ، دور ریخته می‌شود؛ به همین دلیل به جای 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 نیز کنترل‌کننده (control plane) میزبانی‌شده را از چرخه حذف می‌کند.

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

تقریباً هرگز برای ترافیک ورودی (inbound) نیازی نیست. راهنمای رسمی Tailscale می‌گوید: «در بیشتر مواقع، نیازی به باز کردن هیچ پورت فایروالی ندارید.» برای ترافیک خروجی، یک گره به پورت 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 bind کنید یا از tailscale serve 3000 برای پروکسی کردن آن استفاده کنید. اگر listener از قبل روی 0.0.0.0 تنظیم شده است و اتصال به‌جای رد شدن، با timeout مواجه می‌شود، علت آن یک قانون در سیاست‌های امنیتی یا فایروال میزبان است، نه آدرس bind.

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

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