ستاسو اپلیکیشن په خپل کمپیوټر کې یو پروکسي ته نښلول کیږي. بیا هغه مرستندوی د شرکت پروکسي ته تصدیق کوي. اړینه نه ده چې اپلیکیشن پخپله د شرکت د تصدیق تبادله ترسره کړي.

application → local helper → company proxy → destination

د CNTLM په څیر مرستندوی د پورته لوري حساب او پروکسي ترتیبات لري. د هغې ځایي اوریدونکی جلا رسیدنه او د لاسرسي پوله لري. په براوزر کې بل پای ټکي ته ورکړل شوې پټنوم د دواړو له جملي هیڅ یو په اتوماتيک ډول نه تنظیموي.

هغه پړاو وپیژنئ چې ناکام شو

لومړی ډاډ ترلاسه کړئ چې اپلیکیشن د مرستندوی ریښتینی اوریدونکی او پروتوکول غوره کړی. هغه اوریدونکي ته د رسیدو دمخه تېروتنه د NTLM نیمګړتیا نه ده. بیا وګورئ چې مرستندوی خپل تنظیم شوي والد ته ورسید او والد د هغې هویتوب ومنه.

په دې لار راغلی 407 اړتیا لري چې نسبت ورته وشي. د دې پرځای چې فرض کړئ ښکاره حالت هغه حساب ښیي چې ستاسو اپلیکیشن باید ولېږي، ځایي معامله د مرستندوی له ایډیټ شوې تشخیص سره وتړئ.

زوړ مثالونه کله ناکله keep-alive سرلیک ورزیاتوي او بریا اعلانوي. دوام ممکن د اړیکې پر بنسټ تصدیق کې مهم وي، مګر هغه کتنه ثابتوي نه چې هر ناکام مرستندوی ترتیب هماغه سرلیک ته اړتیا لري. د پای ټکي ټاکنه، ملاتړ شوې طریقه، حساب او د اړیکې عمر بیا هم جلا تولیدات دي.

اوریدونکی ریښتینې خدمت دی

Loopback اوریدونکی له شاوخوا شبکې څخه لیرې ساتي؛ خو په هغه کمپیوټر کې ټول پروسسونه یا کاروونکي نه جلا کوي. یو ګیټوی یا پراخه تړل د زنګ وهونکو هغه ټولګه بدلوي چې کولای شي د مرستندوی د پورته لوري هویتوب وکاروي. هغه بدلون په قصد سره وکړئ.

کله چې اپلیکیشن اړین سکیم نه شي کولای، تصویب شوې مرستندوی ترتیبه وکاروئ. ګټور نتیجه یوه پیژندل شوې لار ده چې پیژندل شوې حساب ملکیت لري، نه یو ناڅرګند اضافي خدمت چې یو ډاونلوډ په ناڅاپي ډول کار کوي.

اړوندې مقالې