SSD Nodes Learn Hosting plans →
راهنماها Matt Connorتوسط Matt Connor · به‌روزرسانی شده 2026-09-14

رفع خطاهای نصب Tailscale در Ubuntu

بیشتر خطاهای نصب Tailscale در Ubuntu مربوط به مخازن apt است. با بررسی کد وضعیت apt و اصلاح فایل‌های keyring یا codename در مسیر /etc/apt/sources.list.d مشکل را حل کنید.

چرا خطاهای نصب Tailscale در Ubuntu در واقع خطاهای apt هستند

خطاهای نصب Tailscale در Ubuntu تقریباً همیشه پیش از اجرای هرگونه کد Tailscale رخ می‌دهند. این‌ها خطاهای apt هستند. Ubuntu هیچ بسته tailscale اختصاصی ارائه نمی‌دهد: طبق بررسی آرشیو بسته‌های Ubuntu در اوت 2026، تنها موارد منطبق، کتابخانه‌های کمکی Go و python3-tailscale هستند؛ بنابراین daemon باید از مخزن apt اختصاصی Tailscale در pkgs.tailscale.com دریافت شود.

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

این‌ها دستوراتی هستند که Tailscale برای Ubuntu 24.04 منتشر کرده است:

sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.tailscale-keyring.list | sudo tee /etc/apt/sources.list.d/tailscale.list
sudo apt-get update && sudo apt-get install tailscale

noble نام رمز Ubuntu 24.04 است و در هر دو URL ظاهر می‌شود. دستور دوم یک خط توضیحات و یک خط deb را در /etc/apt/sources.list.d/tailscale.list می‌نویسد و cat دقیقاً نشان می‌دهد که چه چیزی در آنجا ثبت شده است.

cat /etc/apt/sources.list.d/tailscale.list

آن خط deb را به عنوان یک آدرس در چهار بخش بخوانید: گزینه داخل براکت [signed-by=/usr/share/keyrings/tailscale-archive-keyring.gpg]، سپس پایه مخزن که pkgs.tailscale.com/stable/ubuntu است و از طریق https در دسترس است، سپس suite یعنی noble، و در نهایت component یعنی main. ابزار apt پایه و suite را به یک URL تبدیل کرده و آن را دریافت می‌کند: https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease. اگر بتوانید آن URL را به‌صورت دستی دریافت کنید، apt نیز می‌تواند آن را دریافت کند. کل فرآیند عیب‌یابی همین است.

پیش از هر تغییری، خطای apt را بخوانید

عملیات update را به‌تنهایی اجرا کنید تا خروجی خطا با پیام‌های دیگر جابه‌جا نشود.

sudo apt update

یک مخزن (repository) شخص ثالث که با شکست مواجه شده، به این شکل دیده می‌شود. نام رمز (codename) و آدرس IP در سیستم شما متفاوت خواهد بود.

E: Failed to fetch https://pkgs.tailscale.com/stable/ubuntu/dists/wilma/InRelease  404  Not Found [IP: 203.0.113.9 443]
E: Some index files failed to download. They have been ignored, or old ones used instead.

دو مورد در این خروجی تعیین‌کننده گام بعدی شما هستند: کد وضعیت و URL کامل در خط E: Failed to fetch. بر اساس خط خلاصه در پایین صفحه حدس نزنید. URL را کپی کنید و خودتان از سرور پرس‌وجو کنید.

curl -sS -o /dev/null -w '%{http_code}\n' https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease

این دستور برای نام رمزی که Tailscale منتشر می‌کند، 200 را چاپ می‌کند. در بررسی انجام‌شده در اوت 2026، noble یک ایندکس امضاشده حاوی Origin: Tailscale و Codename: noble برمی‌گرداند. noble را با نام رمز موجود در خطای خود جایگزین کنید و دوباره آن را اجرا کنید. اگر curl کد 200 را دریافت کرد در حالی که apt با خطا مواجه شده است، مخزن سالم است و مشکل در پیکربندی خودِ apt قرار دارد.

