מה זה 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 ברמת הליבה, וזהו אחד הפשרות ש-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 runner) ברשת משרדית, או מכונה מאחורי חומת אש של ספק שאין לכם גישה אליה.

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), כיוון שכל חבילה מבצעת עיקוף דרך מכונה שלישית.

צירוף שרת 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

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

שתי הגדרות הן בעלות חשיבות לניהול צי שרתים. מפתחות צומת (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 דורשת נתב subnet על גבי 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 שפורסמו עוקפים את ufw מסביר את המנגנון הזה. פרסום לכתובת ה-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 הוא VPN מבוסס Mesh נפרד שהשרת שלו מורץ על ידכם מקצה לקצה על גבי 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 לנכנס בצד שאתה מנהל פותרת זאת לרוב.

צמת שעבד במשך חודשים נעלם. מפתח הצמת (node key) פג תוקף לאחר 180 יום כברירת מחדל. המכונה מופיעה כפגת תוקף בלוח הניהול, והרצת 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. הגדירו את השירות להאזין לכתובת ה-tailnet, או הריצו tailscale serve 3000 כדי לבצע proxy לחיבור. אם המאזין כבר נמצא ב-0.0.0.0 והחיבור מסתיים ב-timeout במקום בסירוב, הסיבה היא חוק מדיניות או firewall מקומי ולא כתובת ה-bind.

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

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