رفض الاتصال ليس مشكلة في الشهادة: دليل تشغيل لشبكة VPN

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

فحصان يفصلان الحالتين في أقل من دقيقة، وليس أي منهما يمس إعدادات الثقة.

اقرأ الخطأ في الطبقة التي أنتجته

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

والعكس صحيح أيضًا. فالشهادة المُبطلة تُنتج اتصال TCP مكتملًا ثم مصافحة فاشلة، تُسجَّل على الخادم كخطأ تحقق.

رفض TCP: لا أحد يستمع

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

افحص عائلة العناوين أيضًا. فالخدمة المرتبطة بـ 127.0.0.1 أو بـ IPv6 فقط سترفض عميلًا يُحلّ إلى العنوان الآخر.

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

لا توجد في UDP مصافحة ليرفضها

OpenVPN عبر UDP لا ينشئ اتصالًا بمعنى TCP، لذا لا يوجد شيء يمكن رفضه عند connect. وعلى Linux، قد يأتي الخطأ الذي يُظهره مقبس UDP من ICMP port-unreachable ناتج عن مخطط بيانات سابق. وتوضح صفحة دليل udp(7) هذا السلوك اللامتزامن.

ولهذا يمكن لعميل UDP أن يطبع رفضًا بينما عملية الخادم تعمل لكنها غير مرتبطة بالعنوان المتوقع.

أين يُفحص CRL في الواقع

يُستشار CRL أثناء مصافحة TLS، بعد أن يقدّم الطرف الآخر شهادته، وفقط إذا مكّن إعداد الخادم ذلك. وخيار OpenVPN ‏crl-verify يشير إلى الملف، ويظهر الفشل في سجل الخادم كخطأ تحقق يسمّي الشهادة.

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

افحص جهة إصدار CRL وتواريخ صلاحيته عندما تصل إلى تلك المرحلة. فـ CRL موقّع من CA خاطئ، أو انتهت صلاحيته قبل اتصال العميل، يُنتج أخطاء تحقق لا علاقة لها بشهادة العميل نفسها.

دليل تشغيل قصير للمرة القادمة

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

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