کد وضعیت چه چیزی را به شما می‌گوید

  • کد 404 Not Found به این معنی است که مخزن در آن مسیر فایلی ندارد. در pkgs.tailscale.com این مورد تقریباً همیشه به نام رمز (codename) در URL مربوط می‌شود.
  • کد 403 Forbidden به این معنی است که پاسخی دریافت شده اما دسترسی رد شده است. از اوت 2026، این مخزن برای مسیرهایی که وجود ندارند کد 404 برمی‌گرداند؛ بنابراین کد 403 نشان‌دهنده وجود یک پروکسی، ابزار فیلترینگ یا فایروال بین سرور شما و Tailscale است.
  • کدهای 401 Unauthorized یا 407 Proxy Authentication Required به این معنی هستند که یک پروکسی درخواست اعتبارنامه‌هایی را دارد که apt آن‌ها را ارسال نمی‌کند.
  • خطای اتصال (connect error) یا خطای حل نام (name resolution error) به این معنی است که هیچ تبادل HTTP انجام نشده است. به بخش IPv6 بروید.

نام رمز موجود در URL چیزی است که Tailscale آن را منتشر نمی‌کند

Tailscale برای هر نام رمز (codename) اوبونتو یک دایرکتوری جداگانه ایجاد می‌کند. اگر نام رمزی را درخواست کنید که وجود ندارد، با خطای 404 مواجه می‌شوید، زیرا هیچ dists/<codename> روی سرور برای ارائه وجود ندارد. لیست رسمی ارائه‌شده توسط سازنده در pkgs.tailscale.com/stable نشان می‌دهد که کدام نسخه‌ها موجود هستند. در آگوست 2026، این لیست از 16.04 تا resolute که همان Ubuntu 26.04 است، گسترده شده است.

روش معمول برای ورود یک نام رمز اشتباه، استفاده از lsb_release -cs در توزیعی است که بر پایه اوبونتو است اما خود اوبونتو نیست. در Linux Mint 22، این دستور wilma را چاپ می‌کند که نام رمز اختصاصی Mint است و Tailscale هیچ بسته‌ای برای آن منتشر نمی‌کند. در عوض، نسخه پایه اوبونتو را بخوانید.

. /etc/os-release
echo "$VERSION_CODENAME $UBUNTU_CODENAME"

در اوبونتو، هر دو مقدار یکسان هستند. در یک توزیع مشتق‌شده، VERSION_CODENAME نام همان توزیع و UBUNTU_CODENAME نسخه اوبونتویی است که بر پایه آن ساخته شده است. در هر دو URL از UBUNTU_CODENAME استفاده کنید.

روش دوم، ارتقای نسخه (release upgrade) است. ابزار ارتقای اوبونتو هنگام اجرا، مخازن شخص ثالث را غیرفعال می‌کند؛ بنابراین پس از ارتقای Ubuntu 24.04 به 26.04، متوجه می‌شوید که /etc/apt/sources.list.d/tailscale.list یا کامنت شده است و یا همچنان به noble اشاره دارد، در حالی که سیستم اکنون resolute است. این مشکل را با اجرای مجدد دو دستور curl با نام رمز جدید برطرف کنید تا هر دو فایل بازنویسی شوند. اگر خودِ فرآیند ارتقا در میانه راه متوقف شده است و dpkg به جای این مخزن خاص، از بسته‌های نیمه‌پیکربندی‌شده شکایت دارد، ابتدا ارتقای ناموفق نسخه را بازیابی کنید، زیرا هیچ اصلاحی برای tailscale.list روی سیستمی که apt قادر به تکمیل پیکربندی آن نیست، پایدار نخواهد ماند.

روش سوم، زمان‌بندی است. در هفته‌های پس از انتشار یک نسخه جدید اوبونتو، نام رمز آن در Canonical وجود دارد اما هنوز در Tailscale ایجاد نشده است. اشاره دادن فایل به نام رمز LTS قبلی معمولاً باعث نصب می‌شود، زیرا این بسته‌ها وابستگی‌های کمی دارند، اما در این حالت شما در حال اجرای بیلد ساخته‌شده برای یک نسخه قدیمی‌تر هستید. با استفاده از apt policy tailscale بررسی کنید که دقیقاً چه چیزی دریافت کرده‌اید و پس از ظاهر شدن نام رمز واقعی، فایل را به حالت قبل بازگردانید.

کی‌رینگ خالی است و دستوری که آن را نوشته، هیچ خروجی‌ای نداشته است

این مورد بی‌سروصدا است و اکثر این مشکلات به همین‌جا ختم می‌شوند. دوباره به دستور کی‌رینگ نگاه کنید:

curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null

شل (shell) کل پایپ‌لاین (pipeline) را پیش از اجرای برنامه‌ها می‌سازد، بنابراین sudo tee مسیر کی‌رینگ را باز کرده و بلافاصله آن را به صفر بایت کاهش می‌دهد. اگر curl شکست بخورد و -f باعث شود که در هر خطای HTTP متوقف شود، curl هیچ چیزی نمی‌نویسد و با کد خروجی غیرصفر خارج می‌شود. فایل در اندازه صفر بایت باقی می‌ماند. وضعیت خروجی یک پایپ‌لاین، وضعیت آخرین دستور آن است که همان tee است که با موفقیت اجرا شده است. هیچ چیزی چاپ نمی‌شود و شما با تصور اینکه کلید نصب شده است، به سراغ دستور بعدی می‌روید.

فایل را بررسی کنید، نه دستوری که آن را ساخته است.

ls -l /usr/share/keyrings/tailscale-archive-keyring.gpg
gpg --show-keys /usr/share/keyrings/tailscale-archive-keyring.gpg

یک کی‌رینگ سالم، یک خط pub و یک خط uid که نام Tailscale را دارد، چاپ می‌کند. یک فایل صفر بایتی، gpg: no valid OpenPGP data found. و هیچ چیز دیگری چاپ نمی‌کند. فایلی که یک صفحه خطای HTML را دریافت کرده باشد نیز همین را چاپ می‌کند و head -c 80 روی آن، به جای داده‌های باینری کلید، ابتدای یک صفحه وب را نشان می‌دهد.

با کی‌رینگی که هیچ کلید قابل‌استفاده‌ای ندارد، sudo apt update ایندکس را دانلود کرده و سپس آن را رد می‌کند. شما یک خط W: GPG error که نام مخزن Tailscale و suite آن را دارد، متن The following signatures couldn't be verified because the public key is not available: NO_PUBKEY به همراه یک شناسه کلید 16 کاراکتری، و در زیر آن خطایی مبنی بر امضا نشدن مخزن دریافت می‌کنید. به آنچه apt به شما می‌گوید دقت کنید: ایندکس را به‌درستی دانلود کرده، اما نتوانسته امضا را بررسی کند. این یک مشکل کلید است، نه یک مشکل شبکه. اگر فایل کی‌رینگ کلاً وجود نداشته باشد، پیام متفاوت است و مسیر را مستقیماً با Could not open file /usr/share/keyrings/tailscale-archive-keyring.gpg نام می‌برد.

کلید را در دو مرحله بنویسید تا یک دانلود ناموفق، کی‌رینگ سالم را از بین نبرد.

curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.noarmor.gpg -o /tmp/tailscale.gpg
gpg --show-keys /tmp/tailscale.gpg
sudo install -m 0644 -o root -g root /tmp/tailscale.gpg /usr/share/keyrings/tailscale-archive-keyring.gpg

خط میانی حکم دروازه را دارد: اگر یک uid مربوط به Tailscale چاپ نکرد، متوقف شوید و فایل را کپی نکنید. حالت (mode) 0644 اهمیت دارد، زیرا apt برای دریافت و تایید، دسترسی خود را به کاربر بدون امتیاز _apt کاهش می‌دهد؛ بنابراین کی‌رینگی که فقط root بتواند آن را بخواند، کی‌رینگی است که apt نمی‌تواند از آن استفاده کند.

وجود همزمان فایل .list و .sources برای یک مخزن یکسان

اوبونتو در نسخه 24.10 منابع خود را به فرمت deb822 منتقل کرد که در آن /etc/apt/sources.list به /etc/apt/sources.list.d/ubuntu.sources تبدیل شد. Tailscale همچنان مخزن خود را با فرمت تک‌خطی منتشر می‌کند. در بررسی انجام‌شده در اوت 2026، هیچ فایل .sources برای دانلود از pkgs.tailscale.com وجود ندارد و آن URL خطای 404 برمی‌گرداند. بنابراین اگر سیستم شما دارای یک فایل tailscale.sources است، آن را خودتان یا طبق یک راهنما ایجاد کرده‌اید؛ و اگر فایل tailscale.list نیز همچنان موجود باشد، apt اکنون یک مخزن واحد را دو بار شناسایی می‌کند.

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

