Privoxy: HTTP プロキシクライアントを SOCKS トンネルに接続する

SSH ダイナミックトンネルは、PuTTY のダイナミックフォワードを含め、SOCKS インターフェースを提供します。HTTP プロキシしか受け付けないアプリケーションは、そのポートを HTTP と呼ぶだけでは使えません。

両者の間にローカルのプロトコルブリッジを置けます。アプリケーションは HTTP プロキシ要求をブリッジへ送り、ブリッジは SOCKS サービス経由で宛先への接続を開きます。

Privoxy はこの構成をフォワーディングルールで文書化しています。既存のローカル SOCKS5 トンネルなら、設定の断片は次のとおりです。

forward-socks5 / 127.0.0.1:1080 .

アプリケーションが接続するのは Privoxy の HTTP リスナーであり、ポート 1080 ではありません。そのリスナーは想定したアクセス方針のもとでローカルに保ってください。ルール末尾のドットには文書化された意味があり、欠けたインターネットホスト名のプレースホルダーではありません。

これはプロトコルの翻訳です

Privoxy のフォワーディング文書は SOCKS フォワーディングの構文とホスト名の扱いを説明しています。単純な TCP ポートフォワードは同じ翻訳を行いません。クライアントの HTTP バイトをそのまま SOCKS リスナーへ運びますが、そのリスナーは依然として SOCKS ネゴシエーションを期待します。

ブリッジは、理解すべき設定の一部にもなります。Privoxy には独自のコンテンツフィルタリングやアクセスの設定があり得ます。それを追加することは、元のアプリケーションが SOCKS をネイティブにサポートするのとは同じではありません。

HTTPS サイトでは、アプリケーションは通常 HTTP ブリッジに CONNECT を要求し、ブリッジは SOCKS 経由で宛先接続を取得します。通常のサイト TLS はアプリケーションとサイトの関係のままであり、ブリッジがこの経路を提供するためにサイトを装う必要はありません。

アプリケーションが SOCKS を直接使えるなら、追加の構成要素は不要かもしれません。ブリッジは実際のプロトコルの不一致を解消するために使い、リスナーと上流を明確に区別してください。