Privoxy: подключение HTTP-прокси-клиента к туннелю SOCKS

Динамический SSH-туннель, включая динамическую переадресацию PuTTY, предоставляет интерфейс SOCKS. Приложение, принимающее только HTTP-прокси, не может использовать этот порт, просто назвав его HTTP.

Между ними может находиться локальный мост протокола. Приложение отправляет HTTP-прокси-запросы мосту, а мост открывает соединения с пунктом назначения через службу SOCKS.

Privoxy документирует такую схему в своих правилах переадресации. Для существующего локального туннеля SOCKS5 фрагмент конфигурации таков:

forward-socks5 / 127.0.0.1:1080 .

Приложение подключается к HTTP-прослушивателю Privoxy, а не к порту 1080. Держите этот прослушиватель локальным в соответствии с предполагаемой политикой доступа. Завершающая точка в правиле имеет документированное значение; это не заполнитель для отсутствующего имени интернет-хоста.

Это трансляция протокола

Документация Privoxy по переадресации объясняет синтаксис переадресации SOCKS и обработку имён хостов. Обычная переадресация TCP-порта не выполняет такой же трансляции: она передаёт HTTP-байты клиента без изменений прослушивателю SOCKS, который по-прежнему ожидает согласование SOCKS.

Мост также становится частью конфигурации, которую нужно понимать. У Privoxy могут быть собственные настройки фильтрации содержимого и доступа. Его добавление — не то же самое, что встроенная поддержка SOCKS в исходном приложении.

Для сайтов HTTPS приложение обычно запрашивает CONNECT у HTTP-моста, а мост получает соединение с пунктом назначения через SOCKS. Обычный TLS сайта остаётся отношением между приложением и сайтом; мосту не нужно выдавать себя за сайт, чтобы предоставить этот путь.

Если приложение умеет использовать SOCKS напрямую, дополнительный компонент может быть не нужен. Используйте мост для устранения реального несоответствия протоколов, чётко различая прослушиватель и вышестоящее звено.