راه اندازی Tailscale Subnet Router روی VPS

عملکرد روتر زیرشبکه Tailscale

یک روتر زیرشبکه Tailscale ماشینی است که کل محدوده آدرس‌های IP خصوصی را به tailnet شما معرفی می‌کند، به‌طوری که تمام دستگاه‌های موجود در tailnet می‌توانند به آدرس‌های آن محدوده دسترسی داشته باشند، حتی اگر هیچ‌کدام از آن‌ها Tailscale را اجرا نکنند. Tailnet شبکه خصوصی Tailscale شماست: مجموعه‌ای از دستگاه‌هایی که با یک حساب کاربری یا سازمان وارد شده‌اند. Exit node قابلیتی است که معمولاً با این مورد اشتباه گرفته می‌شود، در حالی که عملکردی معکوس دارد. این قابلیت تمام ترافیک یک دستگاه را از طریق VPS هدایت می‌کند تا VPS به مسیر آن دستگاه برای دسترسی به اینترنت عمومی تبدیل شود.

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

زمانی که یک VPS به subnet router نیاز دارد

حالت رایج، شبکه خصوصی است که ارائه‌دهنده از قبل در اختیار شما قرار داده است. VPS شما یک آدرس عمومی و یک اینترفیس دوم در یک سگمنت خصوصی دارد، و سایر سرورهای آن سگمنت هیچ آدرس عمومی ندارند: مانند یک دیتابیس در 10.0.0.20 یا یک مقصد پشتیبان‌گیری در 10.0.0.30. با نصب Tailscale روی یک VPS و تبلیغ (advertise) کردن 10.0.0.0/24، لپ‌تاپ شما مستقیماً به آن آدرس‌های خصوصی دسترسی پیدا می‌کند. هیچ تغییری در سایر بخش‌های آن سگمنت ایجاد نمی‌شود و دیتابیس همچنان فاقد آدرس عمومی باقی می‌ماند. اگر تنها چیزی که از آن سگمنت نیاز دارید یک وب‌اپلیکیشن روی یک پورت خاص است، تبلیغ کردن کل محدوده بیش از نیاز شماست و Tailscale serve با قرار دادن HTTPS روی همان تک‌پورت، کار را انجام می‌دهد. همین استدلال برای دیمونی که عمداً فقط به localhost متصل می‌شود نیز صدق می‌کند، مانند dsh که بدون رابط کاربری تحت systemd اجرا می‌شود؛ در این حالت، یک آدرس tailnet روی آن VPS جایگزین تونل SSH می‌شود که در غیر این صورت باید برای دسترسی به UI آن باز نگه می‌داشتید.

حالت دیگر، شبکه‌ای در سمت دیگر VPS است. یک LAN (شبکه محلی) خانگی یا اداری پشت روتر خودش، یا مجموعه‌ای از تجهیزات که اصلاً نمی‌توانند Tailscale را اجرا کنند، مانند یک سوئیچ مدیریت‌شده یا یک NAS قدیمی با فریم‌ور قفل‌شده. یک دستگاه لینوکسی در آن شبکه، به subnet router برای تمام تجهیزات دیگر تبدیل می‌شود. در خانه، آن دستگاه اغلب یک VM کوچک روی هایپروایزری است که از قبل دارید، و محاسبه هزینه یک میزبان Proxmox در خانه در برابر یک VPS اجاره‌ای موضوعی است که باید پیش از تصمیم‌گیری درباره اینکه سرویس‌هایتان در کدام سمت تونل قرار بگیرند، مشخص کنید.

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

نصب Tailscale و بررسی مسیر محلی در ابتدا

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

این اسکریپت توزیع سیستم‌عامل را شناسایی کرده، مخزن بسته‌های Tailscale را اضافه می‌کند، دستور tailscale و دیمون tailscaled را نصب کرده و سپس سرویس را فعال می‌کند. وضعیت را با systemctl is-active tailscaled تأیید کنید؛ این دستور باید active را نمایش دهد.

