آیا Tailscale امن است؟ بررسی مدل اعتماد و رمزنگاری

آیا Tailscale امن است؟ پاسخ کوتاه

آیا Tailscale امن است؟ برای بخشی که اکثر کاربران نگران آن هستند، پاسخ مثبت است: سرور هماهنگ‌کننده (coordination server) که tailnet شما را مدیریت می‌کند، هرگز کلیدهای خصوصی که ترافیک شما را رمزنگاری می‌کنند در اختیار ندارد؛ بنابراین نمی‌تواند محتوای ارسالی بین دستگاه‌های شما را بخواند. در صفحه امنیت Tailscale مستقیماً آمده است: «کلیدهای خصوصی هرگز دستگاه را ترک نمی‌کنند. تمام ترافیک همیشه به‌صورت سرتاسری (end-to-end) رمزنگاری می‌شود.» پرسش مفیدتر، موضوع دیگری است. سرور هماهنگ‌کننده‌ای که مورد نفوذ قرار گرفته یا تحت حکم قانونی مجبور به همکاری شود، نیازی به خواندن بسته‌های داده شما ندارد. این سرور تعیین می‌کند که دستگاه‌های شما به کدام کلیدهای عمومی اعتماد کنند، بنابراین می‌تواند دستگاهی را که شما هرگز تأیید نکرده‌اید، به شبکه اضافه کند.

مدل اعتماد در یک جمله این است: رمزنگاری از داده‌ها محافظت می‌کند و صفحه کنترل (control plane) عضویت را تعیین می‌کند. هر بخش در ادامه، یک طرفی را که باید به آن اعتماد کنید نام می‌برد، مشخص می‌کند که آن طرف واقعاً چه کاری می‌تواند انجام دهد و کنترلی را که محدودیت‌هایی برای آن ایجاد می‌کند، ارائه می‌دهد. اگر این محصول برای شما جدید است، با چیستی Tailscale و نحوه عملکرد شبکه مش آن شروع کنید.

کنترل پلین (Control Plane) و دیتا پلین (Data Plane) از هم جدا هستند

Tailscale یک شبکه خصوصی مجازی (VPN) مش است که بر پایه WireGuard ساخته شده؛ همان پروتکلی که ممکن است به‌صورت دستی روی یک VPS شخصی با WireGuard پیکربندی کنید. هر دستگاه، جفت‌کلید WireGuard خود را به‌صورت محلی تولید می‌کند. در مطلب نحوه عملکرد Tailscale، از سرور هماهنگ‌کننده (coordination server) به‌عنوان «یک صندوق اشتراکی برای کلیدهای عمومی» یاد شده و تأکید شده است که «کلید خصوصی هرگز، تحت هیچ شرایطی، گره (node) خود را ترک نمی‌کند.»

دیتا پلین، همان ترافیک رمزنگاری‌شده بین دستگاه‌های شماست. این ترافیک مستقیماً از دستگاهی به دستگاه دیگر منتقل می‌شود، مشروط بر اینکه شبکه اجازه برقراری ارتباط مستقیم را بدهد. کنترل پلین شامل تمام موارد دیگر است: اینکه کدام دستگاه‌ها متعلق به tailnet هستند، کدام کلید عمومی به کدام دستگاه تعلق دارد، سیاست‌های دسترسی، تنظیمات DNS و لیست رله‌ها. Tailscale کنترل پلین را به‌عنوان یک سرویس میزبانی‌شده اجرا می‌کند، در حالی که شما دیتا پلین را روی ماشین‌های خودتان مدیریت می‌کنید.

اگر این دو را از هم تفکیک کنید، پاسخ تمام پرسش‌های امنیتی در این حوزه مشخص خواهد شد. رمزنگاری، ویژگیِ دیتا پلین است. عضویت در شبکه، تصمیمی است که در کنترل پلین گرفته می‌شود. هیچ میزان رمزنگاری نمی‌تواند به شما بگوید که چه کسی اجازه دارد یک peer باشد.

یک سرور هماهنگ‌کننده (coordination server) در صورت نفوذ چه کاری می‌تواند انجام دهد؟

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

