תיקון שגיאות התקנת Tailscale ב־Ubuntu

מדוע שגיאות בהתקנת 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, ולבסוף הרכיב main. apt מחבר את הבסיס ואת ה־suite לכתובת URL אחת ומוריד ממנה את התוכן: https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease. אם אפשר להוריד את הכתובת הזאת באופן ידני, apt יכול להוריד אותה גם כן. זהו כל האבחון הנדרש.

קראו את שגיאת apt לפני שאתם משנים דבר

הריצו את העדכון בנפרד, כדי ששום פלט אחר לא יגלול את השגיאה מחוץ למסך.

sudo apt update

מאגר צד שלישי שנכשל נראה כך. שם הקוד וכתובת ה־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

הפקודה מדפיסה 200 עבור שם קוד ש־Tailscale מפרסמת עבורו מאגר. בבדיקה שנערכה באוגוסט 2026, noble מחזירה אינדקס חתום שמכיל את Origin: Tailscale ואת Codename: noble. החליפו את noble בשם הקוד שמופיע בשגיאה שלכם והריצו את הפקודה שוב. אם curl מקבלת 200 במקום השגיאה שקיבל apt, המאגר תקין והבעיה נמצאת בתצורה הפנימית של apt.

מה קוד הסטטוס אומר

• 404 Not Found פירושו שאין במאגר קובץ בנתיב הזה. ב־pkgs.tailscale.com זה כמעט תמיד שם הקוד בכתובת ה־URL.
• 403 Forbidden פירושו שרכיב כלשהו השיב ודחה את הבקשה. נכון ל־August 2026, המאגר מחזיר 404 עבור נתיב שאינו קיים בו, ולכן 403 מצביע על proxy, על התקן סינון או על firewall שנמצאים בין השרת שלכם לבין Tailscale.
• 401 Unauthorized או 407 Proxy Authentication Required פירושם ש־proxy דורש פרטי התחברות ש־apt אינו שולח.
• שגיאת חיבור או שגיאת פתרון שמות פירושה שלא התנהלה כלל תקשורת HTTP. עברו לסעיף IPv6.

שם הקוד בכתובת ה־URL אינו מופץ על ידי Tailscale

Tailscale בונה תיקייה נפרדת לכל שם קוד של Ubuntu. אם מבקשים שם קוד שאינו קיים, מתקבלת שגיאת 404, משום שאין בשרת dists/<codename> שאפשר להגיש. הרשימה של הספק עצמו בכתובת pkgs.tailscale.com/stable מציגה אילו שמות קוד קיימים. באוגוסט 2026 הרשימה נעה מ־16.04 עד resolute, שהיא Ubuntu 26.04.

הדרך הנפוצה שבה נכנס שם קוד שגוי היא lsb_release -cs בהפצה המבוססת על Ubuntu אך אינה Ubuntu. ב־Linux Mint 22 הפקודה מדפיסה wilma, שהוא שם הקוד של Mint, ו־Tailscale אינו מפרסם עבורו דבר. קראו במקום זאת את בסיס Ubuntu.

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

ב־Ubuntu שני הערכים זהים. בהפצה נגזרת, VERSION_CODENAME הוא שם ההפצה הנגזרת ו־UBUNTU_CODENAME הוא המהדורה של Ubuntu שעליה היא מבוססת. השתמשו ב־UBUNTU_CODENAME בשתי כתובות ה־URL.

הדרך השנייה היא שדרוג מהדורה. כלי השדרוג של Ubuntu משבית מקורות של צד שלישי במהלך פעולתו, ולכן לאחר שדרוג Ubuntu 24.04 ל־26.04 תמצאו את /etc/apt/sources.list.d/tailscale.list כשהוא מסומן כהערה, או כשהוא עדיין מציין את noble במחשב שכעת פועל עם resolute. תקנו זאת באמצעות הרצה מחדש של שתי פקודות curl עם שם הקוד החדש. הפקודות יחליפו את שני הקבצים. אם השדרוג עצמו נעצר באמצע, כך ש־dpkg מדווח על חבילות שהוגדרו באופן חלקי ולא רק על בעיה במאגר הזה, שחזרו את שדרוג המהדורה שנכשל תחילה, משום ששום תיקון ל־tailscale.list לא יישמר במערכת שבה apt אינו מצליח להשלים את ההגדרה.

הדרך השלישית היא תזמון. בשבועות שלאחר יציאת מהדורת Ubuntu חדשה, שם הקוד קיים אצל Canonical לפני שהוא קיים אצל Tailscale. הפניית הקובץ לשם הקוד של ה־LTS הקודם מתקינה בדרך כלל את החבילות, משום שיש להן מעט תלויות, אך במקרה כזה אתם מריצים build שנוצר עבור מהדורה ישנה יותר. בדקו מה הותקן בפועל באמצעות 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 פותח את הנתיב של מחזיק המפתחות ומקצר אותו מיד ל־0 בתים. אם curl נכשל, ו־-f גורם לו להיכשל בכל שגיאת HTTP, curl אינו כותב דבר ומסתיים בקוד יציאה שאינו 0. הקובץ נשאר בגודל 0 בתים. סטטוס היציאה של pipeline הוא הסטטוס של הפקודה האחרונה בו, כלומר tee, שהצליחה. לא מוצג דבר, ואתם עוברים לפקודה הבאה מתוך הנחה שהמפתח הותקן.

