ה-DNS של אורח VirtualBox נשבר אחרי שהמארח מתחבר ל-VPN

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

אשר איזה מצב מתאם אתה מתקן

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

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

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

עקוב אחר שם אחד דרך ה-resolver של האורח

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

בתוך האורח, בדוק למה ה-resolver מוגדר באמת. באורח Ubuntu שמריץ systemd-resolved, הסטטוס לפי קישור מציג את השרתים שהגיעו, וקובץ resolv.conf עשוי להכיל רק כתובת stub, וזה נכון ולא חשוד. קובץ שנערך ביד או לקוח DNS מוצפן נפרד יכולים לשלוח שאילתות למקום אחר לגמרי. רשום מה מצאת לפני שאתה משנה.

resolvectl status
resolvectl query app.internal.example

הפרד כאן בין פתרון לנגישות. כתובת שמגיעה בעוד השירות נשאר לא נגיש היא שאלת ניתוב או מדיניות, לא שאלת DNS.

נסה את מצב ה-resolver של המארח במתאם הזה

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

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

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

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

חזור על אותן בדיקות לאורך התחברות מחדש של VPN

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

העובדה שפתרון ציבורי עובד אינה מוכיחה שהשאילתות הפרטיות נשארו בנתיב שהמדיניות שלך דורשת.

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