מהו Tailscale ואיך פועל VPN רשת-המשי שלו?

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

Tailscale מוצא נתיב באמצעות טכניקות המבוססות על תקני STUN (כלי מעבר הפעלות עבור NAT) ו־ICE. כל node שולח חבילת UDP קטנה לשרת STUN ולומד איזו כתובת ציבורית ואיזה פורט הנתב הקצה ל־socket הזה. שני ה־nodes מדווחים על המועמדים האלה לשרת התיאום, והוא מעביר אותם לצד השני. לאחר מכן שני ה־nodes מתחילים לשלוח חבילות זה לזה באותו זמן. כל נתב רואה תחילה חבילה יוצאת, ולכן הוא יוצר מיפוי ומקבל את התשובה שמגיעה מאותה כתובת. אף צד לא נזקק לכלל firewall נכנס. זו גם הסיבה ש־NAS או Pi בבית יכולים להישאר זמינים בלי לבצע port forwarding בנתב, והמאמר שימוש ב־Tailscale במקום port forwarding מסביר את ההגדרה הזו, כולל המגבלות שלה.

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

tailscale netcheck

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

מתי Tailscale משתמש ב־DERP כממסר

DERP (ממסר מוצפן ייעודי למנות) הוא מנגנון הגיבוי. Tailscale מפעיל ממסרים באזורים רבים, שאליהם ניתן להגיע דרך TCP 443, וצומת שאינו מצליח להשיג נתיב ישיר שולח את מנות ה־WireGuard שלו דרך אחד מהם. החריג הוא tailnet שבו הגדרתם ממסרי עמיתים, שהם התקנים שלכם שמעבירים תעבורה דרך UDP. Tailscale מנסה להשתמש בהם תחילה, ועובר ל־DERP רק כאשר אף אחד מהם אינו זמין, ו־tailscale status מציג את החיבור בתור peer-relay.

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

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

tailscale ping db-1

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

הצטרפות של VPS ל־tailnet

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

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

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

sudo systemctl is-enabled tailscaled
tailscale status

is-enabled אמור להציג enabled, ו־tailscale status אמור להציג את הצומת החדש עם הכתובת שלו בטווח 100.x. עבור שרת שנבנה באמצעות סקריפט, כתובת URL אינטראקטיבית אינה שימושית. צרו מפתח אימות במסוף הניהול והעבירו אותו, יחד עם תג שמתעד איזה סוג מכונה זו.

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

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

שתי הגדרות חשובות עבור צי מכונות. מפתחות צמתים פגים לאחר 180 ימים כברירת מחדל (נכון לאוקטובר 2026), וכאשר מפתח פג, "החיבורים אל נקודת הקצה הנתונה וממנה יפסיקו לפעול" עד שהמכשיר יבצע אימות מחדש. מנהל מערכת יכול לבחור באפשרות Temporarily extend key במכונה שפג בה המפתח, במסוף הניהול. פעולה זו מעניקה 30 דקות כדי להתחבר שוב או להשבית את פקיעת התוקף. בצומת שאומת באמצעות תג, כמו זה שמופיע למעלה, פקיעת תוקף המפתח מושבתת כברירת מחדל. עבור כל שרת לא מאויש אחר, פתחו את שורת המכונה במסוף הניהול ובחרו Disable Key Expiry. ‏MagicDNS, שמופעל כברירת מחדל עבור tailnets שנוצרו ב־20 באוקטובר 2022 או לאחר מכן, מעניק לכל צומת שם כגון db-1.yak-bebop.ts.net, שנפתר באמצעות resolver מקומי ב־100.100.100.100. השתמשו בשמות במקום בכתובות, משום שצומת שנבנה מחדש מקבל כתובת חדשה אך שומר על שמו.

אם ההתקנה עצמה נכשלת ב־apt או במאגר, השגיאות הנפוצות בהתקנת 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 כזה מאפשר למפתח גישה של מחשב נייד גנוב להעניק גישה למסד הנתונים. אם אתם עדיין בוחרים פתרון mesh VPN, האופן שבו כותבים כללים כאלה הוא אחד התחומים שבהם האפשרויות נבדלות באמת, ו־NetBird לעומת Tailscale משווה בין שני מודלי המדיניות לצד השאלה מי מפעיל את מישור הבקרה.

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

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

