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

عملکرد subnet router در Tailscale

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

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

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

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

نصب 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 ممکن است هفته‌ها کار کند و درست صبحِ پس از یک reboot ناشی از ارتقای هسته (kernel)، از کار بیفتد. بخش گیج‌کننده اینجاست که هیچ‌چیز ظاهراً خراب به نظر نمی‌رسد. tailscale status همچنان گره را آنلاین نشان می‌دهد، کنسول مدیریت همچنان مسیر (route) را تأییدشده نمایش می‌دهد و کلاینت‌ها نیز مسیر را نصب‌شده دارند. بسته‌ها به VPS می‌رسند و هسته بدون ثبت هیچ لاگی، آن‌ها را حذف می‌کند. نوشتن مقادیر در /etc/sysctl.d/99-tailscale.conf همان کاری است که باعث می‌شود تنظیمات پس از reboot باقی بمانند.

اگر در حالی که forwarding غیرفعال است اقدام به تبلیغ (advertise) مسیرها کنید، tailscale up در همان لحظه با خطی مشابه Warning: IPv4 forwarding is disabled. Subnet routes and exit nodes may not work correctly. به شما هشدار می‌دهد. خروجی آن دستور را بخوانید و از کنار آن عبور نکنید.

تبلیغ مسیرها (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) را با آن برچسب، 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 لیست کند.

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

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

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

آنچه باعث تعجب کاربران می‌شود، رفتار سیستم هنگام آفلاین شدن A است. Tailscale به مسیر با دقت کمتر (less specific) بازنمی‌گردد. ترافیک به مقصد 10.0.0.20 متوقف می‌شود، در حالی که ترافیک به مقصد 10.1.0.20 همچنان از طریق 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 دائمی نیست و با reboot بعدی از بین می‌رود. راهکار اصلی، انتخاب یک محدوده خصوصی است که در محیط‌های عمومی با آن مواجه نشوید. 192.168.0.0/24 و 192.168.1.0/24 مقادیر پیش‌فرض در اکثر روترهای خانگی هستند، بنابراین چیزی در محدوده 10.0.0.0/8 انتخاب کنید که آگاهانه برگزیده شده باشد. همین تداخل باعث از کار افتادن یک VPN ساده WireGuard که به‌صورت دستی پیکربندی کرده‌اید می‌شود، زیرا به همان دلیل، مسیر محلی دقیق‌تر پیروز می‌شود و ترافیک هرگز وارد تونل نمی‌شود.

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

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

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

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

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

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

یک تلهٔ مشابه روی خودِ سرور نام وجود دارد. اگر یک سرور نام سراسری را در کنسول مدیریت روی یک آدرس خصوصی مانند 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 اشاره کند. بدون این مسیر بازگشت، پاسخ‌ها به سمت 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 ذخیره کنید، در غیر این صورت با reboot بعدی از بین می‌رود.

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

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

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

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

در نهایت، تصمیم بگیرید که آیا می‌خواهید از یک سرور هماهنگ‌کننده (coordination server) استفاده کنید که خودتان آن را اجرا نمی‌کنید یا خیر. صفحه کنترل (control plane) در Tailscale یک سرویس میزبانی‌شده است. کلیدهای شما روی ماشین‌هایتان باقی می‌مانند، اما حساب کاربری و فایل سیاست در آنجا قرار دارند. اجرای Headscale، سرور کنترل Tailscale که خودتان میزبانی می‌کنید، این بخش را روی VPS شخصی شما نگه می‌دارد، به قیمت اینکه مسئولیت نگهداری آن با شماست. پاسخ دیگر به همین نگرانی، کنار گذاشتن کلاینت‌های Tailscale و خودمیزبانی سرور VPN NetBird است که لایهٔ هماهنگی و کلاینت‌های mesh اختصاصی خود را روی ماشینی که کنترل می‌کنید قرار می‌دهد. اگر هنوز در حال تصمیم‌گیری بین این مدل و پیکربندی دستی هستید، مقایسه WireGuard و Tailscale توضیح می‌دهد که لایهٔ هماهنگی چه چیزی به شما می‌دهد و چه هزینه‌ای دارد.

FAQ

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

یک subnet router محدوده‌ای از آدرس‌های خصوصی را تبلیغ می‌کند تا دستگاه‌های موجود در tailnet بتوانند به ماشین‌هایی که Tailscale روی آن‌ها اجرا نمی‌شود، دسترسی پیدا کنند. یک exit node خود را به‌عنوان مسیری به کل اینترنت معرفی می‌کند تا دستگاه تمام ترافیک خود را از طریق آدرس عمومی آن گره ارسال کند. یک VPS می‌تواند همزمان هر دو باشد. این‌ها فلگ‌های مجزایی هستند، --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 می‌توانند یک محدوده یکسان را تبلیغ کنند؟

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

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

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