ضيف Hyper-V يفقد DNS عند اتصال VPN المضيف

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

ما الذي لا يزال الضيف قادرًا على رؤيته

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

تلك القراءات الثلاث، المأخوذة مرتين، هي خط الأساس لديك. وكل ما يأتي لاحقًا يُقاس مقابلها.

أي مخرج يستخدمه الضيف

يجيب Hyper-V عن ذلك بأمرين: Get-VMSwitch يسرد المحوّلات، وGet-VMNetworkAdapter -VMName TestVM يُظهر المحوّل الذي يتصل به الضيف. المحوّل الافتراضي شبكة 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 يشرح ما هو المحوّل الافتراضي فعليًا، ويستحق القراءة قبل إنشاء شبكة NAT ثانية تتعارض معه.