Privoxy: connecta un client de proxy HTTP a un túnel SOCKS
Connecta un client de proxy que només accepta HTTP a un túnel SOCKS amb un proxy HTTP local, en lloc de reetiquetar el port del túnel.
Un túnel SSH dinàmic, inclòs el reenviament dinàmic de PuTTY, ofereix una interfície SOCKS. Una aplicació que només accepta un proxy HTTP no pot fer servir aquell port només perquè l'anomeni HTTP.
Un pont de protocol local pot seure entre tots dos. L'aplicació envia les peticions de proxy HTTP al pont, i el pont obre les connexions de destinació a través del servei SOCKS.
Privoxy documenta aquesta disposició a les seves regles de reenviament. Per a un túnel SOCKS5 local existent, un fragment de configuració és:
forward-socks5 / 127.0.0.1:1080 .L'aplicació es connecta a l'oïdor HTTP de Privoxy, no al port 1080. Mantingueu aquest oïdor local sota la política d'accés prevista. El punt final de la regla té un significat documentat; no és un marcador per a un nom d'amfitrió d'internet absent.
Això és traducció de protocol
La documentació de reenviament de Privoxy explica la sintaxi del reenviament SOCKS i el tractament dels noms d'amfitrió. Un reenviament de port TCP simple no fa la mateixa traducció: transporta els bytes HTTP del client sense canvis a un oïdor SOCKS, que encara espera una negociació SOCKS.
El pont també passa a formar part de la configuració que cal entendre. Privoxy pot tenir els seus propis paràmetres de filtratge de contingut i d'accés. Afegir-lo no és el mateix que fer que l'aplicació original admeti SOCKS de manera nativa.
Per als llocs HTTPS, l'aplicació normalment demana CONNECT al pont HTTP, i el pont obté la connexió de destinació a través de SOCKS. El TLS habitual del lloc continua sent una relació entre aplicació i lloc; el pont no necessita suplantar el lloc per oferir aquest camí.
Si l'aplicació pot fer servir SOCKS directament, el component extra pot ser innecessari. Feu servir el pont per resoldre un desajust real de protocol, amb l'oïdor i l'origen clarament distingits.