W: Target Packages (main/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list.d/tailscale.list:1 and /etc/apt/sources.list.d/tailscale.sources:1

حالت جدی زمانی رخ می‌دهد که این دو فایل مسیرهای متفاوتی برای keyring تعریف کرده باشند، زیرا apt نمی‌تواند تشخیص دهد کدام کلید برای مخزن معتبر است. در این حالت، apt پیام E: Conflicting values set for option Signed-By regarding source را به همراه نام مخزن و suite آن، و سپس دو مسیر keyring با عبارت != در میان آن‌ها چاپ کرده و از ادامه عملیات خودداری می‌کند:

E: The list of sources could not be read.

این خطا تمام دستورات apt را مسدود می‌کند و تا زمانی که یکی از فایل‌ها حذف نشود، اجازه اجرای هیچ دستوری را نمی‌دهد. همین خطا ممکن است برای مخازن خود اوبونتو نیز رخ دهد و خطای منبع تکراری apt پس از مهاجرت به deb822 راهنمای کلی برای حل این مشکل است.

پیش از حذف هر فایلی، تمام فایل‌هایی که به Tailscale اشاره دارند را پیدا کنید:

grep -RIn tailscale /etc/apt/sources.list /etc/apt/sources.list.d/

یکی از فایل‌ها را نگه دارید. برای غیرفعال کردن فایل دیگر بدون از دست دادن محتوای آن، نامش را تغییر دهید: apt فقط فایل‌هایی را می‌خواند که با .list یا .sources پایان می‌یابند، بنابراین فایل tailscale.list.bak نادیده گرفته شده و برای ارجاع در دیسک باقی می‌ماند.

نوشتن صحیح فایل منبع deb822

اگر فرمت جدیدتر را ترجیح می‌دهید، فایل موجود خود را تبدیل کنید و آدرس مخزن را دوباره تایپ نکنید، زیرا اشتباه تایپی در آن دقیقاً همان چیزی است که باعث بروز خطاهای بالا می‌شود. نسخه‌های اخیر apt دارای مبدلی هستند که فایل‌های .list را به استنزاهای deb822 بازنویسی کرده و گزینه signed-by را به عنوان Signed-By منتقل می‌کند.

apt modernize-sources --help
sudo apt modernize-sources

نسخه apt در Ubuntu 24.04 قدیمی‌تر از آن است که این زیردستور را داشته باشد، بنابراین خط راهنما در همان لحظه به شما می‌گوید که آیا نسخه شما آن را دارد یا خیر. در مواردی که این قابلیت وجود ندارد، استنزا را از خطی که قبلاً روی دیسک دارید بسازید تا پایه کار از فایل فروشنده گرفته شود، نه از کیبورد شما.

. /etc/os-release
{
  echo 'Types: deb'
  echo "URIs: $(awk '/^deb /{print $3}' /etc/apt/sources.list.d/tailscale.list)"
  echo "Suites: $UBUNTU_CODENAME"
  echo 'Components: main'
  echo 'Signed-By: /usr/share/keyrings/tailscale-archive-keyring.gpg'
} | sudo tee /etc/apt/sources.list.d/tailscale.sources
sudo rm /etc/apt/sources.list.d/tailscale.list

این دستور استنزای نوشته‌شده را چاپ می‌کند تا بتوانید فیلدها را قبل از apt update بعدی بازبینی کنید. چهار مورد از آن‌ها ارزش بررسی دقیق دارند، زیرا هر کدام به روش متفاوتی دچار خطا می‌شوند:

  • URIs در پایه مخزن متوقف می‌شود. چسباندن بخش dists/noble در آن منجر به خطای 404 می‌شود، زیرا apt خودش dists/<suite> را اضافه کرده و درخواست dists/noble/dists/noble می‌کند.
  • Suites نام رمز (codename) است، دقیقاً همان مقداری که در وسط فرمت تک‌خطی قرار داشت.
  • Signed-By یک مسیر مطلق به فایل کلید (keyring) می‌گیرد. این فیلد همچنین کلید armored را که به صورت درون‌خطی در زیر آن قرار گرفته می‌پذیرد، به طوری که هر خط کلید با یک فاصله تورفتگی دارد و هر خط خالی داخل کلید به صورت یک نقطه نوشته می‌شود.
  • Enabled: no یک منبع را بدون حذف کردن غیرفعال می‌کند، که بازگرداندن آن آسان‌تر از تغییر نام است و توضیح دادن آن به نفر بعدی نیز ساده‌تر است.

برای مخازن شخص ثالث، به ازای هر فایل یک استنزا نگه دارید و اگر چندین استنزا را کنار هم قرار دادید، بین آن‌ها یک خط خالی بگذارید. فهرست مخزن، amd64 و arm64 را در میان معماری‌های خود لیست می‌کند، بنابراین یک VPS با معماری ARM نیازی به فیلد اضافی Architectures ندارد.

یک پروکسی در میانه مسیر خطای 403 برمی‌گرداند

از آنجا که مسیری در این مخزن وجود ندارد که پاسخ 404 بدهد، خطای 403 به این معناست که موجودیت دیگری به جای آن پاسخ داده است. ابتدا پیکربندی خود apt را بررسی کنید، زیرا پروکسی تنظیم‌شده در آنجا فقط برای apt اعمال می‌شود و نه برای دستور curl تعاملی شما.

grep -RIn -i proxy /etc/apt/apt.conf.d/ /etc/apt/apt.conf
sudo apt-config dump | grep -i 'acquire::http'

سپس بررسی کنید که apt دقیقاً چه چیزی ارسال می‌کند.

sudo apt -o Debug::Acquire::http=1 update

این دستور خط درخواست، هدرهایی که apt ارسال کرده و پروکسی‌ای که از طریق آن متصل شده است (در صورت وجود) را چاپ می‌کند. آن را با یک دستور curl ساده به همان URL مقایسه کنید. اگر curl کد 200 و apt کد 403 را برگرداند، این دو درخواست در موردی که برای آن واسط (middlebox) اهمیت دارد تفاوت دارند و کاندید معمول برای این تفاوت، user agent است:

curl -sS -o /dev/null -w '%{http_code}\n' -A 'Debian APT-HTTP/1.3' https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease

اگر این دستور خطای 403 برگرداند در حالی که curl پیش‌فرض کد 200 را می‌دهد، یک ابزار فیلترینگ در حال مسدود کردن apt بر اساس نام آن است. راه‌حل این مشکل باید روی همان دستگاه اعمال شود، نه روی سرور شما. یک پروکسی سازمانی که ترافیک TLS را بازرسی می‌کند رفتار متفاوتی دارد: apt به جای کد وضعیت، خطای تأیید گواهی (certificate verification failure) گزارش می‌دهد، زیرا گواهی دریافتی توسط پروکسی صادر شده است و نه توسط مرجع صدور گواهی Tailscale. یک فایروال خروجی ابری (cloud egress firewall) که فقط اجازه دسترسی به مخازن Ubuntu را می‌دهد، منبع رایج دیگر این مشکل است و در آنجا راه‌حل، مجاز کردن pkgs.tailscale.com در فایروال است.

خروجی فقط IPv6 و خطاهایی که کد وضعیت نیستند

اگر apt هیچ پاسخ HTTP دریافت نکرد، هر پروتکل را به‌صورت جداگانه تست کنید.

curl -4 -sS -o /dev/null -w 'v4 %{http_code}\n' https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease
curl -6 -sS -o /dev/null -w 'v6 %{http_code}\n' https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease

زمانی که IPv4 پاسخ می‌دهد اما IPv6 معلق می‌ماند یا خطای Network is unreachable را گزارش می‌کند، apt به این دلیل شکست می‌خورد که کتابخانه resolver اولویت را به IPv6 می‌دهد و سرور مسیر IPv6 فعالی ندارد. برای تأیید این فرضیه، یک بار اجرا را روی IPv4 اجبار کنید:

sudo apt -o Acquire::ForceIPv4=true update

اگر آن به‌روزرسانی موفقیت‌آمیز بود، آن را دائمی کنید.

echo 'Acquire::ForceIPv4 "true";' | sudo tee /etc/apt/apt.conf.d/99force-ipv4

در مورد حالت عکس، صادق باشید. روی یک VPS که اصلاً آدرس IPv4 ندارد، اجبار به استفاده از IPv4 هیچ مشکلی را حل نمی‌کند، زیرا مسیر IPv4ای برای هدایت ترافیک وجود ندارد. در آنجا به NAT64 همراه با DNS64 از سمت ارائه‌دهنده خود نیاز دارید، یا یک پروکسی که دارای آدرس IPv4 باشد. نشانه این وضعیت، خطای اتصال (connect error) است که یک آدرس IPv6 را نام می‌برد، بنابراین خط curl -6 همان جایی است که حقیقت را به شما می‌گوید.

روش‌های جایگزین و هزینه هر کدام

اسکریپت نصب فروشنده. دستور curl -fsSL https://tailscale.com/install.sh | sh همان دستوری است که Tailscale تبلیغ می‌کند. با خواندن اسکریپت، متوجه می‌شوید که توزیع سیستم‌عامل شما را از طریق /etc/os-release شناسایی کرده و سپس همان دو مسیری که این راهنما در حال اصلاح آن‌ها بوده، یعنی /usr/share/keyrings/tailscale-archive-keyring.gpg و /etc/apt/sources.list.d/tailscale.list را از همان URLها می‌نویسد. این موضوع برای انتظارات شما اهمیت دارد: این روش نمی‌تواند مخزنی را که توسط پروکسی مسدود شده دور بزند. این روش دقیقاً با همان خطا مواجه می‌شود، با این تفاوت که خروجی کمتری ارائه می‌دهد. پایپ کردن یک اسکریپت دانلود شده به یک shell با دسترسی root، یک معامله است، نه یک راه‌حل؛ زیرا شما به هر آنچه سرور در آن لحظه بازمی‌گرداند اعتماد می‌کنید و هیچ نسخه‌ای از آنچه اجرا شده است نگه نمی‌دارید. اگر این معامله را می‌پذیرید، با آگاهی کامل آن را انجام دهید:

curl -fsSL https://tailscale.com/install.sh -o install.sh
less install.sh
sh install.sh

فایل‌های باینری استاتیک. همان سرور، فایل‌های tarball ساده را در بخش static binaries در pkgs.tailscale.com/stable منتشر می‌کند. تا آگوست 2026، نسخه پایدار 1.102.2 است و فایل 64 بیتی x86 با نام tailscale_1.102.2_amd64.tgz شناخته می‌شود. شما خودتان کلاینت tailscale و دیمون tailscaled را در جای مناسب قرار می‌دهید و خودتان بر دیمون نظارت می‌کنید، بنابراین هیچ مسیر apt upgrade وجود ندارد و هر به‌روزرسانی در آینده، دانلودی است که باید خودتان آن را به خاطر بسپارید. این روش برای میزبان‌های ایزوله (air-gapped) یا زمانی که مجبور هستید یک نسخه دقیق را ثابت نگه دارید، مناسب است.

بسته اختصاصی اوبونتو. چنین بسته‌ای وجود ندارد. اجرای sudo apt install tailscale بدون پیکربندی مخزن فروشنده، به E: Unable to locate package tailscale ختم می‌شود و هیچ مقدار apt update این وضعیت را تغییر نمی‌دهد. اگر آنچه واقعاً می‌خواهید یک سرور هماهنگ‌کننده تحت کنترل خودتان است و نه سرور میزبانی‌شده توسط Tailscale، این یک تصمیم جداگانه است: اجرای Headscale به عنوان سرور کنترل شخصی این موضوع را پوشش می‌دهد و مقایسه بین Tailscale و WireGuard ساده بررسی می‌کند که آیا اصلاً به این تشکیلات نیاز دارید یا خیر.

بسته نصب شد، اما tailscaled اجرا نمی‌شود

پس از اتمام موفقیت‌آمیز apt، خطاها به سمت daemon منتقل می‌شوند.

systemctl status tailscaled
sudo journalctl -u tailscaled -n 50

در یک VPS که از مجازی‌سازی کانتینری استفاده می‌کند و هسته (kernel) میزبان را به اشتراک می‌گذارد، مانند LXC یا OpenVZ، لاگ‌ها حاوی خطی درباره عدم وجود /dev/net/tun هستند. این daemon برای ایجاد رابط tailscale0 به یک دستگاه TUN نیاز دارد، در حالی که چنین دستگاهی به کانتینر اختصاص داده نشده است. از ارائه‌دهنده خود بخواهید TUN را روی کانتینر فعال کند، یا به یک طرح KVM مهاجرت کنید که در آن هسته اختصاصی خود را دارید. در KVM، این مورد بدون نیاز به تنظیمات اضافی کار می‌کند.

پس از آن، sudo tailscale up یک URL ورود نمایش می‌دهد و tailscale status باید دستگاه شما را با یک آدرس در محدوده 100.64.0.0/10 فهرست کند. دستگاهی که در آنجا ظاهر می‌شود، دستگاهی است که می‌توانید بر پایه آن اقدام کنید؛ خواه این اقدام به معنای معرفی یک زیرشبکه خصوصی از VPS باشد یا استفاده از VPS به عنوان یک exit node.

FAQ

چرا apt می‌گوید مخزن Tailscale امضا نشده است؟

زیرا apt فهرست مخزن را دانلود کرده اما نتوانسته امضای آن را با /usr/share/keyrings/tailscale-archive-keyring.gpg تأیید کند. دلیل معمول این است که keyring صفر بایت است: sudo tee فایل را پیش از آنکه curl موفق به دانلود چیزی شود قطع کرده و چون tee موفقیت‌آمیز بوده، کل pipeline گزارش موفقیت داده است. دستور gpg --show-keys /usr/share/keyrings/tailscale-archive-keyring.gpg را اجرا کنید. یک keyring سالم، یک خط pub و یک خط uid که نام Tailscale را دارد چاپ می‌کند، در حالی که یک فایل خالی یا خراب، gpg: no valid OpenPGP data found. را چاپ می‌کند. کلید را در یک فایل موقت دانلود کنید، آن را بررسی کرده و سپس با مجوز 0644 در جای خود کپی کنید تا کاربر _apt بتواند آن را بخواند.

در URLهای Tailscale باید از کدام نام رمز (codename) اوبونتو استفاده کنم؟

از مقدار UBUNTU_CODENAME در فایل /etc/os-release استفاده کنید که در Ubuntu 24.04 برابر با noble و در Ubuntu 26.04 برابر با resolute است. در توزیع‌های مشتق‌شده از اوبونتو از lsb_release -cs استفاده نکنید: در Linux Mint 22 این دستور wilma را چاپ می‌کند، Tailscale هیچ فایلی با این نام منتشر نمی‌کند و apt خطای 404 روی dists/wilma/InRelease گزارش می‌دهد. پیش از ویرایش هر فایلی، انتخاب خود را با دریافت دستی فهرست توسط curl -sS -o /dev/null -w '%{http_code}\n' از https://pkgs.tailscale.com/stable/ubuntu/dists/<codename>/InRelease تأیید کنید.

آیا اجرای اسکریپت نصب Tailscale از طریق pipe به shell امن است؟

این انتخابی است که باید آگاهانه انجام دهید. اسکریپت از طرف Tailscale ارائه شده و همان کارهای مراحل دستی را انجام می‌دهد: /etc/os-release را می‌خواند، همان keyring و همان /etc/apt/sources.list.d/tailscale.list را می‌نویسد و سپس بسته را نصب می‌کند. هزینه این کار این است که شما هر چه سرور در آن لحظه برمی‌گرداند را با دسترسی root اجرا می‌کنید و هیچ رکوردی از آن نگه نمی‌دارید. آن را با -o install.sh دانلود کنید، بخوانید و اگر می‌خواهید بدون ریسک کورکورانه از راحتی آن بهره‌مند شوید، سپس آن را اجرا کنید. این روش همچنین برای مخزن مسدود شده کمکی نمی‌کند، زیرا از همان URLهایی استفاده می‌کند که قبلاً با شکست مواجه شده‌اند.

چگونه Tailscale را روی اوبونتو بدون مخزن apt نصب کنم؟

از فایل‌های tarball استاتیک منتشرشده در pkgs.tailscale.com استفاده کنید که تا اوت 2026 در نسخه 1.102.2 با فایل amd64 به نام tailscale_1.102.2_amd64.tgz موجود هستند. شما باید برنامه‌های tailscale و tailscaled را خودتان نصب کرده و daemon را تحت systemd اجرا کنید. هزینه این کار مربوط به ارتقاهاست: هیچ بسته apt برای دریافت نسخه جدید وجود ندارد، بنابراین هر به‌روزرسانی باید دستی انجام شود. آرشیو اوبونتو هیچ بسته tailscale اختصاصی ندارد، بنابراین sudo apt install tailscale روی دستگاهی که مخزن رسمی را ندارد، در مرحله E: Unable to locate package tailscale متوقف می‌شود.