בדקו את הקובץ, ולא את הפקודה שיצרה אותו.

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

מחזיק מפתחות תקין מציג שורה מסוג pub ושורה מסוג uid שמציינת את Tailscale. קובץ בגודל 0 בתים מציג 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, עצרו ואל תעתיקו את הקובץ. מצב ההרשאות 0644 חשוב, משום ש־apt עובר למשתמש חסר ההרשאות _apt כדי להוריד ולאמת, ולכן מחזיק מפתחות שרק root יכול לקרוא הוא מחזיק מפתחות ש־apt אינו יכול להשתמש בו.

קובץ .list וקובץ .sources מתארים את אותו מאגר

Ubuntu העבירה את מקורות החבילות שלה לפורמט deb822 ב־Ubuntu 24.10, כאשר /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 אינו יכול לקבוע איזה מפתח מאמת את המאגר. הוא מדפיס את E: Conflicting values set for option Signed-By regarding source, לאחר מכן את המאגר ואת ה־suite שלו, אחר כך את שני נתיבי ה־keyring כאשר != מפריד ביניהם, ולבסוף מסרב להמשיך:

E: The list of sources could not be read.

מצב זה חוסם כל פקודת apt, ולא רק את פעולת העדכון, עד שאחד הקבצים יוסר. אותו כשל מופיע גם במאגרים של Ubuntu עצמה, והמאמר שגיאת מקור apt כפול לאחר מעבר ל־deb822 מסביר את המקרה הכללי.

מצאו כל קובץ שמכיל אזכור ל־Tailscale לפני שתמחקו דבר.

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

השאירו קובץ אחד. כדי להשבית את הקובץ האחר בלי לאבד אותו, שנו את שמו: ‏apt קורא רק קבצים המסתיימים ב־.list או ב־.sources, ולכן tailscale.list.bak ידולג ויישאר בדיסק לעיון עתידי.

כתיבה נכונה של קובץ המקורות בפורמט deb822

אם אתם מעדיפים את הפורמט החדש יותר, המירו את הקובץ שכבר קיים במקום להקליד מחדש את כתובת המאגר. שגיאת הקלדה בכתובת היא בדיוק הדרך שבה השגיאות שלמעלה מתחילות. גרסאות apt עדכניות כוללות ממיר שממיר קובצי .list ל־stanzas בפורמט deb822 ומעביר את האפשרות signed-by בתור Signed-By.

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

Ubuntu 24.04 מגיעה עם גרסת apt שקדמה לפקודת המשנה הזו, ולכן שורת העזרה מראה בתוך שנייה אם היא קיימת אצלכם. אם היא אינה קיימת, בנו את ה־stanza מהשורה שכבר נמצאת בדיסק, כדי שה־base יילקח מהקובץ של הספק ולא מהמקלדת שלכם.

. /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

הפקודה מדפיסה את ה־stanza שכתבה, כדי שתוכלו לקרוא שוב את השדות לפני ה־apt update הבא. כדאי להכיר ארבעה מהם בפירוט, משום שכל אחד מהם נכשל בדרך אחרת:

• URIs נעצר ב־base של המאגר. הדבקת החלק dists/noble לתוכו גורמת ל־404, משום ש־apt מוסיף בעצמו את dists/<suite> ומבקש את dists/noble/dists/noble.
• Suites הוא שם הקוד, בדיוק הערך שהיה באמצע הפורמט של שורה אחת.
• Signed-By מקבל נתיב מוחלט לקובץ keyring. הוא מקבל גם מפתח בפורמט armored שמוטמע מתחתיו, כאשר כל שורה במפתח מוזחת ברווח אחד וכל שורה ריקה בתוך המפתח נכתבת כנקודה יחידה.
• Enabled: no משבית מקור בלי למחוק אותו. כך קל יותר לבטל את השינוי מאשר לאחר שינוי שם, וגם קל יותר להסביר את המצב לאדם הבא.

