מנהרה מפוצלת ב-Windows: תיבת השער והקידומת החסרה

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

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

למה מנהרה שעובדת מרגישה כמו הפסקה

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

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

תיבת הסימון שמתחבאת בדיאלוג IPv4

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

השוו את route print -4 לפני ואחרי החיבור מחדש. הרשומה 0.0.0.0 שהצביעה קודם על המנהרה אמורה להיעלם, והקידומות הארגוניות אמורות להישאר.

route print -4 | findstr /c:"0.0.0.0"
Get-VpnConnection -Name 'Work VPN' | Select-Object Name, SplitTunneling, Routes

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

הקידומת שאף אחד לא רשם

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

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

route -p add 172.20.8.0 mask 255.255.255.0 10.8.0.1
Add-VpnConnectionRoute -ConnectionName 'Work VPN' -DestinationPrefix 172.20.8.0/24
Get-VpnConnection -Name 'Work VPN' | Select-Object -ExpandProperty Routes

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

להוכיח את התוצאה אחרי אתחול

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

tracert -4 www.example.com
tracert -4 wiki.corp.example
ping -4 fileserver.corp.example
ping -4 172.20.8.20

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

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