ლოკალური NTLM პროქსი დამხმარეები: კლიენტის წვდომა და ზედა დონის ავტორიზაცია

თქვენი აპლიკაცია უკავშირდება პროქსის საკუთარ კომპიუტერზე. შემდეგ ეს დამხმარე ავთენტიფიცირდება კომპანიის პროქსისთან. სულაც არ არის აუცილებელი, თავად აპლიკაცია ასრულებდეს კომპანიის ავთენტიფიკაციის გაცვლას.

application → local helper → company proxy → destination

CNTLM-ის მსგავს დამხმარეს აქვს ზედა დონის ანგარიშისა და პროქსის კონფიგურაცია. მის მსმენელს აქვს ცალკე მიწვდომადობისა და წვდომის საზღვარი. ბრაუზერში სხვა ბოლო წერტილისთვის შეყვანილი პაროლი არც ერთს არ აწყობს ავტომატურად.

დაადგინეთ, რომელი ნახტომი ჩავარდა

ჯერ დაადასტურეთ, რომ აპლიკაციამ აირჩია დამხმარის რეალური მსმენელი და პროტოკოლი. შეცდომა ამ მსმენელამდე მისვლამდე NTLM-ის ჩავარდნა არ არის. შემდეგ შეამოწმეთ, მიაღწია თუ არა დამხმარემ კონფიგურირებულ მშობელს და მიიღო თუ არა მშობელმა მისი იდენტობა.

ამ გზაზე დაბრუნებული 407 მიკუთვნებას მოითხოვს. დაუკავშირეთ ლოკალური ტრანზაქცია დამხმარის რედაქტირებულ დიაგნოსტიკას, ნაცვლად იმისა, რომ ჩათვალოთ, თითქოს ხილული სტატუსი განსაზღვრავს ანგარიშს, რომელიც თქვენმა აპლიკაციამ უნდა გააგზავნოს.

ძველი მაგალითები ზოგჯერ keep-alive სათაურს ამატებენ და წარმატებას აცხადებენ. კავშირზე ორიენტირებულ ავთენტიფიკაციაში მუდმივობას შეიძლება ჰქონდეს მნიშვნელობა, მაგრამ ეს დაკვირვება არ ადასტურებს, რომ ყველა წარუმატებელ დამხმარის კონფიგურაციას იგივე სათაური სჭირდება. ბოლო წერტილის არჩევა, მხარდაჭერილი მეთოდი, ანგარიში და კავშირის სიცოცხლე ცალკეულ შეყვანებად რჩება.

მსმენელი რეალური სერვისია

Loopback მსმენელს გარემომცველი ქსელისგან მოშორებით ტოვებს; ის არ არჩევს ამ კომპიუტერის ყველა პროცესს ან მომხმარებელს. კარიბჭე ან უფრო ფართო მიბმა ცვლის იმ გამომძახებელთა სიმრავლეს, რომლებსაც შეუძლიათ დამხმარის ზედა დონის იდენტობის გამოყენება. ეს ცვლილება განზრახ გააკეთეთ.

როცა აპლიკაცია ვერ ასრულებს საჭირო სქემას, გამოიყენეთ დამტკიცებული დამხმარის მოწყობა. სასარგებლო შედეგია ცნობილი გზა ცნობილი ანგარიშის საკუთრებით და არა აუხსნელი დამატებითი სერვისი, რომელიც შემთხვევით ერთ ჩამოტვირთვას ამუშავებს.