מדוע מסלולים בעלי עלות שווה הופכים תקלות VPN לקשות לזיהוי
כשכמה מנהרות חולקות אותה עלות, כל זרם יכול לבחור באחרת. ping מוצלח אינו אומר דבר על הנתיב שהאפליקציה שלך באמת משתמשת בו.
משתמש מדווח שהאפליקציה הפנימית עובדת ממכונה אחת ונכשלת מאחרת, בעוד שה־ping שאתה מריץ מהשער מצליח בשני המקרים. עם כמה מנהרות בעלות שווה, זו אינה סתירה. כל זרם ממוקם על הקפיצה הבאה שלו, כך שהבדיקה שלך והסשן של המשתמש עשויים פשוט להשתמש בנתיבים שונים. הסקירה שלהלן משחזרת את הבחירה לפני שמשנים משהו.
ping אחד, כמה נתיבים אפשריים
כאשר למסלול יש יותר מקפיצה הבאה אחת באותה עלות, על הנתב לבחור אחת לכל מקטע. רוב המימושים מבצעים גיבוב של שדות מהמקטע, בדרך כלל כתובות המקור והיעד יחד עם הפרוטוקול והפורטים, כדי שהתגובות יישארו באותו נתיב. אפליקציות שונות, ואפילו חיבורים שונים של אותה אפליקציה, מייצרים ערכי גיבוב שונים.
לכן אבחון מהשער מוכיח כל כך מעט. לבדיקה של השער יש כתובות ופורטים משל עצמה, ולכן גיבוב משל עצמה. היא עשויה לנחות על המנהרה התקינה בעוד המשתמש ממשיך לנחות על השבורה.
כיצד הפלטפורמה בוחרת קפיצה הבאה
שחזרו את הבחירה במקום לנחש אותה. שאלו את הקרנל באיזה מסלול ישתמש עבור אותו מקור ויעד כמו הסשן שנכשל. החיפוש הזה כולל שדות שחיפוש יעד רגיל מתעלם מהם. הריצו אותו גם מלקוח שעובד והשוו בין שתי התשובות:
ip route get 10.20.5.7 from 10.20.0.14גרסאות חדשות יותר של iproute2 מקבלות גם את הפרוטוקול ואת פורט היעד, מה שחשוב כשהגיבוב כולל אותם. השוו את הפלט הזה לאותו חיפוש מלקוח שעובד, וההבדל הוא הראיה שהייתה חסרה לכם.
| Observation | Likely cause | First check |
|---|---|---|
| Ping works, application fails | A different flow hash selects another tunnel | Per-flow lookup from the client's address |
| Some users fail, others do not | One tunnel lacks a prefix or selector | Compare both tunnels' installed routes |
| Fails only at larger sizes | Tunnels have different effective MTU | Probe the same size over each path |
| Fails after a reconnect | Stateful asymmetry between paths | Session state on both gateways |
עקבו אחרי הזרם שנכשל, לא אחרי טבלת־הניתוב
טבלת־הניתוב מפרטת את שתי המנהרות ונראית נכונה בהגדרה. השאלה היא מה כל מנהרה עושה עם המקטע לאחר שנבחרה. ודאו ששתיהן נושאות את אותן קידומות מוגנות, את אותה הרשאת העברה ונתיב חזרה שמגיע לאותו לקוח.
שימו לב להתקנים בעלי מצב באמצע. אם בקשה יוצאת דרך מנהרה אחת והתגובה חוזרת דרך האחרת, חומת־אש או NAT שמעולם לא ראתה את הזרם המקורי תפיל אותה. שתי המנהרות מעבירות תעבורה כראוי, והחיבור עדיין נכשל.
בדקו גם את ה־MTU לכל נתיב. נתיב עם עטיפה נוספת מקטין את הגודל השמיש, והעברה שמצליחה במנהרה אחת נתקעת בשנייה בדיוק בגודל שבו הקטנה נשברת.
השוו נתיב אחד בכל פעם
היכן שהתכנון מאפשר תחזוקה, הוציאו מנהרה אחת משירות וחזרו על המשימה של המשתמש. אם התקלה נעלמת, הבעיה שייכת לנתיב שהוצאתם, והצעד הבא הוא להשוות את התצורה שלו לזו של שכנו במקום לבחון מחדש את טבלת־הניתוב.
השוו את האפליקציה האמיתית, לא ping חוזרים. רשמו אם התקלה עוקבת אחרי קפיצה הבאה מסוימת, גודל מקטע או מעבר לאחר התחברות מחדש, מפני ששלושת הדפוסים האלה מצביעים על תיקונים שונים.
לבסוף, רשמו מדוע הנתיבים נחשבים שקולים וכיצד תקלה אמורה להוציא אחד מהם משירות. ריבוי נתיבים בטוח רק כאשר הנתיבים באמת ניתנים להחלפה, וזו הצהרת תכנון שראוי לבדוק ולא להניח.