Ձեր հավելվածը միանում է պրոքսիի իր իսկ համակարգչում։ Այնուհետև այդ օգնականը նույնականացվում է ընկերության պրոքսիի մոտ։ Պարտադիր չէ, որ հավելվածն ինքը կատարի ընկերության նույնականացման փոխանակումը։

application → local helper → company proxy → destination

CNTLM-ի նման օգնականն ունի վերևին հաշվի և պրոքսիի կարգավորում։ Նրա տեղական լսիչն ունի առանձին հասանելիության և մուտքի սահման։ Այլ վերջնակետի համար բրաուզերում մուտքագրված գաղտնաբառը ինքնաշխատ չի կարգավորում դրանցից ոչ մեկը։

Որոշեք, թե որ անցումն է ձախողվել

Նախ հաստատեք, որ հավելվածն ընտրել է օգնականի իրական լսիչն ու արձանագրությունը։ Այդ լսիչին հասնելուց առաջ սխալը NTLM ձախողում չէ։ Այնուհետև ստուգեք՝ արդյոք օգնականը հասել է կարգավորված ծնողին և արդյոք ծնողն ընդունել է նրա ինքնությունը։

Այս ուղով վերադարձած 407-ը վերագրման կարիք ունի։ Կապեք տեղական գործարքը օգնականի խմբագրված ախտորոշման հետ՝ փոխարենը ենթադրելու, որ տեսանելի կարգավիճակը նշում է այն հաշիվը, որը պետք է ուղարկի ձեր հավելվածը։

Հին օրինակները երբեմն ավելացնում են keep-alive վերնագիր և հաղորդում հաջողության մասին։ Միացման վրա հիմնված նույնականացման համար կայունությունը կարող է կարևոր լինել, սակայն այդ դիտարկումը չի ապացուցում, որ յուրաքանչյուր ձախողված օգնականի կարգավորում նույն վերնագրի կարիք ունի։ Վերջնակետի ընտրությունը, աջակցվող մեթոդը, հաշիվը և միացման կյանքի տևողությունը մնում են առանձին մուտքեր։

Լսիչը իրական ծառայություն է

Loopback-ը լսիչը հեռու է պահում շրջակա ցանցից, սակայն չի տարբերում այդ համակարգչի բոլոր գործընթացները կամ օգտատերերին։ Դարպասը կամ ավելի լայն կապումը փոխում է զանգահարողների բազմությունը, որոնք կարող են օգտագործել օգնականի վերևին ինքնությունը։ Կատարեք այդ փոփոխությունը գիտակցաբար։

Երբ հավելվածը չի կարող կատարել պահանջվող սխեման, օգտագործեք հաստատված օգնականի կազմակերպում։ Օգտակար արդյունքը հայտնի ուղի է՝ հայտնի հաշվի սեփականությամբ, ոչ թե չբացատրված լրացուցիչ ծառայություն, որն պատահաբար աշխատեցնում է մեկ ներբեռնում։

Առնչվող հոդվածներ