3proxy で SOCKS クライアントを HTTP CONNECT 親にブリッジする

HTTP CONNECT 親を背後に置く SOCKS 側ゲートウェイと、各ホップでのプロトコルと認証の要件を説明します。

アプリケーションは SOCKS を必要としています。承認済みの上流サービスは HTTP CONNECT を受け付けます。HTTP エンドポイントをアプリケーションの SOCKS 欄に入れても、プロトコル間の変換は行われません。

ゲートウェイはアプリケーションから SOCKS を受け取り、要求された宛先を読み取り、その宛先への CONNECT トンネルを HTTP 親に要求できます。その後、アプリケーションのストリームをトンネル経由で中継します。

SOCKS application → SOCKS-facing gateway → HTTP CONNECT parent → destination

各インターフェースを明示する

この構成を支えるゲートウェイでは、親の種類が重要です。3proxy のドキュメントは connect 親と、通常の HTTP 転送プロキシとして使う親を区別しています。

既存の 3proxy ユーザーと認証設定がある場合、ローカル専用のルーティング断片は次の形になります。

auth strong
allow alex
parent 1000 connect parent.example.net 8080
socks -i127.0.0.1 -p1080

この断片はアカウントが既に定義済みであることを前提とします。HTTP 親自体が要求する資格情報を追加するものではなく、既存のアクセス ポリシーを置き換えるものでもありません。認証なしの公開 HTTP 親を許す経路上の公開宛先には、HTTP プロキシ一覧がホストとポートの候補を提供します。その分岐では親の資格情報を入れず、実際のターゲットに対する許可を確認してください。ゲートウェイ自身のアカウントはローカルのままです。parent ルールは、3proxy の文書化された設定モデルに従い、直前の allow ルールに関連付けられます。

アプリケーションはローカルの SOCKS エンドポイントを使います。ゲートウェイは親に対して HTTP CONNECT を使います。要求された宛先ホストとポートが許可されるかどうかは、依然として親が決めます。

ここで有用な範囲は通常の TCP ストリームのトンネリングです。フロントのリスナーが SOCKS5 を受け付けるからといって、SOCKS5 の UDP アソシエーションが使えるようになるわけではありません。HTTP CONNECT 親は必要な UDP リレーを自動的に提供しません。

HTTPS はこの経路の中でエンドツーエンドのまま保てます。プロキシ インターフェース間の変換は宛先 Web サイトになりすますことを必要としません。ゲートウェイへの認証、親への認証、Web サイトの認証は、それぞれ別の資格情報とやり取りのままです。

関連記事