لماذا لا يمكن الوصول إلى الشبكة الفرعية خلف عميل OpenVPN؟

تنجح عمليات ping إلى عنوان النفق على الخادم، ويبدو جدول التوجيه على العميل صحيحًا، ومع ذلك تبقى الشبكة المحلية خلف ذلك العميل غير قابلة للوصول. جدول التوجيه على العميل يبدو سليمًا، ولدى الخادم مسار يشير إلى النفق، ومع ذلك تختفي الحزم. هذه هي العَرَض الكلاسيكي لنفق layer-3 لا يعرف أن أحد عملائه هو أيضًا بوابة.

لا تملك واجهة tun أي قفزة تالية لكل عميل. ترى النواة واجهة واحدة لها أقران كثيرون، لذا يجب أن يُتخذ قرار أي عميل يستقبل حزمة موجهة إلى شبكة محلية بعيدة داخل عملية OpenVPN نفسها. يُضبط ذلك القرار بواسطة iroute، وبدونه لا تجد الحزمة طريقًا.

الخادم يوجّه حسب العميل، لا حسب الواجهة

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

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

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

كتابة سطر iroute الذي يسمّي العميل

يسكن iroute في ملف تهيئة خاص بالعميل، لا في تهيئة الخادم الرئيسية. وجّه الخادم إلى مجلد بخيار client-config-dir، ثم أنشئ ملفًا يحمل اسم الاسم الشائع لشهادة العميل وضع فيه البادئة.

لفرع شبكته المحلية 10.20.0.0/24 واسم شهادته الشائع branch-router، يحتوي الملف في ذلك المسار على سطر مثل iroute 10.20.0.0 255.255.255.0. لا تحتاج التهيئة الرئيسية إلا خيار المجلد؛ البادئة تسكن لدى العميل.

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

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

بناء مسار العودة في الاتجاهين

إيصال الحزم إلى الشبكة المحلية البعيدة نصف المهمة. يجب أيضًا أن يرسل العميل حركة تلك الشبكة إلى النفق، ويتم ذلك عادة بدفع مسار إلى العميل: سطر مثل push "route 10.8.0.0 255.255.255.0" يخبر كل عميل كيف يصل إلى شبكة جهة الخادم. أما الفرع فالمسار المكافئ عنده يشير إلى النفق لما ينبغي أن يصل إليه على جهة الخادم.

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

يجب تفعيل التمرير على مضيف الخادم. بدونه تقبل النواة الحزمة من النفق وترفض تمريرها إلى واجهة الشبكة المحلية، وهو ما يبدو مطابقًا لغياب iroute من وجهة نظر العميل.

التحقق من الوصول بالمجسّات الصحيحة

اختبر على طبقات بدل ping الطرف البعيد والتخمين. من الخادم تحقق من وجود الربط الداخلي للبادئة ومن أن مسار النواة يشير إلى النفق. ومن العميل تأكد من تثبيت المسار المدفوع ومن أن مساره الافتراضي لعنوان الشبكة المحلية هو النفق.

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

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