מדוע גילוי שכנים של IPv6 נכשל דרך VPN מנותב

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

ההיקף קודם לתצורה

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

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

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

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

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

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

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

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

בדוק עם הכתובת שהאפליקציה משתמשת בה

אשר את המסלול עם ip -6 route get, בדוק את רשומת השכן עם ip -6 neigh, ואז אשר את השירות לאורך המסלול המנותב. DNS ומסלול החזרה הם בדיקות נפרדות, ורשומת שכן תקינה אינה מוכיחה אף אחת מהן.

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

רשום איזה תכנון יש לך

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

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