אורח Hyper-V מאבד DNS כשהחיבור ל-VPN של המארח נוצר

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

מה האורח עדיין יכול לראות

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

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

באיזה מוצא האורח משתמש

Hyper-V עונה על כך בשתי פקודות: Get-VMSwitch מציג את המתגים, ו-Get-VMNetworkAdapter -VMName TestVM מציג את זה שאליו האורח מחובר. ה-Default Switch הוא רשת NAT שמנוהלת על ידי Windows; מתג חיצוני מעביר תעבורה למתאם פיזי; מתג פנימי לא נושא דבר עד שמישהו מוסיף NAT או נתב. VirtualBox מציג את אותם שלושה רעיונות כ-NAT, NAT Network ו-bridged.

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

שיתוף מנהרת המארח עם Hyper-V

אם האורח זקוק למנהרה ואינו יכול להריץ לקוח משלו, Windows יכול לשתף את חיבור ה-VPN. פתחו את מאפייני מתאם ה-VPN, עברו לשיתוף, ואפשרו למשתמשי רשת אחרים להתחבר דרכו. כוונו את חיבור הרשת הביתית למתאם Hyper-V, vEthernet (Default Switch), ואז בדקו בקשה חדשה מתוך האורח.

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

התקנה מחדש של תכונת Hyper-V הצילה כמה אורחים עקשנים. שמרו זאת לאחרון, ורשמו קודם את מצב האורח.

העברת פורטים כשהתת-רשת מסוננת

VPN של מארח שמסנן את תת-רשת ה-NAT של האורח שובר גישה ישירה ולא פתרון שמות. המכונה פועלת, אך ssh [email protected] נתקע, בזמן שהתרגום של ההיפרוויזר עדיין עובד. העבירו את הפורטים שהעבודה צריכה והתחברו לכתובת המארח במקום. שורות ה-Vagrantfile שלמטה מכסות SSH ושירות HTTPS אחד; שתיהן נכנסות לפני הטעינה מחדש.

config.vm.network "forwarded_port", guest: 22, host: 22
config.vm.network "forwarded_port", guest: 3443, host: 3443

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

הבדיקה שאומרת לכם שזה עבד

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

Resolve-DnsName intranet.corp
Test-NetConnection 192.0.2.10 -Port 22

רשמו כל שינוי מתג או מנהל התקן עם שלב הביטול שלו. המדריך של Microsoft בנושא Hyper-V NAT מסביר מהו ה-Default Switch באמת, וכדאי לקרוא אותו לפני שיוצרים רשת NAT שנייה שמתנגשת בו.