Privoxy: verbind 'n HTTP-proksie-kliënt met 'n SOCKS-tonnel
Verbind 'n proksie-kliënt wat slegs HTTP aanvaar met 'n SOCKS-tonnel deur 'n plaaslike HTTP-proksie, eerder as om die tonnelpoort te heretiketteer.
'n SSH-dinamiese tonnel, insluitend PuTTY se dinamiese aanstuur, bied 'n SOCKS-koppelvlak. 'n Toepassing wat slegs 'n HTTP-proksie aanvaar, kan nie daardie poort gebruik bloot deur dit HTTP te noem nie.
'n Plaaslike protokolbrug kan tussen hulle sit. Die toepassing stuur HTTP-proksieversoeke na die brug, en die brug maak bestemmingsverbindings deur die SOCKS-diens oop.
Privoxy dokumenteer hierdie reëling deur sy aanstuurreeks. Vir 'n bestaande plaaslike SOCKS5-tonnel is 'n konfigurasiefragment:
forward-socks5 / 127.0.0.1:1080 .Die toepassing verbind met Privoxy se HTTP-luisteraar, nie poort 1080 nie. Hou daardie luisteraar plaaslik onder die beoogde toegangsbeleid. Die laaste punt in die reël het 'n gedokumenteerde betekenis; dit is nie 'n plekhouer vir 'n ontbrekende internet-gasheernaam nie.
Dit is protokolvertaling
Die Privoxy-aanstuur dokumentasie verduidelik SOCKS-aanstuur-sintaksis en gasheernaamhantering. 'n Gewone TCP-poortaanstuur doen nie dieselfde vertaling nie: dit vervoer die kliënt se HTTP-bytes onveranderd na 'n SOCKS-luisteraar, wat steeds 'n SOCKS-onderhandeling verwag.
Die brug word ook deel van die konfigurasie wat jy moet verstaan. Privoxy kan sy eie inhoudfiltreer- en toeganginstellings hê. Om dit by te voeg is nie dieselfde as om die oorspronklike toepassing inheems SOCKS te laat ondersteun nie.
Vir HTTPS-webwerwe vra die toepassing gewoonlik die HTTP-brug om CONNECT, en die brug verkry die bestemmingsverbinding deur SOCKS. Normale webwerf-TLS bly 'n verhouding tussen toepassing en webwerf; die brug hoef nie die webwerf na te boots om hierdie pad te bied nie.
As die toepassing SOCKS direk kan gebruik, is die ekstra komponent dalk onnodig. Gebruik die brug om 'n werklike protokolverskil op te los, met die luisteraar en die opstroom duidelik onderskei.