ضيف VMware الموصل بجسر فقد شبكته بعد OpenVPN

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

الضيف لم يتغيّر، الجسر هو الذي تغيّر

تثبيت عميل OpenVPN على Windows يضيف محوّل شبكة افتراضيًا ترتبط به الخدمة عند ارتفاع نفق. بالنسبة لنظام التشغيل يبدو واجهة عادية لها حالة ارتباط، وغالبًا عناوين خاصة بها. هذا يكفي كي يعامله VMware كمرشح للجسر.

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

ثبّت الجسر أو وجّه الضيف

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

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

للفرع الأول، افتح محرّر الشبكة الافتراضية على المضيف، واختر VMnet0، واستبدل التلقائي بالمحوّل الفيزيائي. إذا وُجدت عدة محوّلات، استخدم قائمة الإعدادات التلقائية وأزل علامة كل ما يجب ألا يحمل حركة الضيف أبدًا: جهاز OpenVPN TAP أو Wintun، إضافة إلى محوّلات Hyper-V وWSL وDocker وloopback. أبقِ محوّلَي الشبكة الفيزيائيين، السلكي واللاسلكي، محدَّدين على الحاسوب المحمول، وإلا فقد الضيف جسره في المرة التالية التي يوصله فيها المستخدم بالقاعدة.

ثلاثة شروط تحسم الاختيار

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

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

لا يملك VMware Player محرّر شبكة في واجهته، لذا يحتاج المضيف الذي يشغّل Player وحده إلى المحرّر المستقل أو تثبيت Workstation للوصول إلى هذه الإعدادات. هذا القيد يحسم الأسلوب أحيانًا من تلقاء نفسه.

اقرأ النتيجة من داخل الضيف

أعد تشغيل بطاقة الشبكة الافتراضية، أو أعد تشغيل الضيف، ليطلب عقدًا جديدًا. ثم اقرأ ما تلقّاه فعلًا، لا ما يعتقد المضيف أنه ضبطه.

ipconfig /all
ip addr
ip route

اقرأ حقلين في ذلك الخرج وتجاهل الباقي في الوقت الحالي. ينبغي أن تكون البوابة موجّه الشبكة المحلية، وينبغي أن يذكر وصف المحوّل جهاز Ethernet من VMware لا نفقًا. وعنوان مُسنَد تلقائيًا في 169.254.0.0/16 يعني أنه لم يجب أي خادم DHCP، وهكذا يبدو جسر على محوّل نفق من جهة الضيف.

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