.NET socket zahtijeva SOCKS rukovanje
Objašnjava šta sirovi .NET TCP socket mora učiniti prije nego što bajtovi aplikacije mogu putovati kroz SOCKS proxy.
Usmjeravanje Socket.Connect() na SOCKS server otvara TCP vezu s tim serverom. Sljedeći bajtovi još uvijek moraju govoriti SOCKS. Trenutno slanje protokola vaše aplikacije ostavlja server da čeka drugi razgovor.
S SOCKS5, uspostavljanje veze uključuje pregovaranje metode, odabranu razmjenu autentifikacije i zahtjev koji imenuje odredište. Samo uspješan odgovor otvara put za bajtove aplikacije. Ove faze definirane su u RFC 1928.
Zadržite pregovaranje u sloju veze
Aplikacija s vlastitim TCP protokolom može koristiti konektor koji razumije proxy i vraća uspostavljeni tok. Ostatak aplikacije zatim čita i piše kroz taj tok. Konektor mora uzeti u obzir djelimična čitanja, adrese promjenljive dužine, neuspjehe autentifikacije i rok za pregovaranje.
Ručno napisana implementacija koja čita jedan bafer fiksne veličine i pretpostavlja uspjeh je krhka. TCP ne čuva granice SOCKS poruka. Pročitajte potpuni odgovor opisan njegovim tipom adrese prije nego što započnete protokol aplikacije. Čitač CONNECT odgovora u .NET 7+ ilustruje taj korak.
Ako održavana biblioteka već pruža ovaj sloj veze, provjerite podržane SOCKS verzije, metode autentifikacije i ciljni okvir. Forum link star deceniju polazište je za istragu, a ne dokaz trenutne kompatibilnosti.
Konfiguracija HTTP klijenta ima odvojen opseg
Postavka proxyja HTTP klijenta konfigurira taj HTTP klijent. Ona ne mijenja svaki sirovi socket u procesu. Socket API prihvaća mrežnu krajnju točku i ostavlja pregovaranje više razine pozivatelju.
Za šifrirani protokol aplikacije izvršite njegovo TLS rukovanje nakon što je proxy tunel uspostavljen. U toj fazi provjerite identitet predviđenog odredišta. Autentifikacija proxyja i autentifikacija odredišta ostaju odvojene iako koriste isti temeljni tok.