SSH 経由で既存の HTTP または SOCKS プロキシに到達する
リモートの loopback HTTP または SOCKS プロキシに、そのリスナーを公開せず SSH 経由で到達します。
relay.example.net がすでに自身の 127.0.0.1:1080 で SOCKS を実行している場合は、そのリスナーを公開するのではなく、アクセスを転送します:
ssh -N -L 127.0.0.1:1081:127.0.0.1:1080 [email protected]| エンドポイント | 役割 |
|---|---|
ノート PC 127.0.0.1:1081 | ノート PC のアプリケーションで設定する SOCKS アドレス。 |
リレー 127.0.0.1:1080 | SSH サーバー側から到達する既存のプロキシ。 |
ローカル転送の構文は、固定の宛先をサーバー側に割り当てます。リモートの loopback ポート 3128 の HTTP プロキシや、proxy.internal.example:8080 のようなイントラネットのエンドポイントも同じ原理で動作します。クライアントをその既存の HTTP プロトコルとアカウントに合わせて設定してください。SSH を通して運んでも、SOCKS や TLS 対応の HTTPS リスナーが作られるわけではありません。
既存のサービスは引き続き、対応するプロトコルバージョン、認証、宛先、最終的な出口を選びます。別の SSH プロセスがそのリモートプロキシを作成した場合、両方のプロセスが稼働し続ける必要があります。ノート PC→リレー→ゲートウェイの経路では、ウェブサイトには最後の外向き接続が見え、ローカルポート 1081 が割り当てた識別情報は見えません。
ノート PC のバインドは明示的にローカルに保ちます。公開範囲を広げるとサービスに到達できる相手が変わり、SSH ログインはリスナーに SOCKS パスワードを追加しません。拒否された場合は、ノート PC のリスナー、SSH トランスポート、リモートプロキシを別々の段階として確認してください。