Tailscale serve לעומת Funnel: מה ההבדל?

ההבדל בין tailscale serve לבין funnel: מי יכול לגשת לכתובת ה-URL

ההבדל בין tailscale serve לבין tailscale funnel טמון בקהל היעד בלבד. הפקודה serve מציבה ממשק HTTPS (פרוטוקול העברת היפר-טקסט מאובטח) מול פורט מקומי ומפרסמת אותו בתוך ה-tailnet שלכם בלבד. הפקודה funnel מפרסמת את אותו פורט מקומי לכל רחבי האינטרנט הציבורי, דרך שרתי ממסר (relay servers) ש-Tailscale מפעילה. שתי הפקודות מקבלות את אותם דגלים (flags) ואת אותם יעדים. מילה אחת בלבד מפרידה בין לוח בקרה פרטי לבין כזה שנגיש לכל העולם.

שתי הפקודות מספקות לכם תעודה שדפדפנים כבר נותנים בה אמון, תחת שם שמסתיים ב-ts.net, ואף אחת מהן אינה דורשת פתיחת פורט נכנס ב-firewall של ה-VPS שלכם. ה-daemon של tailscaled כבר מחזיק חיבור פעיל ל-tailnet, ולכן התעבורה מגיעה דרכו. העלאת שרת ל-tailnet היא משימה אחת, ו-הפעלת VPS כ-exit node של Tailscale או הכרזה על subnet router עבור רשת פרטית מכסות את הצד הזה. פרסום שירות שכבר נמצא ב-tailnet הוא המשימה הנוכחית.

מה נדרש לפני הפעלת הפקודות

• גרסת Tailscale 1.38.3 או חדשה יותר על ה-VPS, כשהוא מחובר ל-tailnet שלכם. בדקו זאת באמצעות tailscale version ו-tailscale status.
• MagicDNS מופעל. MagicDNS הוא שירות ה-DNS (מערכת שמות מתחם) המובנה של Tailscale, והוא זה שמעניק למכונה שם כגון blog-vps.your-tailnet.ts.net במקום כתובת 100.x בלבד.
• תעודות HTTPS מופעלות עבור ה-tailnet, בדף ה-DNS ב-admin console. ללא זאת, לא תהיה תעודה להצבה לפני הפורט שלכם.
• עבור funnel בלבד, נדרש מאפיין ה-node מסוג funnel בקובץ ה-tailnet policy. כאן רוב הניסיונות הראשונים נכשלים, והנושא מוסבר בהמשך.

כל פקודה כאן מתחילה ב-sudo, כיוון שה-CLI מתקשר עם tailscaled דרך socket שרק root רשאי לכתוב אליו. העניקו למשתמש אחד את הזכות לדלג על כך:

sudo tailscale set --operator=$USER

פרסום ל-tailnet באמצעות tailscale serve

הפנו את serve לפורט מקומי, והוא יבצע את השאר.

sudo tailscale serve 3000

Available within your tailnet:
https://amelie-workstation.pango-lin.ts.net

 |-- / proxy http://127.0.0.1:3000

Press Ctrl+C to exit.

הפקודה 3000 כשלעצמה היא קיצור דרך ל-http://127.0.0.1:3000. Tailscale מאזין בפורט 443 של כתובת ה-tailnet של המכונה, מבצע TLS termination עם תעודת ts.net, ומעביר HTTP גלוי לפורט המקומי שלכם. היישום שלכם אינו צריך לדעת על קיומה של תעודה, וזו הסיבה העיקרית להשתמש בכך עבור לוח ניהול שאחרת הייתם משאירים על HTTP גלוי. ממשק אינטרנטי שמאזין רק ל-127.0.0.1 הוא מועמד מובהק, ו-ממשק ה-Web של dsh בפורט 3080 הוא דוגמה טובה: במקום לפתוח מנהרת SSH בכל פעם שתרצו לגשת אליו, הפנו את serve לפורט 3080 פעם אחת, ותוכלו לגשת אליו מכל מכשיר ב-tailnet.

כעת קראו את השורה האחרונה: Press Ctrl+C to exit.. הפקודה רצה בחזית (foreground), והמיפוי קיים בתוך התהליך הזה בלבד. סגירת הטרמינל תגרום להפסקת פעולת ה-URL, כיוון שלא נכתב דבר לדיסק. הוסיפו את --bg והמיפוי יישמר בתצורת ה-serve של הצומת, מה שיבטיח את הישרדותו גם לאחר סגירת הטרמינל וגם לאחר reboot.

sudo tailscale serve --bg 3000

הפקודה serve מקבלת יותר מאשר רק מספר פורט. --set-path מעגן שירות תחת נתיב משנה (subpath), כך שיישומים מרובים יכולים לחלוק שם מארח אחד:

