שיתוף VPN של Windows עם קונסולה בחיבור כבלים: שער PC מול נתב
קונסולה שמאחורי מחשב Windows זקוקה למקטע במורד הזרם, לכתובות, לתרגום וללקוח שמעביר. השוו זאת לנתב שמחזיק את המנהרה.
קונסולות שאינן יכולות להריץ את לקוח ה-VPN יכולות לפעמים לשאול את המנהרה של מחשב Windows, והסדר הזה נכשל לעתים קרובות יותר מכפי שהוא מצליח, מסיבות שאינן קשורות ל-VPN. המחשב חייב להפוך לשער: ממשק נפרד במורד הזרם, כתובות עבור הקונסולה, תרגום, ולקוח שמוכן להעביר מנות של התקן אחר. מנהרה שעובדת עבור היישומים של המחשב עצמו אינה מוכיחה דבר מזה.
ההשוואה שראוי לעשות היא בין הסדר הזה לבין נתב שמחזיק את המנהרה עבור כל הרשת. הם נבדלים בתחזוקה, בהתנהגות בעת תקלה ובכמה מהמדיניות אפשר לראות בבת אחת.
מה שעל שער ה-PC לעשות
שער זקוק לממשק הפונה אל הקונסולה, לטווח כתובות עבור אותו מקטע, ולכלל תרגום שכותב את התעבורה של הקונסולה אל המנהרה. הוא זקוק גם לכך שהלקוח יעביר מנות שהוא עצמו לא יצר, וזו הגדרה שונה מקבלת התעבורה שלו. פתרון השמות חייב לעבור באותו מסלול, אחרת הקונסולה מפענחת שירות משחק דרך מסלול אחד ואז מתחברת דרך אחר. כל אחד מאלה הוא שלב תצורה נפרד עם אופן כשל משלו.
console -> dedicated ethernet -> windows sharing / nat
-> selected tunnel interface -> internetשיתוף חיבור האינטרנט של Windows מספק בדיוק את הצורה הזאת, כשחיבור אחד מוגדר כציבורי והאחר כפרטי. ההגדרה הזו חשובה יותר ממה שאנשים מצפים, מפני שהממשק שמגיע לנתב הביתי אינו בהכרח זה שנושא את המנהרה.
השוואות שמכריעות
שלושה הבדלים מפרידים בין שער PC לשער נתב, ואלה הם אלה שצצים חודשים אחר כך. הטבלה מציבה אותם זה לצד זה.
| Aspect | Windows PC gateway | Router gateway |
|---|---|---|
| Tied to a user session | Yes; sleep or sign-out ends it | No |
| Policy visibility | Split across client and sharing layer | One ruleset |
| Address service | Private side of the sharing feature | Router scope |
| Recovery after reboot | Manual, per session | Automatic |
הקישור לסשן המשתמש הוא ההבדל הראשון וזה שתופס אנשים. מחשב שנרדם, מתנתק או מתקין עדכון מפסיק להיות שער, והקונסולה מאבדת את המסלול שלה בלי שאף תצורה משתנה. נראות המדיניות היא השנייה, מפני שכללי הלקוח ושכבת השיתוף נמצאים בשני מקומות ואף אחד מהם לא מתאר את האחר. שירות הכתובות הוא השלישי, והוא מסביר קונסולה שמחזיקה כתובת ובכל זאת אינה מגיעה לשום דבר.
שום דבר מזה לא הופך את סידור ה-PC לשגוי. הוא הופך אותו לתכנון זמני, וזה מקובל כשהדרישה זמנית.
תעבורה מועברת היא קטגוריה אחרת
לקוח שולחני עשוי להתייחס למנות שמועברות עבור התקן אחר אחרת מהמנות שלו. רשימת הכללה לפי יישום מכסה תהליכים במחשב ואינה אומרת דבר על התעבורה של קונסולה, בעוד שמתג הרג המגן על יישומים מקומיים עשוי שלא להגן על המסלול המועבר כלל. אמתו את ההתנהגות המתועדת של הלקוח לגבי תעבורה מועברת במקום להסיק אותה מטעינת עמוד מוצלחת במחשב. במקום שבו ההתנהגות הזו אינה ברורה, כל הסדר נשען על הנחה.
הכתובות של הקונסולה צריכות לבוא מסידור השיתוף, ולעולם לא מהעתקת כתובת המנהרה של המחשב אליה. העתקה יוצרת כתובת כפולה, שער שגוי ופותרן שמצביע על משהו שהקונסולה אינה יכולה להגיע אליו. הניחו לשירות במורד הזרם לחלק את התצורה, ואז בדקו מה הקונסולה קיבלה בפועל.
בדקו את התעבורה של הקונסולה, לא של המחשב
הבדיקה המשמעותית היחידה מתבוננת במסלול של הקונסולה. במחשב, הפקודות שלמטה מציגות את פריסת הממשקים, את טבלת השכנים לאורך הקישור במורד הזרם, ואם הקונסולה עונה בפורט שירות. הריצו אותן כשסשן משחק מחובר באמת.
Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4Address
Get-NetAdapter | Select-Object Name, Status, LinkSpeed
arp -a | findstr 192.168.137.
Test-NetConnection 192.168.137.10 -Port 3074ממשק בלי כתובת בצד המורד פירושו שהשיתוף מעולם לא התחיל, וזו בעיה שונה מקונסולה שאינה מצליחה להתחבר. רשומה עבור הקונסולה בטבלת השכנים מוכיחה שהקישור והכתובות חיים. בדיקת פורט שנכשלת אחר כך מצביעה על העברה או על אופן הטיפול של הלקוח בתעבורה מועברת, לא על הכבל. השוו את כתובת היציאה של הקונסולה לזו של המחשב לפני שאתם מסיקים שהמנהרה היא המסלול שבשימוש.
שמרו את הסידור מתועד עם שמות הממשקים וטווחי הכתובות. כשהוא יישבר אחרי העדכון הבא, העמוד הזה חוסך שעה של גילוי מחדש.