این سرور می‌تواند یک گره (node) را ثبت کند. زمانی که Tailscale قابلیت tailnet lock را معرفی کرد، این شرکت ریسک مربوطه را با کلمات خود چنین توصیف کرد: یک سرور مخرب می‌تواند «از یک گره که مخفیانه اضافه شده برای ارسال یا دریافت ترافیک به گره‌های موجود شما استفاده کند» و در آن نقطه «اینکه ترافیک رمزنگاری شده باشد اهمیتی ندارد، زیرا خودِ همتا (peer) مخرب خواهد بود». دستگاه شما به یک همتا اعتماد می‌کند، زیرا control plane به آن گفته است که آن کلید متعلق به tailnet شماست.

این سرور می‌تواند تعیین کند که دستگاه‌های شما به چه منابعی دسترسی داشته باشند. سیاست دسترسی (access policy) در control plane قرار دارد و بین گره‌ها توزیع می‌شود. در وایت‌پیپر tailnet lock شرکت Tailscale آمده است که tailnet lock «از ایجاد اختلال در اتصال شبکه توسط یک control plane نفوذپذیر جلوگیری نمی‌کند؛ برای مثال از طریق عدم توزیع کلیدهای گره جدید یا توزیع یک سیاست کنترل دسترسی که دسترسی به تمام گره‌ها را مسدود می‌کند».

این سرور در هر صورت متادیتای اتصالات را می‌بیند. لاگ‌های جریان شبکه (network flow logs) در Tailscale، رویدادهای باز و بسته شدن هر اتصال بین ماشین‌ها را ثبت می‌کنند. مستندات بیان می‌کنند که این لاگ‌ها «به‌طور دقیق حاوی هیچ‌گونه اطلاعاتی درباره عملیات کلاینت یا محتوای ترافیک شبکه نیستند». بنابراین control plane می‌تواند بداند کدام‌یک از دستگاه‌های شما با دیگری ارتباط برقرار کرده و چه زمانی این اتفاق افتاده است، اما نمی‌داند آن‌ها چه گفته‌اند.

تنها یک مورد از این لیست مربوط به رمزنگاری است. موارد دیگر درباره این است که چه کسی عضو شبکه است و سیاست‌ها چه می‌گویند؛ به همین دلیل است که کنترل‌هایی که شایسته توجه شما هستند، همان‌هایی هستند که بر فرآیند ثبت‌نام (enrolment) نظارت دارند.

ارائه‌دهنده هویت شما، ریشه اعتماد در tailnet است

Tailscale هیچ پایگاه داده رمز عبوری برای خود ندارد. مستندات آن به‌صراحت بیان می‌کنند که هیچ رمز عبوری برای Tailscale وجود ندارد و ورود به سیستم به یک ارائه‌دهنده هویت (IdP) واگذار شده است: Apple، Google، GitHub، Microsoft، Okta، OneLogin یا یک ارائه‌دهنده OpenID Connect سفارشی.

این موضوع را به‌عنوان یک بیانیه امنیتی در نظر بگیرید، زیرا دقیقاً همین‌طور است. هر کسی که بتواند به حساب Google یا Microsoft شما وارد شود، می‌تواند به tailnet شما نیز وارد شود. احراز هویت چندعاملی (MFA) شما همان چیزی است که IdP اعمال می‌کند. فرآیند خروج کاربر (offboarding) شما نیز همان چیزی است که IdP هنگام ترک سازمان توسط یک فرد انجام می‌دهد. یک حساب IdP که فیشینگ شده باشد، در واقع یک حساب tailnet است و مهاجم هرگز نیازی به حمله به WireGuard ندارد: آن‌ها یک دستگاه اضافه می‌کنند و هر آنچه سیاست‌های شما به آن کاربر اعطا کرده است را به ارث می‌برند.

دو کنترل بین یک حساب کاربری سرقت‌شده و یک دستگاه فعال در داخل tailnet شما قرار دارد: تأیید دستگاه (device approval) و انقضای کلید (key expiry). قفل tailnet (tailnet lock) مورد سوم است که هدف آن کنترل صفحه مدیریت (control plane) به‌جای حساب کاربری است.

تایید دستگاه: هیچ دستگاهی بدون تایید انسانی به شبکه متصل نمی‌شود

مستندات Tailscale قابلیت تایید دستگاه را به عنوان ویژگی‌ای توصیف می‌کند که «به مدیران شبکه Tailscale اجازه می‌دهد دستگاه‌های جدید را پیش از پیوستن به شبکه، بررسی و تایید کنند». این تایید توسط Owner، Admin یا IT admin قابل انجام است. دستگاه جدید تا زمانی که شخصی اقدام به تایید آن نکند، در صفحه Machines با نشان "Needs approval" نمایش داده می‌شود.

