מדוע לקוח Tailscale ב-Linux מתעלם מנתיבי תת-רשת מוכרזים

טבלה 52 היא הסימן: לקוח Tailscale ב-Linux מתקין נתיב תת-רשת מוכרז רק אחרי --accept-routes, ואישור ההתקן הוא שער נפרד.

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

מה לקוח Linux מסרב להתקין

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

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

הפעלת קבלת נתיבים במחשב הזה

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

sudo tailscale set --accept-routes
tailscale status
ip route show table 52

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

לקוחות ישנים יותר חושפים את אותה העדפה כדגל בפקודת הכניסה, ולכן sudo tailscale up --accept-routes הוא החלופה כשחסר tailscale set. השתמשו בו במקום לערוך נתיבים ביד, כי הדמון כותב מחדש את הטבלה שלו והעריכה שלכם נעלמת בחיבור הבא. בדקו את הגרסה לפני שתעתיקו פקודה מפוסט ישן.

בדיקת ההכרזה והאישור בנפרד

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

sudo tailscale up --advertise-routes=10.80.0.0/24
sysctl net.ipv4.ip_forward
ip -br addr

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

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

בדיקת הכתובת הפרטית לפני שם המארח

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

tailscale ping 10.80.0.1
ping -c 2 10.80.0.25
nc -vz 10.80.0.25 445
getent hosts nas.internal.example

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

בדיקה מקומית אחת שווה לעשות לפני שתאשימו את ה-tailnet. כשהרשת המקומית הנוכחית משתמשת באותה קידומת כמו תת-הרשת המרוחקת, הליבה מעדיפה את הנתיב המחובר ישירות והתעבורה לא עוזבת את המחשב, וזה מה שקורה כשבית ומשרד בוחרים שניהם 192.168.1.0/24.

מדוע דגל לקוח אינו הגדרת ראוטר

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

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

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

מאמרים קשורים