عميل OpenVPN يتوقف عندما يعمل خادمه على المضيف نفسه

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

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

اقرأ العَرَض إلى الوراء

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

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

مقبس واحد وجهاز واحد لكل نسخة

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

lport 1195
nobind
dev tun1

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

nobind ينتمي إلى جانب العميل. يجب على الخادم أن يربط ويستمع مع ذلك، فلا تنسخ السطر إلى إعداد الخادم، ولا تعطّل الربط على عميل يصفّي طرفه النظير على منفذ مصدر ثابت.

اختر مالكًا واحدًا للمسار الافتراضي

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

ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2

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

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

تحقق بالجدول، لا بسطر الحالة

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

ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194

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

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