Un socket .NET are nevoie de un handshake SOCKS

Direcționarea Socket.Connect() către un server SOCKS deschide o conexiune TCP către acel server. Următorii octeți trebuie totuși să vorbească SOCKS. Trimiterea imediată a protocolului aplicației lasă serverul așteptând o altă conversație.

Cu SOCKS5, stabilirea conexiunii include negocierea metodei, orice schimb de autentificare selectat și o cerere care numește destinația. Doar un răspuns reușit deschide calea pentru octeții aplicației. Aceste etape sunt definite în RFC 1928.

Păstrați negocierea în stratul de conexiune

O aplicație cu propriul protocol TCP poate folosi un conector conștient de proxy care returnează un flux stabilit. Restul aplicației citește și scrie apoi prin acel flux. Un conector trebuie să țină cont de citiri parțiale, adrese cu lungime variabilă, eșecuri de autentificare și un termen limită pentru negociere.

O implementare scrisă de mână care citește un buffer de dimensiune fixă și presupune succesul este fragilă. TCP nu păstrează granițele mesajelor SOCKS. Citiți răspunsul complet descris de tipul său de adresă înainte de a începe protocolul aplicației. Un cititor de răspunsuri CONNECT din .NET 7+ ilustrează acel pas.

Dacă o bibliotecă întreținută furnizează deja acest strat de conexiune, verificați versiunile SOCKS acceptate, metodele de autentificare și framework-ul țintă. Un link de forum vechi de un deceniu este un punct de plecare pentru investigație, nu o dovadă a compatibilității actuale.

Configurarea clientului HTTP are un domeniu separat

Setarea de proxy a unui client HTTP configurează acel client HTTP. Ea nu modifică fiecare socket brut din proces. API-ul Socket acceptă un punct final de rețea și lasă negocierea de nivel superior apelantului.

Pentru un protocol de aplicație criptat, efectuați handshake-ul TLS după ce tunelul proxy este stabilit. Validați identitatea destinației dorite în acea etapă. Autentificarea proxy și autentificarea destinației rămân separate chiar dacă folosesc același flux subiacent.