لماذا يفشل VPN الضيف خلف VirtualBox NAT؟

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

حدّد عملية VPN قبل لوم الشبكة

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

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

التبادل الخارجي يحدد التوافق

يسرد دليل شبكات VirtualBox قيود NAT ذات الصلة هنا: فهو لا يمرر بروتوكولات غير TCP وUDP، ويُذكر GRE كغير مدعوم، ويُعطى PPTP كمثال متأثر. يستخدم PPTP تبادل تحكم TCP وGRE للبيانات، لذا يمكن أن ينجح اتصال التحكم بينما لا يستطيع مسار البيانات عبور الحد نفسه. هذان دليلان مختلفان، وواحد فقط منهما يتعلق بحمل الحركة. السماح بمنفذ TCP 47 في قاعدة جدار ناري ليس مثل السماح ببروتوكول IP 47، والاثنان يُخلطان باستمرار.

أبقِ القيد مرتبطاً بترتيب NAT هذا، لا بكل جهاز يستخدم كلمة NAT. قد يمرر موجّه فعلي GRE دون اعتراض بينما يُسقطه NAT الافتراضي، ويتخذ مراقب آخر اختياره الخاص فيما يمرره. حيث تقدم المؤسسة نقلًا معتمدًا داخل TCP أو UDP، استخدم عميلها وملفها الشخصي المدعومين لذلك المسار. التوافق شرط واحد بين عدة شروط، وهو لا يثبت ثقة الخادم ولا إذن الحساب ولا مسارات خاصة عاملة.

ما الذي يغيّره الجسر فعلاً

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

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

نفقان، مسارا أدلة

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

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

أي شرط يمنعك في الواقع

الآن يضيق القرار إلى ثلاثة أسئلة بإجابات مختلفة. إذا كان البروتوكول الخارجي خارج TCP وUDP، فقيود وضع NAT هي القيد، والجسر أو نقل معتمد داخل TCP/UDP هو الطريق قدماً. إذا اكتمل التبادل الخارجي ولم يعمل مسار البيانات، فالقيد هو نفسه الذي ظهر في الدليل الثاني. إذا ارتفع النفق ولم تستجب الموارد، فقد تجاوزت المشكلة المراقب إلى التوجيه أو السياسة.

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