OpenVPN بين iroute ومسار النواة: أيّهما مفقود؟
يوجد على الخادم مسار، ومع ذلك يتوقف المرور. أحد قراري المسار يخصّ نواة النظام، والآخر يخصّ النظير؛ تعلّم أيّهما مفقود وما يجب التحقق منه.
تحتاج حزمة موجّهة إلى 10.77.20.0/24 إلى قرارين منفصلين على خادم OpenVPN: يجب أن يسلّمها نظام التشغيل إلى واجهة VPN، ويجب أن يعرف OpenVPN أي عميل متصل يملك تلك البادئة. مسار النواة المفقود يُسقطها قبل النفق، ومسار النظير المفقود يُسقطها بعده. يبدو الفشلان متطابقين من الشبكة المحلية البعيدة، ويستغرق تشخيص أيّهما لديك أمرًا واحدًا على كل جانب.
في مسار البيانات التقليدي في مساحة المستخدم، يُدخل مسار النواة الحزمة إلى عملية النفق، ويخبر iroute تلك العملية أي نظير يجب أن يستلمها. لا يغني أحدهما عن الآخر، والإعداد الذي يحمل واحدًا منهما فقط سيبدو معقولًا حتى أول اختبار ping.
قراران، لا مسار واحد
تخيّل رابطًا من موقع إلى موقع حيث يقع 10.77.20.0/24 خلف عميل واحد. مسار النواة على الخادم، مثلًا ip route add 10.77.20.0/24 dev tun0، يرسل الحزم المطابقة إلى جهاز النفق. بعد ذلك يراجع OpenVPN جدوله الداخلي الخاص، المبني من مدخلات iroute في دليل إعداد العميل، ليقرر أي اتصال نظير يستقبلها. بدون مسار النواة لا تصل الحزمة إلى العملية أبدًا، وبدون مسار النظير تصل إلى العملية ولا تذهب إلى أي مكان.
من السهل نسيان هذا الانقسام، لأن سطر مسار واحد في ملف تعريف العميل قد يبدو وكأنه يؤدي المهمتين. لكنه لا يفعل: دفع مسار يخبر العملاء بما يجب إرساله عبر النفق، بينما يخبر iroute الخادم بمن يملك نطاق عناوين خلف عميل. فهما يعيشان في ملفات مختلفة، ويقرأهما جانبان مختلفان، ويفشلان في اتجاهين متعاكسين.
أين يقع iroute وماذا يقول
يذهب المدخل في ملف خاص بكل عميل يحمل اسم common_name الخاص بالعميل، ضمن client-config-dir، على هيئة iroute 10.77.20.0/24. مطابقة اسم الملف ليست شكلية: يبحث OpenVPN عن الهوية الموثّقة ويقرأ الملف بهذا الاسم تحديدًا، لذلك لا يسري ملف باسم site-a إلا على عميل اسمه الشائع site-a. أضف ccd-exclusive إذا كان يجب رفض العملاء الذين لا يملكون مثل هذا الملف رفضًا تامًا، وهو الإعداد الصحيح عندما يكون كل عميل بوابة موقع. احتفظ بملف واحد لكل بوابة وسمّه باسم موضوع الشهادة الذي تصدره فعلًا.
اختبر المدخل من الخادم قبل لوم الشبكة المحلية البعيدة. يسرد ملف الحالة العملاء المتصلين بأسمائهم الشائعة، والخادم الذي يعمل عند --verb 4 يسجّل تركيب iroute لحظة اتصال النظير. إذا لم يظهر شيء عند الاتصال، فالملف في الدليل الخطأ أو يشير إلى هوية خطأ.
الفخ: الملف موجود والهوية خطأ
iroute سليم المظهر مرتبط بنظير خطأ يهدر وقتًا أكثر من ملف مفقود، لأن كل شيء على القرص يبدو صحيحًا. إعادة تسمية الشهادات، والأسماء الشائعة المكررة، إضافة إلى username-as-common-name الذي يغيّر الهوية الفعلية، كلها تنتجه. تحقق من الهوية التي صادق عليها الخادم بدلًا من التي توقعتها: مخرجات الحالة هي المرجع، أما اسم الملف فمفتاح بحث فقط.
يمكن أن يعيش المسار أطول من مالكه. المسارات الثابتة ومدخلات iroute تصف بادئة لا ضمان توافر، لذلك يمكن أن يظل المرور يُوجَّه نحو نظير غير متصل حاليًا.
أكمل المسار إلى ما بعد النظير
ملكية النظير هي منتصف المسار، لا نهايته. يجب أن يمرّر العميل الحزم من النفق إلى شبكته المحلية، أي تفعيل تمرير IP على ذلك المضيف وقاعدة جدار حماية تسمح بالعبور. تحتاج المضيفات في الشبكة المحلية البعيدة إلى مسار عودة لعنوان النفق، إما مسار يشير راجعًا إلى البوابة أو تصميم NAT مقصود على جانب العميل. تحقق من إعداد التمرير على العميل عبر sysctl net.ipv4.ip_forward بدلًا من افتراض قيمة افتراضية في التوزيعة.
إذا كان على عملاء VPN آخرين الوصول إلى تلك الشبكة الفرعية، يتوسع الترتيب مرة أخرى: يحتاج الخادم إلى client-to-client، ويحتاج أولئك العملاء إلى توجيه البادئة عبر النفق. لا شيء من ذلك يستلزمه جدول مسارات الخادم نفسه.
تحقق من وجهة واحدة من مصدر حقيقي بدلًا من الخادم نفسه. اختبار ping من مضيف غير ذي صلة في الشبكة المحلية إلى مضيف خلف العميل يمارس مسار العودة وقاعدة التمرير وملكية النظير في خطوة واحدة، بينما مصافحة ناجحة تثبت الهوية فقط. بعد ذلك افصل النظير المالك وسجّل ما يفعله المسار، لأن تلك الإجابة هي نمط فشلك.