האם Tailscale מאובטח? ניתוח מודל האמון והצפנה

האם Tailscale מאובטח? התשובה הקצרה

האם Tailscale מאובטח? עבור החלק שרוב האנשים חוששים ממנו, התשובה היא כן: שרת התיאום (coordination server) שמנהל את ה-tailnet שלכם לעולם אינו מחזיק במפתחות הפרטיים שמצפינים את התעבורה שלכם, ולכן הוא אינו יכול לקרוא את המידע שהמכשירים שלכם מעבירים זה לזה. דף האבטחה של Tailscale מצהיר על כך במפורש: "מפתחות פרטיים לעולם אינם עוזבים את המכשיר. כל התעבורה מוצפנת מקצה לקצה, תמיד". השאלה המועילה היא אחרת. שרת תיאום שנפרץ, או שפועל תחת צו משפטי, אינו צריך לקרוא את החבילות שלכם. הוא מחליט אילו מפתחות ציבוריים המכשירים שלכם יבטחו בהם, ולכן הוא יכול לרשום מכשיר שמעולם לא אישרתם.

זהו מודל האמון במשפט אחד: ההצפנה מגנה על הנתונים, ומישור הבקרה (control plane) קובע את החברות ברשת. כל סעיף להלן מציין גורם אחד שאתם נדרשים לתת בו אמון, מפרט מה אותו גורם יכול לעשות בפועל, ומציג את הבקרה שמגבילה אותו. אם המוצר עצמו חדש לכם, התחילו ב-מהו Tailscale וכיצד פועלת רשת ה-mesh שלו.

מישור הבקרה ומישור הנתונים מופרדים

Tailscale הוא VPN (רשת וירטואלית פרטית) מסוג mesh הבנוי על גבי WireGuard, אותו פרוטוקול שהייתם מגדירים ידנית ב-שרת WireGuard בניהול עצמי. כל התקן מייצר זוג מפתחות WireGuard משלו באופן מקומי. הפוסט של Tailscale בנושא איך זה עובד מכנה את שרת התיאום "תיבת דואר משותפת למפתחות ציבוריים" ומציין כי "המפתח הפרטי לעולם, אבל לעולם, אינו עוזב את הצומת שלו".

מישור הנתונים הוא התעבורה המוצפנת בין ההתקנים שלכם. היא עוברת מהתקן להתקן, ישירות בכל פעם שהרשת מאפשרת זאת. מישור הבקרה הוא כל השאר: אילו התקנים שייכים ל-tailnet, איזה מפתח ציבורי שייך לאיזה התקן, מדיניות הגישה, הגדרות ה-DNS ורשימת ה-relay. Tailscale מפעילה את מישור הבקרה כשירות מנוהל. אתם מריצים את מישור הנתונים על המכונות שלכם.

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

מה יכול לעשות שרת תיאום שנפרץ?

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

הוא יכול לרשום צומת (node) חדש. כאשר Tailscale הכריזה על tailnet lock, החברה תיארה את הסיכון במילים שלה: שרת זדוני יכול "להשתמש בצומת שנוסף בחשאי כדי לשלוח או לקבל תעבורה לצמתים הקיימים שלכם", ובשלב זה "לא ישנה שהתעבורה מוצפנת, כיוון שהצומת עצמו יהיה זדוני". המכשיר שלכם נותן אמון בצומת אחר כיוון שמישור הבקרה (control plane) הורה לו שהמפתח שייך ל-tailnet.

הוא יכול לשנות את היעדים שאליהם המכשירים שלכם מורשים לגשת. מדיניות הגישה מאוחסנת במישור הבקרה ומופצת לצמתים. ה-White paper על tailnet lock של Tailscale מציין כי tailnet lock "אינו מונע ממישור בקרה שנפרץ לשבש את הקישוריות ברשת שלכם, למשל על ידי אי-הפצה של מפתחות צומת חדשים, או הפצה של מדיניות בקרת גישה שחוסמת גישה לכל הצמתים".

