.NET сокету је потребно SOCKS руковање
Објасните шта сирови .NET TCP сокет мора да уради пре него што бајтови апликације прођу кроз SOCKS прокси.
Усмеравање Socket.Connect() ка SOCKS серверу отвара TCP везу са тим сервером. Следећи бајтови и даље морају да говоре SOCKS. Ако одмах пошаљете протокол своје апликације, сервер остаје да чека други разговор.
Код SOCKS5, успостављање везе укључује преговарање о методи, евентуалну изабрану размену аутентификације и захтев који именује одредиште. Само успешан одговор отвара пут за бајтове апликације. Ове фазе су дефинисане у RFC 1928.
Задржите преговарање у слоју везе
Апликација са сопственим TCP протоколом може да користи конектор који познаје прокси и враћа успостављени ток. Остатак апликације затим чита и пише кроз тај ток. Конектор мора да узме у обзир делимична читања, адресе променљиве дужине, неуспехе аутентификације и рок за преговарање.
Ручно написана имплементација која чита један бафер фиксне величине и претпоставља успех је крхка. TCP не чува границе SOCKS порука. Прочитајте комплетан одговор описан његовим типом адресе пре покретања протокола апликације. Читач CONNECT одговора за .NET 7+ илуструје тај корак.
Ако одржавана библиотека већ пружа овај слој везе, проверите њене подржане SOCKS верзије, методе аутентификације и циљни framework. Веза са форума стара деценију је полазна тачка за истраживање, а не доказ тренутне компатибилности.
Конфигурација HTTP клијента има одвојен обим
Подешавање проксија у HTTP клијенту конфигурише тај HTTP клијент. Оно не мења сваки сирови сокет у процесу. Socket API прихвата мрежну крајњу тачку и препушта преговарање вишег нивоа позиваоцу.
За шифровани протокол апликације, извршите његов TLS handshake након што је прокси тунел успостављен. У тој фази проверите предвиђени идентитет одредишта. Аутентификација проксија и аутентификација одредишта остају одвојене иако користе исти основни ток.