Privoxy: conectar un cliente de proxy HTTP a un túnel SOCKS

Un túnel SSH dinámico, incluído o reenvío dinámico de PuTTY, ofrece unha interface SOCKS. Unha aplicación que só acepta un proxy HTTP non pode usar ese porto só por chamalo HTTP.

Unha ponte de protocolo local pode situarse entre ambos. A aplicación envía as peticións de proxy HTTP á ponte, e a ponte abre as conexións de destino a través do servizo SOCKS.

Privoxy documenta esta disposición mediante as súas regras de reenvío. Para un túnel SOCKS5 local existente, un fragmento de configuración é:

forward-socks5 / 127.0.0.1:1080 .

A aplicación conéctase ao oínte HTTP de Privoxy, non ao porto 1080. Mantén ese oínte local segundo a política de acceso prevista. O punto final da regra ten un significado documentado; non é un marcador para un nome de host de internet ausente.

Isto é tradución de protocolo

A documentación de reenvío de Privoxy explica a sintaxe do reenvío SOCKS e o manexo de nomes de host. Un reenvío de porto TCP simple non realiza a mesma tradución: transporta os bytes HTTP do cliente sen cambios a un oínte SOCKS, que segue agardando unha negociación SOCKS.

A ponte tamén pasa a formar parte da configuración que hai que entender. Privoxy pode ter os seus propios axustes de filtrado de contido e de acceso. Engadila non é o mesmo que facer que a aplicación orixinal admita SOCKS de forma nativa.

Para os sitios HTTPS, a aplicación adoita pedir CONNECT á ponte HTTP, e a ponte obtén a conexión de destino a través de SOCKS. O TLS normal do sitio segue sendo unha relación entre aplicación e sitio; a ponte non necesita suplantar o sitio para ofrecer esta ruta.

Se a aplicación pode usar SOCKS directamente, o compoñente extra pode ser innecesario. Usa a ponte para resolver un desaxuste real de protocolo, co oínte e a orixe claramente distinguidos.