הוא רואה מטא-דאטה של חיבורים בכל מקרה. יומני זרימת הרשת של Tailscale מתעדים אירועי פתיחה וסגירה של כל חיבור בין מכונות. התיעוד מציין כי יומנים אלו "אינם מכילים בשום אופן מידע על פעולות הלקוח או על תוכן תעבורת הרשת". לכן, מישור הבקרה יכול לדעת אילו מהמכשירים שלכם תקשרו עם אילו, ומתי. הוא אינו יודע מה נאמר בשיחות אלו.

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

ספק הזהות שלכם הוא שורש האמון של ה-tailnet

ל-Tailscale אין מסד נתונים של סיסמאות משל עצמה. התיעוד שלה מבהיר שאין סיסמאות Tailscale, וההתחברות מואצלת לספק זהות (IdP): Apple, Google, GitHub, Microsoft, Okta, OneLogin, או ספק OpenID Connect מותאם אישית.

התייחסו לכך כאל הצהרת אבטחה, שכן זהו המצב. כל מי שיכול להתחבר לחשבון ה-Google או ה-Microsoft שלכם יכול להתחבר ל-tailnet שלכם. אימות רב-גורמי (MFA) שלכם הוא מה שה-IdP אוכף. תהליך העזיבה (offboarding) שלכם הוא מה שה-IdP מבצע כאשר אדם עוזב את הארגון. חשבון IdP שנפרץ בפישינג הוא חשבון tailnet, והתוקף לעולם לא יצטרך לתקוף את WireGuard: הוא פשוט יוסיף התקן ויירש את כל ההרשאות שהמדיניות שלכם מעניקה לאותו משתמש.

שני בקרים עומדים בין חשבון זהות גנוב לבין התקן פעיל בתוך ה-tailnet שלכם: אישור התקנים (device approval) ותפוגת מפתח (key expiry). נעילת ה-tailnet (tailnet lock) היא אמצעי שלישי, והיא מכוונת למישור הבקרה (control plane) ולא לחשבון עצמו.

אישור התקנים: שום דבר לא מצטרף לפני שניתן אישור אנושי

התיעוד של Tailscale מתאר את אישור ההתקנים כתכונה המאפשרת למנהלי רשת Tailscale לבחון ולאשר התקנים חדשים לפני שהם יכולים להצטרף לרשת ה־Tailscale שלכם. בעלים (Owner), מנהל (Admin) או מנהל IT יכולים לבצע את האישור. התקן חדש יציג תג "Needs approval" בדף ה-Machines עד שמישהו יפעל בנושא.

הפעלת תכונה זו משנה את התרחיש של חשבון שנפרץ. התוקף מבצע התחברות, ההתקן נרשם, ואז הוא ממתין ללא יכולת להגיע לשום יעד, לצד תג במסוף הניהול שלכם המודיע לכם שמכונה שאינכם מזהים מבקשת להצטרף. אוטומציה עדיין עובדת, כיוון שניתן לסמן מפתח אימות (auth key) כמאושר מראש בעת יצירתו, וניתן לאשר התקנים גם דרך ה-API.

מפתחות אימות הם דרך כניסה נוספת, לכן התייחסו אליהם כאל פרטי הזדהות. התיעוד של Tailscale מתבטא בבירור לגבי הסוג המסוכן: "היזהרו מאוד עם מפתחות לשימוש חוזר! אלו עלולים להיות מסוכנים מאוד אם ייגנבו. עדיף לשמור אותם במוצר כספת מפתחות (key vault) שתוכנן במיוחד למטרה זו". נכון לאוגוסט 2026, טווח התפוגה המתועד למפתחות הוא 1 עד 90 ימים, ותפוגה שלא צוינה כברירת מחדל תוגדר למקסימום של 90 ימים. העדיפו מפתחות חד-פעמיים, סמנו אותם כזמניים (ephemeral) עבור מכונות שמופיעות ונעלמות, ושמרו כל מפתח לשימוש חוזר כשהוא מוצפן באמצעות Ansible Vault או בתוך מנהל סודות (secrets manager), ולא בתוך סקריפט shell.

תפוגת מפתח: הטיימר שמגביל כל טעות אחרת