با فعال‌سازی این قابلیت، سناریوی سرقت حساب کاربری تغییر می‌کند. مهاجم وارد سیستم می‌شود، دستگاه ثبت می‌گردد، اما در حالت انتظار باقی می‌ماند و به هیچ منبعی دسترسی ندارد. در کنسول مدیریتی شما نیز نشانی ظاهر می‌شود که اعلام می‌کند دستگاهی ناشناس درخواست پیوستن به شبکه را دارد. اتوماسیون همچنان کار می‌کند، زیرا هنگام تولید auth key می‌توان آن را از پیش تایید شده (pre-approved) علامت‌گذاری کرد و دستگاه‌ها نیز از طریق API قابل تایید هستند.

کلیدهای احراز هویت (Auth keys) راه دیگر ورود به شبکه هستند، بنابراین با آن‌ها مانند اعتبارنامه‌های حساس رفتار کنید. مستندات Tailscale در مورد انواع پرخطر این کلیدها صریح است: «در استفاده از کلیدهای قابل استفاده مجدد بسیار محتاط باشید! اگر این کلیدها به سرقت بروند، می‌توانند بسیار خطرناک باشند. بهتر است آن‌ها را در محصولاتی که مخصوص مدیریت کلید (key vault) طراحی شده‌اند، نگهداری کنید.» تا آگوست 2026، بازه زمانی انقضای کلیدها طبق مستندات بین 1 تا 90 روز است و اگر انقضایی تعیین نشود، به‌طور پیش‌فرض روی حداکثر 90 روز تنظیم می‌شود. ترجیحاً از کلیدهای یک‌بارمصرف استفاده کنید، برای ماشین‌هایی که موقتی هستند آن‌ها را به صورت ephemeral علامت‌گذاری کنید و هرگونه کلید قابل استفاده مجدد را به جای اسکریپت‌های shell، با استفاده از Ansible Vault رمزنگاری کنید یا در یک مدیریت‌کننده اسرار (secrets manager) قرار دهید.

انقضای کلید: تایمری که سایر خطاها را محدود می‌کند

کلیدهای Node منقضی می‌شوند؛ این همان مکانیزمی است که یک دستگاه سرقت‌شده یا فراموش‌شده را به یک مشکل موقتی تبدیل می‌کند. مستندات Tailscale بیان می‌کند که «به‌طور پیش‌فرض، دامنه‌های جدید با دوره انقضای 180 روزه تنظیم می‌شوند» و «اگر احراز هویت مجدد انجام نشود، کلیدها منقضی شده و اتصالات به/از آن endpoint خاص از کار می‌افتند.» شما می‌توانید خودتان یک دستگاه را مجدداً احراز هویت کنید:

tailscale up --force-reauth

مستندات هشدار می‌دهد که این کار «ممکن است اتصال tailnet را قطع کند و بنابراین نباید از راه دور و از طریق SSH یا RDP، بدون داشتن راه جایگزین برای ورود در صورت قطع اتصال، انجام شود.» این دستور را در حالی اجرا کنید که دسترسی کنسول باز است یا از مسیر دومی به دستگاه متصل هستید، زیرا در شرف قطع کردن شبکه‌ای هستید که هم‌اکنون از آن استفاده می‌کنید.

سرورها جایی هستند که این کنترل تغییر می‌کند. دستگاهی که باید هر 180 روز یک‌بار مجدداً احراز هویت شود، در ساعت 3 بامداد که کسی نظارت نمی‌کند از tailnet خارج می‌شود؛ بنابراین مدیران سیستم، انقضای کلید را روی آن غیرفعال می‌کنند. این کار تایمری را که در نهایت یک کلید سرقت‌شده را قطع می‌کرد، از بین می‌برد. استفاده از دستگاه‌های برچسب‌دار (tagged) برای سرورها راهکار بهتری است، زیرا برچسب مالکیت دستگاه را به جای یک شخص، به عهده می‌گیرد؛ بنابراین دستگاه پس از خروج آن شخص از شرکت، همچنان فعال باقی می‌ماند. هر تصمیمی که می‌گیرید، فهرستی از دستگاه‌هایی که انقضای کلید آن‌ها غیرفعال شده است نگه دارید: این کلیدها تا زمانی که دستگاه را حذف نکنید، معتبر باقی می‌مانند.

