pfSense OpenVPN: الوصول إلى شبكة خلف موجه آخر

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

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

حزمة واحدة، وثلاثة قرارات توجيه

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

فشل أي قرار واحد منها ينتج التقرير نفسه من المستخدم. ولهذا فإن ترتيب التنقيح يهم أكثر من الأدوات.

أعطِ العميل بادئة، لا تخمينًا

على خادم pfSense SSL/TLS بشبكة نفق IPv4 أكبر من /30، يوزّع حقل «IPv4 Local network(s)» المسارات على العملاء عند اتصالهم. أضف بادئة الجهة الأدنى هناك بدلًا من الاعتماد على العميل لاختراع واحدة. ثم اقرأ جدول العميل الفعلي بعد الاتصال، لأن ملف تعريف يحتوي على route-nopull أو مرشح مسارات يمكن أن يتجاهل ما أرسله الخادم. فقد يكون الخادم صحيحًا تمامًا بينما لا يثبّت العميل شيئًا.

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

وجّه pfSense إلى الموجه الداخلي

يحتاج المسار الثابت في pfSense إلى بوابة معرّفة وقابلة للوصول، ويجب أن تكون الواجهة المختارة لتلك البوابة هي الواجهة التي تصل إليها فعلًا، كما يوضح دليل Netgate للمسارات الثابتة. في تخطيط توضيحي يكون رابط العبور 192.168.77.1 على الجدار الناري و 192.168.77.2 على الموجه الداخلي، مع شبكة الخدمة عند 172.16.30.0/25 خلفه. ثم يسمّي المسار البادئة والقفزة التالية، لا عنوان الخدمة. واستخدام عنوان من الشبكة البعيدة كبوابة طريقة شائعة لبناء مسار يبدو صحيحًا ولا يمرّر شيئًا.

إعطاء الواجهة اسمًا لا يصف الشبكات التي تقع خلفها. المسار الثابت هو ذلك الوصف.

يجب أن تعرف الجهة البعيدة التجمع

يحتاج الموجه الأدنى إلى مسار عودة للتجمع، في هذا المثال 10.55.0.0/24 عبر 192.168.77.1، ما لم يكن مسار افتراضي أو بروتوكول ديناميكي يوفر واحدًا بالفعل. ويجب أن تؤدي بوابة مضيف الخدمة نفسه نحو ذلك الموجه، وهذا صحيح عادةً عندما يكون الموجه بوابتها الافتراضية، وغير صحيح عندما يكون المضيف قد ضُبط يدويًا. ويمكن لتوجيه السياسات على الجدار الناري أن يتجاوز الجدول لحركة مرور محددة، لذا تحقّق مما إذا كانت قاعدة تختار بوابة مختلفة قبل أن تستنتج أن المسار خاطئ.

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

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

احفظ خطة الجهات الثلاث المالكة إلى جانب التطبيق المسموح، حتى يتمكن المسؤول التالي من إعادة بناء المسار بدلًا من اكتشافه من جديد.