מפתחות של צמתים (nodes) פוקעים, וזה מה שהופך מכשיר גנוב או נשכח לבעיה זמנית בלבד. התיעוד של Tailscale מציין כי "כברירת מחדל, דומיינים חדשים מוגדרים עם תקופת תפוגה של 180 ימים", וכי "אם אימות מחדש לא מתבצע, המפתחות פוקעים והחיבורים אל/מנקודת הקצה הנתונה יפסיקו לעבוד". ניתן לבצע אימות מחדש למכשיר באופן עצמאי:

tailscale up --force-reauth

התיעוד מזהיר כי פעולה זו "עלולה להפיל את חיבור ה-tailnet, ולכן אין לבצע אותה מרחוק באמצעות SSH או RDP ללא אמצעי חלופי להתחברות במקרה שהחיבור יאבד". הרצו את הפקודה כשיש לכם גישה לקונסולה, או מנתיב גישה שני למכונה, כיוון שאתם עומדים לנתק את הרשת שבה אתם משתמשים.

שרתים הם המקום שבו השליטה הזו הופכת לגמישה מדי. מכונה שחייבת לעבור אימות מחדש כל 180 ימים עלולה להתנתק מה-tailnet בשעה 3 לפנות בוקר כשאיש אינו משגיח, ולכן מנהלי מערכות משביתים את תפוגת המפתח בה. פעולה זו מסירה את הטיימר שהיה מנטרל בסופו של דבר מפתח גנוב. מכשיר מתויג (tagged device) הוא פתרון עדיף עבור שרת, כיוון שתג הוא הבעלים של המכונה במקום אדם, כך שהמכונה ממשיכה לפעול גם אם אותו אדם עוזב את החברה. ללא קשר להחלטתכם, החזיקו רשימה של המכונות שבהן תפוגת המפתח מושבתת: מפתחות אלו נשארים תקפים עד שתמחקו את המכשיר.

Tailnet lock: הוצאת שרת התיאום משרשרת האמון

Tailnet lock מטפל בבעיית הרישום באופן ישיר. התיעוד של Tailscale בנושא tailnet lock מסביר את המנגנון: "כאשר צומת חדש מצטרף ל-tailnet, מפתח הצומת הציבורי שלו דורש חתימה ממפתח Tailnet Lock. שרת התיאום מפיץ את מפתח הצומת הציבורי החתום לצמתים עמיתים". המכשירים הקיימים שלכם מאמתים את החתימה הזו לפני שהם מקבלים עמית, כך שמפתח צומת שנוצר על ידי ה-control plane באופן עצמאי נדחה.

tailscale lock status
tailscale lock sign nodekey:1abddef1 tlpub:abcdef12

tailscale lock init מפעיל את התכונה, וברגע זה אתם מגדירים את צמתי החתימה שלכם. Tailscale דורשת לפחות שני צמתי חתימה בעת האתחול ומאפשרת לכל היותר 20 ב-tailnet. לאחר מכן, כל מכשיר חדש זקוק לחתימה מאחד מהם, מה שמהווה עלות תפעולית ממשית: הוספת טלפון מחייבת הרצת פקודה ממחשב נייד.

המגבלות מתועדות, והן חשובות יותר מתיאור התכונה עצמה:

• אובדן ה-disablement secret משמעו שאין אפשרות לשחזור. התיעוד מציין: "אם איבדתם את ה-disablement secrets שלכם, ולא סיפקתם אחד לתמיכה של Tailscale, לא ניתן לשחזר את ה-tailnet".
• מפתח החתימה נמצא על מכשיר שבבעלותכם, ולכן הוא יורש את רמת האבטחה של אותו מכשיר. התיעוד מפורש: "אם המכשיר נפרץ, ניתן להשיג את המפתח".
• לא ניתן להפעיל את שני הבקרות במקביל. Tailscale מציינת כי tailnet lock ואישור מכשירים (device approval) מוציאים זה את זה, כך שהפעלת אחד מהם משמעה ויתור על השני.
• מדובר בשיטת Trust on first use (TOFU). ההגדרה הראשונית עדיין עוברת דרך ה-control plane, ועוגן האמון עובר לרשת שלכם רק לאחר השלב הראשון הזה.

