На .NET сокет му треба SOCKS ракување

Насочувањето на Socket.Connect() кон SOCKS сервер отвора TCP врска со тој сервер. Следните бајти сè уште мора да зборуваат SOCKS. Веднаш испраќање на протоколот на вашата апликација го остава серверот да чека друг разговор.

Со SOCKS5, воспоставувањето на врската вклучува преговарање за методот, избраната размена за автентикација и барање што ја именува дестинацијата. Само успешен одговор го отвора патот за бајтите на апликацијата. Овие фази се дефинирани во RFC 1928.

Задржете го преговарањето во слојот на врската

Апликација со сопствен TCP протокол може да користи конектор што го разбира проксито и враќа воспоставен поток. Остатокот од апликацијата потоа чита и пишува низ тој поток. Конекторот мора да земе предвид делумни читања, адреси со променлива должина, неуспеси при автентикација и рок за преговарањето.

Рачно напишана имплементација што чита еден бафер со фиксна големина и претпоставува успех е кревка. TCP не ги зачувува границите на SOCKS пораките. Прочитајте го целосниот одговор опишан со неговиот тип на адреса пред да го започнете протоколот на апликацијата. Читачот на CONNECT одговор во .NET 7+ го илустрира тој чекор.

Ако одржувана библиотека веќе го обезбедува овој слој на врската, проверете ги поддржаните SOCKS верзии, методи на автентикација и целната рамка. Форумска врска стара десет години е почетна точка за истражување, а не доказ за тековна компатибилност.

Конфигурацијата на HTTP клиентот има одделен опсег

Поставката за прокси на HTTP клиентот го конфигурира тој HTTP клиент. Таа не го менува секој суров сокет во процесот. Socket API прифаќа мрежна крајна точка и го остава преговарањето на повисоко ниво на повикувачот.

За шифриран протокол на апликацијата, извршете го неговото TLS ракување откако ќе се воспостави прокси тунелот. Во таа фаза валидирајте го предвидениот идентитет на дестинацијата. Автентикацијата на прокси и автентикацијата на дестинацијата остануваат одделни иако користат ист основен поток.