نفس الشبكة الفرعية على الطرفين: تعيين شبكة LAN البعيدة إلى نطاق حر

المنزل والمكتب كلاهما يستخدم 192.168.1.0/24، لذا فإن طلبًا إلى 192.168.1.1 له إجابتان محتملتان ويختار العميل واحدة دون أن يسأل. إعادة ترقيم شبكة مكتب عاملة نادرًا ما تكون محبوبة، وعناوين الموجه غالبًا ما تكون مثبتة في الطابعات والكاميرات والوثائق. يمكن لتعيين العناوين من جهة العميل أن يعرض الشبكة البعيدة تحت نطاق حر بدلًا من ذلك، ويمكن أن يبقى جزء المضيف متطابقًا بحيث يظهر 192.168.1.20 كعنوان 10.203.41.20. المشكلة أن بعض العملاء فقط ينفذونه، وأنه لا يفعل شيئًا لمسار العودة.

وجهان للمضيف نفسه

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

تحتفظ الأجهزة المحلية في المنزل بعناوين 192.168.1.x الخاصة بها، وهذا هو جوهر التمرين. تبقى الطابعة في الغرفة المجاورة قابلة للوصول بينما يظهر المكتب تحت نطاق لا يتعارض.

ترتيب الوسائط هو الحيلة كلها

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

push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"

المسار هو ما يرسل حزم العميل للنطاق الجديد إلى النفق؛ ويعيد التعيين كتابة الوجهة أثناء المرور. تُعاد كتابة الرد من 192.168.1.20 إلى 10.203.41.20 بحيث يبقى المقبس على العميل متسقًا. يعمل المضيف الواحد بالطريقة نفسها بقناع كامل الطول، ما دام المسار والتعيين يصفان العنوان نفسه.

هذا تعيين عناوين، لا تعيين منافذ. لا يمكن فصل خدمتين على مضيف واحد به، والبروتوكول الذي يضمّن عناوين IP داخل حمولته سيرى العناوين الحقيقية مع ذلك.

التعيين لا ينشئ مسار عودة

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

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

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

الأسماء والحمولات تنجو من الترجمة

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

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

ثلاثة فحوص قبل الالتزام

أولًا، تأكد من تنفيذ العميل. يدعم Community OpenVPN هذا الخيار؛ وتدرجه قاعدة شيفرة OpenVPN 3 بين الميزات غير المدعومة، لذا قد يتجاهله ملف تعريف يُدفع إلى عميل من نوع Connect ببساطة. والتوجيه الذي يُقبل ولا يُطبق أبدًا أسوأ من خطأ، لأن النفق يبدو سليمًا.

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

إذا لم يستطع العميل إجراء الترجمة، فاطلب المساعدة من جهة البوابة أو اقبل إعادة الترقيم. إضافة المزيد من المسارات للعنوان نفسه ليست تصميمًا.