VPN قيد التشغيل والجهاز الافتراضي غير قابل للوصول؟ المسار على الأرجح لم يكن المشكلة

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

شبكة host-only شبكة برمجية يملكها المضيف ويتقاسمها مع أضيافه، منفصلة عن أي ارتباط فعلي. لا شيء في واجهة عميل VPN نفسها يغيّر تلك الشبكة، لذا قبل أن تمسّها، اكتشف أي الطبقات الأربع فشل فعلًا.

المسار عادةً يبقى محليًا

اسأل النواة بدلًا من الصفحة الأولى لجدول التوجيه. على Linux، يوضح ip route get 192.168.56.10 المسار والواجهة وعنوان المصدر الذين سيُستخدمون بالضبط، وهي إجابة مختلفة عن قراءة مسار افتراضي وتخمينه. إذا سمّى الناتج واجهة host-only، فالنفق غير معني بهذا المسار إطلاقًا.

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

اختيار المسار وقبول الحزم قراران مختلفان

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

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

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

الضيف لديه ثلاث طرق ليقول لا

ضيف يمكنه تصفح الإنترنت لم يثبت شيئًا عن الخدمة التي تريدها. قد يكون المستمع مرتبطًا بـ 127.0.0.1 داخل الضيف، وفي هذه الحالة لا يمكن لأي طلب من المضيف أن يصل مهما كان المسار جيدًا. تحقق بـ ss -ltn في الضيف وانظر إلى عمود العنوان المحلي بدلًا من المنفذ فقط.

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

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

ما الجسر حقًا، وما تكلفته

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

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

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

إن قسم شبكة host-only في VirtualBox يصف واجهة البرمجيات على جانب المضيف وكيف تختلف عن ارتباط الجسر، وهو المرجع الجدير بالقراءة قبل افتراض أن الوضعين قابلان للتبادل.