پیش از هر اقدامی، اطمینان حاصل کنید که VPS می‌تواند به شبکه‌ای که قصد معرفی آن را دارید، دسترسی داشته باشد.

ip route show
ping -c3 10.0.0.20

دستور ip route show باید محدوده آدرس‌های خصوصی را روی یک اینترفیس واقعی فهرست کند، چیزی شبیه به 10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5. اگر دستور ping در اینجا و روی خود روتر با شکست مواجه شود، هیچ فلگ Tailscaleای مشکل را حل نخواهد کرد. مشکل از پیکربندی شبکه VPS یا فایروال روی میزبان مقصد است. ابتدا آن را برطرف کنید، زیرا تمام تست‌های بعدی به این موضوع وابسته هستند.

فعال‌سازی IP forwarding و ماندگاری آن پس از reboot

یک ماشین Linux هر بسته‌ای را که به مقصد خودش نباشد، در صورتی که قابلیت forwarding فعال نباشد، دور می‌ریزد. هدایت بسته‌های سایر ماشین‌ها وظیفه اصلی یک subnet router است، بنابراین این مرحله اختیاری نیست.

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

وضعیت آن را با sysctl net.ipv4.ip_forward بررسی کنید؛ این دستور باید net.ipv4.ip_forward = 1 را چاپ کند.

بسیاری از افراد این مرحله را به‌صورت ناقص انجام می‌دهند. دستور sudo sysctl -w net.ipv4.ip_forward=1 بلافاصله اعمال می‌شود اما با reboot بعدی از بین می‌رود؛ در نتیجه subnet router ممکن است هفته‌ها کار کند و درست صبحِ پس از ارتقای هسته (kernel) و reboot سیستم، از کار بیفتد. بخش گیج‌کننده این است که هیچ‌چیز خراب به نظر نمی‌رسد. tailscale status همچنان گره را آنلاین نشان می‌دهد، کنسول مدیریت همچنان مسیر (route) را تأییدشده نمایش می‌دهد و کلاینت‌ها همچنان مسیر را نصب‌شده دارند. بسته‌ها به VPS می‌رسند و هسته بدون ثبت هیچ لاگی، آن‌ها را دور می‌ریزد. نوشتن مقادیر در /etc/sysctl.d/99-tailscale.conf همان کاری است که باعث می‌شود تنظیمات پس از reboot باقی بمانند.

اگر در حالی که forwarding خاموش است، مسیرها را تبلیغ (advertise) کنید، tailscale up در همان لحظه به شما هشدار می‌دهد. در Linux این خط مشابه Warning: IP forwarding is disabled, subnet routing/exit nodes will not work. است. خروجی آن دستور را بخوانید و از کنار آن رد نشوید.

تبلیغ مسیرها (Advertise routes)

sudo tailscale up --advertise-routes=10.0.0.0/24

روی یک VPS که هم‌اکنون به tailnet شما متصل است، تنظیمات را به این صورت تغییر دهید:

sudo tailscale set --advertise-routes=10.0.0.0/24

برای هر تغییر بعدی از tailscale set استفاده کنید. اجرای مجدد tailscale up با یک فلگ تکی، سایر فلگ‌هایی که تکرار نکرده‌اید را بازنشانی می‌کند و CLI با نمایش یک خطا به شما هشدار می‌دهد که تغییر تنظیمات به این روش، مستلزم ذکر تمام فلگ‌های غیرپیش‌فرض است. دستور tailscale set تنها یک تنظیم را تغییر می‌دهد و بقیه را دست‌نخورده باقی می‌گذارد.

