מדוע מסלול תת-רשת מאושר ב-Tailscale עדיין מסתיים בפסק זמן

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

ארבעה שלבים, כשל אחד

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

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

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

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

בדקו את המסלול היכן שהלקוח פועל

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

tailscale status
tailscale debug prefs | grep -i route
ip route get 10.20.0.42

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

כדי לקבל מסלולים ב-Linux, התחברו מחדש עם הדגל במקום להניח שהוא מוגדר: tailscale up --accept-routes. לקוח שהצטרף עם דגלים אחרים שומר עליהם עד שישתנו, לכן בדקו את ההגדרה הנוכחית לפני שתוסיפו עוד אחת. הרצה חוזרת של הפקודה הראשונה לאחר השינוי אמורה להראות את המסלול בטבלה.

הוכיחו את ההעברה ואת נתיב החזרה

האישור אינו מגדיר את הנתב להעביר חבילות, ואינו מסדר את התשובה. שניהם עניינים ברמת המארח בצד ה-LAN של הנתב. בדקו אותם בנתב, לא בלקוח.

sysctl net.ipv4.ip_forward
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni any host 10.20.0.42 and port 443

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

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

קראו את כלל הגישה למשאב

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

tailscale status --json | head -40
tailscale ping <router-name-or-tailnet-ip>
ping -c 3 10.20.0.42

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

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

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