הפינג אל עמית מנהרת ה-IPv6 שלכם נכשל? בדקו את כתובת ::

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

התסמין שמצביע על הכתובת

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

המזהה שכולו אפסים שמור כ-anycast

RFC 4291 שומר את מזהה הממשק שכולו אפסים ככתובת ה-anycast של נתב תת-הרשת, ולכן /64 כמו 2001:db8:4a::/64 אינו מכיל מארח שמיש בכתובת 2001:db8:4a::. השמירה מצדיקה את מקומה: הודעות נתב וגילוי שכנים ממוענים לצורה הזו, ונתב עונה עבור הקידומת שהוא משרת. הקצאת הערך הזה לקצה מנהרה נותנת תפקיד נתב לעלה, ולכן שום דבר לא חוזר. כל מזהה אחר בקידומת עובד כמארח, ולכן התיקון הוא בדרך כלל ספרה אחת.

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

הקצו כתובות מארח ונתבו את הקידומת

בחרו ::1 ו- ::2 לשני הקצוות, הוסיפו אחת עם ip -6 addr add 2001:db8:4a::2/64 dev tun0, ואז נתבו את הקידומת המרוחקת במקום לנסות להעניק לה כתובת. מסלול עבור 2001:db8:4a::/64 דרך המנהרה הופך את הצד הרחוק לנגיש; הכתובת לבדה רק מגדירה את הממשק המקומי.

עבור מנהרה מלאה יש שלב שלישי, מסלול ברירת מחדל ל-unicast גלובלי דרך ההתקן, שהוא המקבילה ב-IPv6 לשליחת הכול אל המנהרה. אם תדלגו עליו, IPv6 ימשיך להשתמש בקישור הפיזי בזמן ש-IPv4 נוסע בתוך המנהרה, כך שהמארח מדליף בדיוק את התעבורה שחשבתם שמכוסה. אשרו עם ip -6 route get 2001:4860:4860::8888 וקראו איזה התקן הוא מציין במקום להניח את התשובה.

multicast נדחה לפני הניתוב

Android מאמת כתובות ומסלולים עבור VpnService.Builder דרך LinkAddress, והבנאי הזה דוחה multicast לחלוטין. תנו לו קידומת multicast כמסלול והתוצאה היא כשל של פרמטרי LinkAddress גרועים ולא מסלול, שזו תשובת אימות ולא תשובת רשת. הדחייה תואמת למדיום: להתקן tun נקודה לנקודה אין multicast בשכבת הקישור, ולכן למסלול קבוצתי עליו אין מודל מסירה להתקין. כתובות קבוצה נוצרות ונצרכות על ידי ה-stack עצמו ולא נקבעות ביד.

כתובות IPv6 all-nodes ו-solicited-node נופלות תחת אותו כלל. הממשק נושא אותן כי ה-stack שם אותן שם, לא כי מדיניות התכוונה לכך.

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

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

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

שלוש בדיקות לפני שמקצים משהו

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

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