چندین محدوده را می‌توانید در یک لیست با جداکننده کاما و بدون فاصله وارد کنید: --advertise-routes=10.0.0.0/24,192.168.50.0/24. هر ورودی باید یک آدرس شبکه با نماد CIDR (مسیریابی بین‌دامنه‌ای بدون کلاس، فرمت 10.0.0.0/24) باشد. وارد کردن اشتباه آدرس میزبان خودتان به صورت 10.0.0.5/24 رد می‌شود، زیرا بیت‌های بعد از پیشوند صفر نیستند و پیام خطا، پیشوندی که احتمالاً مد نظر داشته‌اید را اعلام می‌کند. برای متوقف کردن تبلیغ مسیرها، یک لیست خالی را با sudo tailscale set --advertise-routes= تنظیم کنید.

تأیید مسیر در کنسول مدیریت

اعلام (Advertise) یک مسیر، صرفاً یک درخواست است، نه یک تغییر نهایی. تا زمانی که مدیر سیستم آن را تأیید نکند، هیچ کلاینتی آن مسیر را دریافت نمی‌کند و هیچ‌چیز در آن محدوده قابل دسترسی نخواهد بود. این موضوع عمدی است، زیرا ماشینی که بتواند خود را به جدول مسیریابی همه اضافه کند، می‌تواند ترافیک هر محدوده‌ای را که بخواهد شنود کند.

آن را در صفحه Machines در کنسول مدیریت تأیید کنید. VPS با یک نشان subnet فهرست شده است. ردیف مربوط به آن را باز کنید، بخش subnets را بیابید، تنظیمات مسیر را ویرایش کنید، تیک مسیر را بزنید و ذخیره کنید.

تأییدیه برای هر پیشوند (prefix) به‌صورت جداگانه است. اگر امروز 10.0.0.0/24 را اعلام کنید و ماه آینده 192.168.50.0/24 را، پیشوند جدید بدون تأیید باقی می‌ماند در حالی که پیشوند قدیمی همچنان کار می‌کند. از دیدگاه VPS، یک مسیر تأییدشده و یک مسیر نادیده‌گرفته‌شده کاملاً یکسان به نظر می‌رسند، بنابراین پیش از عیب‌یابی هر مورد دیگری، کنسول را بررسی کنید.

شما می‌توانید با استفاده از یک بلوک autoApprovers در فایل سیاست tailnet، از این مرحله دستی صرف‌نظر کنید:

{
  "autoApprovers": {
    "routes": {
      "10.0.0.0/24": ["tag:subnet-router"]
    }
  }
}

سپس گره (node) را با آن برچسب (tag) بالا بیاورید، sudo tailscale up --advertise-routes=10.0.0.0/24 --advertise-tags=tag:subnet-router، تا مسیر به محض اعلام شدن، تأیید شود. این برچسب باید ابتدا در بخش tagOwners از همان فایل سیاست وجود داشته باشد. اگر VPS را از طریق اسکریپت بازسازی می‌کنید، این کار ارزش تنظیم کردن را دارد، زیرا یک گره بازسازی‌شده، یک گره جدید محسوب می‌شود و مسیرهای آن دوباره در وضعیت تأییدنشده قرار می‌گیرند.

چرا کلاینت‌های لینوکسی بدون استفاده از --accept-routes مسیر را نادیده می‌گیرند

این مسیر اکنون تبلیغ (advertise) و تأیید شده است. گوشی و مک شما می‌توانند به 10.0.0.20 دسترسی داشته باشند، اما لپ‌تاپ لینوکسی شما نمی‌تواند و کنسول مدیریت نیز هیچ مشکلی را نشان نمی‌دهد.

پذیرش یک subnet route به معنای نوشتن ورودی‌ها در جدول مسیریابی کلاینت است. در اندروید، iOS، macOS، tvOS و ویندوز، کلاینت Tailscale این کار را برای شما انجام می‌دهد. در لینوکس این اتفاق نمی‌افتد، زیرا ماشین لینوکسی اغلب یک سرور یا روتر است که جدول مسیریابی آن توسط شخصی به‌صورت هدفمند پیکربندی شده است؛ بنابراین درج بی‌سروصدای یک /24 که از شبکه یاد گرفته شده، می‌تواند ترافیکی را که آن ماشین در حال حاضر مدیریت می‌کند، مختل کند. بنابراین در لینوکس، شما باید روی هر کلاینت این قابلیت را فعال کنید:

