Privoxy: lidhja e një klienti proxy HTTP me një tunel SOCKS
Lidhni një klient proxy që pranon vetëm HTTP me një tunel SOCKS përmes një proxy HTTP lokal, në vend që të riemërtoni portën e tunelit.
Një tunel dinamik SSH, duke përfshirë përcjelljen dinamike të PuTTY, ofron një ndërfaqe SOCKS. Një aplikacion që pranon vetëm proxy HTTP nuk mund ta përdorë atë portë thjesht duke e quajtur HTTP.
Një urë protokolli lokale mund të qëndrojë midis tyre. Aplikacioni i dërgon kërkesat proxy HTTP urës, dhe ura hap lidhjet e destinacionit përmes shërbimit SOCKS.
Privoxy e dokumenton këtë rregullim përmes rregullave të tij të përcjelljes. Për një tunel SOCKS5 lokal ekzistues, një fragment konfigurimi është:
forward-socks5 / 127.0.0.1:1080 .
Aplikacioni lidhet me dëgjuesin HTTP të Privoxy, jo me portën 1080. Mbajeni atë dëgjues lokal sipas politikës së synuar të aksesit. Pika e fundit në rregull ka një kuptim të dokumentuar; nuk është një zëvendësues për një emër host interneti që mungon.
Kjo është përkthim protokolli
Dokumentacioni i përcjelljes i Privoxy shpjegon sintaksën e përcjelljes SOCKS dhe trajtimin e emrave të hosteve. Një përcjellje e thjeshtë e portës TCP nuk kryen të njëjtin përkthim: transporton bajtët HTTP të klientit pa ndryshim drejt një dëgjuesi SOCKS, i cili ende pret një negocim SOCKS.
Ura bëhet gjithashtu pjesë e konfigurimit që duhet të kuptoni. Privoxy mund të ketë cilësimet e veta të filtrimit të përmbajtjes dhe të aksesit. Shtimi i saj nuk është e njëjta gjë me mbështetjen autoktone të SOCKS nga aplikacioni origjinal.
Për faqet HTTPS, aplikacioni zakonisht kërkon CONNECT nga ura HTTP, dhe ura e merr lidhjen e destinacionit përmes SOCKS. TLS normal i faqes mbetet një marrëdhënie aplikacion-faqe; ura nuk ka nevojë të shtiret si faqja për të ofruar këtë rrugë.
Nëse aplikacioni mund të përdorë SOCKS drejtpërdrejt, komponenti shtesë mund të jetë i panevojshëm. Përdorni urën për të zgjidhur një mospërputhje reale protokolli, me dëgjuesin dhe rrjedhën e sipërme të dalluara qartë.