.NET Socket патрабуе рукапаціску SOCKS
Растлумачце, што павінен зрабіць сыры .NET TCP-сокет, перш чым байты праграмы пойдуць праз проксі SOCKS.
Направіць Socket.Connect() на сервер SOCKS — значыць адкрыць TCP-злучэнне з гэтым серверам. Наступныя байты ўсё яшчэ павінны гаварыць на SOCKS. Калі адправіць пратакол вашай праграмы адразу, сервер будзе чакаць іншай размовы.
У SOCKS5 усталяванне злучэння ўключае перамовы аб метадзе, любы выбраны абмен аўтэнтыфікацыі і запыт з указаннем прызначэння. Толькі паспяховы адказ адкрывае шлях для байтаў праграмы. Гэтыя этапы вызначаны ў RFC 1928.
Трымайце перамовы ў пласце злучэння
Праграма з уласным пратаколам TCP можа выкарыстоўваць канэктары, якія разумеюць проксі і вяртаюць усталяваны паток. Астатняя частка праграмы потым чытае і піша праз гэты паток. Канэктар павінен улічваць частковыя чытанні, адрасы зменлівай даўжыні, збоі аўтэнтыфікацыі і тэрмін для перамоваў.
Напісаная ўручную рэалізацыя, якая чытае адзін буфер фіксаванага памеру і мяркуе поспех, крохкая. TCP не захоўвае межы паведамленняў SOCKS. Чытайце поўны адказ, апісаны яго тыпам адраса, перш чым пачынаць пратакол праграмы. чытач адказаў CONNECT у .NET 7+ ілюструе гэты крок.
Калі бібліятэка, якая падтрымліваецца, ужо дае гэты пласт злучэння, праверце яе падтрыманыя версіі SOCKS, метады аўтэнтыфікацыі і мэтавую платформу. Спасылка на форум дзесяцігадовай даўніны — гэта адпраўная кропка для даследавання, а не доказ бягучай сумяшчальнасці.
Канфігурацыя HTTP-кліента мае асобны абсяг
Налада проксі HTTP-кліента канфігуруе менавіта гэты HTTP-кліент. Яна не змяняе кожны сыры сокет у працэсе. API Socket прымае сеткавую канчатковую кропку і пакідае перамовы вышэйшага ўзроўню выклікаючаму боку.
Для шыфраванага пратаколу праграмы выканайце рукапаціск TLS пасля ўсталявання тунелю проксі. На гэтым этапе праверце меркаваную ідэнтычнасць прызначэння. Аўтэнтыфікацыя проксі і аўтэнтыфікацыя прызначэння застаюцца асобнымі, нават калі яны выкарыстоўваюць адзін і той жа базавы паток.