يفسد DNS في ضيف VirtualBox بعد اتصال المضيف بشبكة VPN

يتحلل تطبيق داخلي على مضيف Windows لحظة اتصال VPN، بينما يظل ضيف Ubuntu خلف NAT في VirtualBox عاجزاً عن العثور عليه. فللضيف محلله الخاص، ويمكن لمحول NAT التعامل مع DNS بأكثر من طريقة. واستبدال محلل الضيف بخادم عام يجعل المواقع العادية تعمل والأسماء الخاصة تفشل، وهو ما ينقل المشكلة بدلاً من حلها. نفّذ الفحوصات الأربعة بالترتيب وتوقف عند أول فحص لا يصمد.

تأكد من وضع المحول الذي تُصلحه

لا يتصرف بالطريقة التي تصفها هذه المقالة إلا محول في وضع NAT الصريح. فالمحول الجسري يجلس على الشبكة الفعلية بهويته الخاصة، وشبكة NAT شبكة تبديل افتراضية مُسمّاة بإعدادات DHCP وDNS خاصة بها، وعميل VPN داخل الضيف يضيف محللاً ثانياً بالكامل. تأكد من الوضع قبل متابعة القراءة، لأن الإصلاح يختلف في كل واحدة من تلك الحالات.

يمكن لآلة افتراضية واحدة أن تحمل محولين في وضعين مختلفين، والمحول المتأثر ليس دائماً الأول.

تأكد أيضاً من أن المضيف يحلل الاسم أصلاً. افتح التطبيق نفسه على المضيف والنفق قائم، مستخدماً الاسم المؤهل بالكامل نفسه الذي سيستخدمه الضيف. وإذا فشل المضيف أيضاً، فليس الضيف هو السبب ولن يصلح أي تغيير في الشبكات الافتراضية ذلك.

تتبَّع اسماً واحداً عبر محلل الضيف

اختر اسماً داخلياً واحداً واسماً عاماً للمراقبة، ثم اختبر كليهما في الموضعين. فالاسم العام الذي يتحلل بينما يفشل الاسم الخاص يحدد موقع العطل في المسار الخاص لا في تحليل الأسماء عموماً. واختبار الاسم الخاص وحده يتركك غير قادر على التمييز بين محلل معطل ومسار معطل.

انظر داخل الضيف إلى ما أُعدّ المحلل لاستخدامه فعلاً. في ضيف Ubuntu يعمل بـ systemd-resolved، تعرض حالة كل وصلة الخوادم التي وصلت، وقد لا يحتوي ملف resolv.conf على شيء سوى عنوان وهمي، وهذا صحيح لا مريب. وملف مُحرَّر يدوياً أو عميل DNS مشفّر منفصل يمكن أن يرسل الاستعلامات إلى مكان آخر تماماً. دوّن ما تجده قبل تغييره.

resolvectl status
resolvectl query app.internal.example

افصل هنا بين التحلل والوصول. فالعنوان الذي يصل بينما تظل الخدمة غير قابلة للوصول مسألة توجيه أو سياسة، لا مسألة DNS.

جرّب وضع محلل المضيف على ذلك المحول

تصف خيارات NAT DNS في VirtualBox آليات مختلفة، ويصبح الفرق مهماً عندما يتغير محلل المضيف نفسه مع النفق. فوكيل DNS يمرر طلبات الضيف إلى خوادم سُلّم بها. أما وضع محلل المضيف فيعترض الطلبات ويستدعي واجهة DNS في المضيف، وهو الوضع الذي يتبع محلل Windows أعيدت تهيئته بواسطة عميل VPN.

فعّل الآلية الخاطئة وسينجح الأمر رغم ذلك بينما لا يتغير السلوك، وهذه طريقة مربكة لخسارة فترة بعد الظهر.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

سجّل إعدادات الآلة الافتراضية الحالية، وأغلقها، واستهدف المحول الذي تأكدت منه سابقاً. فالرقم الأخير في الخيار رقم محول لا ثابت، لذا فإن تطبيقه على آلة افتراضية يكون محولها المتأثر هو الثاني عملية صامتة بلا أثر. ابدأ الضيف وافحص إعداد المحلل الذي تلقاه فعلاً، لأن إعداداً يدوياً في الضيف يتجاوز كل ما تقدمه طبقة NAT. وتذكّر أن وضع محلل المضيف يفترض أيضاً أن مسار DNS الخاص بالمضيف هو ما كنت تقصد مشاركته.

أعد الاختبارات نفسها عبر إعادة اتصال VPN

كرر الاستعلامين في الضيف، ثم افتح التطبيق الحقيقي ودعه يتحقق من الشهادة بنفسه. فاختبار العناوين وحده مفيد لعزل تحليل الأسماء وليس مكافئاً لجلسة TLS عاملة، لذا لا تتوقف عند ping. ثم، في نافذة معتمدة، افصل نفق المضيف وأعد وصله وكرر مرة أخرى. والسلوك الذي يصمد فقط في الاتصال الأول بعد الإقلاع مشكلة دورة حياة يُبلَّغ عنها، لا لغز DNS يُطارَد بمحلل آخر.

عمل التحلل العام لا يثبت أن الاستعلامات الخاصة بقيت على المسار الذي تتطلبه سياستك.

حين لا يغيّر وضع محلل المضيف شيئاً، أعد الإعداد المسجل واحتفظ بالملاحظات الأربع: ما أعاده المضيف، وما أعاده الضيف، ووضع المحول، وحالة المحلل. ويحتاج كل من خادم داخلي غير قابل للوصول، و مرشح يستثني حركة الهايبرفايزر، وتجاوز على جانب الضيف إلى تصحيح مختلف. تحويل المحول إلى جسر يغيّر تصميم الشبكة وليس إعادة ضبط DNS.