بوابتان وشبكة VPN واحدة: لماذا يختار OpenVPN المسار الصاعد الخاطئ

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

عنوان النفق ليس نقطة النهاية

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

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

اعثر على العنوان الذي اتصل به العميل فعلاً

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

ss -tunp | grep -i openvpn
journalctl -u openvpn-client@work --no-pager | grep -i "Peer Connection Initiated"

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

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

ثبّت نقطة النهاية واقرأ ترتيب السياسة

مسار المضيف أكثر تحديداً من أي مسار افتراضي. لذلك يفوز مسار /32 لعنوان النظير داخل الجدول الذي يحتويه. الصيغة المعتادة تسمي البوابة والجهاز صراحةً:

ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0

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

ip rule show
ip route get 203.0.113.40

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

عندما تتحرك نقطة النهاية

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

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

أبقِ السياسة الداخلية منفصلة

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

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

أكّد النتيجة بملاحظتين مستقلتين: العنوان المحلي والجهاز للمقبس، والمسار الذي تُحل إليه الوجهة الخاصة. عندما يتطابق كلاهما مع نيتك، يكون التقسيم حقيقياً. يغطي دليل OpenVPN 2.6 خيارات الربط remote والمحلي التي تقرر أي عنوان يتصل به العميل.