ike-scan لا يتلقى أي رد من بوابة IPsec عاملة

تخدم البوابة الهواتف والحواسيب المحمولة كل يوم، ومع ذلك يعلن ike-scan أن لا مضيف قد رد. تبدو هذه المخرجات كدليل على أن IPsec غائب عن الجهاز. عادةً يعني ذلك أن الجهاز رفض كل مقترح في الفحص واختار ألا يجيب بشيء. الصمت رد، وهو أقل رد مفيد يمكن أن تقدمه الأداة.

اعمل على ثلاثة أسئلة منفصلة: هل وصلت الحزمة، وهل طابق أي مقترح، وهل رفض شيء آخر النظير؟

الخطوة 1: اقرأ المقترح الذي ترسله الأداة

يبدأ النمط الرئيسي بحمولة SA تسرد التحويلات التي سيقبلها المبادر، ويملأ ike-scan تلك القائمة من إعداد افتراضي مُصرَّف. المجموعة الافتراضية قديمة عمدًا: DES و3DES للتشفير، وMD5 وSHA1 للتجزئة، ومجموعتا 1 و2 لتبادل المفاتيح، ومفاتيح مشتركة مسبقًا للمصادقة. لا AES، ولا SHA-2، ولا المجموعة 14. البوابة المهيأة لـAES-256 مع SHA-256 وmodp2048 لا تشترك معه في شيء.

بعض التطبيقات تجيب عن فحص غير مطابق بـ إشعار NO-PROPOSAL-CHOSEN. أما غيرها فيسقطه ببساطة، وهو شائع في الأجهزة التي تعد النظائر المجهولة ضجيجًا. وعلى أي حال لا يطبع الفحص شيئًا، وذلك لا شيء مطابق تمامًا لما يبدو عليه UDP 500 المرشَّح من الخارج، كما أن توثيق مشروع ike-scan يوضح ذلك بشأن المجموعة الافتراضية.

الخطوة 2: اعرض مقترحًا حديثًا واحدًا

استبدل المجموعة الافتراضية بـ--trans. تأخذ صيغة السمات أرقام سمات IKE مباشرة: 1 للتشفير، 2 للتجزئة، 3 للمصادقة، 4 للمجموعة، و14 لطول المفتاح عندما تقبل الخوارزمية طولًا. ما يخرج سطر يمكنك قراءته بصوت عالٍ في مراجعة تغيير.

تحمل الصيغة الموضعية القيم نفسها بالترتيب وتتجنب الأقواس، وهذا يهم عندما يمر الأمر عبر صدفة.

ike-scan --trans="(1=7,14=256,2=5,3=1,4=14)" 203.0.113.10

مقترح واحد لكل حزمة بطيء عند التعداد، لذا كرر على القيم المعقولة: التشفير 5، و7/128، و7/192، و7/256؛ والتجزئة 1، و2، و5، و6، و7؛ والمجموعات 1، و2، و5، و14، و15، و19، و20، و21؛ والمصادقة 1 لمفتاح مشترك مسبقًا و3 لتواقيع RSA. اطبع كل أمر قبل تشغيله ليُظهر السجل ما عُرض وبأي ترتيب.

الخطوة 3: فسّر الرد

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

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

الخطوة 4: فسّر الصمت

الصمت دليل أضعف مما يبدو. ربما رُفض كل مقترح، وربما رُشّح UDP 500 و4500، وربما خُدّ المصدر بمعدل بعد دفعة، أو ربما تستمع الخدمة على عنوان مختلف عن الذي فحصته. قارن سجل IKE للبوابة بعميل يتصل أصلًا ببيانات اعتماد صحيحة قبل أن تستنتج شيئًا عن الصندوق.

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

الخطوة 5: سجّل ما أثبتته

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

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