מה זה Tailscale ואיך זה עובד? הסבר טכני

מהו Tailscale?

Tailscale הוא VPN המחבר את המכונות שלכם ישירות זו לזו, במקום לנתב את כל התעבורה דרך gateway מרכזי שאתם מנהלים. כל צומת (node) מריץ WireGuard, כך שהחבילות עוברות בהצפנה משרת אחד למשנהו, ושום גורם בנתיב אינו יכול לקרוא אותן. שרת תיאום (coordination server) מנוהל אחראי על יצירת הקשרים. הוא מאחסן ומפיץ מפתחות ציבוריים ומעדכן כל צומת היכן נמצאים האחרים. הוא גם דוחף את חוקי הגישה שהגדרתם.

הפרדה זו היא לב התכנון. מישור הנתונים (data plane) הוא peer-to-peer ומוצפן בין הצמתים. מישור הבקרה (control plane) הוא שירות ש-Tailscale מפעיל עבורכם. כל שאלה מהותית בנוגע ל-Tailscale, כולל השאלות הלא-נוחות בנושאי אמון, נובעת משתי עובדות אלו. אם כבר בניתם VPN מבוסס WireGuard באופן ידני על גבי VPS, הרי ש-Tailscale הוא אותו מנהרה בדיוק, כאשר הפצת המפתחות ומעבר ה-firewall מבוצעים עבורכם באופן אוטומטי.

כיצד פועל Tailscale?

הרשת הפרטית של הצמתים שלך נקראת tailnet. ארבעה דברים קורים כאשר מכונה מצטרפת לרשת כזו.

1. ה-daemon של tailscaled מופעל, מייצר זוג מפתחות WireGuard, ושומר את המצב שלו ב-/var/lib/tailscale/tailscaled.state. המפתח הפרטי נשאר על אותה מכונה. הניסוח של Tailscale עצמה חד-משמעי: "המפתח הפרטי לעולם, אבל לעולם, לא עוזב את הצומת שלו".
2. הצומת מבצע התחברות לשרת התיאום ומעלה את המפתח הציבורי שלו, בצירוף הכתובות שבהן הוא סבור שניתן להגיע אליו. Tailscale מתארת את השרת הזה כ"תיבת דואר משותפת למפתחות ציבוריים".
3. שרת התיאום שולח בחזרה מפת רשת: המפתח הציבורי, כתובת ה-tailnet, שם המכונה ונקודות הקצה האפשריות של כל צומת שאליו מותר לצומת זה להגיע.
4. כל זוג צמתים מנסה לאחר מכן לבנות מנהרת WireGuard ישירה ביניהם. כאשר הדבר נכשל, הם מעבירים את החבילות דרך ממסר (relay) במקום זאת.

כל צומת מקבל כתובת יציבה מתוך 100.64.0.0/10, טווח ה-carrier-grade NAT שנע בין 100.64.0.0 ל-100.127.255.255. Tailscale משתמשת בטווח הזה כיוון שהוא שמור לתשתית ספקיות, ולכן הוא מתנגש לעיתים רחוקות עם הכתובות הפרטיות שהשרתים שלך כבר משתמשים בהן. בלינוקס, המנהרה מופיעה כממשק בשם tailscale0.

מימוש ה-WireGuard נמצא בתוך tailscaled במרחב המשתמש (userspace), ולא במודול ה-kernel. זו הסיבה ש-Tailscale פועל על וירטואליזציה של מכולות שבה sudo modprobe wireguard נכשל עם Operation not supported. המשמעות היא גם שתקרת התעבורה על מכונה נתונה נמוכה יותר מאשר ב-WireGuard מבוסס kernel, וזהו אחד הפשרות ש-Tailscale מול WireGuard רגיל מפרט.

שתי פקודות יבהירו לך מה מצבך.

tailscale ip -4
tailscale status

tailscale status מדפיסה שורה אחת לכל צומת, והעמודה האחרונה היא זו שקובעת.

100.101.102.103  web-1      you@  linux  -
100.101.102.104  db-1       you@  linux  active; direct 198.51.100.24:41641
100.101.102.105  ci-runner  you@  linux  active; relay "fra"

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

