透過的な TCP から SOCKS への転送における元の宛先

ファイアウォールは TCP 接続の到達先を変えることができます。しかし、その変更だけでは、送信元のアプリケーションに SOCKS を話させることはできません。

通常の SOCKS サーバーは、要求された宛先を記述するネゴシエーションを待ちます。プロキシを知らないアプリケーションは、代わりに自分のプロトコルバイトを直ちに送り出します。そのバイトをそのまま SOCKS リスナーへリダイレクトすると、双方は最初のメッセージについて食い違います。

欠けている部品は翻訳コンポーネントです

透過的な TCP からプロキシへの部品は、そのインターフェースの間に位置します。アプリケーションが当初要求した宛先を突き止め、適切な SOCKS または HTTP CONNECT セッションを確立し、その後にアプリケーションのデータを出来上がったストリーム上で中継します。

Linux iptables の経路では、redsocks のソースが保存された宛先を SO_ORIGINAL_DST を使って取得します。他のオペレーティングシステムやリダイレクト方式は別の仕組みを使います。これはリダイレクターとネットワーク設定の性質であり、通常の SOCKS クライアントの機能ではありません。

元の宛先の情報は、リダイレクト規則をプロキシホストから無関係なゲートウェイへ移すことが常に等価ではない理由も説明します。受信側のプロセスは、その傍受方式が要求するメタデータを必要とします。別の場所で書き換えられたアドレスは、もはやその情報を期待される形で提供しないかもしれません。

翻訳コンポーネントの範囲を明示しておいてください。動作するリダイレクト済みの TCP 接続は、任意の UDP、ICMP、またはあらゆるリゾルバー経路への対応を証明するものではありません。上流プロキシのプロトコルと翻訳コンポーネントの実装が、対応する操作を依然として定めます。

接続直後に構成が失敗する場合は、アクセス規則を広げる前にプロトコルの境界を確認してください。完全に到達可能な SOCKS リスナーでも、SOCKS 要求でなかったバイトを拒否することがあります。