مستمع OpenVPN 2.5 على DD-WRT ميت؟ اقرأ الإعداد الذي ولّده

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

الخدمة ليست الجدار الناري

التمييز مهم لأن الفشلين يبدوان متطابقين من الخارج: يرسل العميل مصافحة ولا يتلقى ردًا. أحدهما عملية لا تعمل، والآخر عملية تعمل وتُرشّح.

افصل بينهما بفحصين قبل أن تغيّر أي شيء، لأن تعديل جدار ناري على خدمة ميتة يضيف متغيرًا ثانيًا فقط.

اقرأ الإعداد الذي ولّده DD-WRT

لا يمنح DD-WRT برنامج OpenVPN النص الذي كتبته في واجهة الويب. بل يكتب إعدادًا مولّدًا في /tmp/openvpn/openvpn.conf ويشغّل الخدمة على ذلك الملف، فتُدمج حقول الواجهة وأي نص في Additional Config قبل أن تراها OpenVPN. إذا شخّصت النموذج بدلًا من الملف المولّد فأنت تقرأ نيّة لا المدخلات الفعلية. انسخ ذلك الملف إلى مكان دائم قبل أن يمحو إعادة التشغيل محتويات /tmp.

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

إذا كان الملف المولّد فارغًا أو مفقودًا، فالخدمة لم تصل إلى مرحلة البدء أصلًا، والمشكلة تقع قبل OpenVPN.

ما الذي توقف OpenVPN 2.5 عن قبوله

استبدل OpenVPN 2.5 ncp-ciphers بـ data-ciphers، ورفع الحد الأدنى الافتراضي لإصدار TLS إلى 1.2. كما غيّر التعامل مع الضغط بحيث يُرفض الطرف الذي يعرض الضغط ما لم يسمح الإعداد بذلك صراحةً، وأهمل أسماء خيارات أقدم مثل ns-cert-type لصالح remote-cert-tls. كل تغيير من تلك يحوّل إعدادًا كان يعمل سابقًا إلى فشل تحليل أو تفاوض.

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

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

المتطلبات الخاصة بشرائح Broadcom

في إصدارات Broadcom يجب أن يوجد جهاز النفق قبل أن تستخدمه الخدمة. تحقق من أن وحدة tun محمّلة وأن /dev/net/tun موجود، لأن جهازًا مفقودًا ينتج فشل بدء لا علاقة له بالشهادات. الأمر نفسه ينطبق على السكربتات المساعدة التي يولّدها DD-WRT للمسارات وDNS: إن كانت مفقودة أو غير قابلة للتنفيذ، فقد تبدأ الخدمة وتفشل مع ذلك في إكمال إعدادها.

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

ثم أعد الخدمة الطبيعية، لأن خدمة في المقدمة وسكربت التهيئة سيتنازعان على المنفذ.

أثبت وجود المستمع قبل أن تشخّص العملاء

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

لا يصبح تشخيص جهة العميل منطقيًا إلا بعد وجود المستمع. حينها تحقق من أن إعدادات التشفير وTLS لدى العميل تطابق قائمة data-ciphers والحد الأدنى للإصدار لدى الخادم، وأن المنفذ مُمرَّر فعلًا إلى الراوتر.

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