למה מסלול VPN רחב שובר כמה אתרים ציבוריים
כמה אתרים נכשלים בעוד השאר נטענים, כי קידומת רחבה לוכדת את הכתובות שלהם. התאימו את המסלול לכתובת שנפתרה, ואז גלו מי מתקין אותו.
רוב העמודים נטענים, שניים או שלושה מגיעים לפסק זמן, והדפדפן מאשים את החיבור. לאתרים שנכשלים יש משהו משותף שאין לאתרים העובדים: הכתובות שנפתרו שלהם נופלות בתוך קידומת שהתקין ה-VPN. מסלול רחב מספיק כדי לכסות טווח ציבורי יתפוס תעבורה שהמנהרה מעולם לא נועדה לשאת, והתסמין נראה כמו בעיית אתר ולא כמו החלטת ניתוב.
פתרו את השם שנכשל, ואז הסתכלו בטבלת הניתוב ולא בדפדפן.
השוו את הכתובת, לא את שם האתר
חפשו את הכתובת שהלקוח באמת ניסה, ואז בדקו איזה מסלול מתאים לה. יעד בתוך 45.61.20.10 נופל תחת 45.0.0.0/8 אם הקידומת הזו קיימת, גם אם לאתר עצמו אין שום קשר למנהרה. השוואת הכתובת שנכשלת לקידומות המותקנות היא בעיית חיסור, לא ניחוש.
Windows יכול לענות על שני החצאים ישירות, וחיפוש מראה איזה ממשק ואיזה צעד הבא זכו בבחירה. פתרו את השם פעמיים אם האתר מחזיר כמה כתובות. רשמו כל אחת עם המסלול שהתאים לה. כתובות שונות יכולות לתת תשובות שונות, ורק אחת מהן אולי היא המקרה שנכשל.
Resolve-DnsName www.example.org Get-NetRoute -AddressFamily IPv4 | Select-Object DestinationPrefix,InterfaceIndex,NextHop,RouteMetric Find-NetRoute -RemoteIPAddress 45.61.20.10 Get-VpnConnection | Format-List Name,SplitTunneling,Routes
קראו את הקידומת המתאימה הספציפית ביותר, לא את השורה הראשונה שנראית מוכרת. מסלול שקיים בטבלה לא מוכיח שהוא זכה בחיפוש; ההתאמה הארוכה ביותר עושה זאת. שתי קידומות יכולות להתאים לכתובת אחת, ורק אחת מהן מקבלת את החבילה. המפסיד נשאר בטבלה ונראה אמיתי באותה מידה ברשימה.
רשמו את הקידומת, הממשק שלה והכתובת שנפתרה. שלושת הערכים האלה הם כל האבחון.
גלו מי התקין את המסלול
מסלולים מגיעים מארבעה מקומות: פרופיל ה-VPN המקורי, מדיניות ניהול, סקריפט חיבור או לקוח אחר לגמרי. מחיקת הרשומה החיה יכולה לאשר את הרלוונטיות שלה, אבל החיבור הבא יוצר אותה מחדש מהתצורה השמורה, ולכן המקור הוא מה שצריך להשתנות.
בדקו קודם את רשימת המסלולים של הפרופיל, אחר כך את מדיניות הניהול, ואחר כך כל סקריפט שרץ בעת החיבור. הסדר הזה מתאים לתדירות שבה כל אחד מהם מתגלה כאחראי. הוא גם משאיר את השינוי בשכבה אחת במקום שלוש.
קראו בקפידה את ההתנהגות המקורית מבוססת המחלקות
לפרופילים מקוריים של Windows יש הגדרה מתועדת, NativeProfile/DisableClassBasedDefaultRoute, ששולטת במסלול אוטומטי הנגזר מכתובת הממשק. כתובת פרופיל שמתחילה ב-45 יכולה תחת התנהגות זו ליצור רשומה 45.0.0.0/8, וכך כתובת ציבורית אחת לוכדת טווח שלם של מחלקה A.
שם המאפיין מזמין קריאה שגויה: הצבתו ל-true מכבה את הגזירה, ו-false מפעיל אותה. הוא גם אינו אותו אובייקט כמו מסלול ברירת מחדל, והוא אינו שולט בלקוחות צד שלישי שמתקינים קידומות משלהם.
אם הגזירה היא הסיבה המוכחת, תקנו את הפרופיל דרך בעל הניהול שלו וספקו במפורש את הקידומות הפרטיות המיועדות. אם סקריפט הוסיף את הרשומה, תקנו את הסקריפט. החלפת מסלול רחב לא מוסבר באחר משנה את התסמין בלי לענות על השאלה.
תקנו את המקור, ואז בדקו שוב את שני הנתיבים
לאחר השינוי, התחברו מחדש וחזרו על החיפוש עבור אתר ציבורי שנכשל ועבור משאב שחייב להשתמש במנהרה. הראשון אמור כעת להיפתר לממשק הפיזי, והשני אמור עדיין לבחור ב-VPN. אל תעצרו בהצלחה הראשונה; תיקון שגם שובר גישה פרטית החליף תקלה בתקלה אחרת.
עיינו באותו זמן בתכנית הכתובות של השרת. מאגר שחופף למרחב ציבורי גורם לסוג הבעיה הזה שוב ושוב. טווח שהמפעיל בחר בכוונה ראוי לשיחה אחרת, לא למספור מחדש אוטומטי.
העלאת ה-MTU או ניקוי ה-DNS לא יתקנו קידומת שעדיין מפנה את הכתובת הזו למנהרה. בדקו קודם את הבחירה, ואז את הנתיב.