قفل Tailnet: خارج کردن سرور هماهنگ‌ساز از زنجیره اعتماد

قفل Tailnet مستقیماً به مسئله ثبت‌نام (enrolment) می‌پردازد. مستندات قفل Tailnet در Tailscale این مکانیزم را این‌گونه توضیح می‌دهد: «هنگامی که یک گره جدید به tailnet می‌پیوندد، کلید عمومی گره آن نیازمند امضایی از یک کلید قفل Tailnet است. سرور هماهنگ‌ساز، کلید عمومی امضاشده گره را میان گره‌های همتا توزیع می‌کند.» دستگاه‌های موجود شما پیش از پذیرش یک همتا، آن امضا را تأیید می‌کنند؛ بنابراین کلید گره‌ای که control plane به‌طور خودکار ایجاد کرده باشد، رد می‌شود.

tailscale lock status
tailscale lock sign nodekey:1abddef1 tlpub:abcdef12

tailscale lock init این قابلیت را فعال می‌کند و شما در همان لحظه گره‌های امضاکننده خود را تعیین می‌کنید. Tailscale در زمان راه‌اندازی اولیه حداقل به دو گره امضاکننده نیاز دارد و اجازه می‌دهد حداکثر 20 گره در یک tailnet وجود داشته باشد. پس از آن، هر دستگاه جدید نیازمند امضایی از یکی از آن‌هاست که یک هزینه عملیاتی واقعی محسوب می‌شود: افزودن یک گوشی به معنای اجرای یک دستور روی لپ‌تاپ است.

محدودیت‌ها مستند شده‌اند و اهمیت آن‌ها از شرح قابلیت بیشتر است:

• اگر secret غیرفعال‌سازی را گم کنید، هیچ راه بازگشتی وجود ندارد. مستندات می‌گوید: «اگر secretهای غیرفعال‌سازی خود را گم کنید و آن را به پشتیبانی Tailscale ارائه نداده باشید، tailnet قابل بازیابی نخواهد بود.»
• کلید امضا روی دستگاهی که مالک آن هستید قرار دارد، بنابراین امنیت آن کلید از امنیت همان دستگاه ارث‌بری می‌کند. مستندات صراحتاً بیان می‌کند: «اگر دستگاه مورد نفوذ قرار گیرد، کلید قابل دستیابی است.»
• شما نمی‌توانید هر دو کنترل را همزمان اجرا کنید. Tailscale اعلام کرده است که قفل tailnet و تأیید دستگاه (device approval) با یکدیگر ناسازگارند؛ بنابراین فعال‌سازی یکی به معنای صرف‌نظر کردن از دیگری است.
• این مکانیزم مبتنی بر اعتماد در اولین استفاده (TOFU) است. راه‌اندازی اولیه همچنان از طریق control plane انجام می‌شود و لنگر اعتماد تنها پس از آن گام نخست، به شبکه خودتان منتقل می‌گردد.

قفل Tailnet از عضویت محافظت می‌کند. این قابلیت از دسترس‌پذیری (availability) محافظت نمی‌کند و وایت‌پیپر نیز به این موضوع اشاره دارد.

آیا اتصال رله‌شده (relayed) ترافیک من را در معرض دید قرار می‌دهد؟

خیر. هنگامی که دو دستگاه نمی‌توانند مستقیماً به یکدیگر متصل شوند، ترافیک به یک سرور DERP (مخفف Designated Encrypted Relay for Packets) منتقل می‌شود. مستندات Tailscale این ویژگی را بدون هیچ ابهامی بیان می‌کند: «از آنجا که کلیدهای خصوصی Tailscale هرگز دستگاه محلی تولیدکننده خود را ترک نمی‌کنند، برای سرور DERP غیرممکن است که ترافیک شما را رمزگشایی کند. سرور DERP صرفاً ترافیکی را که از قبل رمزگذاری شده است، به‌صورت کورکورانه از یک دستگاه به دستگاه دیگر هدایت می‌کند.»

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

tailscale status
tailscale netcheck

