Դիտարկիչը Squid-ի միջոցով բեռնում է HTTP էջ։ Նույն նպատակակետը proxychains-ի ներքո ձախողվում է։ Դա պարտադիր չէ, որ նշանակի, թե ծրագրերից մեկն ընտրել է սխալ փրոքսի IP։

Սովորական HTTP հասկացող հաճախորդը կարող է վեբ հարցումն ուղարկել առաջընթաց փրոքսիին HTTP փրոքսիի ձևով։ Իսկ ընդհանուր socket-փաթաթան կարիք ունի բայթային թունելի այն կապի համար, որը ծրագիրը ցանկանում էր բացել։ Իր շղթայում գտնվող HTTP փրոքսիի համար proxychains-ը օգտագործում է CONNECT։

Դա նշանակում է, որ 80 պորտում գտնվող պարզ տեքստային կայքը կարող է CONNECT հարցում ստեղծել 80 պորտի համար։ Squid-ի այն քաղաքականությունը, որը CONNECT-ը թույլատրում է միայն իր հաստատված TLS պորտերի ցանկին, կարող է մերժել այդ թունելը, թեև 80 պորտին սովորական HTTP հարցումները թույլատրված են։

Համեմատեք հարցումները, ոչ միայն հոսթանունները

proxychains-ng-ի փաստաթղթերը նկարագրում են դրա HTTP CONNECT աջակցությունը։ Squid-ի մուտքի կանոնները կարող են տարբերել մեթոդը և նպատակակետ պորտը։ Սրանք տարբեր հարցումային ուղիներ են նույն կայքին։

Նախքան փոփոխելը կարդացեք մերժումը և նախատեսված քաղաքականությունը։ CONNECT հասանելիությունը բոլոր պորտերին ընդլայնելը էական փոփոխություն է. այն չպետք է լինի փաթաթանի անհամապատասխանության լռելյայն արձագանքը։

Եթե ծրագիրն ունի ներկառուցված HTTP փրոքսի աջակցություն, դրա օգտագործումը կարող է խուսափել պարզ տեքստային HTTP-ի համար ավելորդ ընդհանուր թունելից։ Եթե իսկապես անհրաժեշտ է հում TCP թունել, ընտրեք հաստատված փրոքսի արձանագրություն և պորտային քաղաքականություն, որոնք տալիս են այն։

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

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