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

application → local helper → company proxy → destination

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

حدِّد القفزة التي أخفقت

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

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

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

المستمع خدمة حقيقية

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

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

مقالات ذات صلة