מתאם ה-VPN מציג /32: זה לא אומר יעד אחד

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

המיתוס: מסכת מארח פירושה מארח אחד שאפשר להגיע אליו

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

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

לקרוא את הכתובת ואת המסלולים כאל אובייקטים נפרדים

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

ip addr show tun0
ip route show
ip route get 10.60.5.10

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

Get-NetIPAddress -InterfaceAlias "VPN"
Find-NetRoute -RemoteIPAddress 10.60.5.10

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

למה הרחבת המסכה בדרך כלל מחמירה את המצב

שינוי ההקצאה ל-/24 כדי להיראות כמו ה-LAN של המשרד יכול ליצור תחילית על הקישור: הגרעין מאמין כעת שכל ה-/24 מחובר ישירות לממשק המנהרה. תעבורה לכתובות שאמורות להיות מנותבות דרך השער נשלחת אז כאילו שכן נמצא על הקישור. התוצאה היא חור שחור שנראה כמו תקלת שרת.

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

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

כשהמסלול נכון והזרימה עדיין נכשלת

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

ping -c1 10.60.5.10
traceroute -n 10.60.5.10
curl -sv https://app.internal.example/ -o /dev/null

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

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