איזה מקור IPv6 בוחרת בקשת VPN, ולמה זה חשוב

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

שני חיפושים, לא אחד

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

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

קראו את הכללים כתחרות מסודרת

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

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

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

קישור של יישום משנה את השאלה

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

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

בדקו שהצד המרוחק מקבל את המקור הזה

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

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

החליטו עם ארבע תצפיות

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

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