מה שרת התיאום יכול ואינו יכול לראות

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

הוא אינו מחזיק במפתח פרטי כלשהו, ולכן אינו יכול לפענח תעבורה בין שני צמתים. ההצפנה היא מקצה לקצה בין עמיתי WireGuard, ושרת התיאום אינו נחשב לעמית.

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

כיצד שני שרתים מאחורי חומות אש שונות מתקשרים ישירות

NAT (תרגום כתובות רשת) הוא המנגנון המאפשר למכונות רבות לחלוק כתובת ציבורית אחת. לרוב ה-VPS שלכם יש כתובת ציבורית משלו, אך המכונות האחרות שברצונכם לכלול ב-tailnet לרוב אינן מחזיקות בכתובת כזו: שרת ביתי, שרת build ברשת משרדית, או מכונה מאחורי חומת אש של ספק שאין לכם גישה אליה.

Tailscale מוצאת נתיב תקשורת באמצעות טכניקות המבוססות על תקני STUN (כלי עזר למעבר NAT) ו-ICE. כל צומת שולח חבילת UDP קטנה לשרת STUN ולומד את הכתובת הציבורית והפורט שהנתב הקצה לאותו socket. שני הצמתים מדווחים על מועמדים אלו לשרת התיאום, שמעביר אותם לצד השני. לאחר מכן, שני הצמתים מתחילים לשלוח חבילות זה לזה בו-זמנית. כל נתב רואה חבילה יוצאת תחילה, לכן הוא יוצר מיפוי ומקבל את התשובה המגיעה מאותה כתובת. אף צד לא נזקק לחוק חומת אש נכנס.

הפורטים הם ספציפיים. מנהרות WireGuard ישירות משתמשות ב-UDP עם פורט מקור שברירת המחדל שלו היא 41641. STUN פועל על גבי UDP 3478 מול שרתי ה-relay של Tailscale. חיבור הבקרה וכל נתון שעובר דרך relay משתמשים ב-HTTPS על גבי TCP 443. ברוב המקרים אין צורך לפתוח דבר בתעבורה נכנסת, אם כי ברשת עם NAT מורכב, אישור UDP 41641 נכנס מגדיל את הסיכוי לחיבור ישיר.

tailscale netcheck

קראו שתי שורות מהדוח הזה. UDP: true משמעו ש-UDP יוצא מהמכונה בכלל, ו-UDP: false משמעו שכל חיבור מצומת זה יעבור דרך relay. MappingVariesByDestIP: true משמעו שהנתב מקצה פורט ציבורי שונה לכל יעד, ולכן חיזוי הכתובת לעיל אינו יכול לעבוד וצמתים אלו לרוב יישארו במצב relay.

מתי Tailscale משתמש ב־DERP relay

DERP (ראשי תיבות של designated encrypted relay for packets) הוא מנגנון הגיבוי. Tailscale מפעילה ממסרים (relays) באזורים רבים, הנגישים דרך TCP 443, וצומת שאינו מצליח ליצור נתיב ישיר מעביר את חבילות ה-WireGuard שלו דרך אחד מהם.

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

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

tailscale ping db-1

התגובות הראשונות חוזרות כ־via DERP(fra), ולאחר מכן שורה מאוחרת יותר מדווחת על משהו כמו via 198.51.100.24:41641. השינוי הזה הוא השדרוג למנהרה ישירה. אם הוא לעולם לא משתנה, הריצו tailscale netcheck בשני הקצוות. נתיב מתווך עדיין עובד. הוא גובה מחיר בשיהוי (latency), מכיוון שכל חבילה מבצעת עיקוף דרך מכונה שלישית. אם מה שהבחנת בו הוא העברות איטיות ולא חיבור שבור, מדוע חיבור Tailscale מתווך איטי משמעותית מחיבור ישיר מודד את הפער ומראה כיצד להביא VPS לנתיב ישיר.

צירוף שרת VPS ל-tailnet שלכם

סקריפט ההתקנה תומך ב-Ubuntu וב-Debian.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