Tailnet lock מגן על החברות ברשת. הוא אינו מגן על הזמינות, כפי שמצוין ב-white paper.

האם חיבור מתווך (relayed) חושף את התעבורה שלי?

לא. כאשר שני התקנים אינם יכולים לתקשר זה עם זה ישירות, התעבורה עוברת דרך שרת DERP (ראשי תיבות של Designated Encrypted Relay for Packets). התיעוד של Tailscale מצהיר על מאפיין זה ללא סייגים: "מכיוון שמפתחות פרטיים של Tailscale לעולם אינם עוזבים את ההתקן המקומי שיצר אותם, בלתי אפשרי עבור שרת DERP לפענח את התעבורה שלך. שרת DERP מעביר באופן עיוור תעבורה שכבר הוצפנה מהתקן אחד לאחר".

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

tailscale status
tailscale netcheck

tailscale status מסמן כל עמית (peer) כחיבור ישיר, המופיע כ-direct 203.0.113.10:41641, או כחיבור מתווך, המופיע כ-relay ולאחריו שם השרת המתווך ומוני בתים. עמית שנשאר מחובר דרך שרת תיווך מעיד על כך ששני הקצוות לא הצליחו ליצור נתיב ישיר, בדרך כלל בגלל שפרוטוקול UDP חסום בנקודה כלשהי או בגלל ששני הצדדים נמצאים מאחורי NAT (תרגום כתובות רשת) מחמיר. tailscale netcheck מדווח האם UDP עובד כלל מהמכונה הזו, כיצד ה-NAT שלכם ממפה פורטים, ומהו השיהוי (latency) לשרתי התיווך הקרובים ביותר, מה שיסייע לכם להבין איזו משתי הסיבות הללו היא הגורם לבעיה. אם החיבור לעמית הוא כבר ישיר וקצב העברת הנתונים עדיין מאכזב, השרת המתווך אינו הבעיה, ואי-התאמה ב-MTU של הנתיב היא בדרך כלל האשמה בביצועים איטיים ב-WireGuard.

צומת יציאה (exit node) מעביר את נקודת היציאה שלך, הוא לא מבטל אותה

צומת יציאה מנתב את כל תעבורת האינטרנט הציבורית של התקן דרך התקן אחר ב-tailnet, תוך שימוש בנתיבי ברירת המחדל 0.0.0.0/0 ו-::/0. בלינוקס, המכונה שמציעה את השירות מפרסמת אותו, וכל לקוח בוחר להשתמש בו:

sudo tailscale set --advertise-exit-node
sudo tailscale set --exit-node=100.101.102.103
sudo tailscale set --exit-node=100.101.102.103 --exit-node-allow-lan-access=true
sudo tailscale set --exit-node=

צומת יציאה חייב לעבור אישור על ידי בעלים (Owner), מנהל (Admin) או מנהל רשת (Network admin) במסוף הניהול, והמדיניות שלך חייבת להעניק autogroup:internet לפני שלקוח יוכל להשתמש בו. שני השלבים הללו מכוונים: מכונה שלא אושרה לא יכולה להפוך בשקט לנקודת היציאה של כל ה-tailnet שלך. אותו מנגנון אישור חל גם על נתיבי רשת משנה (subnet routes), כך שמכונה שמפרסמת טווח פרטי נשארת לא פעילה עד שמנהל מאשר אותה, וזהו המכשול הראשון ב-פרסום רשת פרטית ל-tailnet שלך מ-VPS.

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

מדיניות ברירת המחדל היא רשת שטוחה

Tailnet חדש מגיע בתצורה מאפשרת. תיעוד בקרת הגישה של Tailscale מציין כי קובץ המדיניות המוגדר כברירת מחדל "מאפשר תקשורת בין כל ההתקנים בתוך ה-tailnet". כל התקן יכול להגיע לכל התקן אחר בכל פורט. זוהי רשת שטוחה. העברתם אותה לתוך המנהרה, מה שמסייע מול גורמים חיצוניים אך אינו מגן מפני מחשב נייד שנדבק.

