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

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

עקבו אחרי חיפוש אחד דרך מתאם ה-NAT

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

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

VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natnet
resolvectl status | head -40
cat /etc/resolv.conf

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

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

מצב proxy ומצב resolver של המארח הם מנגנונים שונים

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

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

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

החליפו את המתאם ואז ודאו מה האורח מקבל

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

VBoxManage modifyvm work-ubuntu --natdnshostresolver1 on
VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natdns

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

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

בדקו לאורך כל מחזור החיים של ה-VPN, לא רק פעם אחת

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

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

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