sudo tailscale up מדפיס כתובת URL. פתחו אותה, בצעו אימות, והצומת יופיע ב-admin console שלכם. לאחר מכן ודאו שה-daemon עולה מחדש לאחר reboot, שכן זהו השלב שמשתמשים נוטים לדלג עליו.

sudo systemctl is-enabled tailscaled
tailscale status

is-enabled אמור להדפיס enabled, ו-tailscale status אמור להציג את הצומת החדש עם כתובת ה-100.x שלו. עבור שרת שנבנה באמצעות סקריפט, אין תועלת ב-URL אינטראקטיבי. צרו auth key ב-admin console והעבירו אותו, יחד עם תג (tag) שמציין את סוג המכונה.

sudo tailscale up --auth-key=tskey-auth-REPLACE-ME --advertise-tags=tag:server

צומת מתויג (tagged node) נמצא בבעלות התג ולא בבעלות האדם שהריץ את הפקודה, לכן הוא ימשיך לעבוד גם לאחר שחשבון המשתמש של אותו אדם יוסר. יש להגדיר את התג בקובץ המדיניות שלכם תחת tagOwners תחילה, אחרת הפקודה תידחה. תיוג משנה גם את האופן שבו המכונה נספרת במסגרת התוכנית שלכם, שכן משאב מתויג מתומחר בנפרד ממכשירים אישיים של משתמש, והדף מה כוללת חבילת ה-free tier בפועל מפרט היכן נמצאות מגבלות אלו.

שתי הגדרות חשובות עבור צי מכונות. מפתחות צומת (node keys) פגים לאחר 180 ימים כברירת מחדל (נכון לאוגוסט 2026), וכאשר מפתח פג "חיבורים אל/מנקודת הקצה יפסיקו לעבוד" עד שמישהו יבצע אימות מחדש. לכן, פתחו את שורת המכונה ב-admin console ובחרו ב-Disable Key Expiry עבור שרתים ללא השגחה. MagicDNS, המופעל כברירת מחדל עבור tailnets שנוצרו ב-20 באוקטובר 2022 או לאחר מכן, מעניק לכל צומת שם כגון db-1.yak-bebop.ts.net, אשר מתורגם על ידי stub resolver בכתובת 100.100.100.100. השתמשו בשמות במקום בכתובות, מכיוון שצומת שנבנה מחדש מקבל כתובת חדשה אך שומר על שמו.

אם ההתקנה עצמה נכשלת ב-apt או מול ה-repository, הדף שגיאות התקנה נפוצות של Tailscale ב-Ubuntu מפרט את הפתרונות.

גישה לשירות המאזין ל-localhost

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

ss -tlnp | grep 3000

אם הפקודה מציגה 127.0.0.1:3000, ה-socket מקבל רק חבילות שהיעד שלהן הוא 127.0.0.1. בקשה שמגיעה מצומת אחר מופנית לכתובת ה-100.x של צומת זה, לכן ל-kernel אין תהליך שמאזין לכתובת זו והוא משיב ב-TCP reset. הלקוח מדווח על Connection refused. המנהרה תקינה, אך השירות המאזין הוא מקור הבעיה.

קיימים שני פתרונות נכונים. ניתן להגדיר את השירות להאזין לכתובת ה-tailnet של הצומת, מה ששומר עליו מחוץ לממשק הציבורי ללא צורך ב-proxy: העבירו את --bind 100.101.102.104 או את האפשרות המקבילה בקובץ התצורה שלכם, ובמקרה של מכולה, פרסמו את הפורט כ--p 100.101.102.104:3000:3000. לחלופין, השאירו את השירות על ה-loopback והציבו לפניו את Tailscale.

tailscale serve 3000

פעולה זו מבצעת proxy לבקשות אל http://127.0.0.1:3000 ומגישה אותן בתוך ה-tailnet שלכם תחת שם ts.net ב-HTTPS, לאחר הפעלת תעודות HTTPS עבור ה-tailnet. השירות נשאר פרטי עבור הצמתים שלכם. הגרסה הציבורית של רעיון זה היא Funnel, והדף Tailscale serve מול funnel מפרט באיזו אפשרות כדאי לבחור.

