.NET ligzdai ir nepieciešama SOCKS rokasspiediena
Paskaidro, kas jāizdara neapstrādātai .NET TCP ligzdai, pirms lietotnes baiti var ceļot caur SOCKS starpniekserveri.
Norādot Socket.Connect() uz SOCKS serveri, tiek atvērts TCP savienojums ar šo serveri. Nākamajiem baitiem joprojām jārunā SOCKS valodā. Tūlītēja lietotnes protokola nosūtīšana atstāj serveri gaidām citu sarunu.
Ar SOCKS5 savienojuma izveide ietver metodes saskaņošanu, jebkuru izvēlēto autentifikācijas apmaiņu un pieprasījumu, kas nosauc galamērķi. Tikai veiksmīga atbilde atver ceļu lietotnes baitiem. Šie posmi ir definēti RFC 1928.
Turiet saskaņošanu savienojuma slānī
Lietotne ar savu TCP protokolu var izmantot starpniekserveri apzinošu savienotāju, kas atgriež izveidotu plūsmu. Pārējā lietotnes daļa pēc tam lasa un raksta caur šo plūsmu. Savienotājam jāņem vērā daļējas lasīšanas, mainīga garuma adreses, autentifikācijas kļūmes un saskaņošanas termiņš.
Ar roku rakstīta implementācija, kas nolasa vienu fiksēta izmēra buferi un pieņem panākumus, ir trausla. TCP nesaglabā SOCKS ziņojumu robežas. Izlasiet pilnu atbildi, kas aprakstīta ar tās adreses tipu, pirms sākat lietotnes protokolu. .NET 7+ CONNECT atbildes lasītājs ilustrē šo soli.
Ja uzturēta bibliotēka jau nodrošina šo savienojuma slāni, pārbaudiet tās atbalstītās SOCKS versijas, autentifikācijas metodes un mērķa platformu. Desmit gadus sens foruma links ir izmeklēšanas sākumpunkts, nevis pašreizējās saderības pierādījums.
HTTP klienta konfigurācijai ir atsevišķa joma
HTTP klienta starpniekservera iestatījums konfigurē šo HTTP klientu. Tas nemaina katru neapstrādāto ligzdu procesā. Socket API pieņem tīkla galapunktu un atstāj augstāka līmeņa saskaņošanu zvanītājam.
Šifrētam lietotnes protokolam veiciet tā TLS rokasspiedienu pēc starpniekservera tuneļa izveides. Tajā posmā validējiet paredzēto galamērķa identitāti. Starpniekservera autentifikācija un galamērķa autentifikācija paliek atsevišķas, lai gan tās izmanto vienu un to pašu pamata plūsmu.