.NET-i socket vajab SOCKS-kätlust
Selgitage, mida toores .NET-i TCP-socket peab tegema enne, kui rakenduse baidid saavad SOCKS-proksist läbi liikuda.
Socket.Connect() suunamine SOCKS-serverile avab TCP-ühenduse selle serveriga. Järgmised baidid peavad siiski rääkima SOCKS-i. Kui saata kohe rakenduse protokoll, jääb server ootama teistsugust vestlust.
SOCKS5 puhul hõlmab ühenduse loomine meetodi läbirääkimist, valitud autentimisvahetust ja sihtkohta nimetavat päringut. Ainult edukas vastus avab tee rakenduse baididele. Need etapid on määratletud dokumendis RFC 1928.
Hoia läbirääkimine ühenduskihis
Oma TCP-protokolliga rakendus saab kasutada proksiteadlikku connectorit, mis tagastab loodud voo. Ülejäänud rakendus loeb ja kirjutab selle voo kaudu. Connector peab arvestama osalisi lugemisi, muutuva pikkusega aadresse, autentimise ebaõnnestumisi ja läbirääkimise tähtaega.
Käsitsi kirjutatud teostus, mis loeb ühe fikseeritud suurusega puhvri ja eeldab õnnestumist, on habras. TCP ei säilita SOCKS-sõnumite piire. Lugege enne rakenduse protokolli alustamist täielik vastus, mida kirjeldab selle aadressitüüp. .NET 7+ CONNECT-vastuse lugeja illustreerib seda sammu.
Kui hooldatud teek pakub seda ühenduskihti juba, kontrollige selle toetatud SOCKS-versioone, autentimismeetodeid ja sihtraamistikku. Kümme aastat vana foorumilink on uurimise lähtepunkt, mitte tõend praeguse ühilduvuse kohta.
HTTP-kliendi konfiguratsioonil on eraldi ulatus
HTTP-kliendi proksiseade konfigureerib seda HTTP-klienti. See ei muuda protsessis iga toorest socketit. Socket API võtab vastu võrgu lõpp-punkti ja jätab kõrgema taseme läbirääkimise kutsujale.
Krüpteeritud rakendusprotokolli puhul tehke selle TLS-kätlus pärast proksitunneli loomist. Kontrollige selles etapis kavandatud sihtkoha identiteeti. Proksi autentimine ja sihtkoha autentimine jäävad eraldi, kuigi need kasutavad sama alusvoogu.