Ang .NET socket ay nangangailangan ng SOCKS handshake
Ipaliwanag kung ano ang dapat gawin ng raw .NET TCP socket bago makapaglakbay ang mga byte ng application sa isang SOCKS proxy.
Ang pagturo ng Socket.Connect() sa isang SOCKS server ay nagbubukas ng TCP koneksyon sa server na iyon. Ang susunod na mga byte ay kailangan pa ring magsalita ng SOCKS. Ang agarang pagpapadala ng protocol ng iyong application ay nag-iiwan sa server na naghihintay ng ibang usapan.
Sa SOCKS5, kasama sa pagtatatag ng koneksyon ang negosasyon ng pamamaraan, anumang napiling palitan ng authentication, at isang kahilingang nagsasaad ng destinasyon. Tanging matagumpay na tugon ang nagbubukas ng daan para sa mga byte ng application. Ang mga yugtong ito ay tinukoy sa RFC 1928.
Panatilihin ang negosasyon sa connection layer
Ang isang application na may sariling TCP protocol ay makakagamit ng connector na nakakaalam ng proxy at nagbabalik ng naitatag na stream. Ang natitirang bahagi ng application ay nagbabasa at nagsusulat sa stream na iyon. Dapat isaalang-alang ng connector ang mga partial read, variable-length na address, pagkabigo ng authentication, at deadline para sa negosasyon.
Ang manu-manong implementasyong nagbabasa ng isang fixed-size buffer at ipinapalagay ang tagumpay ay marupok. Ang TCP ay hindi nagpapanatili ng mga hangganan ng mga mensaheng SOCKS. Basahin ang kumpletong tugon na inilalarawan ng uri ng address nito bago simulan ang protocol ng application. Ang reader ng CONNECT reply para sa .NET 7+ ay naglalarawan ng hakbang na iyon.
Kung ang isang maintained library ay nagbibigay na ng connection layer na ito, suriin ang mga sinusuportahang bersyon ng SOCKS, pamamaraan ng authentication, at target framework. Ang isang link sa forum na isang dekada na ang edad ay panimulang punto para sa pagsisiyasat, hindi ebidensya ng kasalukuyang pagiging tugma.
Ang configuration ng HTTP client ay may hiwalay na saklaw
Ang proxy setting ng isang HTTP client ay nagko-configure sa HTTP client na iyon. Hindi nito binabago ang bawat raw socket sa proseso. Tumatanggap ang Socket API ng network endpoint at iniiwan ang negosasyon sa mas mataas na antas sa tumatawag.
Para sa isang naka-encrypt na protocol ng application, isagawa ang TLS handshake nito pagkatapos maitatag ang proxy tunnel. I-validate ang nilalayong pagkakakilanlan ng destinasyon sa yugtong iyon. Nananatiling hiwalay ang authentication ng proxy at authentication ng destinasyon kahit gumagamit sila ng parehong underlying stream.