Ծրագրին SOCKS է պետք։ Ձեր հաստատված վերին ծառայությունը ընդունում է HTTP CONNECT։ HTTP վերջնակետը ծրագրի SOCKS դաշտում դնելը չի թարգմանում արձանագրությունների միջև։

Դարպասը կարող է SOCKS ընդունել ծրագրից, կարդալ պահանջված նպատակակետը և HTTP ծնողից CONNECT թունել խնդրել այդ նպատակակետի համար։ Այնուհետև ծրագրի հոսքը փոխանցում է թունելով։

SOCKS application → SOCKS-facing gateway → HTTP CONNECT parent → destination

Դարձրու յուրաքանչյուր ինտերֆեյս բացահայտ

Այս դասավորությունը սատարող դարպասի համար կարևոր է ծնողի տեսակը։ 3proxy-ի փաստաթղթերը տարբերում են connect ծնողին սովորական HTTP փոխանցող պրոքսիի պես օգտագործվող ծնողից։

Առկա 3proxy օգտատիրոջ և նույնականացման դեպքում միայն տեղական երթուղային հատվածը կարող է ունենալ այս տեսքը.

auth strong
allow alex
parent 1000 connect parent.example.net 8080
socks -i127.0.0.1 -p1080

Այս հատվածը ենթադրում է, որ հաշիվն արդեն սահմանված է։ Այն չի ավելացնում HTTP ծնողի իսկ պահանջած որևէ հավատարմագիր և չի փոխարինում գոյություն ունեցող մուտքի քաղաքականությունը։ Չնույնականացված հանրային HTTP ծնող թույլատրող երթուղու հանրային նպատակակետերի համար HTTP պրոքսիների ցանկը առաջարկում է հոսթի և պորտի թեկնածուներ։ Այդ ճյուղի համար թող ծնողի հավատարմագրերը բացակայեն և հաստատիր թույլտվությունը փաստացի թիրախի համար. դարպասի սեփական հաշիվը մնում է տեղական։ parent կանոնը կապվում է նախորդ allow կանոնի հետ 3proxy-ի փաստաթղթավորված կազմաձևման մոդելով։

Ծրագիրն օգտագործում է տեղական SOCKS վերջնակետը։ Դարպասը HTTP CONNECT է օգտագործում ծնողի ուղղությամբ։ Ծնողը դեռ որոշում է՝ արդյոք պահանջված նպատակակետ հոսթն ու պորտը թույլատրված են։

Այստեղ օգտակար շրջանակը սովորական TCP հոսքի թունելավորումն է։ SOCKS5-ի UDP միավորումը չի դառնում աջակցվող միայն այն պատճառով, որ առջևի լսողն ընդունում է SOCKS5։ HTTP CONNECT ծնողը ինքնաշխատ չի ապահովում պահանջվող UDP ռելեը։

HTTPS-ը կարող է մնալ ծայրից ծայր այս ուղու մեջ. պրոքսի ինտերֆեյսների միջև թարգմանությունը չի պահանջում նպատակակետ կայքի ձևանալ։ Դարպասի, ծնողի և կայքի նույնականացումները մնում են տարբեր հավատարմագրեր և փոխանակումներ։

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