يتعطّل DNS الضيف في VirtualBox بعد انضمام المضيف إلى VPN

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

تتبَّع بحثًا واحدًا عبر واجهة NAT

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

تأكَّد أولًا من أن الواجهة NAT عادية فعلًا قبل المضي قدمًا. الواجهة الجسرية وشبكة NAT المسماة وعميل VPN ثانٍ داخل الضيف لكل منها إعداداته وتفسيره الخاص. التخمين في هذه المرحلة يهدر بقية التحقيق.

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

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

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

وضع الوكيل ووضع مُحلِّل المضيف آليتان مختلفتان

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

هذا الفرق هو المشكلة كلها في جملة واحدة. إعطاء الضيف قائمة عناوين خوادم ليس مثل مطالبة Windows بحلّ اسم عبر مُحلِّله المهيأ، وفي VPN بتقسيم DNS تختلف الإجابتان. خيار الواجهة يتعلق بالآلية لا بالإذن.

لا يمنح أي من الوضعين وصولًا إلى أي شيء. التفويض يعيش في سياسة VPN وفي الخدمة، والبحث الناجح لا يعني سوى أن اسمًا تحوَّل إلى عنوان.

بدِّل الواجهة ثم تحقَّق مما يتلقاه الضيف

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

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

الرقم الأخير يختار رقم الواجهة، لذا ليس قيمة عالمية؛ إعداد الواجهة 2 يحمل 2 في ذلك الموضع. استخدم برنامج VBoxManage التابع لإصدار VirtualBox المثبَّت، لأن نسخة أقدم في المسار قد تكتب إعدادات يتجاهلها الإصدار العامل.

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

اختبر عبر دورة حياة VPN، لا مرة واحدة فقط

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

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

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