לשתי משימות קשורות יש דפים ייעודיים משלהן. גישה לרשת פרטית שלמה שבה לא מותקן Tailscale דורשת נתב תת-רשת ב-VPS, והעברת תעבורת האינטרנט היוצאת של צומת דרך צומת אחר דורשת צומת יציאה (exit node).

סגירת פורטים שאינם נחוצים עוד

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

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

sudo ufw allow in on tailscale0
sudo ufw status verbose

לאחר מכן, מחקו את חוק ה-SSH הציבורי והתחברו מחדש באמצעות שם ה-MagicDNS. שימו לב למה ש-ufw allow in on tailscale0 עושה בפועל: הוא נותן אמון בכל מה שמגיע דרך ה-tunnel, לכן קובץ ה-policy של Tailscale הופך להיות בקרת הגישה במקום ufw. כתבו את ה-policy תוך התחשבות בכך.

אזהרה למי שמריץ מכולות (containers): פורט שפורסם ב-Docker מתקין חוקי NAT משלו ועוקף את ufw, לכן פקודת ufw deny לא תסגור אותו. המאמר Docker published ports bypassing ufw מסביר את המנגנון. פרסום לכתובת ה-tailnet, כפי שהוצג לעיל, עוקף בעיה זו. אם היישום רץ תחת Docker Compose, המדריך a Tailscale sidecar in the Compose stack מציע צעד נוסף ומסיר את הפורט המפורסם לחלוטין, כך שהמכולה נגישה רק באמצעות שם ה-tailnet שלה.

מה Tailscale מאבטח, ומה לא

כדאי להבהיר זאת, שכן הגרסה השיווקית מטשטשת את הגבולות.

מאובטח: תעבורה בין שני צמתים מוצפנת מקצה לקצה באמצעות WireGuard, ואף ממסר (relay) בדרך אינו יכול לקרוא אותה. מפתחות פרטיים לעולם אינם עוזבים את המכונה שיצרה אותם. צמתים אינם זקוקים לפורט ציבורי פתוח נכנס, לכן אין שום דבר בפורטים 22 או 5432 שסורקים באינטרנט יכולים למצוא. הגישה בין צמתים נקבעת לפי קובץ מדיניות ולא לפי מי שמכיר כתובת מסוימת.

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

ישנן שתי תשובות לסיכון של הפצת מפתחות. הראשונה היא tailnet lock, הדורשת מצמתים מהימנים קיימים לחתום קריפטוגרפית על צומת חדש לפני שהצמתים האחרים שלכם יקבלו אותו. מישור בקרה (control plane) שמוסיף צומת ללא חתימה תקפה נדחה. קונסולת הניהול מייצרת את שורת ה-tailscale lock init המדויקת עבור צמתי החתימה שלכם, וכל צומת יכול לאשר את מה שהוא רואה.

tailscale lock status

כל הצמתים צריכים לדווח על אותה קבוצה של מפתחות חתימה מהימנים. התשובה השנייה היא להריץ את מישור הבקרה בעצמכם. שרת תיאום Headscale בהתקנה עצמית מדבר באותו פרוטוקול לאותם לקוחות, מה שמעביר את גרף המכשירים ואת הפצת המפתחות לחומרה שבבעלותכם. אתם גם אחראים לזמינות (uptime) של אותו שרת. אם אתם עדיין משווים בין מישורי בקרה בהתקנה עצמית במקום להחליט על זה, NetBird הוא Mesh VPN נפרד שהשרת שלו מורץ מקצה לקצה על גבי VPS יחיד.

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

{
  "tagOwners": {
    "tag:server": ["autogroup:admin"]
  },
  "acls": [
    {"action": "accept", "src": ["autogroup:member"], "dst": ["tag:server:22"]}
  ]
}

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

מצבי כשל והודעות שיופיעו