הדקו את המדיניות בקובץ ה-tailnet, המקבל רשימות בקרת גישה (ACLs) או את מנגנון ה-grants החדש יותר; שניהם כתובים בניב של JSON המאפשר הוספת הערות:

{
  "acls": [
    {"action": "accept", "src": ["group:eng"], "dst": ["tag:prod:22"]},
    {"action": "accept", "src": ["autogroup:member"], "dst": ["autogroup:internet:*"]}
  ]
}

מדיניות זו מאפשרת לקבוצה אחת לגשת ל-SSH בשרתי הייצור, מאפשרת לחברים להשתמש ב-exit node, וחוסמת כל דבר אחר כברירת מחדל. Tailscale מפרטת אילו יעדי חוקים זמינים בכל תוכנית, לכן בדקו זאת לפני תכנון המבוסס על tags או autogroups, ועיינו ב-מה כוללת התוכנית החינמית בפועל. עבור התקן שלעולם אינו אמור לקבל חיבורים נכנסים, כגון טלפון אישי, tailscale set --shields-up חוסם אותם ברמת הלקוח.

מה משתנה באירוח עצמי של ה-control plane באמצעות Headscale

Headscale הוא "מימוש קוד פתוח, באירוח עצמי, של שרת ה-control של Tailscale". ה-README שלו מגדיר את היקף הפעילות בכנות: "הוא מיישם היקף מצומצם, רשת Tailscale (tailnet) אחת, המתאימה לשימוש אישי או לארגון קוד פתוח קטן". רשימת התכונות שלו כוללת ACLs והרשאות, subnet routers, exit nodes, שרת DERP מובנה, Tailscale SSH ו-Taildrop. אם היקף מצומצם זה מהווה מכשול, NetBird היא רשת mesh נוספת שמפיצה control plane שניתן לארח באופן עצמאי, ו-הרצת שרת NetBird על גבי ה-VPS שלכם מעבירה את אותה החלטת רישום לחומרה שבבעלותכם.

מה שמשתנה הוא זהות הגורם שיכול לרשום צומת (node) זדוני. עם Headscale, ספריית המפתחות והמדיניות נמצאות על השרת שלכם. אף צד שלישי אינו מחזיק ברשימת המפתחות הציבוריים של המכשירים שלכם, ואף צד שלישי לא יכול להידרש למסור אותם או לחתום על צומת חדש.

מה שאינו משתנה הוא מישור הנתונים. זהו אותו WireGuard, עם אותה הצפנה מקצה לקצה, ואותו מנגנון fallback דרך relay כאשר לא ניתן ליצור נתיב ישיר. בנוסף, אתם מקבלים עליכם את המשימות ש־Tailscale ביצעה: זמינות, החלת תיקונים, גיבויים ואבטחה פיזית של השרת. אם השרת הזה הוא VPS שכור, האחרון שבהם הוא התחייבות של גורם אחר ולא יכולת שבשליטתכם, משום של־hypervisor יש אפשרות לקרוא את זיכרון ה־guest שלכם, ובאמצעותו גם את ספריית המפתחות, אלא אם החומרה תומכת ב־זיכרון מוצפן שניתן לאמת.

שרת Headscale שנפרץ מעניק לתוקף בדיוק את היכולות ששרת תיאום שנפרץ היה מעניק לו: צירוף node והפצת מדיניות. Tailnet lock אינו מופיע ברשימת התכונות של Headscale, ולכן אמצעי הבקרה המפצה עבור סיכון מסוים זה אינו זמין שם. גם העלות דוחפת חלק מרשתות ה־tailnet לאותו כיוון, משום ש־Tailscale מחייבת לפי משתמש ולא לפי התקן, והחישוב משתנה מיד כאשר צוות קטן חורג ממגבלת התוכנית החינמית. אם שאלת הבעלות היא הגורם שמכריע עבורכם, אירוח עצמי של מישור הבקרה באמצעות Headscale מסביר את תהליך ההגדרה.

מפני מה Tailscale מגן

