نفقان من OpenVPN على مضيف Linux واحد: من يملك المسار؟

ملفا تعريف متصلان، وأحدهما يحمل بهدوء حركة مرور مقصودة للآخر. يستطيع مضيف Linux تشغيل عميلَي OpenVPN في آن واحد دون صعوبة. ما لا يستطيع فعله هو أن يقرر نيابة عنك أي عملية يحق لها المطالبة بأي بادئة. هذا القرار يجب أن يُتخذ قبل ظهور النفق الثاني، لا بعد أن يتوقف مورد عن الاستجابة.

ابدأ من المهمة التي يجب أن يؤديها الرابط الثاني

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

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

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

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

تجمعات العناوين المتداخلة تتعطل قبل أن يتعطل التوجيه

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

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

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

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

أعطِ كل ملف تعريف وحدته وكل بادئة مالكها

يحصل كل ملف تعريف على اسم نسخة خاص به وملف إعداد خاص به، فنسخة تُسمى office تحمّل office.conf بينما تحمّل نسخة تُسمى lab الملف lab.conf. أكّد هذا الربط عبر مدير الخدمات بدلاً من الوثوق بقائمة مجلد، لأن ملف drop-in يمكن أن يغيّر الملف المحمّل. الخطأ في الربط يعني أنك تضبط الملف الذي لا يعمل.

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

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

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

العلامات تبقي الردود على الواجهة التي وصلت منها

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

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

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

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

أثبت العزل بإيقاف رابط واحد

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

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

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