.NET socket-ին անհրաժեշտ է SOCKS ձեռքսեղմում

Socket.Connect()-ը SOCKS սերվերին ուղղելը բացում է TCP կապ այդ սերվերի հետ։ Հաջորդ բայթերը դեռ պետք է խոսեն SOCKS։ Հավելվածի արձանագրությունն անմիջապես ուղարկելը սերվերին թողնում է սպասելու այլ զրույցի։

SOCKS5-ի դեպքում կապի հաստատումը ներառում է մեթոդի բանակցություն, ընտրված նույնականացման փոխանակում և հարցում, որը նշում է նպատակակետը։ Միայն հաջող պատասխանն է բացում ուղին հավելվածի բայթերի համար։ Այս փուլերը սահմանված են RFC 1928-ում։

Բանակցությունը թողեք կապի շերտում

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

Ձեռքով գրված իրականացումը, որը կարդում է մեկ ֆիքսված չափի բուֆեր և ենթադրում հաջողություն, խոցելի է։ TCP-ն չի պահպանում SOCKS հաղորդագրությունների սահմանները։ Նախքան հավելվածի արձանագրությունը սկսելը կարդացեք ամբողջական պատասխանը, որը նկարագրվում է իր հասցեի տեսակով։ .NET 7+-ի CONNECT պատասխանի ընթերցիչը ցույց է տալիս այդ քայլը։

Եթե սպասարկվող գրադարանն արդեն տրամադրում է այս կապի շերտը, ստուգեք դրա աջակցվող SOCKS տարբերակները, նույնականացման մեթոդները և թիրախ framework-ը։ Տասը տարվա ֆորումի հղումը հետազոտության մեկնարկային կետ է, ոչ թե ընթացիկ համատեղելիության ապացույց։

HTTP client-ի կարգավորումն առանձին շրջանակ ունի

HTTP client-ի պրոքսի կարգավորումը կարգավորում է հենց այդ HTTP client-ը։ Այն չի փոփոխում գործընթացի յուրաքանչյուր հում socket։ Socket API-ն ընդունում է ցանցային վերջնակետ և բարձր մակարդակի բանակցությունը թողնում է կանչողին։

Գաղտնագրված հավելվածի արձանագրության համար կատարեք դրա TLS ձեռքսեղմումը պրոքսի թունելը հաստատվելուց հետո։ Այդ փուլում ստուգեք նախատեսված նպատակակետի ինքնությունը։ Պրոքսիի նույնականացումը և նպատակակետի նույնականացումը մնում են առանձին, թեև օգտագործում են նույն հիմքային հոսքը։