Privoxy: collegare un client proxy HTTP a un tunnel SOCKS

Un tunnel SSH dinamico, incluso l'inoltro dinamico di PuTTY, fornisce un'interfaccia SOCKS. Un'applicazione che accetta solo un proxy HTTP non può usare quella porta solo chiamandola HTTP.

Un ponte di protocollo locale può stare tra i due. L'applicazione invia le richieste proxy HTTP al ponte, e il ponte apre le connessioni di destinazione tramite il servizio SOCKS.

Privoxy documenta questa disposizione tramite le sue regole di inoltro. Per un tunnel SOCKS5 locale esistente, un frammento di configurazione è:

forward-socks5 / 127.0.0.1:1080 .

L'applicazione si connette al listener HTTP di Privoxy, non alla porta 1080. Mantieni quel listener locale secondo la politica di accesso prevista. Il punto finale nella regola ha un significato documentato; non è un segnaposto per un nome host internet mancante.

Questa è traduzione di protocollo

La documentazione sull'inoltro di Privoxy spiega la sintassi dell'inoltro SOCKS e la gestione dei nomi host. Un semplice inoltro di porta TCP non esegue la stessa traduzione: trasporta i byte HTTP del client invariati verso un listener SOCKS, che si aspetta ancora una negoziazione SOCKS.

Il ponte diventa anche parte della configurazione che bisogna capire. Privoxy può avere le proprie impostazioni di filtro dei contenuti e di accesso. Aggiungerlo non equivale a far supportare SOCKS nativamente all'applicazione originale.

Per i siti HTTPS, l'applicazione di solito chiede CONNECT al ponte HTTP, e il ponte ottiene la connessione di destinazione tramite SOCKS. Il normale TLS del sito resta una relazione tra applicazione e sito; il ponte non deve impersonare il sito per offrire questo percorso.

Se l'applicazione può usare SOCKS direttamente, il componente aggiuntivo può essere superfluo. Usa il ponte per risolvere una reale discrepanza di protocollo, con il listener e l'upstream chiaramente distinti.