צומת שפעל במשך חודשים נעלם. סיבה נפוצה היא מפתח צומת שפג תוקפו לאחר ברירת המחדל של 180 יום, ולכן בדקו תחילה את המכונה במסוף הניהול. אם היא מסומנת כפגת תוקף, sudo tailscale up במכונה מחזיר אותה לפעולה, והשבתת תפוגת המפתחות בשרתים מונעת את הישנות הבעיה. אם המפתח לא פג, בדקו את קובץ המדיניות, משום שההנחיה של Tailscale למכשיר שחסר ב־tailscale status היא לבדוק אם כללי גישה מונעים את החיבור.

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

שמות MagicDNS אינם נפתרים. ping db-1 נכשל, בעוד ping 100.101.102.104 פועל. תחילה ודאו שהלקוח מקבל את הגדרות ה־DNS של Tailscale: צומת שהופעל עם --accept-dns=false לעולם אינו שולח את השאילתות שלו ל־stub resolver שב־100.100.100.100. לאחר מכן בדקו את cat /etc/resolv.conf ואת כל רכיב אחר במכונה שכותב לקובץ הזה. במערכת המשתמשת ב־systemd-resolved, הקובץ הוא בדרך כלל קישור סמלי אל /run/systemd/resolve/stub-resolv.conf, ולכן היעדרו של 100.100.100.100 שם צפוי. כאשר tailscaled כותב את הקובץ ישירות, לקוח DHCP או כלי אחר שדורס אותו משבש את MagicDNS. אם אף אחד מההסברים האלה אינו מתאים, התקלה יכולה להיות גם בתצורת ה־DNS המקומית או ברשת. זהו אותו סוג של בעיה כמו תקלה ב־DNS בתוך מנהרת WireGuard.

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

FAQ

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

שני המונחים נכונים, והם מתארים שכבות שונות. המנהרות משתמשות ב־WireGuard, ולכן מדובר ב־VPN. הטופולוגיה היא mesh, משום שכל צומת יוצר מנהרה ישירות לכל צומת שאליו הוא מתקשר, במקום לשלוח כל מנהרה דרך שרת מרכזי אחד. שרת התיאום נמצא במישור הבקרה ולא במישור הנתונים, ולכן אם הוא אינו זמין, המנהרות הקיימות ממשיכות להעביר תעבורת רשת. מה שנפסק בזמן השבתה הוא צירוף של צמתים חדשים והחלת שינויים במפתחות או במדיניות. עם זאת, כברירת מחדל זה אינו VPN לשמירה על פרטיות: אתרי אינטרנט עדיין רואים את הכתובת הציבורית שלכם, עד שתעבירו תעבורה דרך exit node, והאופן שבו Tailscale מסתיר מידע מאתרי אינטרנט ומספק האינטרנט שלכם תלוי בכל הגדרה.

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

לא את התוכן שלה. התעבורה מוצפנת מקצה לקצה בין צמתים באמצעות WireGuard, מפתחות פרטיים לעולם אינם עוזבים את הצמתים, ו־DERP מעביר מנות שאין לו אפשרות לפענח. 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 מסרב לחיבורים שמגיעים כשהם מיועדים לכתובת ה־tailnet של הצומת, 100.x, משום שה־socket הזה מקבל רק יעד loopback, והלקוח מקבל Connection refused. הגדירו את השירות כך שיקשיב בכתובת ה־tailnet, או הפעילו tailscale serve 3000 כדי לשמש כ־proxy עבורו. אם המאזין כבר נמצא על 0.0.0.0 והחיבור מסתיים ב־timeout במקום בסירוב, כתובת ה־bind אינה הבעיה. בדקו תחילה כללי מדיניות ו־firewall במארח, ולאחר מכן firewalls ברשת ואת השאלה אם האימות של אחד ההתקנים פג.

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

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