פתרון שגיאות התקנה של Tailscale ב-Ubuntu

מדוע שגיאות התקנה של Tailscale ב-Ubuntu הן שגיאות apt

שגיאות התקנה של Tailscale ב-Ubuntu מתרחשות כמעט תמיד לפני שקוד כלשהו של Tailscale מופעל. אלו הן שגיאות של apt. מערכת Ubuntu אינה מפיצה חבילת tailscale משל עצמה: בבדיקה מול מאגר החבילות של Ubuntu באוגוסט 2026, ההתאמות היחידות שנמצאו הן ספריות עזר של Go ו-python3-tailscale, לכן ה-daemon חייב להגיע ממאגר ה-apt של Tailscale בכתובת pkgs.tailscale.com.

הוספת מאגר זה יוצרת שני קבצים. קובץ אחד מורה ל-apt היכן נמצאות החבילות. הקובץ השני מכיל את מפתח ה-public key ש-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, והוא מופיע בשתי הכתובות. הפקודה השנייה כותבת שורת הערה ושורת 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. אם אתם יכולים למשוך את ה-URL הזה ידנית, גם 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 מדובר כמעט תמיד בשם הקוד (codename) המופיע ב-URL.
• 403 Forbidden מציין שגורם כלשהו השיב וסירב לבקשה. נכון לאוגוסט 2026, מאגר זה מחזיר 404 עבור נתיב שאינו קיים, לכן קוד 403 מצביע על proxy, התקן סינון או firewall הנמצאים בין השרת שלכם לבין Tailscale.
• 401 Unauthorized או 407 Proxy Authentication Required מציינים ש-proxy דורש אימות (credentials) ש-apt אינו שולח.
• שגיאת חיבור או שגיאת פתרון שמות (name resolution) משמעותן שלא התקיימה תקשורת 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 כשהוא מוער (commented out) או עדיין מצביע על noble במכונה שהיא כעת resolute. תקנו זאת על ידי הרצה חוזרת של שתי פקודות ה-curl עם שם הקוד החדש, אשר ידרסו את שני הקבצים.

הדרך השלישית היא עיתוי. בשבועות שלאחר שחרור גרסת Ubuntu חדשה, שם הקוד קיים אצל 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 לא כותב דבר ומסיים עם קוד יציאה שאינו אפס. הקובץ נשאר בגודל אפס בתים. סטטוס היציאה של ה־pipeline הוא הסטטוס של הפקודה האחרונה בו, שהיא 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 המציינת את ה-repository של Tailscale ואת ה-suite שלו, את הטקסט The following signatures couldn't be verified because the public key is not available: NO_PUBKEY ולאחריו מזהה מפתח בן 16 תווים, ותחתיו שגיאה המציינת שה-repository אינו חתום. שימו לב למה ש־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 מתארים את אותו מאגר (repository)

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

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

. /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 נוסף.

שרת proxy בתווך מחזיר שגיאת 403

מכיוון שנתיב שאינו קיים במאגר זה מחזיר 404, שגיאת 403 מעידה על כך שגורם אחר השיב בשמו. התחילו בבדיקת התצורה של apt עצמו, שכן הגדרת proxy שם חלה על 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

פקודה זו מדפיסה את שורת הבקשה, את ה־headers ששלח apt, ואת ה־proxy שאליו התחבר, אם קיים. השוו זאת לבקשת 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 לפי שמו. התיקון נדרש באותו רכיב, לא בשרת שלכם. שרת proxy ארגוני שמבצע בדיקת TLS מתנהג אחרת: apt ידווח על כשל באימות תעודה במקום על קוד סטטוס, כיוון שהתעודה שהתקבלה הונפקה על ידי ה־proxy ולא על ידי רשות התעודות של Tailscale. חומת אש מסוג egress בענן שמאפשרת רק את ה־mirrors של 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 מצד ספק התשתית, או ב-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. זה משמעותי לציפיות שלכם: הוא לא עוקף מאגר (repository) שחוסם proxy. הוא נכשל באותה צורה עם פחות פלט. הזרמת סקריפט שהורד ישירות לתוך shell כ־root היא פשרה, לא פתרון, כיוון שאתם נותנים אמון בכל מה שהשרת מחזיר באותו רגע ואינכם שומרים עותק של מה שהורץ. אם אתם בוחרים בפשרה הזו, עשו זאת בעיניים פקוחות:

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

קבצים בינאריים סטטיים. אותו שרת מפרסם קובצי tarball פשוטים תחת המקטע של קבצים בינאריים סטטיים ב-pkgs.tailscale.com/stable. נכון לאוגוסט 2026, הגרסה היציבה היא 1.102.2 והקובץ עבור x86 ב-64 ביט הוא tailscale_1.102.2_amd64.tgz. אתם מציבים את הלקוח tailscale ואת ה-daemon‏ tailscaled בעצמכם, ואתם מנהלים את ה-daemon בעצמכם, לכן אין נתיב apt upgrade וכל עדכון עתידי הוא הורדה שאתם צריכים לזכור לבצע. זה מוצדק במארח מנותק מרשת (air gapped), או כאשר עליכם לקבע גרסה מדויקת אחת.

החבילה של Ubuntu. אין כזו. הרצת sudo apt install tailscale ללא הגדרת המאגר של הספק מסתיימת ב-E: Unable to locate package tailscale, ושום כמות של apt update לא תשנה זאת. אם מה שאתם באמת רוצים הוא שרת תיאום (coordination server) בשליטתכם במקום זה שמתארח אצל Tailscale, זו החלטה נפרדת: הרצת Headscale כשרת בקרה עצמי מכסה זאת, ו-ההשוואה בין Tailscale לבין WireGuard רגיל מכסה את השאלה האם אתם זקוקים לכל המערכת הזו.

החבילה הותקנה, אך tailscaled אינו עולה

לאחר ש-apt מסיים את עבודתו בהצלחה, תקלות עלולות להתרחש ברמת ה-daemon.

systemctl status tailscaled
sudo journalctl -u tailscaled -n 50

בשרת VPS המשתמש בווירטואליזציה מבוססת מכולות (container) החולקת את ה-kernel של המארח, כגון LXC או OpenVZ, הלוג יציג שורה המציינת כי /dev/net/tun אינו קיים. ה-daemon זקוק להתקן TUN כדי ליצור את הממשק tailscale0, והמכולה לא קיבלה הרשאה לכך. בקשו מהספק שלכם להפעיל TUN במכולה, או עברו לתוכנית KVM שבה יש לכם kernel עצמאי. ב-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 הספיק להוריד משהו, וצינור הפקודה (pipeline) דיווח על הצלחה מכיוון ש-tee הסתיים בהצלחה. הריצו את gpg --show-keys /usr/share/keyrings/tailscale-archive-keyring.gpg. קובץ keyring תקין מדפיס שורת pub ושורת uid המציינת את Tailscale, בעוד שקובץ ריק או פגום מדפיס gpg: no valid OpenPGP data found.. הורידו את המפתח לקובץ זמני, בדקו אותו שם, ולאחר מכן העתיקו אותו למקומו עם הרשאות 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?

השתמשו בקובצי ה-tarball הסטטיים המפורסמים ב-pkgs.tailscale.com, אשר נכון לאוגוסט 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.