sudo tailscale set --accept-routes

سپس بررسی کنید که مسیر در کجا قرار گرفته است:

ip route show table 52
ip route get 10.0.0.20

Tailscale در لینوکس مسیرهای پذیرفته‌شده را در جدول مسیریابی اصلی قرار نمی‌دهد. این مسیرها در جدول مسیریابی 52 قرار می‌گیرند و قوانین خط‌مشی (policy rules) نصب می‌شوند که با ip rule show در محدوده اولویت 5210 تا 5270 قابل مشاهده هستند و بسته‌های منطبق‌نشده را به آن جدول می‌فرستند. بنابراین ip route show به‌تنهایی هرگز 10.0.0.0/24 را لیست نمی‌کند و کاربری که فقط آن دستور را بررسی کند، نتیجه می‌گیرد که --accept-routes هیچ کاری انجام نداده است. ip route show table 52 دستوری است که حقیقت را نشان می‌دهد و باید محدوده تبلیغ‌شده را روی tailscale0 لیست کند.

یک استثنا وجود دارد که دانستن آن مفید است. اگر این گره لینوکسی خود یک subnet router دوم برای شبکه محلی خودش باشد، --accept-routes باعث می‌شود ترافیک مربوط به زیرشبکه متصل به خودش، به‌جای خروج از رابط (interface) خودش، از طریق روتر دیگر ارسال شود. در یک روتر آماده‌به‌کار (standby) در یک جفت با دسترس‌پذیری بالا (high availability)، --accept-routes را غیرفعال بگذارید و فقط تبلیغ (advertise) کنید.

حالت شکست: دو روتر که محدوده‌های هم‌پوشان را تبلیغ می‌کنند

دو روتر زیرشبکه (subnet router) می‌توانند محدوده‌های یکسانی را تبلیغ کنند؛ این همان روشی است که یک جفت با قابلیت دسترسی بالا (high availability) کار می‌کند: هر روتر دقیقاً پیشوندهای یکسانی را تبلیغ می‌کند و کلاینت‌ها می‌توانند از یکی به دیگری سوئیچ کنند (failover). محدوده‌های هم‌پوشان با طول پیشوند متفاوت نیز مجاز هستند و Tailscale دقیق‌ترین تطابق را انتخاب می‌کند. با تبلیغ 10.0.0.0/24 توسط روتر A و 10.0.0.0/16 توسط روتر B، ترافیک به مقصد 10.0.0.20 به سمت A هدایت می‌شود.

آنچه کاربران را غافلگیر می‌کند، رفتار سیستم هنگام آفلاین شدن A است. Tailscale به مسیر با دقت کمتر (less specific) بازنمی‌گردد، زیرا یک روتر آفلاین نمی‌تواند تبلیغ خود را پس بگیرد و کلاینت‌ها همچنان پیشوند دقیق‌تر را ترجیح می‌دهند. ترافیک به مقصد 10.0.0.20 متوقف می‌شود، در حالی که ترافیک به مقصد 10.0.1.20 که تنها توسط /16 روتر B پوشش داده می‌شود، همچنان از طریق B کار می‌کند. این نشانه به نظر می‌رسد که بخشی از شبکه خصوصی قطع شده است، در حالی که علت اصلی، یک گره آفلاین است که پیشوند دقیق‌تر را در اختیار دارد. اگر به قابلیت failover نیاز دارید، روتر با محدوده وسیع‌تر را تنظیم کنید تا پیشوندهای محدودتر را نیز تبلیغ کند، به‌طوری که هر دو روتر آدرس‌های یکسانی را پوشش دهند.

