שיתוף הפעלת VPN של המארח עם אורח VMware

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

שתי סיבות לכך שהגשר אינו יכול לעבוד

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

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

צרו מקטע שהמארח מחזיק בו

בעורך הרשת הווירטואלית, הוסיפו רשת מארח בלבד כמו VMnet3 על קידומת שאינכם מנתבים בשום מקום אחר, למשל 172.28.90.0/24. המארח לוקח 172.28.90.1 במתאם הזה והאורח מתחבר לאותו מתג. השביתו את ה-DHCP של ההיפרוויזור במקטע הזה כדי ששירות כתובות אחד יחזיק בו.

ודאו ש-Windows רואה את הממשק לפני שאתם בונים עליו משהו, כי כל התכנון תלוי בכך שהמתאם הזה יהיה רגיל:

Get-NetAdapter | Format-Table Name, InterfaceDescription, Status
Get-NetIPAddress -AddressFamily IPv4 | Where-Object PrefixLength -eq 24

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

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

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

Get-NetNat | Format-Table Name, InternalIPInterfaceAddressPrefix, Active
New-NetNat -Name "LabGuestEgress" -InternalIPInterfaceAddressPrefix 172.28.90.0/24

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

בדקו את הקפיצה הראשונה, ואחר כך את המחיר

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

tracert -d 172.20.31.10
nslookup intranet.corp.example
Get-NetNatSession -NatName "LabGuestEgress"

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

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