خطأ واحد وثلاثة أسرار: أي بيانات اعتماد VPN فشلت؟
يعرض العميل خطأ واحدًا لكل مرحلة. اقرأ الرابطة وتبادل المستخدم والطريقة قبل إعادة تعيين كلمة مرور لم يتحقق منها أحد.
قد يشير «فشل المصادقة» إلى شهادة خادم أو مفتاح مشترك مسبقًا للجهاز أو كلمة مرور مستخدم. أيّها المقصود يعتمد على البروتوكول، لأن كل بروتوكول يعرّف مجموعة مختلفة من الأسرار. أعد تعيين غير المقصود وستبقى المشكلة كما هي. المخرج هو تحديد عدد الأدلة التي يتطلبها البروتوكول قبل تعديل أي شيء.
دليلان يشيران في اتجاهين متعاكسين
على النفق أن يجيب عمّا إذا وصل إلى البوابة الصحيحة، وعن هوية المستخدم بشكل منفصل. دليل البوابة على مستوى الجهاز: شهادة خادم أو مفتاح مشترك مسبقًا أو مفتاح عام ثابت. دليل المستخدم على مستوى الشخص: كلمة مرور أو رمز أو شهادة عميل أو لا شيء على الإطلاق. وهذان اتجاهان متعاكسان للثقة ويستهلكان مادة مختلفة.
ينفّذ IKEv2 دليل البوابة داخل IKE_AUTH، وعند استخدام EAP ينفّذ دليل المستخدم في تبادل منفصل بعده. وتحتفظ مواصفة IKEv2 بهذين قسمين منفصلين، وهذا تلميح قوي إلى مكان البحث عندما تغطي رسالة واحدة الجولتين.
اقرأ المرحلة، لا الرسالة
يعرض العميل سلسلة خطأ واحدة أيًّا كانت المرحلة التي فشلت، لذا لا تحمل السلسلة نفسها تقريبًا أي معلومات. الذي يحمل معلومات هو الحالة التي يمكنك فحصها في كل مرحلة: هل توجد رابطة، وهل بدأ تبادل للمستخدم، وهل عرض العميل الطريقة التي أرادتها البوابة. يرتب الجدول المراحل بهذه الطريقة بدلًا من اسم البروتوكول.
| Stage that failed | Evidence you can inspect | What a password change cannot fix |
|---|---|---|
| The machine proof | no security association in the state list | a mismatched pre-shared key or an untrusted chain |
| The user proof | an association is up while PPP or EAP reports failure | an expired token, a locked account, a missing client key |
| The client's method support | the client offers no method the gateway accepts | a client without the required EAP or key material |
| The server's policy | the gateway rejects before any user exchange starts | a policy that requires a certificate the profile lacks |
الصف الثاني وحده يتعلق ببيانات اعتماد يمكن للمستخدم إعادة كتابتها. أما الثلاثة الأخرى فهي حقائق تهيئة، وهذا التناقض هو سبب انتهاء كثير من هذه التقارير بإعادة تعيين كلمة مرور لا تغيّر شيئًا. اقرأ الصف الذي يطابق دليلك قبل لمس أي حقل.
بروتوكول بسرّين يكشف أوراقه
L2TP عبر IPsec يجعل العدد مرئيًا، لأن الفحصين يحدثان في عمليتين مختلفتين. يجب أن تنهض طبقة IPsec أولًا بمفتاح مشترك مسبقًا أو شهادة، وعندها فقط يحاول PPP داخلها تسجيل دخول مستخدم.
عندما يكون سرّ الجهاز خاطئًا لا تتشكل أي رابطة ولا يُجرَّب اعتماد المستخدم أبدًا. وعندما يكون سرّ الجهاز صحيحًا وسرّ المستخدم خاطئًا تكون الرابطة موجودة ويرفض PPP تسجيل الدخول بعد أن يكون النفق قد قام بالفعل. وكلاهما ينتج الرسالة نفسها على الشاشة من حدثين مختلفين.
sudo swanctl --list-sas
sudo ip xfrm state list
sudo journalctl -u xl2tpd -n 50 --no-pagerقائمة رابطة فارغة تستبعد طبقة المستخدم فورًا، لذا افحصها قبل كلمة المرور. أما رابطة قائمة مع حالات فشل متكررة في PPP فتشير إلى الاتجاه الآخر، إلى طبقة المستخدم أو إلى بروتوكول المصادقة داخلها. ولا أحد من الاستنتاجين متاح من نص خطأ العميل.
على ماذا يعتمد الدخول بكلمة المرور فقط فعليًا
الوصول بكلمة مرور فقط أمر عادي في L2TP وPPTP وSSTP وIKEv2 مع EAP. أما WireGuard فلا يملك هذا الخيار إطلاقًا، لأن أقرانه مفاتيح لا مستخدمون. وفي OpenVPN يأتي الجواب من شرط شهادة العميل على الخادم: البوابة التي تطلب الشهادة وكلمة المرور معًا ستظل ترفض عميلًا بكلمة مرور فقط، مهما كُتب في الحقل.
أي مكوّن تحتاج يتبع من الجواب نفسه. تسجيل الدخول بكلمة مرور في IKEv2 يتطلب عميلًا يتحدث EAP، بينما يحتاج تسجيل الدخول بالشهادة إلى المفتاح الخاص للعميل وسلسلة الخادم. ثبّت المكوّن الخاطئ وسيبدو الفشل كخطأ في بيانات الاعتماد رغم أن طريقة المصادقة نفسها هي المفقودة.
غيّر شيئًا واحدًا ثم أعد الاختبار
حدّد ثلاث حقائق أولًا: أي بروتوكول يعمل، وكم سرًّا يعرّف، وأيها يخص الجهاز لا المستخدم. تفشل الأجهزة في المرحلة الأولى ويفشل الناس في الثانية، والخلط بين الاثنين هو كل هذه المشكلة.
ثم غيّر شيئًا واحدًا بالضبط وأعد الاختبار من العميل نفسه. يحوّل هذا الانضباط فشلًا محيّرًا إلى إصلاح يمكنك وصفه للشخص التالي، وهو أنفع من اتصال يعمل لا يستطيع أحد شرحه.