tailscale status وضعیت هر همتا (peer) را مشخص می‌کند؛ اگر اتصال مستقیم باشد با direct 203.0.113.10:41641 و اگر رله‌شده باشد با relay به همراه نام رله و شمارنده بایت‌ها نمایش داده می‌شود. اگر یک همتا روی حالت رله باقی می‌ماند، به این معناست که دو طرف نتوانسته‌اند مسیر مستقیمی ایجاد کنند؛ معمولاً به این دلیل که پروتکل UDP در جایی مسدود شده است یا هر دو طرف پشت یک NAT (ترجمه آدرس شبکه) سخت‌گیرانه قرار دارند. tailscale netcheck گزارش می‌دهد که آیا UDP از آن ماشین کار می‌کند یا خیر، NAT شما چگونه پورت‌ها را نگاشت (map) می‌کند و تأخیر (latency) تا نزدیک‌ترین رله‌ها چقدر است؛ این اطلاعات به شما می‌گوید که با کدام‌یک از دو دلیل فوق مواجه هستید.

یک exit node مسیر خروجی شما را تغییر می‌دهد، نه آنکه آن را حذف کند

یک exit node تمام ترافیک اینترنت عمومی دستگاه را از طریق دستگاه دیگری در tailnet هدایت می‌کند و از مسیرهای پیش‌فرض 0.0.0.0/0 و ::/0 استفاده می‌کند. در لینوکس، ماشینی که این سرویس را ارائه می‌دهد آن را تبلیغ (advertise) می‌کند و هر کلاینت به‌صورت انتخابی از آن استفاده می‌کند:

sudo tailscale set --advertise-exit-node
sudo tailscale set --exit-node=100.101.102.103
sudo tailscale set --exit-node=100.101.102.103 --exit-node-allow-lan-access=true
sudo tailscale set --exit-node=

یک exit node باید توسط یک Owner، Admin یا Network admin در کنسول مدیریت تأیید شود و خط‌مشی (policy) شما باید پیش از آنکه کلاینتی بتواند از آن استفاده کند، دسترسی autogroup:internet را اعطا کرده باشد. هر دو مرحله آگاهانه انجام می‌شوند: یک ماشین تأییدنشده نمی‌تواند بی‌سروصدا به مسیر خروجی کل tailnet شما تبدیل شود.

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

سیاست پیش‌فرض، یک شبکه تخت است

یک tailnet جدید به‌صورت پیش‌فرض با دسترسی‌های باز عرضه می‌شود. مستندات کنترل دسترسی Tailscale بیان می‌کند که فایل سیاست پیش‌فرض «امکان برقراری ارتباط بین تمامی دستگاه‌های موجود در tailnet را فراهم می‌کند». هر دستگاه می‌تواند به هر دستگاه دیگری در هر پورتی متصل شود. این یک شبکه تخت (flat network) است. شما آن را به داخل تونل منتقل کرده‌اید که در برابر عوامل خارجی مفید است، اما در برابر لپ‌تاپی که آلوده شده باشد، هیچ کاری انجام نمی‌دهد.

آن را در فایل سیاست tailnet محدود کنید؛ این فایل ACLها (لیست‌های کنترل دسترسی) یا grantsهای جدیدتر را می‌پذیرد که هر دو با گویشی از JSON نوشته می‌شوند که امکان استفاده از کامنت را فراهم می‌کند:

{
  "acls": [
    {"action": "accept", "src": ["group:eng"], "dst": ["tag:prod:22"]},
    {"action": "accept", "src": ["autogroup:member"], "dst": ["autogroup:internet:*"]}
  ]
}

این سیاست به یک گروه اجازه می‌دهد به SSH در سرورهای production دسترسی داشته باشد، به اعضا اجازه می‌دهد از یک exit node استفاده کنند و هر چیز دیگری را به‌طور پیش‌فرض رد می‌کند. Tailscale مشخص می‌کند که کدام اهدافِ قوانین در کدام طرح (plan) در دسترس هستند، بنابراین پیش از طراحی بر اساس tags یا autogroups، آن را بررسی کنید و ببینید طرح رایگان دقیقاً شامل چه مواردی است. برای دستگاهی که هرگز نباید اتصالات ورودی را بپذیرد، مانند یک تلفن شخصی، tailscale set --shields-up آن‌ها را در سمت کلاینت مسدود می‌کند.

تغییرات ناشی از میزبانی شخصی control plane با Headscale

