حلّ المجتمع

لا يوجد اتصال بالإنترنت في الوضع المُجسَّر لـ ZVM: استكشاف أخطاء Windows 11 وإصلاحها

A Windows 11 VM had internet in NAT but not Bridged mode; one user fixed it by disabling proxy auto-detection, while a later similar case did not.

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

يتضمن موضوع المصدر تحذيرًا مهمًا من التعميم المفرط: فقد أصلح أحد المستخدمين المشكلة بتعطيل خيار Windows «اكتشاف الإعدادات تلقائيًا» ضمن الوكيل، لكن مستخدمًا لاحقًا واجه العَرَض العام نفسه ولم يُفِدْه هذا التغيير. تعامل مع تبديل الوكيل على أنه إصلاح خاص بحالة تم التحقق منها، وليس حلًا شاملًا.

ما الذي يغيّره الوضع المُجسَّر؟

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

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

الخطوة 1: تحقّق من إعدادات IP في Windows

داخل Windows، شغّل:

ipconfig /all

ابحث عن عنوان صالح للشبكة المحلية، وقناع الشبكة الفرعية، والبوابة الافتراضية، وخادم DNS. ويعني العنوان المعيّن ذاتيًا 169.254.x.x أن DHCP لم يكتمل.

الخطوة 2: اختبر البوابة قبل اختبار الإنترنت

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

إذا استجابت البوابة، فاختبر بعد ذلك عنوان IP خارجيًا، مثل محلّل DNS معروف لديك. ولا تبدأ استكشاف أخطاء أسماء DNS إلا بعد نجاح اتصال IP الخام.

الخطوة 3: تحقّق من الاكتشاف التلقائي لوكيل Windows

في الحالة الموثّقة في المصدر، فتح المستخدم الإعدادات ← الشبكة والإنترنت ← الوكيل وعطّل الاكتشاف التلقائي للوكيل. وعندها عمل الوصول إلى الإنترنت.

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

الخطوة 4: تحقّق من توصيل الواجهة الفعلية الصحيحة بالجسر

إذا كان مضيف ZimaOS يحتوي على عدة منافذ Ethernet، فتأكد من أن الآلة الافتراضية متصلة بواجهة الشبكة المتجهة إلى الشبكة المحلية التي تتوقعها. تحقّق من أسماء الواجهات الحالية للمضيف، وحالة الاتصال، وعناوين IP ضمن الإعدادات ← الشبكة.

يوثّق دليل شبكات ZimaOS الحالي كيفية عرض ZimaOS لحالة الواجهات الفعلية.

انتبه عند إنشاء جسر عبر Wi-Fi

يتوافق جسر Ethernet التقليدي بسهولة مع بطاقة شبكة سلكية. أما واجهات عملاء Wi-Fi فقد تواجه قيودًا في إنشاء جسر شفاف من الطبقة الثانية، لأن العديد من نقاط الوصول لا تقبل عناوين MAC مصدر عشوائية خلف محطة واحدة.

إذا كان مضيف ZimaOS نفسه يعتمد على Wi-Fi، فاختبر الآلة الافتراضية عبر Ethernet سلكي قبل إضاعة الوقت في إعدادات Windows.

الخطوة 5: افصل بين عنوان IP الثابت وإعادة توجيه المنافذ

لا تحتاج إلى تثبيت عنوان IP يدويًا داخل Windows لمجرد الحفاظ على عنوان ثابت لخادم الألعاب. وقد تكون عملية حجز عنوان عبر DHCP في جهاز التوجيه أسهل في الإدارة وتتجنب التعارضات.

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

تحقّق من جدار حماية Windows وملف تعريف الشبكة

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

يوفّر دليل إعداد ZVM سياقًا أوسع حول الآلات الافتراضية.

متى تُبلّغ عن مشكلة في جسر ZVM؟

إذا حصل الضيف على عنوان DHCP صالح لكنه لا يستطيع اختبار البوابة، وكان وضع NAT يعمل، وتستخدم Ethernet سلكية، ويعمل جهاز فعلي آخر على المبدّل نفسه بشكل طبيعي، فاجمع إصدار ZimaOS، وعنوان MAC وIP للضيف، وواجهة المضيف، واختيار الجسر، والشبكة الفرعية لجهاز التوجيه، ونتائج الاختبار.

تُعد هذه الأدلة أقوى بكثير من قولك: «لا يوجد إنترنت في الوضع المُجسَّر».

الأسئلة الشائعة

هل يؤدي تعطيل الاكتشاف التلقائي لوكيل Windows إلى إصلاح الوضع المُجسَّر في ZVM؟

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

هل يمكن لآلة افتراضية مُجسَّرة امتلاك عنوان IP خاص بها على الشبكة المحلية؟

نعم، فهذا هو الغرض المعتاد من الشبكات المُجسَّرة. ويمكن لحجز عنوان عبر DHCP في جهاز التوجيه إبقاء هذا العنوان ثابتًا.

لماذا يعمل NAT بينما يفشل الوضع المُجسَّر؟

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

هل ينبغي إعادة توجيه المنافذ قبل إصلاح الوصول إلى الإنترنت؟

لا. تأكد أولًا من قدرة الضيف على الوصول إلى بوابته وإلى الإنترنت، ثم اضبط إعادة التوجيه الوارد للخدمة.