Windows portproxy による固定宛先への TCP リレー
portproxy ルールはリスナーを固定の宛先へ転送します。プロキシ対応クライアントが期待する SOCKS や HTTP CONNECT のネゴシエーションは追加しません。
Windows の portproxy ルールは、TCP を 1 つの設定済み宛先へリレーします。ブラウザーの HTTP プロキシー要求や SOCKS の宛先要求をネゴシエーションすることはありません。
| サービス | 宛先を選ぶのは誰か |
|---|---|
| 固定 TCP リレー | リスナーの転送設定。 |
| SOCKS5 プロキシー | サーバーポリシーの範囲内でのクライアント要求。 |
| HTTP フォワードプロキシー | 一般的な HTTPS トンネリング用の CONNECT を含む HTTP プロキシー要求。 |
netsh interface portproxy show all で既存のリレーを確認します。設定済みのバックエンドと、クライアントが送るプロトコルを比較してください。netsh リファレンス はリスナーと宛先のアドレス/ポートを説明します。TCP を受け入れることは、HTTP や SOCKS のハンドシェイクを確立することにはなりません。
通常のリレーに送られた SOCKS ネゴシエーションは、その固定バックエンドに届くだけです。SOCKS でないサービスに要求を理解させたり、新しいターゲットを選ばせたりすることはできません。
実際のプロキシーの前にあるリレーは別です。上流のプロキシーは依然として宛先と認証をネゴシエーションし、リレーはそのプロキシーへの接続を運びます。ネットワークに公開されたリレーはそのバックエンドへのアクセスを広げる可能性があるため、リスナーのアクセス境界を意図的に保ってください。
要件が一般的な HTTP または SOCKS の出口である場合は、プロトコルに対応したサービスを選んでください。転送されたポートはその経路の一部にすぎません。