• פורטים ציבוריים להאזנה. שירות שקשור לכתובת tailnet אינו נגיש מהאינטרנט, ולכן הסורקים שפוגעים בכל VPS בפורט 22 לעולם לא יראו אותו. החריג הוא שירות שאתם מפעילים בעצמכם, שכן Funnel מפרסם שירות tailnet לאינטרנט הפתוח באופן מכוון; זו הסיבה שכדאי לדעת היכן מסתיים serve והיכן מתחיל funnel לפני שמריצים את אחת הפקודות הללו. שמרו על ה-firewall של המארח בכל מקרה, כיוון שפורט Docker שפורסם כותב חוקים משלו ו-עוקף את ufw בממשק הציבורי.
• ניחוש סיסמאות מול התחברויות חשופות. אין מה לנסות (spray) כאשר הפורט עונה רק בתוך ה-tunnel. זהו מצב חזק יותר מאשר הגבלת קצב (rate limiting) לפורט פתוח, אם כי עדיין כדאי להריץ fail2ban on Ubuntu 24.04 על כל מה שחייב להישאר ציבורי.
• רשתות לא מהימנות בנתיב. תעבורה בין המכונות שלכם מוצפנת מקצה לקצה מעל רשת של בית קפה או LAN משותף של ספק, והיא נשארת מוצפנת גם כאשר היא מועברת (relayed).
• ניהול ידני של הפצת מפתחות. כל peer שמוסף ידנית לקובץ תצורה של WireGuard הוא הזדמנות לשימוש חוזר בכתובת או להדבקת מפתח שגוי. ה-mesh מבצע את ניהול הרישומים הזה עבורכם, וזהו ההבדל המעשי העיקרי ב-WireGuard לעומת Tailscale.

מפני מה Tailscale אינו מגן

• נקודת קצה שנפרצה. ה-tailnet נותן אמון במכשירים. תוכנה זדונית על מחשב נייד מאושר מקבלת גישה למנהרה, לכתובות ה-tailnet ולכל הרשאה שהמדיניות מעניקה לאותו משתמש. זהו הפער המשמעותי ביותר, ואף VPN אינו סוגר אותו.
• מנהל מערכת זדוני או רשלן. כל מי שיכול לערוך את קובץ המדיניות יכול להעניק לעצמו גישה לכל דבר, וכל מי שיכול להשתלט על חשבון המשתמש של הבעלים (Owner) יכול לעשות את אותו הדבר. בצעו סקירה לשינויי מדיניות כפי שאתם סוקרים קוד.
• ניתוח תעבורה. ספק האינטרנט (ISP) שלכם רואה תעבורת UDP מוצפנת הזורמת לנקודת קצה, לצד תזמון ונפח. יומני הזרימה של Tailscale מתעדים אילו עמיתים תקשרו ומתי. אף אחד מהם לא רואה את התוכן, אך עצם קיום החיבור אינו מוסתר; לכן, קראו על ההבדלים בין Tor ל-VPN לפני בחירת כלי למשימה זו.
• מכשיר שכבר אבד לכם. תפוגת מפתח היא מנגנון הגנה איטי המוגדר כברירת מחדל ל-180 ימים. הסרת המכשיר דרך מסוף הניהול היא הדרך המהירה, לכן ודאו שאתם יודעים היכן נמצא כפתור זה לפני שתזדקקו לו.

בדיקת ה-tailnet שלכם

1. הריצו את tailscale status על מכשיר ועיינו ברשימת העמיתים (peers). מכונה שאינכם מזהים היא בדיוק המצב שאישור מכשירים נועד למנוע.
2. הריצו את tailscale lock status כדי לראות אם נעילת ה-tailnet מופעלת, ולאחר מכן החליטו אם העלות של חתימה על כל מכשיר חדש מצדיקה את עצמה עבור ה-tailnet שלכם.
3. פתחו את מסוף הניהול ורשמו כל מכונה שבה תוקף המפתח אינו מוגבל, בנוסף לכל מפתח אימות רב-פעמי שעדיין קיים. שניהם מהווים אישורי גישה ללא הגבלת זמן.
4. קראו את קובץ המדיניות שלכם. אם הוא עדיין מוגדר כברירת מחדל, כל מכשיר יכול להגיע לכל מכשיר אחר בכל פורט, ומחשב נייד נגוע אחד עלול להגיע לכולם.

