.NET socket potrebuje rokovanje SOCKS
Pojasnite, kaj mora surov vtič TCP v .NET storiti, preden lahko aplikacijski bajti potujejo skozi proxy SOCKS.
Usmeritev Socket.Connect() na strežnik SOCKS odpre povezavo TCP s tem strežnikom. Naslednji bajti morajo še vedno govoriti SOCKS. Če takoj pošljete protokol svoje aplikacije, strežnik ostane čakati na drug pogovor.
Pri SOCKS5 vzpostavitev povezave vključuje pogajanje o metodi, morebitno izbrano izmenjavo preverjanja pristnosti in zahtevo z navedbo cilja. Samo uspešen odgovor odpre pot za bajte aplikacije. Te faze so opredeljene v RFC 1928.
Pogajanje ohranite v povezavnem sloju
Aplikacija z lastnim protokolom TCP lahko uporabi priključek, ki pozna proxy in vrne vzpostavljen tok. Preostanek aplikacije nato bere in piše skozi ta tok. Priključek mora upoštevati delno branje, naslove spremenljive dolžine, neuspehe preverjanja pristnosti in rok za pogajanje.
Ročno napisana izvedba, ki prebere en medpomnilnik fiksne velikosti in predpostavi uspeh, je krhka. TCP ne ohranja meja sporočil SOCKS. Pred začetkom aplikacijskega protokola preberite celoten odgovor, opisan z njegovim tipom naslova. Bralnik odgovorov CONNECT za .NET 7+ ponazarja ta korak.
Če vzdrževana knjižnica že ponuja ta povezavni sloj, preverite njene podprte različice SOCKS, metode preverjanja pristnosti in ciljno ogrodje. Desetletje star forumski zemljevid je izhodišče za preiskavo, ne dokaz o trenutni združljivosti.
Konfiguracija odjemalca HTTP ima ločen obseg
Nastavitev proxy v odjemalcu HTTP konfigurira ta odjemalec HTTP. Ne spreminja vsakega surovega vtiča v procesu. Vmesnik Socket API sprejme omrežno končno točko in pogajanje na višji ravni prepusti klicatelju.
Pri šifriranem aplikacijskem protokolu izvedite njegovo rokovanje TLS po vzpostavitvi tunela proxy. Na tej stopnji preverite predvideno identiteto cilja. Preverjanje pristnosti proxyja in cilja ostaneta ločena, čeprav uporabljata isti osnovni tok.