Un socket .NET richiede un handshake SOCKS
Spiega cosa deve fare un socket TCP .NET grezzo prima che i byte dell'applicazione possano viaggiare attraverso un proxy SOCKS.
Puntare Socket.Connect() verso un server SOCKS apre una connessione TCP a quel server. I byte successivi devono comunque parlare SOCKS. Inviare subito il protocollo dell'applicazione lascia il server in attesa di un'altra conversazione.
Con SOCKS5, l'instaurazione della connessione comprende la negoziazione del metodo, un eventuale scambio di autenticazione scelto e una richiesta che nomina la destinazione. Solo una risposta riuscita apre il percorso per i byte dell'applicazione. Queste fasi sono definite nella RFC 1928.
Mantieni la negoziazione nel livello di connessione
Un'applicazione con un proprio protocollo TCP può usare un connettore consapevole del proxy che restituisce uno stream già stabilito. Il resto dell'applicazione legge e scrive attraverso quello stream. Un connettore deve tenere conto di letture parziali, indirizzi di lunghezza variabile, errori di autenticazione e una scadenza per la negoziazione.
Un'implementazione scritta a mano che legge un singolo buffer di dimensione fissa e presuppone il successo è fragile. TCP non preserva i confini dei messaggi SOCKS. Leggi la risposta completa descritta dal suo tipo di indirizzo prima di avviare il protocollo dell'applicazione. Un lettore di risposte CONNECT per .NET 7+ illustra questo passaggio.
Se una libreria mantenuta fornisce già questo livello di connessione, controlla le versioni SOCKS supportate, i metodi di autenticazione e il framework di destinazione. Un link a un forum di dieci anni fa è un punto di partenza per indagare, non la prova della compatibilità attuale.
La configurazione del client HTTP ha un ambito separato
L'impostazione del proxy di un client HTTP configura quel client HTTP. Non modifica ogni socket grezzo del processo. L'API Socket accetta un endpoint di rete e lascia la negoziazione di livello superiore al chiamante.
Per un protocollo applicativo cifrato, esegui il suo handshake TLS dopo che il tunnel del proxy è stabilito. Convalida l'identità della destinazione prevista in quella fase. L'autenticazione del proxy e quella della destinazione restano separate anche se usano lo stesso stream sottostante.