כאשר מסלולי מנהרה מפוצלת חופפים: איזה קידומת מנצחת

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

1. רשמו את היעד ואת המקור

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

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

2. שאלו את הגרעין איזה מסלול הוא בחר

אל תקראו את טבלת המסלולים ואל תסיקו את התשובה. שאלו את אותה שאלה שהמחסנית שואלת, עם אותה כתובת מקור: ip route get 10.20.4.10 from 10.8.0.2 ב-Linux, או Find-NetRoute -RemoteIPAddress 10.20.4.10 ב-PowerShell. הפלט מציין את המסלול שבאמת היה בשימוש, ולעיתים קרובות זה לא זה שציפיתם לו בקריאת הטבלה.

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

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

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

כאן מסתתרות שתי מלכודות. כלל שמצביע על טבלה ריקה יוצר חיפוש שנופל לכלל הבא, ולכן נראה שהכלל לא עושה דבר. השנייה היא מספר העדיפות עצמו: כללים נקראים בסדר עולה, והערכים המובנים הם 0 local, 32766 main ו-32767 default. כלל שמספרו נמוך מ-32767 נבדק לפני כלל ברירת המחדל שתופס הכול. כלל שמספרו גבוה מ-32767 נמצא מאחוריו ומגיעים אליו רק כשאין טבלה קודמת שעונה, דבר שמסלול ברירת מחדל רגיל ב-main מונע, ולכן בפועל אף פעם לא מגיעים אליו והוא אינו עושה דבר בשקט בעודו נראה מותקן. אם הלקוח כתב כלל ומסלול, בדקו את שניהם, ובדקו אותם שוב לאחר חיבור מחדש, כי פרופיל שנכתב מחדש יכול להוסיף כלל שני עם עדיפות אחרת.

4. הפרידו בין תיקו בניתוב לבין תוכנית כתובות משוכפלת

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

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

5. ודאו שהפותרן מסכים עם המסלול

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

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

6. התחברו מחדש, בדקו את המצב שהוחל, ואז בדקו את שתי הזרימות

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

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