منفذ VPN صامت؟ المستمع أو عنوان الربط أو جدار حماية المضيف

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

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

هل المقبس موجود أصلًا

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

systemctl status openvpn-server@server --no-pager
journalctl -u openvpn-server@server -n 30 --no-pager
ss -lunp

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

على أي عنوان وأي عائلة عناوين يستجيب المقبس

خطأان يبدوان متطابقين من جهة العميل ويفسّران معظم تقارير "تعذّر الوصول". الخادم المرتبط بعنوان الاسترجاع الربطي لا يقبل أبدًا حركة من جهاز آخر، والخادم المرتبط بعنوان IPv4 فقط لا يجيب أبدًا عميلًا يتصل بعنوان IPv6 لنفس المضيف. قارن العنوان في جدول المقابس بالعنوان الذي يتصل به العميل فعلًا، حرفًا بحرف، قبل أن تفترض أي شيء عن السياسة.

حصر القائمة في منفذ واحد يبقيها مقروءة حين يشغّل المضيف خدمات عدة. مرشّح المنفذ المصدر يأخذ المنفذ مع النقل الذي تختبره:

ss -lun 'sport = :51820'
ss -ltnp 'sport = :1194'

عمود البروتوكول يغيّر الجواب كله

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

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

محاولة واحدة وثلاثة مواضع للنظر

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

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

سمِّ المرحلة قبل أن تغيّر قاعدة

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

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