Headscale یک «پیاده‌سازی متن‌باز و خود-میزبان از سرور کنترل Tailscale» است. فایل README این پروژه محدودهٔ آن را صادقانه بیان می‌کند: «این پروژه محدودهٔ محدودی دارد، یک شبکهٔ Tailscale (یا tailnet) واحد، که برای استفاده شخصی یا یک سازمان کوچک متن‌باز مناسب است.» لیست قابلیت‌های آن شامل ACLها و دسترسی‌ها، subnet routerها، exit nodeها، یک سرور DERP داخلی، Tailscale SSH و Taildrop می‌شود. اگر این محدودهٔ محدود مانع کار شماست، NetBird گزینهٔ mesh دیگری است که یک control plane قابل میزبانی ارائه می‌دهد و اجرای سرور NetBird روی VPS شخصی، تصمیم‌گیری دربارهٔ ثبت‌نام گره‌ها را به سخت‌افزاری که مالک آن هستید منتقل می‌کند.

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

آنچه تغییر نمی‌کند، data plane است. این همان WireGuard با همان رمزنگاری سرتاسری (end-to-end) و همان مکانیزم relay fallback در زمانی است که مسیر مستقیم غیرممکن باشد. شما همچنین مسئولیت‌هایی را که Tailscale انجام می‌داد به ارث می‌برید: آپ‌تایم، وصله‌کردن، پشتیبان‌گیری و امنیت فیزیکی دستگاه. یک میزبان Headscale که مورد نفوذ قرار گرفته باشد، دقیقاً همان دسترسی‌هایی را به مهاجم می‌دهد که یک سرور هماهنگ‌کننده (coordination server) در صورت نفوذ به مهاجم می‌داد؛ یعنی قدرت ثبت یک گره و توزیع سیاست‌ها. قابلیت Tailnet lock در لیست ویژگی‌های Headscale وجود ندارد، بنابراین کنترل جبرانی برای آن ریسک خاص در آنجا در دسترس نیست. اگر مسئلهٔ مالکیت، فاکتور تعیین‌کننده برای شماست، میزبانی شخصی control plane با Headscale مراحل راه‌اندازی را گام‌به‌گام توضیح می‌دهد.

محافظت‌هایی که Tailscale فراهم می‌کند

• پورت‌های شنود عمومی. سرویسی که به یک آدرس در tailnet متصل است، از طریق اینترنت قابل دسترسی نیست؛ بنابراین اسکنرهایی که تمام VPSها را روی پورت 22 هدف قرار می‌دهند، هرگز آن را نمی‌بینند. استثنا حالتی است که خودتان آن را فعال کنید، زیرا Funnel یک سرویس tailnet را عمداً در اینترنت آزاد منتشر می‌کند. به همین دلیل پیش از اجرای هر یک از این دو دستور، لازم است بدانید کجا serve تمام می‌شود و funnel آغاز می‌گردد. در هر صورت فایروال میزبان را فعال نگه دارید، زیرا یک پورت Docker منتشرشده، قوانین خاص خود را می‌نویسد و ufw را در رابط عمومی دور می‌زند.
• حدس رمز عبور برای لاگین‌های در معرض دید. وقتی پورت فقط در داخل تونل پاسخ می‌دهد، چیزی برای حمله brute-force وجود ندارد. این وضعیت نسبت به محدود کردن نرخ (rate limiting) یک پورت باز، امنیت بالاتری دارد؛ هرچند همچنان توصیه می‌شود fail2ban روی Ubuntu 24.04 را روی هر سرویسی که باید عمومی بماند، اجرا کنید.
• شبکه‌های غیرقابل اعتماد در مسیر. ترافیک بین ماشین‌های شما در شبکه‌های کافی‌شاپی یا LANهای اشتراکی ارائه‌دهندگان، به‌صورت سرتاسری (end-to-end) رمزنگاری می‌شود و هنگام رله شدن نیز رمزنگاری‌شده باقی می‌ماند.
• توزیع کلید به صورت دستی. هر peer که به‌صورت دستی به پیکربندی WireGuard اضافه می‌شود، احتمال استفاده مجدد از یک آدرس یا جای‌گذاری اشتباه کلید را به همراه دارد. این شبکه مش (mesh) تمام این مدیریت را برای شما انجام می‌دهد که بخش عمده تفاوت عملی در مقایسه WireGuard با Tailscale را تشکیل می‌دهد.

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

