מארח Tailscale אחד לא נגיש: נתב תת-רשת או צומת יציאה?

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

התחל מהיעד שנכשל

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

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

הגע להתקן שאף פעם לא מריץ Tailscale

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

tailscale up --advertise-routes=10.40.0.0/24 --advertise-exit-node=false
ip route get 10.40.0.55
tailscale status

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

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

הוצא תעבורה ציבורית דרך מכונה אחרת

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

tailscale up --advertise-exit-node
tailscale up --exit-node=100.101.102.103 --exit-node-allow-lan-access=false
tailscale status --json | grep -i exitnode

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

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

קרא את החלוקה המשולשת כשמארח אחד בלבד נכשל

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

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

אשר את המסלול שאתה חושב שבנית

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

ip route get 10.40.0.55
ip -6 route show default
tailscale ping 10.40.0.55

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