sudo tailscale serve --bg --set-path=/grafana 3000
sudo tailscale serve --bg --set-path=/metrics 9090

יעד יכול להיות גם ספרייה של קבצים סטטיים, או backend שכבר מדבר TLS עם תעודה שאינכם רוצים שתעבור בדיקה:

sudo tailscale serve --bg /srv/reports
sudo tailscale serve --bg https+insecure://localhost:8443

השימוש אינו מוגבל ל-HTTP בלבד. --tcp=<port> מעביר זרם TCP גלוי, ו---tls-terminated-tcp=<port> מסיים את ה-TLS בצומת שלכם ומעביר את המידע הגלוי הלאה. כך ניתן להציב תעודה מהימנה לפני שירות שאינו תומך ב-HTTP כלל:

sudo tailscale serve --bg --tls-terminated-tcp=443 tcp://127.0.0.1:9899

מדוע Funnel מציג שגיאה שה־node attribute לא מוגדר?

השירות Funnel כבוי כברירת מחדל עבור כל ה־tailnet. ההרצה הראשונה מציגה הודעה זו ועוצרת:

Funnel not available; "funnel" node attribute not set. See https://tailscale.com/kb/1223/tailscale-funnel/.

הפקודה הייתה תקינה. מדיניות ה־tailnet לא העניקה לצומת זה הרשאה לפרסם, לכן הלקוח מסרב לפעולה עוד לפני יצירת קשר עם ה־relay. יש לערוך את קובץ מדיניות ה־tailnet במסוף הניהול, תחת Access Controls, ולהוסיף את ה־attribute:

"nodeAttrs": [
  {
    "target": ["autogroup:member"],
    "attr":   ["funnel"],
  },
],

הערך autogroup:member מעניק הרשאה זו לכל חבר ב־tailnet. אם רק מכונה אחת אמורה לפרסם, יש לתייג את אותה מכונה ולכוון את ההרשאה לתג, למשל tag:public. יש לשמור את המדיניות ולהריץ שוב את פקודת ה־funnel.

אם החשבון שלכם הוא חשבון מנהל (admin) ב־tailnet, לקוחות עדכניים מציעים קיצור דרך: ממשק ה־CLI מדפיס כתובת URL לאישור ב-login.tailscale.com, ומעבר אליה מפעיל תעודות HTTPS ומוסיף את ה־attribute עבורכם. אם אינכם מנהלים, כתובת ה-URL הזו לא תסייע לכם. אדם בעל הרשאות עריכת מדיניות חייב לבצע את השינוי.

פרסום לאינטרנט באמצעות Tailscale Funnel

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

sudo tailscale funnel --bg 3000

Available on the internet:
https://amelie-workstation.pango-lin.ts.net

 |-- / proxy http://127.0.0.1:3000

Press Ctrl+C to exit.

קראו את השורה הראשונה הזו בכל פעם מחדש. Available within your tailnet ו-Available on the internet הם ההבדל הנראה לעין היחיד בין שירות פרטי לשירות ציבורי, והפקודות שמייצרות אותם נבדלות במילה אחת בלבד.

נכון לאוגוסט 2026, Funnel מאזין בפורטים 443, 8443 או 10000, ולא באף פורט אחר. ברירת המחדל היא 443, ו---https=8443 או --https=10000 הם החלופות. כל פורט אחר יידחה, כיוון שניתבי ה-funnel מקבלים חיבורים רק בפורטים אלו. זו הסיבה שכתובת ה-URL של ה-funnel היא תמיד שם המארח (hostname) בלבד, או שם המארח עם :8443 מודבק בסופו.

כיצד ניתן לראות מה מפורסם כרגע?

ניחושים הם הדרך שבה לוח בקרה נשאר חשוף לציבור במשך חודש. מוטב לשאול את ה-node ישירות.

tailscale serve status
tailscale funnel status
tailscale serve status --json

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

No serve config

אם אתם רואים זאת לאחר הגדרה שווידאתם שעבדה, המשמעות היא שהמיפוי נוצר בחזית (foreground) והתהליך הסתיים. צרו אותו מחדש באמצעות --bg.

כדי להסיר מיפוי בודד, חזרו על הפקודה שיצרה אותו והוסיפו off בסופה. כדי למחוק את כל מיפויי ה-serve וה-funnel ב-node, השתמשו ב-reset.

sudo tailscale funnel --https=443 3000 off
sudo tailscale serve reset

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

מה אתם מקבלים, ועל מה אתם מוותרים

היתרונות הם ממשיים, והם הסיבה שאנשים בוחרים בפתרון זה על פני reverse proxy.