Tailscale מבססת את המוניטין שלה על מישור הנתונים (data plane), שבו התכנון אינו מותיר למפעיל שום דרך לקרוא את התעבורה שלכם. התייחסו לטענה זו כפי שהספק מתעד אותה, ולאחר מכן בצעו ביקורת על החלקים שבשליטתכם: חשבונות הזהות, הגדרת האישור, רשימת התוקף וקובץ המדיניות. דף האבטחה של Tailscale מדווח על הסמכת SOC 2 Type II ועבודה שוטפת בתחום האבטחה עם Latacora; אלו מהווים עדות לתהליכים שלהם, ולא הצהרה על התצורה שלכם.

FAQ

האם Tailscale יכול לקרוא את התעבורה שלי?

לא. התעבורה מוצפנת באמצעות מפתחות WireGuard הנוצרים על גבי המכשירים שלך, ודף האבטחה של Tailscale מציין כי "מפתחות פרטיים לעולם אינם עוזבים את המכשיר. כל התעבורה מוצפנת מקצה לקצה, תמיד." הדבר תקף גם לחיבורים המסתמכים על ממסר DERP, כיוון שהממסר "מעביר באופן עיוור תעבורה שכבר הוצפנה ממכשיר אחד למשנהו" ואינו מחזיק במפתח שיאפשר לו לפענח אותה. מה שהתשתית של Tailscale כן רואה הוא מטא-דאטה: אילו מכשירים קיימים, ואילו מהם התחברו למי ומתי.

מה יכול לעשות שרת תיאום (coordination server) של Tailscale שנפרץ?

הוא יכול לרשום צומת (node) חדש. ההודעה של Tailscale בנושא tailnet lock מתארת את הסיכון שבהוספה חשאית של צומת שעלול "לשלוח או לקבל תעבורה לצמתים הקיימים שלך", מצב שבו הצפנה אינה עוזרת "מכיוון שהצד השני עצמו זדוני". מישור בקרה שנפרץ יכול גם להפיץ מדיניות שמשנה את היעדים אליהם המכשירים שלך יכולים להגיע, והמסמך הלבן של tailnet lock מציין שהוא עלול לשבש את הקישוריות על ידי מניעת הפצה של מפתחות צומת חדשים. מה שהוא לא יכול לעשות הוא לפענח תעבורה בין המכשירים הקיימים שלך, כיוון שהוא מעולם לא החזיק במפתחות הפרטיים שלהם.

האם צומת יציאה (exit node) מסתיר את הגלישה שלי מספק האינטרנט (ISP)?

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

האם Headscale מאובטח יותר משרת התיאום של Tailscale?

זו החלטת אמון שונה ולא בהכרח בטוחה יותר באופן מוחלט. עם Headscale אתה מחזיק בספריית המפתחות ובמדיניות, כך שאף גורם חיצוני לא יכול להיאלץ לרשום מכשיר ב-tailnet שלך. אתה גם לוקח על עצמך את הפעלת השרת: עדכוני אבטחה, זמינות (uptime), גיבויים ואבטחת המארח עצמו. מארח Headscale שנפרץ מעניק לתוקף את אותה יכולת רישום שהייתה לשרת תיאום שנפרץ, ומכיוון ש-tailnet lock אינו ברשימת התכונות של Headscale, עליך להגן על המארח בהתאם.

האם אני עדיין צריך firewall ב-VPS שנמצא בתוך ה-tailnet שלי?

כן. ממשק הרשת הציבורי עדיין קיים, וכל שירות שמאזין ל-0.0.0.0 נשאר נגיש מהאינטרנט, ללא קשר לשאלה אם Tailscale פועל או לא. הגדר שירותים להאזנה לכתובת ה-tailnet בלבד, שמור על מדיניות ברירת מחדל של חסימה (deny) בממשק הציבורי, ובדוק את הפורטים שחשפת במכולות (containers), כיוון ש-Docker מחדיר חוקים משלו ועלול לחשוף פורט שחשבת שהוא סגור.