Privoxy: pontigi HTTP-proksan klienton al SOCKS-tunelo
Pontigu proksan klienton, kiu akceptas nur HTTP, al SOCKS-tunelo per loka HTTP-prokso anstataŭ renomi la tunelan pordon.
Dinamika SSH-tunelo, inkluzive de la dinamika plusendo de PuTTY, provizas SOCKS-interfacon. Aplikaĵo, kiu akceptas nur HTTP-prokson, ne povas uzi tiun pordon simple nomante ĝin HTTP.
Loka protokola ponto povas sidi inter ili. La aplikaĵo sendas HTTP-proksajn petojn al la ponto, kaj la ponto malfermas celajn konektojn per la SOCKS-servo.
Privoxy dokumentas ĉi tiun aranĝon per siaj plusendaj reguloj. Por ekzistanta loka SOCKS5-tunelo, konfigurapeco estas:
forward-socks5 / 127.0.0.1:1080 .La aplikaĵo konektiĝas al la HTTP-aŭskultanto de Privoxy, ne al pordo 1080. Tenu tiun aŭskultanton loka laŭ la celita alirpolitiko. La fina punkto en la regulo havas dokumentitan signifon; ĝi ne estas lokokupilo por mankanta interreta gastnomo.
Ĉi tio estas protokola traduko
La plusenda dokumentaro de Privoxy klarigas la sintakson de SOCKS-plusendo kaj la traktadon de gastnomoj. Ordinara TCP-porda plusendo ne faras la saman tradukon: ĝi transportas la HTTP-bajtojn de la kliento senŝanĝe al SOCKS-aŭskultanto, kiu ankoraŭ atendas SOCKS-intertraktadon.
La ponto ankaŭ fariĝas parto de la agordo, kiun vi devas kompreni. Privoxy povas havi proprajn agordojn pri enhavfiltrado kaj aliro. Aldoni ĝin ne samas kiel igi la originan aplikaĵon native subteni SOCKS.
Por HTTPS-retejoj, la aplikaĵo kutime petas CONNECT de la HTTP-ponto, kaj la ponto akiras la celan konekton per SOCKS. Normala reteja TLS restas rilato inter aplikaĵo kaj retejo; la ponto ne bezonas imiti la retejon por provizi ĉi tiun vojon.
Se la aplikaĵo povas uzi SOCKS rekte, la plia komponanto eble estas nenecesa. Uzu la ponton por solvi realan protokolan malkongruon, kun la aŭskultanto kaj la supra fluo klare apartigitaj.