שמרו stanza אחד בכל קובץ עבור מאגרי צד שלישי, והוסיפו שורה ריקה בין stanzas אם אתם שומרים כמה מהם יחד. אינדקס המאגר מציין את 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, שתי הבקשות שונות בפרט שרכיב התווך מתייחס אליו. המועמד הרגיל הוא סוכן המשתמש:

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 מדווח על כשל באימות תעודה במקום על קוד סטטוס, משום שהתעודה שקיבל הונפקה על ידי הפרוקסי ולא על ידי רשות האישורים של Tailscale. מקור נפוץ נוסף הוא firewall בענן שמאפשר רק את מראות Ubuntu. במקרה כזה, יש לאפשר ב־firewall את 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 מצד הספק, או proxy שמחזיק כתובת IPv4. התסמין הוא שגיאת חיבור שמציינת כתובת 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-ים. הדבר חשוב לתיאום הציפיות: הסקריפט אינו עוקף מאגר ש־proxy חוסם. הוא נכשל באותה צורה, עם פחות פלט. הזרמת סקריפט שהורד אל 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. נכון ל־August 2026, הגרסה היציבה היא 1.102.2 והקובץ עבור x86 של 64 סיביות הוא tailscale_1.102.2_amd64.tgz. אתם ממקמים בעצמכם את הלקוח tailscale ואת הדמון tailscaled, ומפקחים בעצמכם על הדמון, ולכן אין נתיב apt upgrade וכל עדכון עתידי הוא הורדה שתצטרכו לזכור לבצע. אפשרות זו מתאימה לשרת מנותק־רשת, או למצב שבו אתם חייבים לנעול גרסה מדויקת אחת.

החבילה של Ubuntu עצמה. אין חבילה כזו. הפעלת 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 המשתמש בווירטואליזציה מבוססת מכולות ומשתף את ליבת ה־host, כגון LXC או OpenVZ, הלוג כולל שורה המציינת ש־/dev/net/tun אינו קיים. ה־daemon זקוק להתקן TUN כדי ליצור את ממשק tailscale0, אך המכולה לא קיבלה התקן כזה. בקשו מהספק להפעיל TUN במכולה, או עברו למסלול KVM שבו מוקצית לכם ליבה משלכם. ב־KVM הדבר פועל ללא הגדרה נוספת.

לאחר מכן, sudo tailscale up מציג כתובת URL להתחברות, ו־tailscale status אמור להציג את המכונה שלכם עם כתובת בטווח 100.64.0.0/10. מכונה שמופיעה שם היא בסיס מתאים להמשך, בין אם לצורך פרסום רשת משנה פרטית מה־VPS שלכם ובין אם לצורך שימוש ב־VPS כצומת יציאה.

FAQ

מדוע apt מציג שהמאגר של Tailscale אינו חתום?

משום ש־apt הוריד את האינדקס של המאגר ולא הצליח לאמת את החתימה שלו מול /usr/share/keyrings/tailscale-archive-keyring.gpg. הסיבה השכיחה היא שקובץ keyring הוא בגודל אפס: sudo tee קיצר את הקובץ לפני ש־curl נכשל בהורדת תוכן כלשהו, וה־pipeline דיווח על הצלחה משום ש־tee הצליח. הריצו את gpg --show-keys /usr/share/keyrings/tailscale-archive-keyring.gpg. קובץ keyring תקין מציג שורת pub ושורת uid שבה מופיע השם Tailscale, ואילו קובץ ריק או פגום מציג gpg: no valid OpenPGP data found. הורידו את המפתח לקובץ זמני, בדקו אותו שם, ולאחר מכן העתיקו אותו למקומו עם mode 0644, כדי שהמשתמש _apt יוכל לקרוא אותו.

באיזה codename של Ubuntu עליי להשתמש בכתובות ה־URL של Tailscale?

השתמשו בערך של UBUNTU_CODENAME מתוך /etc/os-release. הערך הוא noble ב־Ubuntu 24.04 ו־resolute ב־Ubuntu 26.04. אל תשתמשו ב־lsb_release -cs בהפצה המבוססת על Ubuntu: ב־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 כשהוא מוזרם ל־shell?

זהו שיקול שיש לקבל במודע. הסקריפט מגיע מ־Tailscale ומבצע את אותן פעולות כמו השלבים הידניים: הוא קורא את /etc/os-release, כותב את אותו keyring ואת אותו /etc/apt/sources.list.d/tailscale.list, ולאחר מכן מתקין את החבילה. המחיר הוא שהשרת מריץ כל תוכן שהוא מחזיר באותו רגע, בהרשאות root, ושאין לכם תיעוד של התוכן. הורידו אותו באמצעות -o install.sh, קראו אותו, ולאחר מכן הריצו אותו אם אתם מעוניינים בנוחות בלי לוותר על היכולת לבדוק את התוכן. הסקריפט גם אינו יכול לסייע כאשר המאגר חסום, משום שהוא משתמש באותן כתובות URL שכבר נכשלו.

כיצד מתקינים Tailscale ב־Ubuntu בלי מאגר apt?

השתמשו ב־tarballs הסטטיים שפורסמו ב־pkgs.tailscale.com. נכון ל־August 2026, הם בגרסה 1.102.2, וכוללים קובץ amd64 בשם tailscale_1.102.2_amd64.tgz. עליכם להתקין בעצמכם את התוכניות tailscale ו־tailscaled ולהפעיל בעצמכם את ה־daemon באמצעות systemd. המחיר הוא עדכונים: אין חבילת apt שתוריד גרסה חדשה, ולכן כל עדכון מתבצע ידנית. הארכיון של Ubuntu אינו כולל חבילת tailscale משלו, ולכן sudo apt install tailscale במחשב ללא מאגר הספק נעצר ב־E: Unable to locate package tailscale.