• תעודה שדפדפנים סומכים עליה, המתחדשת עבורכם. אין צורך להתקין לקוח ACME (סביבת ניהול תעודות אוטומטית), ואין משימת חידוש שניתן לשכוח.
• אין צורך בפורט נכנס ב-firewall של ה-VPS. ה-tailscaled יוצר חיבור יוצא, כך ש-מדיניות ברירת מחדל של חסימה ב-ufw על ה-VPS שלכם יכולה להישאר הדוקה בדיוק כפי שהייתה.
• אין צורך לרכוש רשומת DNS, להפנות אותה או להמתין לעדכונה.
• אין צורך ב-port forwarding, שזהו כל הסיפור במכונה שנמצאת מאחורי NAT (תרגום כתובות רשת) ולא ב-VPS עם כתובת IP ציבורית.

העלויות הן ממשיות באותה מידה, ו-funnel מרכז את כולן.

• השם אינו שלכם. מבקרים חיצוניים רואים את host.your-tailnet.ts.net. ל-funnel אין תמיכה בדומיין מותאם אישית, לכן לא ניתן להציב את app.example.com לפניו.
• הנתיב אינו שלכם. התעבורה מגיעה תחילה ל-relay של Tailscale, וה-relay מבצע proxy לזרם הנתונים אל הצומת שלכם דרך ה-tailnet. ב-Tailscale מציינים כי תעבורת funnel כפופה למגבלות רוחב פס שאינן מפורסמות ולא ניתן להגדירן, לכן מדדו את התפוקה שלכם לפני שאתם מסתמכים על מספר מסוים.
• הבקרה חסרה. reverse proxy שאתם מריצים נותן לכם לוגים של גישה, הגבלות קצב (rate limits), הגבלות על גודל בקשה ומקום להטמיע אימות. funnel נותן לכם URL. כל השאר חייב להתקיים בתוך היישום שלכם.
• רשימת הפורטים קבועה, כפי שצוין לעיל.

שתי התכונות מסתמכות גם על תשתית שמופעלת על ידי Tailscale: הנפקת תעודות עבור שם ה־ts.net עצמו, וכן ממסרי ה־funnel. השאלה אם התלות הזו צריכה להדאיג אתכם תלויה במה שהשרתים האלה יכולים ואינם יכולים לעשות עם התעבורה שלכם. בדיוק את הנקודה הזו מגדיר מודל האמון של Tailscale. השימוש בשתי התכונות אינו כרוך בתשלום, משום ש־התוכנית החינמית כוללת עד שישה משתמשים, עם מספר בלתי מוגבל של מכשירים לכל משתמש. מספר המשתמשים, ולא רשימת התכונות, הוא שבסופו של דבר מעביר את ה־tailnet לתוכנית בתשלום. מנקודה זו ואילך, החיוב נקבע לפי המשתמשים ולא לפי המכונות. לכן כדאי לבדוק כמה באמת עולה tailnet בתוכנית בתשלום לפני שה־serve או ה־funnel הופכים לרכיב קריטי. אם אתם שוקלים שרת בקרה עצמאי של Headscale, אל תניחו שאחת מהתכונות תעבור איתכם. בדקו את הערות הגרסה של גרסת Headscale שאתם מתכננים להפעיל.

במה כדאי לבחור?

הכלל פשוט.

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

השתמשו ב-funnel עבור קישור להדגמה, מקבל webhook שצד שלישי חייב לבצע אליו POST, או callback של OAuth במהלך פיתוח. זו הדרך המהירה ביותר לקבל כתובת HTTPS ציבורית, ופקודה אחת של off מסיימת את הפעולה. עם זאת, "ציבורי" משמעו ציבורי: שם המארח אינו סוד, ו-funnel לפני יישום ללא מנגנון התחברות הוא שירות פתוח. כל מה שנמצא מאחוריו חייב לאמת את הבקשות של עצמו, באותה רמת זהירות הנדרשת עבור נקודת קצה חשופה של Ollama API.

השתמשו ב-reverse proxy אמיתי עבור כל מה שאתם מגדירים כסביבת production. הדומיין שלכם, התעודה שלכם, הלוגים שלכם, הגבלות הקצב (rate limits) שלכם, ואף גורם נוסף בנתיב הבקשה. המדריך השוואה בין nginx, Caddy ו-Traefik כ-reverse proxy מסייע בבחירת הכלי המתאים.

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

Funnel מסרב לעלות. Funnel not available; "funnel" node attribute not set. מעיד על בעיית מדיניות, לא על בעיה בפקודה. הוסיפו את המאפיין funnel לקובץ המדיניות של ה-tailnet, שמרו את השינויים ונסו שוב.

זה עבד, אך כעת tailscale serve status מציג No serve config. המיפוי נוצר בחזית (foreground) והתהליך הסתיים. הריצו את אותה פקודה שוב עם --bg.

