אורח מגושר ב-VMware איבד את הרשת אחרי OpenVPN

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

האורח לא השתנה, הגשר כן

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

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

קבעו את הגשר או נתבו את האורח

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

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

לענף הראשון, פתחו את עורך הרשת הווירטואלית במארח, בחרו VMnet0 והחליפו את האוטומטי במתאם הפיזי. אם יש כמה מתאמים, השתמשו ברשימת ההגדרות האוטומטיות והסירו את הסימון מכל דבר שאסור לו לשאת תעבורת אורח: התקן OpenVPN TAP או Wintun, וכן מתאמי Hyper-V, WSL, Docker ו-loopback. השאירו מסומנים גם המתאם הפיזי הקווי וגם האלחוטי במחשב נייד, אחרת האורח יאבד את הגשר בפעם הבאה שהמשתמש יעגן אותו.

שלושה תנאים שמכריעים את הבחירה

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

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

ל-VMware Player אין עורך רשת בממשק שלו, ולכן מארח שמריץ רק Player זקוק לעורך העצמאי או להתקנת Workstation כדי להגיע להגדרות האלה. המגבלה הזו לעיתים מכריעה את הגישה בעצמה.

קראו את התוצאה מתוך האורח

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

ipconfig /all
ip addr
ip route

קראו שני שדות בפלט הזה והתעלמו מהשאר לעת עתה. השער צריך להיות נתב ה-LAN, ותיאור המתאם צריך לנקוב בהתקן ה-Ethernet של VMware ולא במנהרה. כתובת שהוקצתה לעצמה ב-169.254.0.0/16 משמעה שאף שרת DHCP לא ענה, וכך נראה גשר על מתאם מנהרה מצד האורח.

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