משתפים חיבור Windows? נתיב ה-VPN משתנה מתחתיו

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

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

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

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

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

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

Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name,InterfaceIndex,LinkSpeed
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias,IPAddress,PrefixLength
Get-NetIPInterface | Select-Object InterfaceAlias,Forwarding,ConnectionState
Get-NetConnectionProfile

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

העברה, תרגום וסינון

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

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

הריצו את הבדיקות בלקוח, לא במארח

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

Resolve-DnsName intranet.example.net -Type A
Resolve-DnsName intranet.example.net -Type AAAA
Invoke-RestMethod https://api.ipify.org
Test-NetConnection intranet.example.net -Port 443 -InformationLevel Detailed

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

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