• یک endpoint آلوده. شبکه Tailnet به دستگاه‌ها اعتماد می‌کند. بدافزار موجود روی یک لپ‌تاپ تأییدشده، به تونل، آدرس‌های Tailnet و هر آنچه سیاست‌های امنیتی شما برای آن کاربر تعیین کرده است، دسترسی پیدا می‌کند. این بزرگ‌ترین شکاف امنیتی است و هیچ VPNای آن را پوشش نمی‌دهد.
• یک مدیر سیستم مخرب یا بی‌دقت. هر کسی که بتواند فایل سیاست‌ها (policy file) را ویرایش کند، می‌تواند به خود دسترسی به هر چیزی را بدهد و هر کسی که بتواند کنترل حساب کاربری یک Owner را به دست بگیرد، می‌تواند همین کار را انجام دهد. تغییرات سیاست‌ها را همان‌طور بررسی کنید که کدها را بازبینی می‌کنید.
• تحلیل ترافیک. ارائه‌دهنده خدمات اینترنت (ISP) شما، ترافیک رمزگذاری‌شده UDP را که به سمت یک endpoint می‌رود، به همراه زمان‌بندی و حجم آن مشاهده می‌کند. لاگ‌های جریان (flow logs) در Tailscale نشان می‌دهند که کدام peerها و در چه زمانی با هم ارتباط داشته‌اند. هیچ‌کدام محتوای داده‌ها را نمی‌بینند، اما اصل برقراری اتصال پنهان نمی‌ماند؛ بنابراین پیش از انتخاب ابزار برای این منظور، تفاوت Tor و VPN را مطالعه کنید.
• دستگاهی که قبلاً آن را از دست داده‌اید. انقضای کلید (Key expiry) یک راهکار پشتیبان کند است که به‌صورت پیش‌فرض روی 180 روز تنظیم شده است. حذف دستگاه از طریق کنسول مدیریت، راهکار سریع است؛ بنابراین پیش از آنکه به آن نیاز پیدا کنید، محل این دکمه را یاد بگیرید.

بررسی tailnet خود

1. دستور tailscale status را روی یک دستگاه اجرا کنید و لیست peerها را بخوانید. دستگاهی که نمی‌توانید آن را شناسایی کنید، دقیقاً همان وضعیتی است که قابلیت تایید دستگاه (device approval) برای جلوگیری از آن وجود دارد.
2. دستور tailscale lock status را اجرا کنید تا ببینید آیا tailnet lock فعال است یا خیر؛ سپس تصمیم بگیرید که آیا هزینهٔ امضای هر دستگاه جدید برای tailnet شما ارزشش را دارد یا نه.
3. کنسول مدیریتی را باز کنید و تمام دستگاه‌هایی که انقضای کلید (key expiry) در آن‌ها غیرفعال است، به همراه تمام کلیدهای احراز هویت قابل‌استفادهٔ مجدد (reusable auth keys) که هنوز وجود دارند را یادداشت کنید. هر دوی این موارد، اعتبارنامه‌هایی بدون محدودیت زمانی هستند.
4. فایل سیاست (policy file) خود را بخوانید. اگر هنوز در حالت پیش‌فرض است، هر دستگاه می‌تواند به هر دستگاه دیگری در تمام پورت‌ها دسترسی داشته باشد و یک لپ‌تاپ آلوده می‌تواند به همهٔ آن‌ها نفوذ کند.

Tailscale شهرت خود را مدیون data plane است، جایی که طراحی سیستم به اپراتور اجازه نمی‌دهد ترافیک شما را بخواند. این ادعا را همان‌طور که فروشنده مستند کرده است بپذیرید، سپس بخش‌هایی که مربوط به شماست را ممیزی کنید: حساب‌های کاربری، تنظیمات تایید، لیست انقضا و فایل سیاست. صفحهٔ امنیتی Tailscale گزارش گواهی SOC 2 Type II و همکاری مستمر امنیتی با Latacora را ارائه می‌دهد که این موارد شواهدی دربارهٔ فرآیندهای آن‌هاست، نه بیانیه‌ای دربارهٔ پیکربندی شما.

FAQ

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

