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

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

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

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

שתי טופולוגיות, שתי צורות כתובת

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

TopologyClient address shapePeerRoute to expect
Point-to-point block per clientTwo neighbouring addresses inside a small blockThe far address of that blockA single host route on the tunnel device
Shared poolOne address carrying the pool maskThe server's tunnel addressA single host route on the tunnel device

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

כשהמאגר ורשת המשרד תובעים את אותם ביטים

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

קידומות שרק נראות דומות הן מקרה אחר, והשוואת אוקטטים בעין אינה השוואת קידומות. כתבו את שתיהן וספרו את הביטים הממוסכים: 192.168.4.0/24 מול 192.168.6.0/24 מתלכדות עד ביט 22 ומתפצלות בביט 23, כי האוקטט השלישי נקרא 00000100 מול 00000110, ולכן שתי הרשתות האלה נפרדות באמת. שימו 10.8.0.0/24 לצד 10.8.0.0/24 אחר וכל 24 הביטים הממוסכים מתלכדים, כלומר מסלול אחד אינו יכול לבטא את שני המקומות. אורך המסכה קובע היכן ההשוואה נעצרת, והרשת שהותקנה שנייה היא זו שמפסידה.

מה שקישור מנותב אינו יכול לספק

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

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

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

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

ip -4 addr show dev tun0
ip route show dev tun0
ip route get 10.8.0.1

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

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