.NET socket treba SOCKS rukovanje
Objasnite što sirovi .NET TCP socket mora učiniti prije nego bajtovi aplikacije mogu putovati kroz SOCKS proxy.
Usmjeravanje Socket.Connect() na SOCKS poslužitelj otvara TCP vezu s tim poslužiteljem. Sljedeći bajtovi ipak moraju govoriti SOCKS. Slanje protokola aplikacije odmah ostavlja poslužitelj da čeka drugi razgovor.
Kod SOCKS5 uspostava veze uključuje pregovaranje metode, eventualnu odabranu razmjenu autentifikacije i zahtjev koji imenuje odredište. Samo uspješan odgovor otvara put bajtovima aplikacije. Ti su koraci definirani u RFC 1928.
Zadržite pregovaranje u sloju veze
Aplikacija s vlastitim TCP protokolom može koristiti konektor koji poznaje proxy i vraća uspostavljeni tok. Ostatak aplikacije zatim čita i piše kroz taj tok. Konektor mora uzeti u obzir djelomična čitanja, adrese promjenjive duljine, neuspjehe autentifikacije i rok za pregovaranje.
Ručno napisana implementacija koja čita jedan međuspremnik fiksne veličine i pretpostavlja uspjeh je krhka. TCP ne čuva granice SOCKS poruka. Pročitajte potpuni odgovor opisan njegovim tipom adrese prije pokretanja protokola aplikacije. Čitač CONNECT odgovora za .NET 7+ ilustrira taj korak.
Ako održavana biblioteka već pruža ovaj sloj veze, provjerite njezine podržane verzije SOCKS-a, metode autentifikacije i ciljni framework. Forumski link star desetljeće početna je točka za istraživanje, a ne dokaz trenutne kompatibilnosti.
Konfiguracija HTTP klijenta ima zaseban opseg
Proxy postavka HTTP klijenta konfigurira taj HTTP klijent. Ne mijenja svaki sirovi socket u procesu. Socket API prihvaća mrežnu završnu točku i prepušta pregovaranje na višoj razini pozivatelju.
Za šifrirani protokol aplikacije izvedite njegovo TLS rukovanje nakon uspostave proxy tunela. U tom koraku provjerite identitet namjeravanog odredišta. Autentifikacija proxyja i autentifikacija odredišta ostaju odvojene iako koriste isti temeljni tok.