خیر. ترافیک با کلیدهای WireGuard که روی دستگاه‌های شما تولید می‌شوند، رمزنگاری می‌گردد. صفحه امنیت Tailscale تصریح می‌کند که «کلیدهای خصوصی هرگز دستگاه را ترک نمی‌کنند. تمام ترافیک همیشه به‌صورت سرتاسری (end-to-end) رمزنگاری می‌شود.» این موضوع حتی در مورد اتصالاتی که به رله DERP متکی هستند نیز صدق می‌کند، زیرا رله «ترافیکِ از پیش رمزنگاری‌شده را به‌صورت کورکورانه از یک دستگاه به دستگاه دیگر هدایت می‌کند» و هیچ کلیدی برای رمزگشایی در اختیار ندارد. آنچه زیرساخت Tailscale مشاهده می‌کند، صرفاً متادیتا است: اینکه چه دستگاه‌هایی وجود دارند و کدام‌یک از آن‌ها در چه زمانی به دیگری متصل شده است.

یک سرور هماهنگ‌کننده (coordination server) در Tailscale در صورت نفوذ چه کاری می‌تواند انجام دهد؟

می‌تواند یک گره (node) جدید ثبت کند. اطلاعیه tailnet lock خودِ Tailscale به ریسک اضافه شدن مخفیانه یک گره اشاره می‌کند که می‌تواند «ترافیک را به گره‌های موجود شما ارسال یا از آن‌ها دریافت کند»؛ در این حالت رمزنگاری کمکی نمی‌کند «زیرا خودِ همتا (peer) مخرب است». یک کنترل‌پلنِ نفوذشده همچنین می‌تواند سیاستی را توزیع کند که دسترسی دستگاه‌های شما را تغییر دهد. وایت‌پیپر tailnet lock اشاره می‌کند که این وضعیت می‌تواند با توزیع نکردن کلیدهای جدید گره، باعث اختلال در اتصال شود. آنچه این سرور نمی‌تواند انجام دهد، رمزگشایی ترافیک بین دستگاه‌های موجود شماست، زیرا هرگز کلیدهای خصوصی آن‌ها را در اختیار نداشته است.

آیا exit node فعالیت‌های وب‌گردی من را از ISP مخفی می‌کند؟

این کار مقاصد ترافیک را از شبکه‌ای که به آن متصل هستید (از جمله ISP خانگی یا کافه) مخفی می‌کند، زیرا همه چیز از دستگاه شما به‌صورت ترافیک رمزنگاری‌شده به مقصد exit node خارج می‌شود. این کار شما را ناشناس نمی‌کند. در عوض، exit node و ارائه‌دهنده میزبانی و شبکه بالادستی آن، این مقاصد را می‌بینند و سایت‌هایی که بازدید می‌کنید نیز آدرس IP همان exit node را مشاهده می‌کنند. شما ناظر متفاوتی را انتخاب کرده‌اید، پس کسی را انتخاب کنید که واقعاً به او اعتماد دارید.

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

این یک تصمیم متفاوت در مورد اعتماد است، نه لزوماً امن‌تر بودن مطلق. با Headscale، شما دایرکتوری کلیدها و سیاست‌ها را در اختیار دارید، بنابراین هیچ شخص ثالثی نمی‌تواند مجبور به ثبت یک دستگاه در tailnet شما شود. در مقابل، مسئولیت اجرای آن سرور نیز با شماست: وصله‌کردن، پایداری (uptime)، پشتیبان‌گیری و امنیت خودِ میزبان. یک میزبان Headscale که مورد نفوذ قرار گرفته باشد، همان قدرت ثبت گره را به مهاجم می‌دهد که یک سرور هماهنگ‌کننده نفوذشده به او می‌داد؛ همچنین از آنجا که tailnet lock در لیست قابلیت‌های Headscale نیست، باید از آن میزبان به‌طور مناسب محافظت کنید.

آیا همچنان به فایروال روی VPS که در tailnet من است نیاز دارم؟

بله. رابط شبکه عمومی همچنان وجود دارد و هر سرویسی که به 0.0.0.0 متصل باشد، فارغ از اینکه Tailscale در حال اجرا باشد یا خیر، از اینترنت قابل‌دسترسی است. سرویس‌ها را به آدرس tailnet محدود کنید، یک سیاست پیش‌فرضِ deny روی رابط عمومی اعمال کنید و پورت‌های منتشرشده کانتینرها را بررسی کنید؛ زیرا Docker قوانین خاص خود را تزریق می‌کند و ممکن است پورتی را که تصور می‌کردید بسته است، در معرض دید قرار دهد.