هم‌پوشانی دیگر به کلاینت نزدیک‌تر است. حضور در شبکه یک هتل با آدرس 192.168.1.0/24 در حالی که روتر زیرشبکه شما 192.168.1.0/24 را تبلیغ می‌کند، به این معناست که این دو برای مقاصد یکسان با هم رقابت می‌کنند و اینکه کدام‌یک پیروز شود، به پلتفرم بستگی دارد. در لینوکس، یک rule پیش از rule خودِ Tailscale نصب کنید تا آدرس‌های محلی از جدول اصلی (main table) استفاده کنند:

sudo ip rule add to 192.168.1.0/24 priority 2500 lookup main

این rule دائمی نیست و با بوت بعدی از بین می‌رود. راه حل واقعی، انتخاب یک محدوده خصوصی است که در محیط‌های عمومی با آن مواجه نشوید. 192.168.0.0/24 و 192.168.1.0/24 مقادیر پیش‌فرض در اکثر روترهای خانگی هستند، بنابراین چیزی را از داخل محدوده 10.0.0.0/8 انتخاب کنید که آگاهانه برگزیده‌اید. همین تداخل باعث از کار افتادن یک VPN معمولی WireGuard که به‌صورت دستی پیکربندی کرده‌اید می‌شود، به همان دلیل: مسیر محلی دقیق‌تر پیروز می‌شود و ترافیک هرگز وارد تونل نمی‌شود.

حالت شکست: DNS به آدرسی ترجمه می‌شود که هیچ مسیری آن را پوشش نمی‌دهد

عیب‌یابی این مورد دشوار است، زیرا هیچ خطایی گزارش نمی‌شود. نام دامنه ترجمه می‌شود اما اتصال با timeout مواجه می‌گردد.

فرض کنید db.internal.example.com از طریق nameserver خصوصی شما به 10.0.5.20 ترجمه می‌شود و شما 10.0.0.0/24 را تبلیغ (advertise) کرده‌اید. این lookup موفقیت‌آمیز است، زیرا ترجمه DNS (سامانه نام دامنه) و مسیریابی IP دو مرحله مجزا هستند و هیچ‌کدام دیگری را بررسی نمی‌کند. سپس بسته ارسالی به 10.0.5.20 هیچ مسیر منطبقی در tailnet پیدا نمی‌کند، بنابراین از طریق gateway پیش‌فرض کلاینت خارج شده و ناپدید می‌شود.

دو دستور زیر این دو بخش را از هم تفکیک می‌کنند:

nslookup db.internal.example.com
ip route get 10.0.5.20

اگر lookup یک آدرس را برمی‌گرداند اما ip route get با dev tailscale0 پاسخ نمی‌دهد، نام دامنه صحیح است و مسیر وجود ندارد. محدوده‌ای را تبلیغ کنید که آن آدرس را پوشش دهد، یا 10.0.0.0/16 یا یک prefix صریح دوم، سپس prefix جدید را در کنسول تأیید کنید.

یک تله مشابه روی خودِ nameserver وجود دارد. اگر یک nameserver سراسری را در کنسول مدیریت روی یک آدرس خصوصی مانند 10.0.0.53 تنظیم کنید، آن آدرس باید درون یک مسیر تأییدشده قرار داشته باشد، در غیر این صورت دستگاه‌های شما اصلاً نمی‌توانند به resolver دسترسی پیدا کنند. اگر گزینه‌ای را فعال کنید که DNSهای محلی را نادیده بگیرد (override) در حالی که به resolver غیرقابل‌دسترسی اشاره می‌کنید، تمام دستگاه‌های موجود در tailnet بلافاصله ترجمه نام را از دست می‌دهند، حتی آن‌هایی که یک ثانیه قبل کار می‌کردند. ابتدا مسیر رسیدن به resolver را تبلیغ و تأیید کنید، سپس تنظیمات DNS را تغییر دهید. اگر DNS درون تونل بخشی است که همچنان با آن مشکل دارید، نحوه اختلال DNS در تونل WireGuard همین مکانیزم را بدون لایه هماهنگیِ روی آن بررسی می‌کند.

