Privoxy: conectarea unui client proxy HTTP la un tunel SOCKS
Conectați un client proxy care acceptă doar HTTP la un tunel SOCKS printr-un proxy HTTP local, în loc să redenumiți portul tunelului.
Un tunel SSH dinamic, inclusiv redirecționarea dinamică din PuTTY, oferă o interfață SOCKS. O aplicație care acceptă doar un proxy HTTP nu poate folosi acel port doar numindu-l HTTP.
O punte de protocol locală poate sta între ele. Aplicația trimite cererile proxy HTTP către punte, iar puntea deschide conexiunile către destinație prin serviciul SOCKS.
Privoxy documentează această aranjare prin regulile sale de redirecționare. Pentru un tunel SOCKS5 local existent, un fragment de configurare este:
forward-socks5 / 127.0.0.1:1080 .Aplicația se conectează la ascultătorul HTTP al Privoxy, nu la portul 1080. Păstrați acel ascultător local conform politicii de acces prevăzute. Punctul final din regulă are o semnificație documentată; nu este un substituent pentru un nume de gazdă de internet lipsă.
Aceasta este traducere de protocol
Documentația de redirecționare a Privoxy explică sintaxa redirecționării SOCKS și tratarea numelor de gazdă. O simplă redirecționare de port TCP nu face aceeași traducere: transportă octeții HTTP ai clientului neschimbați către un ascultător SOCKS, care încă așteaptă o negociere SOCKS.
Puntea devine și ea parte din configurația pe care trebuie să o înțelegeți. Privoxy poate avea propriile setări de filtrare a conținutului și de acces. Adăugarea ei nu este același lucru cu a face aplicația originală să accepte SOCKS nativ.
Pentru site-urile HTTPS, aplicația cere de obicei CONNECT de la puntea HTTP, iar puntea obține conexiunea de destinație prin SOCKS. TLS-ul normal al site-ului rămâne o relație între aplicație și site; puntea nu trebuie să se dea drept site pentru a oferi această cale.
Dacă aplicația poate folosi SOCKS direct, componenta suplimentară poate fi inutilă. Folosiți puntea pentru a rezolva o nepotrivire reală de protocol, cu ascultătorul și partea superioară clar separate.