שם המתחם מתורגם אך אין מענה. ה-proxy מנתב תעבורה ליעד שהגדרתם; אם אין שירות שמאזין בפורט זה, אין למה לנתב. ודאו זאת באמצעות ss -ltnp | grep 3000 על אותו שרת שמריץ את tailscaled. סיבה נפוצה היא מכולה (container) שמפרסמת את הפורט שלה בכתובת ה-bridge של Docker במקום ב-127.0.0.1, מה שגורם לכך שהמארח (host) לא מזהה מאזין בכתובת המצופה. כיצד פועלת רשת ב-Docker Compose מפרט היכן פורט מפורסם ממוקם בפועל.

שגיאות תעודה בשם ts.net. ככל הנראה תעודות HTTPS אינן מופעלות עבור ה-tailnet. הפעילו אותן ב-admin console, ולאחר מכן הריצו את שלב התעודות בנפרד כדי שהשגיאות לא יתערבבו עם הפלט של ה-serve:

sudo tailscale cert your-host.your-tailnet.ts.net

ה-funnel נטען ברשת סלולרית אך מתנהג אחרת מאשר במחשב הנייד. המחשב הנייד שלכם נמצא ב-tailnet, לכן MagicDNS מתרגם את השם לכתובת 100.x ואתם ניגשים לשירות ישירות, ללא מעבר דרך ממסר (relay). זו התנהגות תקינה, והמשמעות היא שהמחשב הנייד אינו יכול לבדוק נגישות ציבורית כלל. השתמשו ב-curl ממכשיר שאינו מחובר ל-tailnet.

FAQ

מה ההבדל בין tailscale serve לבין tailscale funnel?

ההבדל טמון במי שיכול להגיע לתוצאה. tailscale serve מפרסם פורט מקומי בכתובת HTTPS שרק מכשירים בתוך ה-tailnet שלכם יכולים להגיע אליה. tailscale funnel מפרסם את אותו פורט בכתובת שכל אחד באינטרנט יכול להגיע אליה, דרך שרתי ממסר (relay) ש-Tailscale מפעילה. הדגלים והיעדים משותפים לשניהם. שורת הפלט הראשונה מציינת מה קיבלתם: Available within your tailnet או Available on the internet.

מדוע tailscale funnel מציג הודעה שה-node attribute לא מוגדר?

מכיוון ש-funnel מושבת עבור ה-tailnet עד שמישהו מפעיל אותו. ההודעה היא Funnel not available; "funnel" node attribute not set. והיא מגיעה מהלקוח שלכם, עוד לפני שנוצר קשר עם שרת ממסר כלשהו. הוסיפו רשומת nodeAttrs המעניקה את ה-attribute מסוג funnel ל-autogroup:member, או לתג (tag) אם רק מכונה אחת אמורה לפרסם, בתוך קובץ המדיניות של ה-tailnet תחת Access Controls. מנהל ה-tailnet יכול לחלופין לעקוב אחר כתובת ה-URL להסכמה שה-CLI מדפיס.

באילו פורטים יכול Tailscale Funnel להשתמש?

רק 443, 8443 ו-10000. ברירת המחדל היא 443, ואתם יכולים לבחור אחר באמצעות --https=8443 או --https=10000. זוהי מגבלה של שרתי הממסר של ה-funnel, לא של השרת שלכם, לכן שום שינוי ב-firewall או בתצורה ב-VPS לא יסיר אותה. ל-tailscale serve אין מגבלה כזו, מכיוון שהתעבורה לעולם לא יוצאת מה-tailnet שלכם.

האם כתובת URL של serve או funnel נשמרת לאחר אתחול?

רק אם השתמשתם ב---bg. בלעדיו, הפקודה רצה בחזית, מדפיסה Press Ctrl+C to exit., והמיפוי נעלם יחד עם התהליך. עם --bg, המיפוי נכתב לתצורת ה-serve של הצומת וחוזר עם tailscaled לאחר אתחול. בדקו זאת באמצעות tailscale serve status, שמדפיס No serve config כאשר שום דבר אינו מוגדר.

האם זה בטוח להשאיר funnel פעיל?

זה בטוח מבחינת התעבורה: החיבור הוא HTTPS ושום פורט אינו פתוח ב-firewall שלכם. זה לא בטוח במובן המקובל, מכיוון שהכתובת ציבורית, ולכן היישום שמאחוריה חשוף לציבור. השאירו funnel פעיל רק לפני שירות שמבצע אימות (authentication) לבקשות שלו, והסירו אותו כשהדמו או בדיקת ה-webhook מסתיימים, באמצעות הפקודה שיצרה אותו בתוספת off בסוף.

מקורות להתנהגות הפקודות לעיל: תיעוד Tailscale Serve ו-Funnel והפניית ה-CLI בכתובת tailscale.com/docs.