Source NAT و لینک‌های site-to-site

به‌صورت پیش‌فرض، subnet router آدرس مبدأ تمام بسته‌های فوروارد شده را به آدرس خصوصی خود تغییر می‌دهد. این همان SNAT (ترجمه آدرس شبکه مبدأ) است و وجود آن باعث می‌شود پاسخ‌ها بدون نیاز به تغییر در شبکه خصوصی به مقصد برسند: پایگاه داده در 10.0.0.20 به VPS پاسخ می‌دهد، چرا که مسیر رسیدن به آن را می‌داند. هزینه این کار این است که پایگاه داده، تمام اتصالات tailnet را از سمت VPS می‌بیند؛ بنابراین قوانین فایروال مبتنی بر مبدأ و لاگ‌های دسترسی، اطلاعات مفیدی ارائه نمی‌دهند.

زمانی که می‌خواهید آدرس واقعی tailnet کلاینت حفظ شود، آن را در لینوکس غیرفعال کنید:

sudo tailscale set --snat-subnet-routes=false

سپس میزبان‌های موجود در شبکه خصوصی به یک مسیر بازگشت به 100.64.0.0/10، یعنی محدوده‌ای که Tailscale به دستگاه‌ها اختصاص می‌دهد، نیاز دارند که به سمت subnet router اشاره کند. بدون این مسیر بازگشت، پاسخ‌ها به سمت default gateway می‌روند و هرگز به مقصد نمی‌رسند، در نتیجه اتصالات پس از اولین بسته متوقف می‌شوند. مسیر ایستا (static route) را روی gateway شبکه خصوصی اضافه کنید یا SNAT را روشن بگذارید.

یک لینک site-to-site شامل دو subnet router است که هم‌زمان این کار را انجام می‌دهند؛ هر کدام شبکه خود را تبلیغ کرده و شبکه دیگری را می‌پذیرد:

sudo tailscale up --advertise-routes=10.0.0.0/24 --snat-subnet-routes=false --accept-routes

دستور مشابه را روی روتر دیگر با محدوده آدرس خودش اجرا کنید. این دو محدوده باید متفاوت باشند. اگر انتقال‌های حجیم در حالی که ssh و ping سالم هستند متوقف می‌شوند، علت آن MSS (حداکثر اندازه سگمنت) است؛ یعنی بزرگ‌ترین تکه داده‌ای که یک بسته TCP حمل می‌کند. سربار تونل باعث می‌شود بسته‌های فوروارد شده برای برخی لینک‌های میانی بیش از حد بزرگ شوند و clamping این مشکل را حل می‌کند:

sudo iptables -t mangle -A FORWARD -o tailscale0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

آن قانون را با iptables-persistent ذخیره کنید، در غیر این صورت با بوت بعدی از بین می‌رود.

نگهداری برای تداوم عملکرد

کلیدهای گره (Node keys) به‌طور پیش‌فرض پس از 180 روز منقضی می‌شوند؛ این وضعیت از اکتبر 2026 اعمال شده است. هنگامی که کلید روی یک subnet router منقضی شود، گره از سیستم خارج (sign out) شده و کل محدودهٔ معرفی‌شده (advertised range) غیرقابل‌دسترس می‌شود، بدون آنکه تغییری در پیکربندی رخ داده باشد که این موضوع را توضیح دهد. انقضای کلید را برای این ماشین در صفحه Machines در کنسول مدیریت غیرفعال کنید و سپس این اقدام را یادداشت نمایید. گره‌ای که تحت یک tag بالا آمده باشد، همان‌طور که در مثال autoApprovers در بالا ذکر شد، به‌طور پیش‌فرض انقضای کلید غیرفعالی دارد.

