Privoxy: połączenie klienta proxy HTTP z tunelem SOCKS
Połącz klienta proxy akceptującego tylko HTTP z tunelem SOCKS przez lokalne proxy HTTP, zamiast zmieniać nazwę portu tunelu.
Dynamiczny tunel SSH, w tym dynamiczne przekierowanie PuTTY, udostępnia interfejs SOCKS. Aplikacja akceptująca tylko proxy HTTP nie może użyć tego portu tylko dlatego, że nazwie go HTTP.
Między nimi może znajdować się lokalny mostek protokołu. Aplikacja wysyła żądania proxy HTTP do mostka, a mostek otwiera połączenia docelowe przez usługę SOCKS.
Privoxy dokumentuje taki układ w swoich regułach przekazywania. Dla istniejącego lokalnego tunelu SOCKS5 fragment konfiguracji to:
forward-socks5 / 127.0.0.1:1080 .Aplikacja łączy się z nasłuchiwaczem HTTP Privoxy, a nie z portem 1080. Trzymaj ten nasłuchiwacz lokalnie zgodnie z zamierzoną polityką dostępu. Końcowa kropka w regule ma udokumentowane znaczenie; nie jest zastępnikiem brakującej nazwy hosta internetowego.
To jest tłumaczenie protokołu
Dokumentacja przekazywania Privoxy wyjaśnia składnię przekazywania SOCKS i obsługę nazw hostów. Zwykłe przekierowanie portu TCP nie wykonuje tego samego tłumaczenia: przenosi bajty HTTP klienta bez zmian do nasłuchiwacza SOCKS, który nadal oczekuje negocjacji SOCKS.
Mostek staje się też częścią konfiguracji, którą trzeba rozumieć. Privoxy może mieć własne ustawienia filtrowania treści i dostępu. Dodanie go nie jest tym samym, co natywne wsparcie SOCKS w pierwotnej aplikacji.
W przypadku witryn HTTPS aplikacja zwykle prosi mostek HTTP o CONNECT, a mostek uzyskuje połączenie docelowe przez SOCKS. Zwykły TLS witryny pozostaje relacją aplikacja-witryna; mostek nie musi podszywać się pod witrynę, aby zapewnić tę ścieżkę.
Jeśli aplikacja może używać SOCKS bezpośrednio, dodatkowy komponent może być zbędny. Użyj mostka, aby rozwiązać rzeczywistą niezgodność protokołów, z wyraźnie rozdzielonym nasłuchiwaczem i stroną nadrzędną.