.NET socket potrebuje handshake SOCKS
Vysvetlite, čo musí surový TCP socket v .NET urobiť predtým, ako aplikačné bajty prejdú cez proxy SOCKS.
Nasmerovanie Socket.Connect() na server SOCKS otvorí TCP spojenie s týmto serverom. Ďalšie bajty musia stále hovoriť SOCKS. Ak okamžite odošlete protokol svojej aplikácie, server zostane čakať na iný rozhovor.
Pri SOCKS5 zahŕňa vytvorenie spojenia vyjednávanie metódy, prípadnú zvolenú výmenu autentifikácie a požiadavku s uvedením cieľa. Iba úspešná odpoveď otvorí cestu pre bajty aplikácie. Tieto fázy sú definované v RFC 1928.
Vyjednávanie ponechajte v spojovej vrstve
Aplikácia s vlastným protokolom TCP môže použiť konektor, ktorý rozumie proxy a vráti vytvorený stream. Zvyšok aplikácie potom cez tento stream číta a zapisuje. Konektor musí počítať s čiastočným čítaním, adresami premenlivej dĺžky, zlyhaniami autentifikácie a lehotou pre vyjednávanie.
Ručne napísaná implementácia, ktorá prečíta jednu vyrovnávaciu pamäť pevnej veľkosti a predpokladá úspech, je krehká. TCP nezachováva hranice správ SOCKS. Pred spustením aplikačného protokolu prečítajte celú odpoveď opísanú jej typom adresy. Čítač odpovedí CONNECT pre .NET 7+ tento krok ilustruje.
Ak udržiavaná knižnica už túto spojovú vrstvu poskytuje, skontrolujte jej podporované verzie SOCKS, metódy autentifikácie a cieľový rámec. Desiatky rokov starý odkaz na fórum je východiskom pre skúmanie, nie dôkazom súčasnej kompatibility.
Konfigurácia HTTP klienta má samostatný rozsah
Nastavenie proxy v HTTP klientovi konfiguruje tento HTTP klient. Neupravuje každý surový socket v procese. Rozhranie Socket API prijíma sieťový koncový bod a vyjednávanie na vyššej úrovni ponecháva volajúcemu.
Pri šifrovanom aplikačnom protokole vykonajte jeho TLS handshake po vytvorení tunela proxy. V tejto fáze overte zamýšľanú identitu cieľa. Autentifikácia proxy a autentifikácia cieľa zostávajú oddelené, aj keď používajú ten istý základný stream.