Tailscale اتصال مستقیم بین همتایان (peers) را ترجیح می‌دهد و در صورت عدم موفقیت، به سرورهای relay خود متوسل می‌شود. این relayها کار می‌کنند، اما تأخیر (latency) را افزایش می‌دهند. یک VPS با آدرس عمومی حالت ساده است: اجازه ورود ترافیک UDP 41641 را بدهید تا اکثر همتایان مستقیماً متصل شوند. زمانی که ترافیک به محدودهٔ خصوصی کندتر از حد انتظار برای لینک VPS است، بررسی اینکه آیا کلاینت شما مستقیماً به subnet router می‌رسد یا از طریق یک relay اولین گام برای رفع ابهام است. اگر ufw فایروال را مدیریت می‌کند، قوانین ufw که یک VPS واقعاً به آن نیاز دارد سینتکس لازم را پوشش می‌دهد.

قوانین دسترسی (Access rules) نیمهٔ دیگر ماجرا هستند. در یک tailnet پیش‌فرض، هر دستگاه شما می‌تواند به هر دستگاه دیگر دسترسی داشته باشد، بنابراین یک مسیر تأییدشده به‌سادگی کار می‌کند. هنگامی که یک سیاست ACL می‌نویسید، سمت مقصد در یک قانون باید محدودهٔ خصوصی را نام ببرد، زیرا 10.0.0.20 یک آدرس tailnet نیست و توسط قوانینی که برای IPها یا tagهای tailnet نوشته شده‌اند، پوشش داده نمی‌شود.

در نهایت، تصمیم بگیرید که آیا می‌خواهید از سرور هماهنگ‌کننده‌ای استفاده کنید که خودتان آن را اجرا نمی‌کنید یا خیر. صفحه کنترل (control plane) در Tailscale یک سرویس میزبانی‌شده است. کلیدهای شما روی ماشین‌هایتان باقی می‌مانند، اما حساب کاربری و فایل سیاست در آنجا قرار دارند. اینکه کسی با یک صفحه کنترلِ نفوذشده یا یک ورودِ هویتِ سرقت‌شده واقعاً چه کاری می‌تواند انجام دهد، بخشی است که پیش از دادن دسترسی به شبکه خصوصی‌تان باید درباره آن تصمیم بگیرید، و مدل اعتماد Tailscale مشخص می‌کند که این مرز کجا قرار دارد. هزینه به‌ندرت دلیلی است که افراد را از آن دور می‌کند، زیرا طرح رایگان تا شش کاربر با تعداد نامحدودی از دستگاه‌های شخصی را پوشش می‌دهد، اگرچه یک subnet router که تحت یک tag بالا می‌آورید، متفاوت از موردی که با حساب کاربری خودتان وارد شده‌اید محاسبه می‌شود. پس از آن نقطه، صورت‌حساب بر اساس تعداد افراد است نه ماشین‌ها، بنابراین آنچه یک خانواده یا یک تیم پنج‌نفره پس از پایان طرح رایگان واقعاً پرداخت می‌کند ارزش بررسی دارد پیش از آنکه حسابی را اضافه کنید که شما را از حد مجاز فراتر ببرد. اجرای Headscale، سرور کنترل Tailscale با میزبانی شخصی آن را روی VPS خودتان نگه می‌دارد، به قیمت اینکه باید خودتان آن را نگهداری کنید. پاسخ دیگر به همان نگرانی، کنار گذاشتن کلاینت‌های Tailscale و میزبانی شخصی سرور VPN NetBird است که لایه هماهنگی و کلاینت‌های mesh مخصوص خود را روی یک ماشینی که کنترلش می‌کنید قرار می‌دهد. اگر هنوز بین این مدل و پیکربندی دستی در حال تصمیم‌گیری هستید، مقایسه WireGuard و Tailscale توضیح می‌دهد که لایه هماهنگی چه چیزی به شما می‌دهد و چه هزینه‌ای دارد.

FAQ

تفاوت بین subnet router و exit node چیست؟

