.NET Socket се нуждае от SOCKS ръкостискане

Насочването на Socket.Connect() към SOCKS сървър отваря TCP връзка към този сървър. Следващите байтове все още трябва да говорят SOCKS. Ако изпратите протокола на приложението веднага, сървърът ще чака друг разговор.

При SOCKS5 установяването на връзка включва договаряне на метод, евентуален избран обмен на удостоверяване и заявка, която посочва дестинацията. Само успешен отговор отваря пътя за байтовете на приложението. Тези етапи са дефинирани в RFC 1928.

Дръжте договарянето в слоя на връзката

Приложение със собствен TCP протокол може да използва съединител, който разбира прокси и връща установен поток. Останалата част от приложението след това чете и пише през този поток. Съединителят трябва да отчита частични четения, адреси с променлива дължина, неуспехи при удостоверяване и краен срок за договарянето.

Написана на ръка реализация, която чете един буфер с фиксиран размер и предполага успех, е крехка. TCP не запазва границите на SOCKS съобщенията. Прочетете пълния отговор, описан от неговия тип адрес, преди да започнете протокола на приложението. четец на CONNECT отговори в .NET 7+ илюстрира тази стъпка.

Ако поддържана библиотека вече предоставя този слой на връзката, проверете поддържаните от нея версии на SOCKS, методи за удостоверяване и целева рамка. Форумна препратка от десетилетие е отправна точка за разследване, а не доказателство за текуща съвместимост.

Конфигурацията на HTTP клиента има отделен обхват

Прокси настройката на HTTP клиент конфигурира този HTTP клиент. Тя не променя всеки суров сокет в процеса. Socket API приема мрежова крайна точка и оставя договарянето на по-високо ниво на извикващия.

За криптиран протокол на приложението изпълнете TLS ръкостискането след установяване на прокси тунела. Проверете предвидената идентичност на дестинацията на този етап. Удостоверяването на прокси и удостоверяването на дестинацията остават отделни, дори когато използват един и същ базов поток.