☰

SSH動的ポート転送でSOCKSプロトコルを使用する方法は？ [コピー]

tag-icon • tag-icon ssh proxy port-forwarding
SSH動的ポート転送でSOCKSプロトコルを使用する方法は？ [コピー]

  1. SSH動的ポート転送を介してアプリケーションクライアントとアプリケーションサーバー間の接続を作成するときにssh -DSOCKSプロトコルはどのように使用されますか？ SOCKSを通信プロトコルとして使用するかどうか

    • アプリケーションクライアントとSSHクライアント間
    • または、SSH クライアントと SSH サーバー間、
    • それともSSHサーバーとアプリケーションサーバーの間にありますか？

  2. アプリケーションクライアントがSSHダイナミックポート転送を介してアプリケーションサーバーに接続すると、SSHクライアントとサーバーは通常「邪魔になります」。これは、SSHプロトコルが使用されなくなったことを意味しますか？ SOCKSやSSHなど、どのプロトコルがまだ使用されていますか？アプリケーションクライアントとアプリケーションサーバー間の通信はまだSSHプロトコル内にカプセル化され保護されていますか？

ありがとうございます。

答え1

SSHプロトコル単一のTCP接続を介して複数の独立したデータストリームを多重化できます。各データストリームは次のように呼び出されます。チャンネル。 TCP接続を介して送信されるすべてのデータは暗号化されます。送信者は、さまざまなチャネルのデータを単一のデータストリームに集約してから暗号化します。受信者はデータを復号化し、集約されたデータストリームをそのチャネルに戻します。

ポート転送の場合、SSH クライアントは TCP 接続を使用して TCP 経由でリモート SSH サーバーに接続します。SSHプロトコル。一般的なクライアント - >サーバー転送シナリオでは、SSHクライアントはTCP接続のためにポートでもリッスンします。このポートへの接続はサーバーによって宛先に転送されます。

「イニシエータ」（別名「アプリケーションクライアント」）がSSHクライアントのリスンポートに接続されると、SSHクライアントはサーバにチャネルオープン要求を送信します。「direct-tcpip」チャンネルリクエスト。この要求のパラメータには、チャネルを接続する必要があるホスト名/ IPアドレスとポートが含まれます。 SSHサーバーは、指定されたホストとポートへの別のTCP接続を確立し、これを「ターゲット」と呼びます。今、3つのTCP接続があります。

  1. イニシエータとSSHクライアント間
  2. SSHクライアントとSSHサーバー間
  3. SSHサーバーと転送先の間

SSH クライアントとサーバーは、SSH 接続を介してイニシエーターとターゲットの間の双方向にデータを中継します。

したがって、イニシエータから接続を転送するときに、SSHクライアントはSSHサーバーに接続が転送されるべき場所を知らなければなりません。sshポートを転送するためにコマンドラインオプションを使用して実行する場合、たとえば、次のようになります。

ssh -L 1234:example.com:2345 ...

接続を渡す場所に関する情報は、コマンドラインパラメータから取得されます。sshポート 1234 への接続は example.com ポート 2345 に転送されます。

sshたとえば、SOCKSサーバーを実行するためのオプションで呼び出された場合：

ssh -D 1234

その後、SOCKSポートに接続する各イニシエータは、まず接続するホストとポートを指定するSOCKSプロトコルメッセージを送信する必要があります。sshdirect-tcpip チャネルオープン要求は、SOCKS メッセージの情報を使用して構成されます。

答え2

SSHクライアントとサーバーの「妨害」は、動的ポート転送を説明する非常に悪い方法であり、おそらく一部の作成者が特定の環境で学んだかもしれない不器用な説明や過度に単純な説明を繰り返した結果でしょう。小さい。

他の人が説明したように、SOCKSは互換性のあるTCPプロキシに接続がどこに行くべきかを示す標準化された方法として使用されます。本質的には、SOCKSプロトコルは、古い電話を使用するのと同じです。 「交換員様、市内電話番号Yにつながってください。相手とどんな言語でも通話したいです。

SSH動的転送では、アプリケーションクライアントは動的に転送されたポート（SOCKSサーバーポート）へのTCP接続を開き、特定のIPアドレスとポートに接続するための標準SOCKS要求を送信し、ローカルで使用されたプロトコルを使用して再起動できます。 。そのTCP接続を介して。最初のSOCKS要求を行うことができるはずですが、もはや情報を知る必要はありません。 （接続の最後にいくつかのSOCKS関連があるかもしれませんが、そうでない場合、転送された接続はエンドポイントに対して完全に透過的でプロトコル中立です。）

もう一方の端にあるアプリケーションサーバーは、SSHサーバー上の既存のTCP接続のみを表示できます。接続が転送されていることを知る必要もなく、クライアントがSOCKSプロトコルに関連付けられていることも知る必要はありません。

（電話が鳴って応答すると、電話が有線ネットワークに出る回線と完全な機能を備えた手動電話交換機能を備えた技術博物館から着信している場合でも、特別な措置を講じる必要はありません。）

したがって、厳密なクライアント/サーバー側で動的配信機能が有効になっている場合SSHクライアント役割も果たします。ソックスサーバーSOCKSサーバーを使用するすべての接続は、暗号化されたSSHトンネル内でリモートで転送されるという特定の追加の属性があります。SSHサーバーそこから通常のTCP接続に戻ります。

つまり、動的転送が有効なSSHクライアント+ SSH接続+ SSHサーバーの組み合わせは、SOCKSプロキシのインバウンド側が配置されるようにSSH接続がカバーする距離まで拡張されたSOCKSプロキシとして機能します。 SSHクライアントと同じ距離内の同じ場所で、アウトバウンドエンドはSSHサーバーにあり、その間に何が起こっているのかは、外部の観察者には説明のない暗号化SSHトラフィックのように見えます。

気づくSSHクライアントとSSHサーバー間のホップだけがSSHで保護されています。ただし、アプリケーションクライアントとSSHクライアント/ SOCKSサーバー間のホップは通常、単一のホスト内で行われます。暗号化できない唯一の残りの部分は、（アプリケーションプロトコルに独自の暗号化が含まれていない場合）、SSHサーバーとアプリケーションサーバー間のホップです。

答え3

SOCKSプロトコルは使用されますか？

クライアント（Webブラウザ）はSSHサーバーと通信します（Sshクライアント経由）。

アプリケーションクライアントとアプリケーションサーバー間の通信はまだSSHプロトコル内にカプセル化され保護されていますか？

はい。

参考資料

関連情報