یک subnet router محدوده‌ای از آدرس‌های خصوصی را تبلیغ (advertise) می‌کند تا دستگاه‌های موجود در tailnet بتوانند به ماشین‌هایی که Tailscale روی آن‌ها اجرا نمی‌شود، دسترسی پیدا کنند. یک exit node خود را به‌عنوان مسیری به کل اینترنت معرفی می‌کند تا دستگاه، تمام ترافیک خود را از طریق آدرس عمومی آن گره ارسال کند. یک VPS می‌تواند هم‌زمان هر دو باشد. این‌ها flagهای جداگانه‌ای هستند، --advertise-routes و --advertise-exit-node، و هر کدام نیاز به تأیید جداگانه در کنسول مدیریت دارند.

چرا کلاینت لینوکسی من مسیر subnet تبلیغ‌شده را نادیده می‌گیرد؟

کلاینت‌های لینوکسی تا زمانی که از آن‌ها نخواهید، مسیرهای subnet را نمی‌پذیرند. دستور sudo tailscale set --accept-routes را روی کلاینت اجرا کنید. سپس با ip route show table 52 بررسی کنید، نه ip route show. Tailscale مسیرهای پذیرفته‌شده را در جدول مسیریابی 52 نصب می‌کند و از طریق قوانین policy به آن‌ها دسترسی پیدا می‌کند، بنابراین جدول اصلی هرگز آن‌ها را فهرست نمی‌کند و یک مسیر فعال ممکن است گم‌شده به نظر برسد.

subnet من پس از reboot از کار افتاد. چه چیزی خراب شده است؟

به احتمال زیاد IP forwarding. مقداری که با sysctl -w تنظیم می‌شود، پس از reboot باقی نمی‌ماند، بنابراین آن را در /etc/sysctl.d/99-tailscale.conf بنویسید و با sysctl net.ipv4.ip_forward تأیید کنید. اگر forwarding فعال است و محدوده همچنان غیرقابل‌دسترسی است، گره را در کنسول مدیریت بررسی کنید. کلیدهای گره به‌صورت پیش‌فرض پس از 180 روز منقضی می‌شوند و یک subnet router منقضی‌شده، بیشتر شبیه به یک خطای شبکه به نظر می‌رسد تا یک مشکل حساب کاربری.

آیا دو subnet router می‌توانند یک محدوده یکسان را تبلیغ کنند؟

بله. محدوده‌های یکسان روش کار یک جفت با قابلیت دسترسی بالا (high availability) هستند: هر دو روتر دقیقاً پیشوندهای یکسانی را تبلیغ می‌کنند. محدوده‌های هم‌پوشان با طول پیشوند متفاوت نیز مشکلی ندارند و دقیق‌ترین (most specific) آن‌ها اولویت دارد. failover در اینجا نیاز به دقت دارد: وقتی روتری که پیشوند دقیق‌تر را دارد آفلاین می‌شود، Tailscale به مسیر گسترده‌تر بازنمی‌گردد، بنابراین آن ترافیک متوقف می‌شود. برای داشتن یک جفت آماده‌به‌کار (standby) واقعی، هر دو روتر باید پیشوندهای دقیق یکسانی را تبلیغ کنند.

نام میزبان (hostname) ترجمه می‌شود اما اتصال timeout می‌دهد. چرا؟

ترجمه DNS و مسیریابی مراحل جداگانه‌ای هستند. یک نام می‌تواند به آدرسی ترجمه شود که هیچ مسیر تأییدشده‌ای آن را پوشش نمی‌دهد، و در نتیجه بسته از طریق gateway پیش‌فرض کلاینت خارج می‌شود. دستور ip route get <address> را روی کلاینت اجرا کنید. اگر پاسخ شامل dev tailscale0 نیست، محدوده‌ای را تبلیغ کنید که آن آدرس را پوشش دهد و پیشوند جدید را در کنسول مدیریت تأیید کنید.