האם מכונה וירטואלית של Hyper-V משתמשת ב-VPN של המארח? זה תלוי במתג

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

המיתוס, בניסוח פשוט

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

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

שלושה סוגי מתגים, שלושה נתיבים

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

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

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

מתג ברירת המחדל הוא סידור בפני עצמו

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

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

ארבע עובדות שמיישבות את השאלה

אספו את אלה לפני שתשנו משהו: סוג המתג והקישור שלו למעלה, המתאם המחובר למכונה הווירטואלית, הכתובת, השער וה-DNS של האורח עצמו, ומצב ה-NAT ומסלול ברירת המחדל של המארח. הפקודות לקריאה בלבד הן Get-VMSwitch, Get-VMNetworkAdapter -VMName "TestVM", Get-NetNat, ו-Get-NetRoute -DestinationPrefix 0.0.0.0/0; ובתוך האורח ipconfig /all נותן את השאר.

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

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

מה המיתוס עולה

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

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

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