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

Un túnel SSH dinámico, incluido el reenvío dinámico de PuTTY, ofrece una interfaz SOCKS. Una aplicación que solo acepta un proxy HTTP no puede usar ese puerto por el mero hecho de llamarlo HTTP.

Un puente de protocolo local puede situarse entre ambos. La aplicación envía las peticiones de proxy HTTP al puente, y el puente abre las conexiones de destino a través del servicio SOCKS.

Privoxy documenta esta disposición mediante sus reglas de reenvío. Para un túnel SOCKS5 local existente, un fragmento de configuración es:

forward-socks5 / 127.0.0.1:1080 .

La aplicación se conecta al oyente HTTP de Privoxy, no al puerto 1080. Mantén ese oyente local según la política de acceso prevista. El punto final de la regla tiene un significado documentado; no es un marcador para un nombre de host de internet ausente.

Esto es traducción de protocolo

La documentación de reenvío de Privoxy explica la sintaxis del reenvío SOCKS y el manejo de nombres de host. Un reenvío de puerto TCP simple no realiza la misma traducción: transporta los bytes HTTP del cliente sin cambios a un oyente SOCKS, que sigue esperando una negociación SOCKS.

El puente también pasa a formar parte de la configuración que hay que entender. Privoxy puede tener sus propios ajustes de filtrado de contenido y de acceso. Añadirlo no es lo mismo que hacer que la aplicación original admita SOCKS de forma nativa.

Para los sitios HTTPS, la aplicación suele pedir CONNECT al puente HTTP, y el puente obtiene la conexión de destino a través de SOCKS. El TLS normal del sitio sigue siendo una relación entre aplicación y sitio; el puente no necesita suplantar al sitio para ofrecer esta ruta.

Si la aplicación puede usar SOCKS directamente, el componente adicional puede ser innecesario. Usa el puente para resolver un desajuste real de protocolo, con el oyente y el origen claramente diferenciados.