vpnc أمام Check Point أو Nortel: لماذا يتوقف عن الاستجابة

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

حدِّد المنتج قبل تعديل أي حقل آخر في الملف الشخصي.

الفشل يبدو كبيانات اعتماد خاطئة

يبدأ vpnc بإرسال IKE إلى UDP 500، وإذا كان اجتياز NAT معروضًا، إلى UDP 4500. البوابة التي تنهي SSL بدلًا من IPsec لا تجيب على أي منهما، فيعيد العميل المحاولة ثم يستسلم في النهاية بخطأ عام. إذا كان الحساب نفسه يعمل عبر بوابة ويب تحمّل تطبيقًا مساعدًا صغيرًا، فهذا مؤشر قوي على أن النفق قائم على SSL وأن العميل يسأل السؤال الخطأ.

المحاولة الفاشلة هنا لا تقول شيئًا عن حساب المستخدم، لأن أيا من بيانات الاعتماد لم يُعرض على البوابة.

تحقّق من البروتوكول الذي تقدّمه البوابة

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

nc -zvu gw.example.com 500
nc -zvu gw.example.com 4500
nc -zvt gw.example.com 443
curl -sI https://gw.example.com/ | head -5
openssl s_client -connect gw.example.com:443 -servername gw.example.com </dev/null | head -20

منفذ 443 مفتوح مع إعادة توجيه إلى صفحة تسجيل دخول وصمت على 500 و4500 يشير إلى SSL VPN. انفتاح 500 و4500 مع شهادة تُقدَّم على 443 يوحي ببوابة IPsec تشغّل أيضًا واجهة ويب، وهي الحالة التي بُني vpnc من أجلها.

إن SSL Network Extender من Check Point وعميل Aventail من Nortel يقعان كلاهما في الفئة الثانية، ولا يقبل أي منهما سرًا جماعيًا لـ IKEv1.

ما يمكن لملف vpnc الشخصي التعبير عنه وما لا يمكن

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

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

اختيار العميل المطابق للبوابة

بالنسبة لبوابة Check Point، استخدم حزمة SNX المبنية لإصدار تلك البوابة، والتي ينشرها المورد إلى جانب وثائق الوصول عن بُعد. تفشل إصدارات SNX الأقدم كثيرًا على التوزيعات الحالية لأنها تتوقع مكتبات 32-bit لم تعد مثبتة، وترقيع حزمة مهجورة أسوأ عادة من تشغيل العميل المدعوم على منصة مدعومة.

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

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