لماذا تفوت عملاء OpenVPN محدِّدات IPsec الخاصة بالبوابة

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

اختبار Ping من البوابة يفحص مسارًا لا يستخدمه عميلك أبدًا

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

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

ادفع البادئة البعيدة التي يحتاجها التطبيق فعلاً

خذ الزوج التوضيحي للعملاء المتصلين 10.8.0.0/24 وللشبكة البعيدة المحمية 172.30.239.0/25. ما يحتاجه العميل هو مسار إلى تلك البادئة الثانية، لا إلى شبكة البوابة المحلية ولا إلى عنوان نفق آخر. والمسار المدفوع إلى المجموعة هو ما يجعل العميل يسلم تلك الحركة إلى البوابة أصلاً. وبدونه لا تصل الحزمة أبدًا إلى قرار السياسة الذي تُشخِّصه.

في خادم Community الذي يقبل المسارات المدفوعة، تأخذ التوجيهات القناع الحقيقي: push "route 172.30.239.0 255.255.255.128". ويضبط Access Server الوجهة نفسها عبر إعدادات الشبكة الخاصة أو قواعد الوصول في النسخة المثبتة، مع اختيار الوضع الموجَّه أو المترجَم بوعي. وتحرير سلاسل جدار الحماية المولّدة بدلًا من الإعداد المالك هو الطريق إلى إعداد عامل يصبح من المستحيل إعادة إنتاجه.

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

اجعل المحدِّدات تشمل مجموعة العملاء

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

افحص السياسة المتفاوض عليها إضافة إلى المقترحات المضبوطة، مثلًا بالأمر ipsec statusall على strongSwan أو أمر الحالة المكافئ في تطبيقك. في IPsec القائم على السياسات قد يشير المسار العادي إلى واجهة فعلية بينما تظل الحركة المطابقة مشفَّرة، لذا لا يثبت غياب جهاز النفق شيئًا. قارن أزواج المحدِّدات بالمجموعة والبادئة التي دوَّنتها.

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

اختر التوجيه أو الترجمة عن قصد

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

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

أغلق الحلقة على التمرير والرد

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

تحقَّق بطلب حقيقي واحد من عميل إلى تطبيق، وراقبه يعبر واجهة OpenVPN وقرار IPsec والمضيف البعيد. افحص الرد كملاحظة منفصلة، لأن طلبًا يصل وردًّا لا يعود أبدًا يبدوان متطابقين من مقعد العميل. وطلب واحد متتبَّع أغلى من أي عدد من اختبارات ping من البوابة.

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