كيف تصل إلى خدمة خاصة عبر VPN في جهاز ظاهري

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

سجّل المسارين قبل تغيير أي شيء

على الضيف، يعرض ipconfig /all المحوّل الذي يحمل نقل VPN والعنوان الذي حصل عليه من DHCP الشبكة الافتراضية۔ وعلى جهاز Mac، سجّل الواجهة الافتراضية التي أنشأها برنامج المحاكاة لذلك القطاع؛ فمع VMware Fusion يكون الجهاز المخصّص للمضيف عادةً vmnet1، بينما يسمّي Parallels جهازه باسم خاص به۔ لاحظ من يوزّع العناوين هناك، ثم اكتب كل ذلك، لأن الشبكة الفرعية المخصّصة للمضيف يُعاد تعيينها كثيراً عند إعادة إنشاء شبكة افتراضية۔ تحقّق من وضع الشبكة في الجهاز الظاهري من داخل برنامج المحاكاة لا من ذاكرتك عنه۔ الوضع المشترك أو وضع NAT للمحوّل المواجه للإنترنت، مع وضع مخصّص للمضيف للمحوّل المواجه لجهاز Mac، هو الترتيب الذي تفترضه هذه الخطوات۔

محوّلان لغرضين مختلفين۔ خلطهما بحيث يخدم واحد منهما جهاز Mac والإنترنت معاً هو ما يحوّل باباً ضيقاً إلى مسار موجّه۔

تأكّد أولاً من VPN الخاص بالضيف

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

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

أضف مسار المضيف واختبره وحده

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

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

أعد توجيه منفذ واحد، لا الشبكة الفرعية

فضّل منفذاً واحداً معاد توجيهه على إعادة توجيه IP العام۔ يوفّر Windows الأمر netsh interface portproxy، الذي يعيد توجيه منفذ استماع إلى مضيف وجهة ومنفذ، ويحتاج إلى تشغيل خدمة IP Helper۔

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

تحقّق، ثم اكتب خطة التراجع

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

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