תעבורת IPv6 מחוץ ל-VPN: מצא את המסלול המדליף

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

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

איזה זרם באמת יצא, ועל איזה מתאם

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

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

לקרוא את המסלול שהגרעין בחר

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

ip -6 route get 2606:4700:4700::1111
ip -6 rule show
ip -6 route show table all

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

מאין מגיעה מדיניות ה-IPv6 של הלקוח

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

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

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

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

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

שלוש דרכים לסגור את הפער

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

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