tailscale status מציג תמיד relay. שני הצמתים לא הצליחו ליצור נתיב ישיר. הריצו את tailscale netcheck בשני הצדדים. UDP: false מציין שפרוטוקול UDP חסום ביוצא, ולכן רק ממסר (relay) יכול לעבוד. MappingVariesByDestIP: true מציין שקיים NAT קשיח בדרך; לעיתים קרובות, פתיחת פורט UDP 41641 לנכנס בצד שאתם מנהלים תפתור זאת.

צומת שעבד במשך חודשים נעלם. מפתח הצומת פג בתום תקופת ברירת המחדל של 180 ימים. המכונה מופיעה כפגה (expired) במסוף הניהול, והרצת sudo tailscale up על המכונה תחזיר אותה לפעילות. בטלו את פקיעת המפתח בשרתים כדי למנוע הישנות של המקרה.

צמתים מופיעים ברשימה אך החיבורים מסתיימים ב-timeout. הקישוריות תקינה אך המדיניות חוסמת את התעבורה. בדקו את סעיף acls עבור חוק המכסה את המקור, היעד והפורט הרלוונטיים. חבילה שנחסמה מושלכת במקום לקבל מענה, וזו הסיבה שמתקבל timeout במקום Connection refused.

שמות MagicDNS אינם מתורגמים. ping db-1 נכשל בעוד ping 100.101.102.104 עובד. גורם כלשהו החליף את /etc/resolv.conf, ולכן שאילתות לעולם לא מגיעות ל-stub resolver בכתובת 100.100.100.100. בדקו את cat /etc/resolv.conf עבור 100.100.100.100, ובדקו אילו תהליכים נוספים במכונה כותבים לקובץ זה. זוהי אותה קטגוריה של בעיות כמו שבירת DNS בתוך מנהרת WireGuard.

tailscale up מסרב לקבל את התג (tag) שלכם. התג אינו מוגדר תחת tagOwners בקובץ המדיניות. הוסיפו אותו שם, ולאחר מכן הריצו את הפקודה שוב.

FAQ

האם Tailscale הוא VPN או רשת mesh?

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

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

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

האם עליי לפתוח פורטים ב-firewall עבור Tailscale?

כמעט אף פעם לא עבור תעבורה נכנסת. ההנחיה של Tailscale היא ש"ברוב המקרים, אין צורך לפתוח פורטים ב-firewall". עבור תעבורה יוצאת, צומת זקוק ל-TCP 443 כדי לתקשר עם שרת התיאום והממסרים, ובנוסף ל-UDP 3478 עבור STUN. מנהרות ישירות משתמשות ב-UDP עם פורט מקור שברירת המחדל שלו היא 41641. אישור UDP 41641 נכנס הוא אופציונלי, והוא מסייע רק להצלחת חיבורים ישירים ברשתות מורכבות.

מדוע צמתים אחרים לא יכולים להגיע לשירות שלי בפורט 3000?

בדקו תחילה את כתובת ה-bind באמצעות ss -tlnp. מאזין ב-127.0.0.1:3000 מסרב לחיבורים שמגיעים ממוענים לכתובת ה-100.x של ה-tailnet, כיוון שה-socket מקבל רק יעד loopback, והלקוח מקבל Connection refused. בצעו bind לשירות לכתובת ה-tailnet, או הריצו tailscale serve 3000 כדי לבצע לו proxy. אם המאזין כבר נמצא ב-0.0.0.0 והחיבור מסתיים ב-timeout במקום בסירוב, הסיבה היא חוק מדיניות או firewall מקומי ולא כתובת ה-bind.

האם עליי להריץ Headscale במקום שרת התיאום של Tailscale?

הריצו Headscale כאשר גרף המכשירים או הפצת המפתחות חייבים להישאר בתשתית שבשליטתכם, או כאשר ה-tailnet חייב לעבוד ללא תלות בשירות חיצוני. הלקוחות והפרוטוקול זהים. המחיר הוא שאתם כעת מנהלים את שרת התיאום, ותקלה בו תעצור הצטרפות צמתים חדשים ותמנע החלת שינויי מדיניות. עבור צי קטן, שרת הבקרה המנוהל עם Tailnet lock מופעל הוא לרוב הפשרה העדיפה.