Tailscale Serve מול Funnel: מי באמת יכול לפתוח את הקישור?

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

Serve עונה על שאלה בתוך ה-tailnet שלך

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

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

Funnel משנה את הקהל לאינטרנט הפתוח

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

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

קראו את המצב מהלקוח, לא מהפורט

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

tailscale serve status
tailscale funnel status
tailscale status --json | head -40

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

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

בדקו עם הקהל שהתכוונתם אליו באמת

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

curl -sI https://host.tailnet-name.ts.net
curl -sI https://host.tailnet-name.ts.net --resolve host.tailnet-name.ts.net:443:203.0.113.10

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

פרסום שירות גם אינו אותה החלטה כמו בחירת צומת יציאה, ששולטת מהיכן התעבורה היוצאת שלכם יוצאת. Serve ו-Funnel עונים על מי יכול להגיע למשהו שאתם מריצים; צומת יציאה עונה מהיכן נראה שהחיבורים שלכם מגיעים. הפרידו בין שתי השאלות וההשוואה נשארת פשוטה.